Turn your helpdesk into a testimonial engine
The moments that earn an ask, what an engineer actually says, and a simple workflow that means nobody has to remember
6 min read
To turn an MSP helpdesk into a testimonial engine, trigger the ask from events rather than dates: a complex ticket resolved, an onboarding completed, a fast outage recovery, a restore test that worked, or a project closed. Check how the client feels first, let the engineer mention it in one sentence, log the name for one owner to follow up the same day, and send one reminder at most.
In five ways to get testimonials from your clients I said the helpdesk should do the asking, because engineers are the only people in your business who are in the room when a client feels relief. A few people asked the obvious follow-up, which is how, exactly, without turning engineers into salespeople or relying on anyone to remember.
This is the how. It's less about persuasion than plumbing: the right trigger, a quick check, one sentence from the engineer, and a named person who picks it up.
The moments that earn an ask
Ask when something has just gone well, and the feeling is fresh. These are the events that reliably qualify:
- A complex ticket resolved. The classic trigger. Relief is a strong feeling and it's easy to date.
- An onboarding completed without drama. The client had a fear about moving to you, and it didn't happen.
- A fast recovery from an outage. The most emotional moment in the whole relationship.
- A backup restore test that worked. Proof of something they were paying for and could never see.
- A migration or project closed out. A clear ending, which is rare in managed services.
- A clear explanation during a difficult ticket. It names an individual, which makes the proof specific.
The timing has two edges. Ask too soon and the fix hasn't held yet, so the client isn't sure they're happy. Ask too late and the feeling has gone, so they're trying to remember how they felt. The window is short, and it's measured in hours rather than weeks. The request rarely gets refused; it gets buried under the next three tickets.
Check the mood before anyone asks
Don't ask and hope. Check first, then ask. The check can be the CSAT score on the ticket, an NPS response, or just the tone of the client's reply.
- A top score with a specific comment: that client goes on the list that week.
- A top score with no comment: fine for a review request, weaker as a testimonial nomination, because it doesn't tell you they have anything to say.
- A low score: nobody asks for anything. The account owner calls them, privately, within a couple of days.
That check is what stops an engineer walking into an ask with a client who is quietly unhappy, and it turns a lucky guess into something you can repeat.
When not to ask
There are predictable bad moments, and every engineer already recognises them:
- While a ticket is still open, even a minor one.
- During a contract renegotiation, or in the few weeks before a renewal.
- When the person is visibly overloaded.
Reading the room is a skill your helpdesk uses every day. This is the same skill pointed at one more question.
What the engineer actually says
The engineer's only job is to mention it. They're not selling, they're not closing and they're not booking anything. One sentence, in their own words, something like:
A few details make it land. Name the specific thing ("the restore on Tuesday"), because "tell us what you think" doesn't say about what. Offer a written option in the same breath, so camera shyness doesn't get logged as a no. And don't ask them to log in or fill anything in, because nobody jumps through a hoop to pay a compliment.
If the engineer is asking for a Google review rather than a testimonial, it's reasonable for them to make it personal: "it would really help me out if you mentioned my name". It also produces a review that names a person rather than a company, which reads as more genuine.
When praise arrives unasked
This is the best trigger of all, and the one most MSPs never act on. A thank-you in a ticket reply or an email is a client telling you, in writing, that they're happy. Reply the same day, while it's still warm:
Leading with their own words matters. Confirming something they already said is a much smaller ask than inventing something new.
The workflow behind it
The engineer mentions it. Everything after that should not depend on anyone's memory.
- The engineer marks the ticket or contact as a story candidate, using whatever tag, status or note field your PSA already has, with a line about what the client said.
- One named owner reviews the list daily and follows up the same day, from their own name, not a system address.
- One reminder, then stop. If the client doesn't reply, send one short follow-up a couple of working days later, ideally on a different channel. Then park it and try again after the next good moment.
- Change the shape, not the frequency. If you do come back to someone, send something different, such as the questions in advance or a suggested time, rather than the same email again.
Make it part of closing the job. For projects and onboardings, the simplest way to stop the ask being forgotten is to make it a step that has to be done before the project can be marked complete. It takes the question "did anyone ask?" out of the equation.
Rewards and rules
Reward the mention, never the yes. An engineer controls whether they mention it and nothing else. Score them on outcomes and they'll only ask the easy clients. A point for each mention logged, a visible leaderboard and something worth winning each month is plenty.
Never reward the client for a public review. Discounts, vouchers or gifts in exchange for a Google review break Google's rules and can get reviews removed. A thank-you sent afterwards, whatever they said, is good manners.
Know which rule applies where. Only inviting happy clients to leave a public Google review is treated by Google as against its rules, so review requests should go to clients consistently rather than only to the ones you expect to be positive. That rule is about public review platforms. Choosing which happy client to invite to a recorded customer story is a different thing: it's your story to curate.
Questions people ask
When should an MSP ask a client for a testimonial?
Straight after something has gone well and the client has confirmed they're happy: a complex ticket resolved, an onboarding completed, a quick outage recovery or a project delivered. Ask within hours, not weeks.
What should an engineer say when asking for a testimonial?
One sentence in their own words, naming what they just fixed, mentioning that the company does short customer stories, and offering a written quote as an alternative to video. Someone else handles the follow-up.
Is it okay to only ask happy clients for testimonials?
For a recorded testimonial or case study you publish yourself, yes, you choose who to feature. For public Google reviews, requests should go to clients consistently rather than only to those you expect to be positive.
Should engineers be rewarded for getting testimonials?
Reward them for mentioning it, not for getting a yes. They control the mention; they don't control the client's answer.
How many times should you follow up a testimonial request?
Once. Send one short reminder a couple of working days later, then park it until the next good moment.
Related reading
- Five ways to get testimonials from your clients
- What if my client says no to a testimonial?
- Which client should you ask for a testimonial?
Your helpdesk finds the client. We do the asking, the interview and the whole pack, back in 14 working days.
See how it worksJames interviews MSP and tech vendor customers for a living and runs MSP Testimonials, the interview-led testimonial service. If a customer of yours has a story worth telling, this is how it gets told.
