What breaks when you land your first enterprise customers.

The first enterprise logo is a milestone. It's also the point at which a post-sale function that has worked perfectly well quietly stops working — and it usually takes two or three renewal cycles before anyone understands why.

Mid-market adoption is forgiving. The person who buys is usually the person who uses it, decisions are made by a handful of people in one room, and if the product is good the usage follows. Enterprise breaks all three of those assumptions at once, and most CS functions meet them without noticing they've changed.

What actually changes when you move upmarket

Four things, and they compound.

The buyer isn't the adopter. A VP signs against a business case. Adoption then depends on several hundred people across business units who never met your Sales team, weren't consulted, and have an existing process they're reasonably happy with.

Adoption requires internal change your customer has to run. In mid-market, adoption is largely a product experience. In enterprise it's a change programme inside someone else's organisation — and your customer's capacity to run that varies enormously.

Time to value stretches, and so does the gap before you know anything. A three-week onboarding tells you quickly whether it's working. A six-month enterprise rollout can look fine at every checkpoint and still be failing, because the checkpoints measure deployment rather than use.

The renewal is decided by people who never met you. Procurement, a finance business partner, possibly a sponsor who inherited the contract. They assess it on evidence, not relationship — and if nobody assembled that evidence, the absence is what they find.

What looks like a retention problem is almost always an adoption problem. And the adoption problem was seeded in the first ninety days.

The pattern that keeps repeating

In most enterprise motions I've diagnosed, the shape is consistent: Sales closes against a specific use case and a specific set of stakeholders. CS inherits the account later with a different brief, different contacts, and no agreed adoption trajectory. The customer fills that gap with their own expectations, which rarely match what was sold.

The seam isn't visible to you. It is extremely visible to them.

What the handoff should actually transfer

Most handoffs transfer contract facts: seats, use case, named stakeholders, timeline, anything sitting in a CRM field. All useful, none of it sufficient — because what determines adoption is organisational reality, and none of that is in the CRM.

Nobody hands over that the operations director was sceptical throughout. That there's a competing internal tool with a loyal following in one division. That the sponsor committed without consulting the people who'll actually use it. That the business case assumes a process change nobody has yet agreed to.

That information exists — Sales encountered all of it during the cycle. It's simply never asked for, because handoff is designed as a data transfer rather than a briefing. The fix isn't a better checklist. It's CS engaged during late-stage sales, adoption milestones defined before signature, and commercial accountability for the first ninety days shared rather than transferred.

Finding the champion, not inheriting the sponsor

These are different roles and conflating them is one of the most expensive mistakes in enterprise post-sale.

A sponsor has budget and political cover. A champion has credibility with the people who have to change how they work. Your sponsor is rarely your champion — they're usually too senior, too removed from daily use, and their enthusiasm doesn't transmit downward as well as they think it does.

The champion usually has to be found after signature, and sometimes built. That means identifying who the users actually listen to, and giving that person a reason to advocate: early access, influence over configuration, visible credit when it works. It's deliberate work, and almost nobody plans for it, because the deal already had an enthusiastic person attached and everyone assumes that's the same thing.

A sponsor without a champion produces the most common enterprise failure mode: executive commitment, flat usage, and no one who can explain the gap.

Whose change management is this?

Enterprise adoption is behaviour change in an organisation that didn't sign your contract. Someone has to run that — communications, training, workflow redesign, dealing with the team that liked the old way.

Your customer might have a change function that does this well. Most don't. The failure is assuming it will happen because the contract is signed, and discovering in month five that nobody owned it.

So assess it explicitly during onboarding. Has this organisation rolled out something like this before? Who ran it? What happened? If the answer is thin, that's not a reason to walk away — it's a gap you can fill, and filling it is worth more than any feature conversation you'll have that year. It's also where an expansion case is most often found.

Reconciling the business case with the user experience

This is the bridge between the two sides, and it's usually missing.

What was sold is a business case in the sponsor's language — efficiency, risk reduction, consolidation. What drives adoption is whether an individual user gets something out of it in week three. Those are different claims, and both have to be true.

If you only track the business case, usage stays flat while everyone reports progress. If you only track usage, you arrive at renewal with engagement data and no answer to the question the CFO asks, which is what this bought us.

Agree both up front, in the customer's own numbers, and instrument both. The discipline is deciding at onboarding what evidence you'll need at renewal, then collecting it as you go — rather than assembling a case retrospectively in the last quarter, which is when it's least convincing and hardest to gather.

When the sponsor leaves

The recurring version of the same problem. Your sponsor moves on in month fourteen. Their replacement inherits a contract they didn't choose, from a vendor they have no relationship with, and arrives with their own priorities and often their own preferred suppliers.

If you built a champion in the user organisation, you have advocacy that survives the change. If your entire relationship was the sponsor, you're starting from nothing with a renewal a quarter away — and by then the evidence either exists or it doesn't.

This is why the first ninety days matter beyond the first ninety days. What you establish then is what you still have when the people change.

The trajectory is set early

None of this is irreversible, but it gets steadily more expensive to fix. An adoption trajectory set in the first quarter can be changed in the second at moderate cost, in the fourth at considerable cost, and in the renewal quarter not at all.

When the handoff is designed, the customer never feels the seam. When it isn't, the seam becomes the story they tell internally when the renewal conversation begins.