CHURN IS DEAD
Your Best Customer Is Not Your Reference Desk
7 min read · Customer Growth
The sales team has a deal that might close this week. The buyer wants to hear from someone already using the product. There is one obvious name.
That customer likes the product. She spoke at your event a few months ago. She helped with a story for the website. The account owner thinks she'll say yes to a call.
Then the request comes in: "Can she speak to this prospect tomorrow?"
This is a made-up situation, not a real customer story. But the choice is familiar to anyone in Customer Success (CS). A customer was happy to help once. Does that make her the person to call every time a deal needs proof?
I don't think it does.
The customer may still want to help. The prospect may have a fair question. The mistake is to treat the customer's earlier yes as permission for a different ask, on a different day, for a different purpose.
A good reference request starts with what the customer is being asked to give, not what your team needs to close.
The prospect's question matters
The easiest way to mishandle this is to make it a fight between CS and Sales. Sales says the call matters. CS says the customer is busy. Both could be right.
Start with the buyer's actual question. Are they unsure whether the product works in a similar environment? Do they want to know how long setup took? Are they worried that support disappears after signing? Those are different questions. A call with a happy customer won't answer all of them.
If the question is about a feature, a product expert might be better. If it is about the first month of rollout, an existing story or a conversation with the implementation team may do the job. If the buyer wants to hear the trade-offs from a peer, a customer call might be worth asking for.
That distinction helps the customer too. Nobody should spend half an hour on a call only to discover that the buyer needed a technical answer they couldn't give.
The account owner should be able to say why this particular customer is a fit. "She's our happiest customer" isn't enough. What has she done that matches the buyer's situation? What can she speak about comfortably? And what should stay out of the conversation?
A yes to one thing is not a yes to everything
A logo on a slide, a quote in a case study and a live call each ask something different of the customer. One uses a name. One uses their words. One uses their time, often with no chance to rehearse the questions.
GitLab's public customer advocacy process treats customer names, logos, quotes, stories and speaking opportunities as separate kinds of reference. It says references should be secured in writing and asks its team to check whether a potential speaker has already been used too often. Its event lead times are GitLab's own, not a rule for every CS team.
GitLab also describes explicit, documented agreement for different reference activities in one of its programmes. That is a useful operating reminder. It isn't legal advice: your company still needs to follow its own contracts and approval process.
The practical question for CS is simpler. Before anybody approaches the customer, what exactly are we asking them to do? Where will their name or words appear? Who will hear them? How long will it take? What can they say no to?
"They agreed to be a reference" may be true in some limited sense. It does not tell you whether they agreed to tomorrow's call.
The customer has a job of their own
Back to the made-up request. The customer who spoke at the event may be delighted to talk to a peer. She may also be preparing her own launch. You don't know until you ask, and the deal deadline is not her deadline.
It is easy to say, "It's only thirty minutes." For the customer, it may mean finding the right person, checking what can be discussed, getting internal approval and making time around their real work. It may also mean saying no to an awkward request from a vendor they otherwise like.
This doesn't mean CS should hide customers from Sales. It means the person making the request should do the preparation instead of passing that work to the customer.
Send the buyer's question in advance. Offer a time window rather than a demand for tomorrow. Make it clear that a decline won't change the support the customer receives. If the customer wants to help but can't do a call, ask whether a shorter or less public option would suit them. Don't assume a quote is easier; sometimes the approval for public words is the hardest part.
GitLab's reference-program role description includes respect for the customer's time and effort, and a positive result for the customer as well as the vendor. That's a stated job responsibility, not proof that every reference programme lives up to it. But it is a decent standard for the conversation.
What does the customer get from this? There might be a chance to share work they're proud of, meet someone with the same problem, or build their own profile. Sometimes the honest answer is: not much, beyond helping a partner. Don't dress that up as a benefit. Make a smaller ask.
Try the smaller ask first
There is a fair objection: this could become another slow process. If every reference request needs a meeting, a form and three approvals, the team will stop asking. Some customers enjoy helping. Prospects do need to speak to peers. A useful customer story can give the customer credit for work that otherwise stays invisible.
So don't build a committee. Put a short note in the opportunity you already use. It needs to answer three things.
First, what is the buyer trying to learn? Write the question in the buyer's words if you have them. If nobody can state it, don't send a vague request to the customer yet.
Second, what would the customer actually have to do? Name the format, the time, the audience and the deadline. Include any approval needed for a logo, quote or public story. Check whether other teams have approached the same person recently. You do not need a public list of individual advocates to do this; the account owner can check privately with the people involved.
Third, is there a smaller way to answer the question? Maybe the buyer can read a story already approved for this use. Maybe a product or delivery lead can answer first, and the customer call is reserved for what only a peer can explain. Maybe the customer would rather send two written points than join a live meeting. Maybe this is simply the wrong week.
Then make one decision: ask as planned, make a smaller ask, use existing proof, or wait. Give a reason. If you wait, say what would change the answer. "Not now" should not become a quiet veto with no next step.
The Reference Request Note is one page for that conversation. It isn't a new database or a score for how generous a customer has been.
How the made-up request could end
The account owner learns that the buyer wants to know what went wrong during rollout and how the customer handled it. That is a good peer question. The existing case study doesn't answer it. A product demo won't answer it either.
The customer has already given time to the event and the story, so the account owner checks with CS before asking again. They send the question, explain the audience and ask whether a call next week would suit. They also offer the buyer an approved story for now.
The customer can say yes, choose another time, suggest a colleague, or decline. There is no invented happy ending here. The point is that she gets a real choice, and the prospect gets a reference matched to the question rather than a name pulled from a list.
If she says yes, prepare both sides. Tell the buyer which topics are fair game and which are not. Don't script the customer to make the product look flawless. If the buyer needs to hear only praise, the team isn't looking for a reference. It is looking for an ad.
Try this on the next request
Pick one live request this week. Before anyone contacts the customer, ask the account owner to write down the buyer's question and the exact customer ask. Then choose the least demanding way to answer it. Use the existing opportunity notes; you do not need a new process for every deal.
Afterward, check whether the customer was comfortable with what happened and whether the buyer's question was actually answered. Don't count the customer's yes as the whole result.
You won't learn from one request whether this changes retention or win rates. You will learn whether your team knows the difference between a customer willing to help and a customer with time to spare.
The job is not to protect customers from every ask. It is to make the ask worth making.
Sources and methodology
Accessed 6 October 2026. The opening and closing situations are illustrative, not customer stories or Kuber's experience. The four-way decision and Reference Request Note are original editorial proposals. No causal claim about win rate, retention or churn is made.
By Kuber Sethi · All issues · Subscribe