Testimonial interview questions for MSPs, and the follow-ups that matter more

Most testimonial question lists online are fine, as far as they go. They'll get you a customer saying nice things in roughly the right order. The trouble is that nice things in roughly the right order is exactly what every other testimonial on the internet already sounds like, and a buyer who has watched three of them has stopped listening by the fourth.

I've run a lot of these interviews with MSP customers and with the MSPs who partner with software vendors, and the thing I've learned, sometimes by getting it wrong on tape, is that the prepared questions only get you to the door. The story is behind a follow-up question you can't write down in advance. So below are the questions I use, and then the part that actually matters.

Why do most testimonial questions produce nothing useful?

Because they ask for an opinion. "What do you like about working with them?" invites a list of adjectives, and adjectives don't convince anybody: responsive, proactive, really good to deal with. Every MSP in the country has a customer who would say that.

What convinces a buyer is a scene they recognise from their own business. The Monday nobody could get into their email, the phone app that rang on everyone's personal mobile at eight in the evening, the stock written down on paper on the shop floor. A peer watching that thinks "that's us", which is the only reaction a testimonial exists to produce.

The other common failure is asking by service. "Tell me about your cyber security" gets you a category answer, a sort of verbal brochure, and there's no moment in it anyone can hold onto.

The five phases of a testimonial interview

Every interview follows the same shape, because it's the shape a buyer's own doubts take: who are you and are you like me, what went wrong, why did you pick them, did it work, and would you do it again?

It runs about 45 minutes, and the time isn't split evenly. Results gets the most, because that's where a buyer needs evidence, and context gets the least, because nobody watches a testimonial to hear a company history.

Phase 1: Context questions

Three to five minutes. You're establishing who this person is, so a viewer can decide whether they're a peer.

• Tell me about the business: what you do, who for, and roughly how big you are.
• What's your role, and how much of IT lands on your desk?
• How long have you worked with them?
• Before them, who looked after your IT?

Always ask how long they've been a customer, because tenure changes the story completely. A customer of six months can tell you about the switch and the first impressions. A customer of five years can tell you what it's like when the account manager changes, or the business doubles, and they can't really tell a switching story at all because they've forgotten the detail.

Phase 2: Pain questions

Five to seven minutes. This is the before, and it's the phase most interviewers rush because it feels a bit negative. It's also the phase your prospect recognises themselves in.

• Take me back to before. What was a normal week like with IT?
• Was there a day it went properly wrong? Take me to that day.
• What did you think IT support was going to be like? What did it actually turn out like?
• Who felt it most in the business?

That third one is what I call the Gap question, and it works almost every time. The difference between what someone expected and what they got is where the frustration lives, and frustration is what makes a story.

Phase 3: Decision questions

About five minutes. This is where you answer the question every prospect is silently asking, which is why anyone bothers switching IT provider at all.

• Why did you do something about it when you did, and not a year earlier?
• What was the last straw?
• Who else did you look at, and what made you pick them?
• What were you worried about before you moved?
• What did you buy from them first, and what made you come back for the next thing?

The first question is the trigger, and people will nearly always answer it with a general build-up ("it had been getting worse for a while"). Don't let that go. Ask what the last one was. A pile of problems isn't datable, but the last straw always is.

Cheryl Kearney, the CEO of the autism charity Sycamore Trust, was replacing an office server that had been in place for about ten years. The reason she kept coming back to wasn't its age at all, it was the local authority funders who ask a charity to prove its IT is secure:

If you can't show that, then you will not be awarded local authority contracts.

That's a decision a peer can feel, and no question on a list would have produced it on its own.

Phase 4: Results questions

About ten minutes, the longest phase. You want evidence, and evidence means specifics.

• What's different now?
• What changed on a Monday morning?
• Is there a number that shows it: tickets, hours, downtime, cost?
• What did you think the win would be? What did it turn out to be?
• Is there a moment that showed you it was working?

After every fact, ask about the feeling. If someone tells you tickets went down, the next question isn't another metric, it's what that meant for them. When Patrik Kekonius, a sales manager at the Swedish MSP Coegi Cloud, talked about the security awareness platform they resell, the result was clear enough:

And comparing the two different customer types, the ones using usecure and the ones not using usecure, we don't have any tickets from the ones using usecure.

Phase 5: Verdict questions

Three to five minutes, and it's where the lines that end up on quote cards come from.

• If a peer in your position asked whether they should hire them, what would you tell them?
• Who is it right for? And who isn't it right for?
• If someone was nervous about doing one of these interviews themselves, what would you say to them?

The "who isn't it right for" question feels risky and it's gold. A customer who can say who a supplier wouldn't suit sounds like someone telling the truth, and that credibility spills over onto everything else they've said.

The follow-up questions that matter more than the list

This is the bit I'd pin above the desk of anyone running these interviews.

Ask for the scene, never accept the summary. "It took months" is a summary. "Take me to that exact day. Where were you, what did you see, what did you say?" is how you get the story.

When you hear something good, dig, don't label it. The reflex when a guest says something vivid is to say "brilliant" and move to your next question. That praise feels supportive and it's the end of the story. In one interview a guest mentioned, almost in passing, a phone call from a worried customer about staff who had clicked a phishing link, and I moved straight on to my next question. It was the best story in the conversation and I left it on the table.

Never answer your own question. "It's peace of mind really, isn't it?" puts your words in their mouth, and if you said it, it isn't their story any more.

Mirror numbers and emotional words. If they say "a million" or "scared", say it straight back as a question, and then stop talking.

Count to five after they finish. The silence is uncomfortable, and people fill it with the thing they were holding back.

Questions to avoid in a testimonial interview

• "What do you love about them?" You'll get adjectives.
• Two questions in one breath. "Was there an incident, or was it more of a general pain?" gives them an escape hatch and they'll take it.
• "Would you recommend them?" A yes or no answer is no use in an edit. Ask what they'd say to a peer instead.
• Working through the service list. Ask for the story and note which services come up; don't turn the conversation into an audit.

What changes when a vendor interviews an MSP partner?

The phases stay the same, but the evidence a partner needs is different, because an MSP isn't only buying a product, it's staking its own customer relationships on someone else's software. So the results questions shift towards the MSP's business: how long onboarding took, how much engineer time it costs, what their customers noticed, whether it helps them sell.

When I asked Patrik about getting customers onto the platform, his answer did more for a sceptical MSP than any feature list could:

I can't even remember if it took an hour. The whole platform is so self-explanatory.

Should you run the testimonial interview yourself?

You can, and if budget's tight you should rather than not having a story at all. Use the questions above, record on a decent phone, and ask the follow-ups.

The honest limitation is that customers are polite to their suppliers. They'll tell an outsider things they'd never say to their account manager across a table, including what it was like before, which is the part that sells. An interviewer who knows the MSP world also saves the customer ten minutes explaining what co-managed IT means, so the conversation goes on the story rather than the background.

Questions people ask

How many questions should a testimonial interview have?

Prepare fifteen to twenty across the five phases, and expect to use fewer, because the best material comes from following the customer rather than the list.

Should you send testimonial questions to the customer in advance?

Yes, if they'd like them. It removes the fear of being caught out. Make it clear there's nothing to memorise, because a rehearsed answer sounds rehearsed.

How long should a testimonial interview be?

About 45 minutes. That's long enough to get past the polite first answers and short enough to be a reasonable ask of a busy customer.

What is the most important testimonial interview question?

"Take me to that exact day." Whatever the phase, asking for one specific moment rather than a general impression is what turns an answer into a story.

Related reading

• How to be good on camera in a video testimonial
• Why most MSP testimonials don't work
• How a remote video testimonial works