Low adoption is one of the most dangerous symptoms in customer success because it invites premature solutions. The current Cisco 820-605 CSM blueprint explicitly expects candidates to identify adoption barriers, use multiple evidence sources, and select actions that address problems such as stalled implementation, lost sponsorship, product quality issues, missing capabilities, or poor product fit.
Those categories matter because “users are not adopting” is not a diagnosis. It is an observation. The same usage pattern can come from a broken integration, a training gap, an approval bottleneck, a cultural objection, a licensing limitation, weak executive sponsorship, or a feature that simply does not solve the intended problem.
A disciplined Customer Success Manager treats adoption like an operational incident: establish the expected behavior, compare it with the baseline, collect high-value evidence, isolate the likely cause, choose the smallest corrective action that addresses that cause, and then validate whether behavior changed.
Define what successful adoption would look like
Before investigating a problem, the team must know what it expected. “More usage” is too vague. A useful adoption statement names the users, use case, frequency or milestone, and connection to the desired outcome. For example: branch administrators should use the standardized deployment workflow for new sites so provisioning time and configuration variance decline.
This definition determines what data is relevant. Login counts may be meaningless if the workflow is automated. Feature clicks may be irrelevant if the desired outcome depends on a small specialist group. A successful deployment may still show low user interaction because the value is delivered through background automation.
The success plan should therefore contain an adoption hypothesis: if this population uses this capability in this way, it should contribute to this operational or business result. That hypothesis gives the CSM something testable rather than a generic engagement target.
Separate implementation barriers from behavior barriers
A common mistake is to treat incomplete deployment and poor adoption as the same problem. If the integration is not finished, the service is unstable, or required data is missing, users may be rational to avoid the capability. Training them harder will not fix the system.
Implementation evidence includes deployment milestones, open defects, integration status, performance, access, data quality, and readiness of dependent services. Behavior evidence includes who is using the capability, which workflows remain on the old path, where users abandon the process, and whether managers reinforce the new behavior.
The distinction changes ownership. A technical barrier may belong to engineering or support. A process barrier may belong to the customer’s operations team. A sponsorship barrier may require executive attention. Customer success coordinates the system but should not pretend every problem can be solved by the CSM personally.
Use telemetry to narrow the problem, not to finish the diagnosis
Usage data is powerful because it shows what happened at scale, but it rarely explains why. A sharp drop after a release can point toward a technical regression. Concentrated use in one team can reveal a successful local champion or a permissions difference. Repeated abandonment at the same workflow step can identify friction.
Telemetry also has blind spots. It may not capture work completed outside the product, shared accounts, offline processes, or the business reason a user chose another path. It may lag. It may aggregate populations that behave differently. A dashboard can therefore produce a precise picture of the wrong question.
The CSM should use telemetry to generate hypotheses and then test them through conversations, process observation, support history, and stakeholder evidence. The strongest diagnosis combines what the system records with what the customer is actually trying to accomplish.
Classify the barrier before choosing the action
Cisco’s barrier categories—business, operational, technical, and corporate culture—create a useful forcing function. A business barrier may be a changed priority or weak funding. An operational barrier may be unclear ownership or a workflow that has not been redesigned. A technical barrier may be reliability, integration, performance, or missing functionality. A cultural barrier may be distrust, change fatigue, or incentives that reward the old process.
The categories can overlap. A performance problem can damage trust and become a cultural barrier. A lost sponsor can cause budget and ownership problems. The goal is not to force one label but to identify the mechanism that must change.
This diagnostic mindset complements broader technology adoption planning. Adoption programs work best when they address both the capability being introduced and the organizational conditions required for people to use it.
Prefer targeted experiments over broad campaigns
When the cause is uncertain, a small intervention can create better evidence than a company-wide campaign. If one user group has low adoption, the CSM might compare its workflow, permissions, training, and management expectations with a group that is successful. If users stop at one step, a focused usability or process change can test whether that friction is causal.
Targeted experiments reduce the cost of being wrong. A broad training program can consume time while the real problem is access. A major configuration change can introduce risk when the obstacle is sponsorship. The CSM should choose an action that is proportional to the evidence and easy to evaluate.
Every intervention needs a success condition and observation window. Otherwise, the team can declare victory because activity occurred—sessions delivered, emails sent, configuration changed—without knowing whether adoption or value improved.
Treat lost sponsorship as a structural change
Cisco specifically calls out loss of a project sponsor because it changes more than communication. Sponsors often provide authority, funding, conflict resolution, and a connection between the solution and the business priority. When that role disappears, adoption can stall even if the technology is healthy.
The CSM should identify which responsibilities were actually being performed by the sponsor. Is a new executive decision-maker needed? Has the business outcome changed? Does the success plan still reflect current priorities? Are operational teams now waiting for decisions nobody owns?
Replacing a name in a stakeholder list is not enough. The account may need to revalidate outcomes, success criteria, governance, and review cadence. Sponsor loss is therefore both a relationship event and a systems event.
Know when the product-fit hypothesis is wrong
Customer-success practice can become unhealthy when every adoption problem is framed as resistance. Sometimes the capability is not the right fit for the use case, a required feature is absent, or the cost of changing the surrounding process exceeds the expected value. Cisco’s outline explicitly includes lack of product features and product not being the right fit among common barriers.
This is where trust matters. The CSM should distinguish a solvable gap from a fundamental mismatch and avoid manufacturing activity to hide the issue. A credible recommendation may be to narrow the use case, change the implementation, delay expansion, or involve product and account teams in a more honest fit discussion.
Recognizing poor fit protects long-term relationships because it aligns the success plan with reality. It also improves renewal analysis: unresolved fit problems should be visible as risk rather than disguised as an engagement opportunity.
Validate recovery through behavior and outcome evidence
A corrective action is complete only when the evidence changes. That may mean usage by the target group increases, the blocked workflow completes successfully, support volume declines, time to value improves, or a related business metric begins moving. The exact signal depends on the success plan, not on a generic adoption benchmark.
The Cisco Customer Success model expects the CSM to connect barriers to customer value across the lifecycle. The diagnostic habit is therefore more important than any particular dashboard: define expected behavior, observe the gap, narrow the cause, coordinate the right owner, and prove that the customer is again moving toward the intended outcome.
When adoption rises for the right reason, the change should also be recorded in the success plan. That preserves the lesson, updates risk, and gives future reviews a clear explanation of what changed. Diagnosis becomes institutional memory instead of a one-time rescue.
Adoption diagnosis is stronger when the team keeps a short barrier log. Record the observed symptom, evidence sources, working hypothesis, owner, intervention, and validation result. This prevents the same account from cycling through repeated “enablement” activity without learning why previous attempts failed. It also helps a new CSM inherit the reasoning rather than only the history of meetings.
Timing can reveal causality as well. If usage dropped immediately after an access-policy change, that event deserves investigation before a broad cultural explanation. If adoption has been flat since launch despite stable technology, process and sponsorship become stronger hypotheses. The CSM should use sequence and correlation carefully—not as proof, but as a way to prioritize the next piece of evidence.
Finally, corrective action should preserve customer agency. The goal is not to push users toward a metric because the vendor wants adoption. The goal is to remove barriers to a use case the customer has already connected to an outcome. If the customer’s priorities have changed, the success plan should change too.
A useful diagnostic checkpoint is to ask what evidence would disprove the current hypothesis. If the team believes training is the problem, what observation would show that trained users are still blocked? If the team believes performance is the cause, what would show healthy performance with the same low adoption? This habit reduces confirmation bias and encourages the CSM to seek evidence that can change the plan, not only evidence that supports the first explanation.
It also makes escalation cleaner. Technical teams receive a better-defined symptom and evidence set, business owners see the process or sponsorship dependency, and the customer understands why the proposed action is tied to the observed barrier.
