Imagine two customers who had the same haircut on the same Friday. One gets the review request at 5pm the same day. The other gets it at 9am Wednesday. The hypothesis behind this guide is that the same-day send has a better shot at a response, because the visit is still fresh, but the only way to know for your shop is to measure it.
This guide covers the mechanics of the send: when to fire, what event to fire on, how eligibility is defined, and how to cap a second nudge.
A two-to-six-hour window to test
- 0hVisit ends
- 1–2hSend request
- 24hNudge once
- 72hStop nudging
- 0hVisit ends
- 1–2hSend request
- 24hNudge once
- 72hStop nudging
In that window, the visit is a recent memory, her phone is nearby, and she has not yet been pulled into work email, kid pickup, or a grocery run. That is the hypothesis behind trying this window first.
Outside the window, the request competes with everything else in her day. Whether that changes your actual response count is worth checking against your own baseline; a clever subject line will not substitute for that measurement.
Fire on the appointment-completed event
Not a nightly batch. Not a next-day cron. The moment your booking tool marks the appointment as completed, a short delay starts. Send inside the window that delay defines.
Whether your booking tool exposes this event natively is worth confirming in the tool itself. If it does not, that is the seam to close before anything else in the review flow, because everything downstream depends on it firing at the right moment.
The eligibility rule
Write one eligibility rule and apply it to every completed customer. Eligibility is based on whether the appointment was completed and whether a recent request already went out, never on predicted satisfaction. A private service-recovery path runs in parallel and does not suppress an eligible public request.
- No-shows. Not a completed appointment, so no request.
- Same-day cancels. Not a completed appointment, so no request.
- Customers who already received a request inside your defined window.
- Everyone else who completed a visit gets the same request, including customers who raised an issue. Service recovery runs alongside it.
Send-time collisions
If the customer just paid, add spacing before the review request fires. Treat the gap between the payment message and the review request as a variable to test: start with fifteen minutes, then compare response and opt-out data against your baseline before shortening or lengthening it.
One channel per customer
Send on the channel the customer booked with. Not both. Not the other channel as a fallback three days later. Match the ask to how the customer chose to interact with you in the first place.
The one nudge
If the first request does not produce a review in three days, one soft nudge on the same channel is a reasonable design to test. Same channel. Shorter message. Cap the sequence at a defined number of messages and compare reply and opt-out data against your baseline before adding another.
A haircut appointment on Friday afternoon
Show the worked example
Hypothetical numbers, not a measured result.
Service ends at 3:45 PM. Payment posts at 3:52. The review request sends automatically at 6:52 PM, three hours after payment, still inside the same evening.
In this scenario, the customer opens the text between dinner and Netflix. One soft nudge at 10 AM the following Monday is built into the flow as the one allowed follow-up.
If the trigger were instead set to next-day 10 AM, the same setup would compete with a full day of other messages. The mechanics, not an assumed outcome, are the point: earlier and closer to the completed event is the model worth testing against your own numbers.
Frequently asked questions
start here
Wire a review path that fires on the right event.
The Loop Audit checks your records and a test booking, then names the seam. Any module is prescribed after that, against a written scope.
No card, no sales call required. Report emailed to you.