The Review Request Build Standard

1. What this standard covers

One finished job, and one ask for a Google review. The trigger is the job marked complete, or paid, in the job system, whichever the business picks and writes down. After a written wait (two hours, say, so the customer has seen the result), the customer gets one SMS or email with a thanks, a 1 to 5 “how did we go” and the business’s Google review link. If there is no reply and no review after a written interval, one reminder goes with the same link, and then nothing more. Every ask, reminder, reply, hold and alert is recorded against the job. It is the method in Asking Every Customer for a Google Review, written so a build can be checked against it.

What is out of scope. Answering reviews: that is the owner’s, every one. Chasing something a customer owes you that is not money, such as a signed variation or a form, is the Follow-Up standard, which has the same one-reminder-then-stop shape on a different job. The next service or warranty reminder is the Next Service standard: the same job-complete trigger starts it, and the two run side by side without either sending the other’s message. Answering the call that books the job in the first place is the Booked After Hours standard.

What cannot meet it, and what can. The build has to read the job’s status from the job system itself, at the moment of sending, so it needs a sanctioned way in. ServiceM8, Simpro, Fergus, Jobber and AroFlo each offer an integration route; check that yours exposes job status, linked callback jobs and the invoice state before you start. Tradify has no public API, so a Tradify business cannot meet check 1 live: the nearest it gets is a list somebody exports or types, which is exactly the trigger this standard refuses. If your job system has no place for a disputed invoice or an open complaint, pick one it does have (a job status, a tag) and write down that it means that. The build reads what you wrote down.

Is there a ready-made version? Not yet. No product of ours sends review requests, and review software that does usually ships with the score-first filter switched on. So this standard is a Draft, and the build is yours.

2. Every customer gets the same message and the same link

A lot of review software sells a different flow: ask for a score first, send the Google link only to people who answer 4 or 5, and send everyone else to a private form. It is called review gating, and it is the one part of this job the standard refuses. Google’s review policy bars businesses from selectively asking happy customers for reviews or discouraging unhappy ones, and the ACCC’s guidance on online reviews treats a rating built only from the customers you chose as misleading. The dated detail is at the foot of this page.

So the test is simple, and check 3 runs it on every message the build sent: take the customer’s name out, and every ask must be the same words with the same link. Nothing goes to a customer because of what they replied. A 2 gets the owner a text to call; a 5 gets no “since you loved it” push. Whether either of them posts a review is up to them, with the link they already have.

3. When a job is not really finished yet

Asking for a review in the middle of a dispute is a bad idea, and it is tempting to fix that by not asking the unhappy ones. That is gating by another name. The lawful version reads the job, not the customer: a job that still has work or a dispute open on it in the job system is not finished, so the ask waits, for every customer, the same way.

The owner is told why each job is held. The job is read again at the moment the message would go, so a callback raised during the two-hour wait still holds it. When the state clears, the customer gets exactly the message everyone else got. A hold is never a way to skip a customer for good. What is never a reason to hold:

• A reply of 1, 2 or 3. It alerts the owner; the customer's link is unchanged.
• A guess at how the customer feels, from a note, a tone, a model or anything else.
• A customer the owner would rather not hear from. Every customer is asked the same way.

4. The records it keeps, in the shape your developer needs

Five objects. The Hold is the one most builds leave out, and the one that keeps a disputed job from being asked mid-dispute without filtering anybody by score.

Rules                             # one per business, written down
  - trigger (complete | paid)
  - wait_hours, reminder_hours, window_days
  - review_link                     # the only link any message carries
  - message_text, reminder_text     # one of each, for every customer

Job                               # read from the job system, never copied
  - id, customer_id, status, completed_at, paid_at
  - open_callback, invoice_disputed, open_complaint
  - review_marked_by                # the office marked a review as posted

Ask                               # unique on job_id
  - job_id, customer_id
  - channel (sms | email)           # the customer's channel on record
  - body                            # message_text with the name filled in
  - asked_at, reminded_at (nullable, set once)
  - status (waiting | held | asked | reminded | replied |
            review_marked | skipped_window | opted_out)

Hold
  - job_id
  - reason (open_callback | invoice_disputed | open_complaint)
  - raised_at, cleared_at           # cleared when the job system says so

Reply                             # append only
  - job_id, customer_id, text       # exactly as received
  - score (1..5, nullable)
  - received_at, owner_alerted_at, owner_called_at

OptOut                            # keyed on the customer, not the job
  - customer_id, said, received_at

There is no link field on an Ask, no score threshold anywhere and no feedback form. An Ask whose body differs from message_text by more than the customer's name is the defect this standard exists to make unrepresentable.

5. The checks, in order

The order is the claim. The trigger and the wait come first, the job is judged finished or held before anything goes, the window and the opt-out come next, and only then the one message, the one reminder and the alert.

