CHURN IS DEAD
The Expansion Deal Your CS Team Should Slow Down
7 min read · Customer Growth
The customer wants to buy more. The paperwork can be signed this month. Sales is happy.
Then someone asks who will get it up and running.
The person who manages the system is still busy setting up the last purchase. The new department hasn't agreed to change how it works. The person who approved the budget thinks all of that is sorted.
This is a made-up example, not a customer story. But it raises a real question for Customer Success (CS): when should you slow down a deal the customer is willing to sign?
Not because expansion is bad. Not because every customer must reach some perfect adoption score before buying anything else.
Because wanting to buy something isn't the same as being ready to use it. If nobody checks the difference, the customer success manager ends up trying to keep a promise they didn't make.
I'd want CS involved before that happens. But with a specific objection and a workable alternative, not a vague feeling that the customer “isn't ready”.
Buying more can be the right answer
First, ask why buying more makes sense.
A new feature might solve the problem holding up the current setup. Extra licences might be needed for people already waiting to use the product. One department might be ready even while another is struggling. And if the customer waits, the budget might no longer be available.
“They haven't adopted everything they own” is not enough to reject an expansion. Customers don't owe vendors maximum feature usage. They need a result worth paying for.
The question is narrower: what must be true for this particular expansion to work, and which of those things has someone actually agreed to do?
Now there's something concrete to discuss. Instead of arguing about whether Sales is pushing too hard, you can check whether the person doing the work has time to do it.
Maybe the connection to the other system has already been tested. Maybe the customer has paid for help with setup. Maybe the new team can start without waiting for the old team's problems to be fixed. If so, go ahead.
Don't hold up a good deal because a different part of the account has a problem.
What are we actually promising?
When a customer wants to buy more, I'd put two things next to each other: what they want to achieve, and the work needed to get there.
“Add another department” tells you who's included. It doesn't tell you what those people will do differently, who will help them start or how you'll know it's working.
You don't need a new planning system for this. GitLab's published process puts the customer's goals, the people involved and the steps to get started in a shared plan. That plan carries on after the sale. This is how one company organises the work, not proof that its approach keeps more customers.
That's the useful bit: the plan shouldn't disappear once the deal closes.
Microsoft's guidance for moving to Teams separates what will change, what the team wants to achieve and how it will check success. It also suggests considering a small trial to see whether the people and technology are ready. That's advice for a particular software move, not a study of expansion deals. But the point is useful: agreeing what you want doesn't mean you can do it yet.
Neither source proves that slowing a deal leads to more revenue. What follows is a practical approach I'd suggest trying, not a proven formula.
Write down three things before the deal closes
Use the account notes or plan you already have. The one-page guide below is there to help the conversation, not give everyone another form to fill in.
What does the customer want to achieve?
Write down one thing the extra purchase should help the customer do. Then check it with the person who will actually run the work.
The executive might want every department to use the same system. The team manager might want to stop copying numbers between spreadsheets every Friday. Both matter. But “everyone has an account” won't tell you whether Friday's work got any easier.
Ask why it needs to happen now, too. What would waiting cost? You might not know the exact amount, and that's fine. But don't list every risk of starting while ignoring the cost of doing nothing.
What could stop it from working?
Pick the missing piece that could stop the work. You aren't trying to fix every problem in the account before selling anything.
It might be access to another system, someone's time, a security approval or a feature that isn't available yet. It could simply be that the customer hasn't decided to stop doing things the old way.
Find out who can sort it out and what needs to happen. “The customer will find someone” is a guess. “Their manager has agreed that Alex can spend two days on setup next week” is something you can plan around.
Check your own side just as carefully. If the product can't yet connect to a system the customer needs, their enthusiasm won't change that. Don't promise a date for a feature just because someone hopes it will be built soon.
What can we safely agree to now?
There are usually more options than signing the full rollout or walking away.
You could start with one team, arrange help with setup, or buy now and start later. Sometimes it makes sense to wait until the missing piece is sorted. Any change to price, dates or contract terms needs the right people on both sides to agree. CS shouldn't promise it on their behalf.
Be clear about what you recommend: go ahead, start smaller, or wait. If you say wait, explain what needs to change and when you'll check again. Otherwise “not ready” can leave a deal stuck for weeks, with nobody sure how to move it forward.
What that looks like in a real conversation
Here is a fictional example, not a reported account outcome.
A customer wants three departments to use the same reporting product. The product can do the job. One department has someone free to set it up. The other two need their existing data cleaned up first, and nobody has been given that work.
A weak objection is: “Adoption isn't mature enough.” It gives the account owner nothing useful to work with.
A better recommendation is:
I'd start with the first department. The other two need their data sorted out, and nobody has time set aside for that yet. Let's agree who will do it before we promise their start dates.
The customer might not want to split the purchase. Their buying rules might require one order. The price might be different. Or they might be happy to pay now so they can start when their people are free.
Fine. Just make sure everyone understands that choice. What are they buying now? What starts later? What happens if the data isn't ready in time? Don't say all three departments are ready just because someone can sign the order.
If the customer frees up the right people tomorrow, change the plan tomorrow. The point is to make the work possible, not prove CS was right to say no.
Don't turn CS into a second approvals committee
The obvious objection: aren't we just slowing down deals that would have been fine?
We could be. Nobody needs another meeting and a new score every time a customer buys a few more licences.
Use this check when buying more also means changing how people work. A new department, a connection to another system or a promise of customer time that hasn't been confirmed. If it's just more people using something that already works, a quick check may be enough.
CS doesn't need the power to block every deal. It needs to explain a real risk to the people who can decide what to do about it. Include the customer in that conversation. Don't make the decision for them in an internal meeting.
Sales should be able to push back, too. What's actually missing? What would fix it? What will waiting cost? If CS can't answer those questions, “I'm worried” may not be a good enough reason to slow the deal.
Try it on one opportunity this week
Take one expansion that changes how the customer will work. Bring the account owner and the customer's delivery lead into the same conversation.
Use the Expansion Decision Note to write down what the customer wants, what's missing and what you recommend. Add it to the account notes. Don't start a separate tracker.
Once the first piece of work is due, look back. Was the missing piece sorted out? Did the customer get the result they wanted? Did starting smaller help, or did this extra check just slow down a simple purchase? Be honest about both.
One account won't prove that this keeps customers longer. But it can show you whether you caught a problem worth asking about earlier next time.
The point isn't to save customers from buying. It's to stop a signed order being mistaken for a plan to make it work.
Sources and methodology
Accessed 27 September 2026. The decision note, recommendations and fictional example are original editorial proposals. No causal claim about revenue or churn is made, and no customer or employer experience is implied.
By Kuber Sethi · All issues · Subscribe