How HVAC Shops Trigger Housecall Pro Review Requests After Completed Jobs

For an HVAC review workflow, the trigger matters more than the message template. If GoHighLevel (GHL) starts from the wrong Housecall Pro event, the office can end up asking for a review based on a payment event even when the job is later canceled or refunded.

The practical setup is straightforward: trigger on Job Completed, pass the job date into GHL’s Last Job Date field, then wait a day or two before sending the request. Here’s what to verify—and what not to assume—when you build it.

Use Job Completed, Not Job Paid, As The Trigger

Choose Housecall Pro’s Job Completed event for the review-request webhook; don’t use Job Paid as a substitute for job completion. A payment can be recorded before later changes to a job make that payment event a poor reason to ask for a review.

In the HVAC setup we reviewed, Job Paid had been used previously. That caused problems when a job was later canceled or a refund was issued. The revised choice was Job Completed, because it avoids starting the review workflow from a job that is rescheduled, updated, canceled, or deleted.

That is the operational reason for choosing this event—not a claim that a completed job can never change afterward. Keep Housecall Pro as the source of truth for the job, and make sure the event you select matches the moment your office considers the service ready for a review request.

Confirm The Housecall Pro Plan Before Building

Housecall Pro MAX is required for the webhooks and API integrations used in this setup. Check the account plan before spending time configuring the connection; the integration depends on those capabilities being available.

The implementation described here passes the job event into GHL without a third-party integration service. That avoids adding another service to the path. It doesn’t mean every account has identical screens or configuration options, so verify the available webhook and API settings in the actual Housecall Pro and GHL accounts rather than copying an assumed menu path.

Before enabling a live workflow, confirm the intended event is Job Completed and that the destination is the correct GHL account. The specific step-by-step screen settings and a separate test procedure weren’t confirmed for this setup, so don’t treat those details as universal instructions.

Map The Job Date And Add A Short Wait

Map the Housecall Pro job date to GHL’s Last Job Date field, then place a one- or two-day wait before the review request. The date gives GHL a usable record of when the latest job occurred, while the wait keeps the request from going out immediately after the completion event.

A simple workflow outline is:

1. Receive the Housecall Pro Job Completed event.
2. Map the job date to GHL’s Last Job Date field.
3. Wait a day or two.
4. Send the review request.

The confirmed implementation doesn’t specify other required fields, exact GHL condition branches, or a particular message template. Don’t add guessed requirements and present them as part of the proven setup. If your account needs extra routing or eligibility rules, document and test those separately.

Keep Estimates Out Of This Review Workflow

An estimate should not start the review-request workflow; the trigger should be Job Completed. That single decision keeps a prospect or an uncompleted service call from entering a workflow intended for completed work.

The workflow is not a general follow-up for every Housecall Pro status. Its job is narrow: wait for the chosen completion event, record the job date, pause, and request a review. Sending a request to a repeat customer is acceptable, according to the implementation details we received; repeat status alone isn’t a reason to block the request.

The interview did not establish duplicate-contact handling or how to suppress a request after a separate complaint, callback, or other customer-service issue. Don’t assume those controls are included just because the completion trigger is correct. If your office needs them, define those rules and verify how they interact with the workflow before launch.

Check The Event And Field Mapping Before Relying On It

Verify that a completed test job reaches the intended GHL workflow and updates Last Job Date before relying on live review requests. The known failure was a trigger choice—Job Paid instead of Job Completed—so start your review with the event and date mapping, not just the text message.

A practical office-side check is to confirm the Housecall Pro plan supports the integration, confirm the selected trigger reads Job Completed, and inspect whether the job date appears in the correct GHL field. Then verify the configured wait before a request is sent. The operator’s account of this setup did not include a measured before-and-after result or a detailed test protocol, so we won’t claim a specific increase in reviews or a guaranteed error rate.

If you’re documenting the flow for the office, write down the exact event name, destination field, wait length, and who owns monitoring. That makes it easier to catch a change if the source software or account configuration is updated.

Housecall Pro review automation works best when the trigger reflects completed service—not merely a payment—and the date mapping and delay are explicit. If you’d rather have the integration and workflow managed alongside your other HVAC follow-up, talk with our team. See our Housecall Pro integration overview and HVAC GoHighLevel support for related details.