1. The ask starts when the job system says the job is finished. The trigger is the job marked complete, or paid, whichever the business picked and wrote down, read from the job system itself. Not a list somebody typed, not a guess from the calendar. A job still in progress is never asked about.
2. The ask waits the written time after the job is finished. The business writes down how long to wait (two hours, say) so the customer has seen the result. Nothing goes before that, whichever run of the build happens to notice the job first.
3. Every customer gets the same message and the same review link. One message for everyone: thanks, how did we go from 1 to 5, and the business's Google review link, with the business's name and a way to opt out. Nobody gets a different link, a private feedback form instead, or a second message because of what they replied.
4. A job that is not really finished is held, with the reason. An open callback or rework job, an invoice marked disputed, or an open complaint recorded on the job in the job system means the job is not finished yet. The ask is held and the owner is told why. The hold reads the job, the same way for every customer, and is never based on a score, a guess at how the customer feels, or anything they said.
5. The job is read again at the moment of sending. A callback raised during the wait holds the ask, even though the job looked finished when it was first seen. The decision is made on the job as it stands when the message would go.
6. When the hold clears, the same ask goes the same way. Once the callback is closed, the dispute is settled or the complaint is closed in the job system, the customer gets exactly the message everyone else got. A hold is not a way to skip an awkward customer, whatever way the dispute ended.
7. One ask per customer, however many jobs they had. At most one ask per customer in the window the business writes down (thirty days, say), and never two for one job. A customer with three jobs in a week hears from you once.
8. Asked only on the channel on record, and a STOP is for good. SMS or email, whichever the customer's record holds. A customer with neither is an exception, not a guess. A STOP or unsubscribe is recorded against the customer, not the job, and no later job ever asks them again.
9. One reminder if nothing comes back, then stop. If there is no reply and the business has not marked a review as posted after the written interval, one reminder goes with the same link. A reply, a STOP or a review marked as posted stops it. There is never a third message.
10. A low score tells the owner to call, and changes nothing for the customer. A reply of 1, 2 or 3 sends the owner an alert with the job, the customer and their words, so they can ring while it is fixable. The customer keeps the link they already have. Nothing asks them not to post, and nothing routes them anywhere else. A high score gets no extra push either.
11. It never makes up, rewards or answers a review. The build never writes a review, suggests what to say or how many stars, offers anything in exchange (a discount, a voucher, a draw), posts anywhere, or replies to a review on Google. Answering reviews is the owner's job. There is nothing in the build that could post.
12. Every ask, reminder, reply, hold and alert is on the record by job. Kept so that a customer who says they were pestered, or a question about how the reviews came in, is answered from the record: what went, when, on which channel, what came back word for word, and why a job was held.
13. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
14. The pass test passes. Real jobs, marked finished in the real job system, produce one identical ask each at the written time. A job with an open callback is held until the callback closes. A low score, texted back days later from a real phone, reaches the owner, and the customer's link is never taken away.

The holds and exceptions, a closed list:

6. The message, the reminder and a low score

One message, written once by the business. For example: “Hi Ana, thanks for having Banksia Plumbing out. How did we go, 1 to 5? If you have a minute, a Google review helps a small business a lot: [link]. Reply STOP to opt out.” It names the business, carries the link and a way to opt out, and goes on the channel the customer’s record holds. A customer with no mobile and no email is an exception, not a guess.

At most one ask per customer in the window the business writes down, thirty days say, and never two for one job. A customer with three jobs in a week hears from you once. The one reminder goes only if nothing came back and nobody marked a review as posted, after the written interval, with the same link. A reply, a STOP or a marked review stops it, and there is never a third message.

A reply of 1, 2 or 3 sends the owner a text straight away, with the job, the customer and their words, so they can ring while it is still fixable. That is good service, not reputation management: the customer still has the same link as everyone else, nothing asks them not to post, and nothing routes them anywhere else. A STOP is recorded against the customer and honoured on every later job.

7. What stays with a person

• ✓Answering every Google review, good and bad. The build has no way to post or reply.
• ✓The call to a customer who scored you 1 to 3, and whatever apology or fix it needs.
• ✓Closing the callback, settling the dispute or closing the complaint in the job system. The build only reads it.
• ✓Writing the one message, the wait, the reminder interval and the window, and changing them.
• ✓Marking a review as posted, when the office sees it.
• ✓Taking a customer off the opt-out list, which happens only if they ask.

The build must never write a review, suggest the wording or the stars, or offer anything in exchange: no discount, no voucher, no draw.

8. Run it on what you already use

The workflow lives wherever the business already works. Three ways, all held to the same checks:

