Automating review requests without risking your reputation

When should the review request actually fire?

Trigger on the event the client would recognise as the end of the work, not on the administrative status change that follows it. Those are usually different dates, and often different weeks.

In most practices the file gets marked closed when someone gets around to it. If you hang the automation off that field, requests land long after the client has moved on, and the reply rate falls. Better triggers, in rough order of reliability:

1. The final deliverable is sent. Tax return lodged, contract exchanged, campaign delivered. The cleanest signal, because a system timestamps it rather than a person's memory.
2. The final invoice is paid. Slightly later, but it filters out clients who are quietly unhappy about fees, which is useful.
3. The final meeting is marked complete. Good for advisory work where the value is the conversation.

Pick one trigger per service line and write it down. What a practice should not have is three overlapping triggers sending the same client three requests.

Add a delay you can defend. One to three business days after the trigger is normal: long enough that the request does not arrive in the same minute as the invoice, short enough that the work is still fresh.

Which clients should never get an automated request?

Any client with an open complaint, an active fee dispute, an overdue invoice, a written-down bill, or a matter that ended badly. Also anyone who has already reviewed you, and anyone who has asked not to be contacted for marketing.

Build this as a suppression list the automation checks before it sends, not as a judgement someone makes in the moment. The list should read from real fields in your systems:

• Open complaint or incident record against the matter
• Invoice more than a set number of days overdue
• Fee reduction or write-off applied to the final bill
• Matter closed with an outcome flag you have defined as adverse
• Any manual "do not contact" flag on the client record
• A review request already sent in the last twelve months

That last one matters more than people expect. Repeat clients in professional services can close several matters a year, and nothing sours goodwill faster than being asked for a review every quarter.

This is not review gating. You are excluding people you have a live problem with, which is ordinary commercial judgement, and you are excluding them before the ask rather than filtering their responses afterwards.

Is it safe to filter out unhappy clients before they review you?

No, not as a design principle. Sending a satisfaction survey first and only forwarding the happy respondents to a public review page is known as review gating, and the major platforms have had policies prohibiting it. Policies change, so check the current terms of whichever platform you are pointing clients at before you build anything.

There is also a practical problem, separate from policy. A page of uniform five-star reviews with no substance reads worse to a sophisticated buyer than a strong average with a couple of honest three-star entries you have answered well.

The defensible version does two things at once. Everyone who passes the suppression check gets the same request, with the same link. And separately, you make it very easy for an unhappy client to reach a person, because most people would rather complain to you than to the internet if you give them a route that feels like it will actually work.

How do you route a negative response to a human first?

Give the request a genuine reply path, watch that path with a classifier, and alert a named person when the reply reads as dissatisfied. The alert is the whole point of the build.

A workable structure looks like this:

1. Send from a monitored address. Not a no-reply address. Roughly a third of the useful signal you will ever get comes from people who hit reply instead of clicking the link.
2. Classify inbound replies. A language model is genuinely good at sorting "thanks, done" from "actually, I was not happy with how that was handled". Keep the categories small: positive, neutral, negative, off-topic.
3. Alert on negative, immediately. A message to a named partner or manager, with the client name, the matter, the reply text and a link to the file. Not a daily digest.
4. Halt the sequence for that client. No reminder, no follow-up, no newsletter, nothing automated at all until a person clears the flag.
5. Monitor the public pages too. Set up alerts for new reviews on the platforms you actually appear on, so a low rating reaches you the day it lands rather than the month you next look.
6. Log the outcome. Who responded, when, and what was done. Over a year this becomes the most honest quality data the practice has.

The response itself stays human. A model can draft a starting point, but the reply to an unhappy client is exactly the message that should never leave the building unread.

What should the automated request say?

Short, specific, from a person, and honest about what you are asking for. Three or four sentences is plenty.

Name the actual work, because a generic "how did we do" reads like a mass send and gets treated like one. Say who is asking. Make the private reply path visible in the message itself, with wording close to "if anything about this did not go the way you expected, reply to this email and it comes straight to me". That single line does more reputational work than any of the automation around it.

What breaks, and how would you know?

The failure modes are predictable, so instrument for them. A review workflow should fail loudly rather than quietly sending the wrong thing.

• Trigger drift. Someone renames a status or adds a service line, and requests silently stop. Watch the count of requests sent per week and alert if it hits zero.
• Suppression lookup failure. If the automation cannot read the complaints or debtors data, it must stop, not proceed on the assumption that no news is good news.
• Duplicate sends. Guard on client identity, not email address, or the same person gets asked twice under two contact records.
• Wrong name, wrong matter. Merge-field errors are the most visible mistake you can make in a message asking someone to praise your attention to detail.

What to do next

Start by writing down, in one line each, your completion event, your suppression rules, and the name of the person who receives the negative alert. If you cannot name that person, do not build the automation yet, because the alert is the part that protects you.

Then build in this order: suppression check, send, reply monitoring, alert. Not the other way around. Most firms build the sending first, get a good run for two months, and then discover the alerting gap the hard way.

Keep a human in front of every reply for the first month while you calibrate the classifier. If you would rather have someone else set the routing up in your own accounts and hand it over documented, that is the kind of build Shift does. Either way, the rule is the same: nothing that touches a client goes out unwatched, and nothing that sounds unhappy goes anywhere except to a person.