Multi-location home services · the ask that ignores the complaint

A customer complained about the job on Monday. Your review request went out Wednesday anyway.

Review requests fire on a job-closed event, same as this site already argues they should. What they rarely check is whether a complaint about that exact job already exists in a different system — so the automated ask goes out to a customer who just complained.

The desire, and the check that never runs before sending

Nobody searching “customer complaint software” wants a ticket log. They want a complaint to actually stop the next automated message from going out, not sit in a separate system the review-request tool never looks at.

1. 1. The trigger — job closed, request scheduled. Review-request automation fires reliably on a job-closed event. This is the well-known half, and the reason it usually works.
2. 2. The gap — the complaint record lives elsewhere. A complaint logged in a support inbox, a CRM ticket, or a manager’s note sits in a system the review-request tool was never wired to check before sending.
3. 3. The close — gate the send on the complaint record. An open or recent complaint for that job holds the review-request and routes to service recovery instead — the ask resumes only once the complaint is resolved.

This is the negative-signal counterpart to /customer-advocacy-software’s positive-signal timing — the same principle, read in the opposite direction.

Which platform this runs on

• Reputation management software, by scale — the platform whose send should gate on the complaint record.
• Reputation management software: one signal, two AI jobs — the same platform, a different unread signal.
• Dispatch software: the job-closed event nobody wired together — the same trigger event, a different downstream system reading it.

Some links on the recommendation page are partner links: the vendor pays us if you sign up, your price does not change, and each button says which.

How to build it yourself, end to end

Five steps. Each names the vendor touchpoint from the picks above.

1. 1. Log complaints against the job record, not a free-form inbox. A complaint needs to attach to the same job ID the review-request trigger reads, or the two systems have nothing to match on.
2. 2. Check for an open complaint before the review-request fires. A single lookup against the complaint record, run at the moment the send would otherwise go out.
3. 3. Route a match to service recovery, not silence. Suppressing the ask is not the goal by itself — the complaint still needs a human response; the ask just should not arrive first.
4. 4. Resume the ask once the complaint closes, not automatically after a delay. A fixed cooldown risks asking again before the issue is actually resolved; tie the resume to complaint status, not a calendar.
5. 5. Track how many asks the gate actually suppresses. A near-zero suppression rate means complaints are not making it into the checked record in the first place — a logging problem, not a gating problem.

Step 1 is the one to get right first — a gate with nothing reliable to check against cannot catch anything.

Or have it scoped and built

Wiring a complaint gate into your review-request automation is scoped work against your specific platforms — the readiness assessment is where that gets mapped out before anything is built.