For most of my career, telemetry has been a way of making complicated systems easier to understand.
I spent years in telecoms and network performance, then moved deeper into enterprise software and observability. At IBM I owned the global Digital Customer Success and product-led growth operating model across 34 software businesses and more than 30,000 customers. With Instana, part of the work was defining the telemetry and instrumentation that helped us see what customers were genuinely adopting, which capabilities they reached and where they stalled.
The question underneath all of that was familiar: what is actually happening?
I now find myself asking the same question about the customer journey after a software sale. We can see product usage, feature activity, support history and implementation milestones, yet it can still be difficult to connect those signals back to the outcome that justified the purchase in the first place.
A customer can be live and active while the evidence of business value is still weak or fragmented. When renewal gets closer, the problem may not be a lack of data. It may be that nobody can trace a clear line from what was sold, through what changed, to the outcome the customer can now demonstrate.
That is the telemetry problem I am interested in now.
The customer journey is one system
Companies naturally divide the post-sale journey across teams. Sales sees one part, implementation another, Customer Success and product see their own signals, and finance eventually sees the renewal or expansion number.
The customer experiences the whole thing.
A working model I use at Routeability is:
Outcome sold → Handoff → Deployment → First value → Adoption → Provable outcome → Renewal → Expansion
I do not treat this as a universal journey, and I do not assume the break happens in the same place for every company. It is simply a way of making the transitions visible enough to investigate.
Sales may have captured a strong business outcome, but some of that context can weaken during handoff. Implementation may complete successfully without a clear definition of the value the customer expects to prove. Product usage may rise while the commercial outcome remains vague. In other cases, the route may be working perfectly well and the real problem sits somewhere else entirely.
That is why I am wary of starting with a solution category. If retention is under pressure, the answer is not automatically to redesign Customer Success. If adoption looks weak, another playbook may not be the first move. If the team is overloaded, automation may help, but only once we understand what is actually getting in the way.
Product telemetry is only part of the evidence
Product telemetry can tell us a great deal about behaviour inside the product. It can show whether customers reached particular capabilities, how often they use them and where activity changes.
That is useful evidence, but it does not, on its own, tell us whether the customer achieved the result they bought the software to produce.
To get closer to that, the product signals need context. What was the customer trying to change? What would count as progress? What would they need to be able to show internally? When should that evidence become visible? Who needs to believe it?
This is where my thinking about telemetry has shifted. In observability, collecting more signals does not automatically create understanding. The useful system is the one that helps you establish what is happening, what changed and where to look next.
I think the same principle applies to customers.
What I mean by customer telemetry
I am not suggesting that every SaaS company needs another giant data platform.
By customer telemetry, I mean a connected evidence model for the route from customer commitment to demonstrated value. It should help a company see what outcome was sold, how that outcome was translated into the post-sale motion, what evidence of progress exists, where confidence is weak and when a problem first becomes visible.
Some of that evidence will come from the product. Some will sit in CRM, implementation and support systems. Some will come from conversations with the customer. The important thing is whether those signals can be connected well enough to answer the commercial question:
Can we still see the outcome the customer bought, and can the customer show that they are getting closer to it?
If we can answer that early, the team has more room to intervene intelligently. If the question only becomes serious when renewal is approaching, the available options are usually narrower.
Start with diagnosis, not another playbook
This is the thinking behind the Revenue Diagnostic I am developing at Routeability.
The starting point is deliberately simple: establish what is happening today before prescribing a new operating model. Look at the outcome that was sold, trace how it moves through handoff, implementation and adoption, identify the evidence the business currently has, separate observable symptoms from plausible causes, and keep the unknowns visible.
From there, the work might involve the customer journey, a common taxonomy across teams, adoption, or automation and AI. Those areas are connected, but they are not a fixed checklist and they do not need to be tackled in the same order.
Sometimes the most useful finding may be that the expected problem is not the real problem.
The model needs to be challenged
I am not treating this as a universal diagnosis. I do not know that weak outcome continuity is the main cause of churn across the market, that one executive role always owns the problem, or that a better evidence model automatically improves retention. Those questions need evidence.
That is why I have been building a recognition interview alongside the diagnostic. I want people to challenge the model before I treat it as established. Which parts feel familiar? Where does the route really break? What happens when it does? When does it become visible? What would make the issue important enough to act on? What evidence would be required before investing in a fix?
Disagreement is useful. If customers describe the problem differently, the model should change.
The question I keep coming back to is simple: when a customer reaches renewal, can both sides point to credible evidence of the outcome that justified the original purchase, or are they reconstructing the value story too late?
That is the problem Routeability is being built to investigate and improve.