• Existing tools only. A scheduled script or a flow that reads the job system every fifteen minutes, with the rules and the record in a Google Sheet or Microsoft 365 lists. The Microsoft 365 plan lays out the lists and flows.
• A personal dashboard. Hand this page to a coding agent and it builds a small page with the holds, the asks, the replies and the low scores to call, against the stub until the job system has to be real.
• A long-lived bot. A routine woken by the job system’s own job-completed event, which sends the ask after the wait and texts the owner when a low score comes back.

How to run any standard each of these ways is in run a standard anywhere.

9. What your developer builds, and the step that needs care

One step needs care: reading the job's real state out of the job system at the moment of sending, and catching the reply that comes back through the carrier days later. No product of ours does this, so it runs on your own job system and SMS or email account. Everything else a coding agent builds against the stub in an afternoon.

provider:
  stub:       local.mock_review_jobs
  production: none                       # scoped build, not a product

the stub                             # local.mock_review_jobs
  - jobs the runner marks complete or paid, with callbacks,
    disputes and complaints it raises and closes
  - customers with a channel on record, and replies it delivers
  - a send that refuses a customer who opted out
  - no way to post, draft or answer a review, on purpose

production: your own systems, as a scoped build
  - the job system: ServiceM8, Simpro, Fergus, Jobber or AroFlo,
    read for status, linked callbacks and invoice state
  - an SMS or email account the business owns, with replies and
    STOP coming back into the build
  - the record, in a store the business owns

stays local                          # yours, and the standard
  - the wait, the window, the hold, the one message, the one
    reminder, the alert and the record

cannot meet the standard
  - Tradify: no public API, so no live read of job status
  - any build that asks for a score before it sends the link

A vendor selling review requests is often selling the score-first filter. Ask them three things: does every customer get the same link whatever they score, what happens to a job with an open callback, and what the customer receives after replying 2.

10. A checklist to hold any build or supplier to

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. The ask starts when the job system says the job is finished. The trigger is the job marked complete, or paid, whichever the business picked and wrote down, read from the job system itself. Not a list somebody typed, not a guess from the calendar. A job still in progress is never asked about.
• ✓2. The ask waits the written time after the job is finished. The business writes down how long to wait (two hours, say) so the customer has seen the result. Nothing goes before that, whichever run of the build happens to notice the job first.
• ✓3. Every customer gets the same message and the same review link. One message for everyone: thanks, how did we go from 1 to 5, and the business's Google review link, with the business's name and a way to opt out. Nobody gets a different link, a private feedback form instead, or a second message because of what they replied.
• ✓4. A job that is not really finished is held, with the reason. An open callback or rework job, an invoice marked disputed, or an open complaint recorded on the job in the job system means the job is not finished yet. The ask is held and the owner is told why. The hold reads the job, the same way for every customer, and is never based on a score, a guess at how the customer feels, or anything they said.
• ✓5. The job is read again at the moment of sending. A callback raised during the wait holds the ask, even though the job looked finished when it was first seen. The decision is made on the job as it stands when the message would go.
• ✓6. When the hold clears, the same ask goes the same way. Once the callback is closed, the dispute is settled or the complaint is closed in the job system, the customer gets exactly the message everyone else got. A hold is not a way to skip an awkward customer, whatever way the dispute ended.
• ✓7. One ask per customer, however many jobs they had. At most one ask per customer in the window the business writes down (thirty days, say), and never two for one job. A customer with three jobs in a week hears from you once.
• ✓8. Asked only on the channel on record, and a STOP is for good. SMS or email, whichever the customer's record holds. A customer with neither is an exception, not a guess. A STOP or unsubscribe is recorded against the customer, not the job, and no later job ever asks them again.
• ✓9. One reminder if nothing comes back, then stop. If there is no reply and the business has not marked a review as posted after the written interval, one reminder goes with the same link. A reply, a STOP or a review marked as posted stops it. There is never a third message.
• ✓10. A low score tells the owner to call, and changes nothing for the customer. A reply of 1, 2 or 3 sends the owner an alert with the job, the customer and their words, so they can ring while it is fixable. The customer keeps the link they already have. Nothing asks them not to post, and nothing routes them anywhere else. A high score gets no extra push either.
• ✓11. It never makes up, rewards or answers a review. The build never writes a review, suggests what to say or how many stars, offers anything in exchange (a discount, a voucher, a draw), posts anywhere, or replies to a review on Google. Answering reviews is the owner's job. There is nothing in the build that could post.
• ✓12. Every ask, reminder, reply, hold and alert is on the record by job. Kept so that a customer who says they were pestered, or a question about how the reviews came in, is answered from the record: what went, when, on which channel, what came back word for word, and why a job was held.
• ✓13. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓14. The pass test passes. Real jobs, marked finished in the real job system, produce one identical ask each at the written time. A job with an open callback is held until the callback closes. A low score, texted back days later from a real phone, reaches the owner, and the customer's link is never taken away.

Facts that can change, and when we checked them