An enterprise account's usage has flatlined six months after an onboarding everyone called a success. How do you work out why?

Short answer

If enterprise adoption stalls after onboarding, first prove the usage data is real, then check whether the sponsor or champion changed and whether the live workflow is the one the customer funded. Recovery usually comes from fixing the blocked business outcome, not from scheduling another generic training session.

Start by doubting the number

"Usage flatlined" is a claim about your telemetry, not about the customer. Before you build a recovery plan you have to know whether anything changed in what you are counting. A licence reassignment, a move behind a corporate proxy that broke client-side event collection, a switch from your UI to your API, an SSO migration that silently created a second tenant — each of these produces a flat line that has nothing to do with the customer's enthusiasm. So does a metric that was never a proxy for value in the first place. Weekly logins are the classic offender: a team that automated its workflow through your API may log in less every month while getting more out of you than it ever did.

The first hour is therefore spent reconciling. Take one thing you know the account does with the product, find it in the data, and confirm it appears. If it does not, you have an instrumentation problem masquerading as a churn risk, and the honest move is to fix the measurement and re-baseline rather than open a conversation about disappointing adoption with a customer who is not in fact disappointed.

Then ask who the account is now

Enterprise accounts are bought by people, and people move. The onboarding you are proud of was designed with a sponsor who had a reason to care and a champion who did the internal work. Six months is long enough for either to have changed role, changed team, or left. When the champion goes, three things go with them: the internal narrative for why the tool exists, the informal support desk that answered colleagues' questions, and the political cover that made the rollout mandatory rather than optional.

The signal is usually in your own records rather than in the product. Who has stopped replying to your emails. Who is on the recurring call now. Whether the person who signed the order form still appears in the customer's own directory. If the answer is that the account has quietly changed hands, your problem is not adoption, it is that nobody currently inside the customer can explain the purchase. That is a different piece of work, and it starts with re-establishing the business case with the new owner rather than teaching anyone to use a feature.

Then ask whether you deployed the right thing

The most uncomfortable finding is that onboarding succeeded at the wrong objective. Enterprise deals are frequently sold on an ambitious use case and implemented on an easy one, because the easy one can go live inside the onboarding window and the ambitious one is blocked on a data feed, a security review, or another team entirely. Everyone declares victory at go-live. The trouble is that the easy use case was not what the budget was approved for, so it generates no visible business result, so nobody defends it when attention moves on.

flowchart TD
    A[Usage flat at six months] --> B{Is the telemetry<br/>measuring real work}
    B -- no --> C[Fix instrumentation<br/>then re-baseline]
    B -- yes --> D{Are the sponsor and<br/>champion still in post}
    D -- no --> E[Rebuild the business case<br/>with the new owner]
    D -- yes --> F{Was the deployed use case<br/>the funded one}
    F -- no --> G[Re-scope onto<br/>the funded workflow]
    F -- yes --> H[Find the manual step<br/>people fell back to]

What to look for in that path is the branch nobody checks: the gap between the use case named in the deal and the use case actually in production. It is the only branch where the account can look green on every onboarding checklist and still be worthless to the customer.

What the evidence looks like in each case

The last row is the one worth chasing hardest. When a team pulls data out on a schedule and does the real work elsewhere, they have told you precisely which step of your product they gave up on, and they will usually explain it if asked directly.

Why reaching for more training is the reflex to resist

More enablement is the default remedy because it is the only one a customer success manager can deliver alone, and because it is never obviously wrong. It is also almost always the wrong answer, for a simple reason: people who understood the product well enough to use it during onboarding did not forget how. If they stopped, something made stopping rational — a step that took longer than the manual alternative, an approval they could not get, a report their manager did not accept, a colleague who told them the output was untrustworthy. Training addresses none of those. Worse, offering it signals that you think the problem is their competence, which is an expensive thing to imply to a customer six months before a renewal.

What does work is narrower and less comfortable. Find one team inside the account with a real deadline, agree one outcome that matters to their manager, remove the specific obstruction in their way even if removing it means engineering work or a change on the customer's side, and make the result visible to the person who pays. Adoption recovers as a by-product of a team getting a result, and almost never as a by-product of a session in a calendar.

What you commit to, and how you will know

Say what you will measure and when, in terms the customer's own management would recognise, and set the checkpoint far enough before renewal that a second attempt is still possible. "Twelve of the eighteen underwriters filing through the tool by the end of next quarter" is a commitment. "Improved engagement" is a description of hope, and an interviewer hears the difference immediately.

Stalled adoption is a symptom with at least four different diseases behind it, and the one thing that treats none of them is another training session.

© 2026 Preptima. Originally published at preptima.com.