The request competes with a memory
A review gets written from memory, and the memory it gets written from is short. What a customer keeps of a routine job is the name of the person who turned up, what was done, whether the floor was left clean and whether the price matched the quote. That is the material a useful review is made of, and it's at its clearest on the afternoon the van pulls away. The name is the first thing to go, and once it has gone the job becomes one more thing that happened.
The request competes with the fading of the job more than with anything else in the inbox. The job is the only reason to open it. A message that arrives the same afternoon lands while the customer still has that reason, because the company was in their kitchen that morning. The same message at the end of the week comes from a firm they have finished thinking about. By then it reads as marketing, which is what it has become.
The second half of the argument is about what the review says, and it can be checked before anything is built. We read a client's existing reviews against the completion dates in the job system. The ones written on the day of the job tend to carry the name of the person who did the work and a line about what they did, because those details were still to hand. The ones that come in after a Friday batch, when any come at all, carry a star rating and the words great service. Anyone choosing a plumber from a page of reviews can tell the two apart.
Where the weekly batch goes wrong
Most teams we sit with send review requests in a batch, usually on a Friday, and the reason is rarely a decision anyone made. It's the day the export from the job system gets run, or the day the office manager has a quiet hour, and nobody has gone back to the setting since. It also depends on a person remembering. On the weeks the office is busiest, which are the weeks with the most finished jobs in them, the export gets skipped and rolled into the next one, so a weekly send becomes a fortnightly one without anybody deciding that it should. That drift is the first of four things the batch gets wrong, and the only one the office already knows about.
The age of the job is the second. A Friday send covers work finished on Monday and work finished that morning, so one message reaches a customer whose job is already most of a week behind them and another who was still wiping down the worktop at lunch. The wording has to suit the oldest job on the list, which means it names nothing, because whoever wrote it couldn't know what any one customer still remembers. It reads as a template because it is one.
The export is the third. A job list pulled on a Friday holds jobs that were quoted, jobs that were scheduled, jobs that were finished and jobs that were invoiced, and the filter that separates them was set once by somebody who has since left. We have seen requests go to a customer whose job was booked for the following week, and to a customer who had been on the phone that morning about the work being done wrong. Both were sent on time by the batch's own definition.
The signature is the fourth, and the one teams notice least. A week's list has more than one technician on it, so the message can't come from the person who was in the house and goes out from the company instead, under a name nobody at the customer's end has met. The technician's name is the one thing the customer would have recognised. A batch throws it away by design, and then the wording has to work harder to earn an open it would otherwise have had for nothing.
What counts as the job being finished
Once the request is tied to the completion event, the whole build turns on what that event is. A job system offers more than one candidate. The technician marks the job done on site, the office closes it when the paperwork is in, the invoice is raised, the invoice is paid. Each of those is called complete somewhere in the system and they can sit days apart. Only one of them is the moment the customer thinks of as the job being over.
We use the on-site status, set by the person who did the work before they drive to the next job. It is the earliest of the candidates and the one that matches the customer's own sense of timing, since the customer watched the van leave. The invoice is the wrong trigger for the same reason. It can be raised the following Tuesday by someone in the office, and a request tied to it arrives with the bill, which is not the moment anyone sits down to praise the company.
The trigger then carries conditions, and we write them down before anything is connected. The job has to have a customer contact on it, a mobile number or an email address, and the contact has to belong to the person who was there and not to the letting agent who booked it. The customer can't have had a request inside an agreed number of months, whatever the number of jobs since. A job flagged as a callback or a warranty visit is excluded, and so is any customer with an open complaint on their record.
The last condition is a short delay, and it is the one clients argue with. The message goes out an hour or two after the status changes, so that it arrives once the customer has closed the door and not while the technician is still on the drive writing up. An hour is also long enough for the office to reverse a status set by mistake, because a job marked done and then reopened must not have a request in flight. Completions after the evening cut-off wait for the next morning. That is the one exception to the same day, and a memory survives a night better than it survives a working week.
The message names the job and asks once
Firing from the event is what lets the message be specific, and being specific is the point of the timing. The request comes from the person who did the work or from the office manager the customer spoke to, with a real name and a reply address that reaches them. It names the job and the date, in the plain words the customer would use, and it carries one link and one ask, with nothing about referrals and no second link to a survey.
The person whose name is on the message writes it with us, and the test it has to pass is whether it could have gone to every job on last Friday's list unchanged. If it could, it is a batch message with a better send time. The timing has bought nothing. Most of the drafts we're handed at the start fail on exactly that. They open with thanks for choosing us and they ask the customer to take a moment of their time, and neither line knows which job it is about. A technician writing to someone whose boiler they fixed that morning would write two lines about the boiler, and the automated version should read like those two lines.
There is no incentive in it. A discount for a review is against the platforms' rules, and it changes what the customer is being asked for, from an account of the job to a transaction, and the reviews that come back read that way. One reminder follows if the link hasn't been opened after an agreed number of days, and then it stops. A reply to either message goes to the named person, never back into the automation, because a customer who answers a review request with a paragraph is telling the company something it needs to hear that day.
The link goes to one place. We choose it with the client before the build, and it is the profile that appears when the company's name is searched. Offering a choice of platforms turns the minute the customer was asked for into a decision about where to spend it, and a decision is a reason to close the message. If a second platform matters, it gets its own request to a different set of customers, and only once the first one is working.
