Customer Success
Why Customer Success Should Own Its Data
Most Customer Success organizations operate on borrowed data. Health scores built on product telemetry they didn't define. Usage metrics aggregated by engineering teams solving for different questions. CRM fields designed around pipeline progression, not customer outcomes. The result is a function that's accountable for retention, expansion, and increasingly for gross profit contribution, yet has no authority over the inputs that drive those results.
This isn't an access problem. Most CS teams can get to the data they need eventually: after a request to BI, a compromise on definitions, and a lag that makes the insight stale by the time it arrives. The problem is structural. When CS inherits its data model from Product, Sales, or a centralized data team, it inherits their priorities, their assumptions, and their blind spots.
The consequence is predictable: CS operates reactively. It responds to signals someone else decided were important, on a timeline someone else set, using definitions that may not reflect what actually drives outcomes in a specific book of business. A health score that weights login frequency is meaningless when your product is an API. An adoption metric that counts active users tells you nothing about whether the economic buyer, the person who signs the renewal, has seen value.
None of this is controversial in isolation. Most CS leaders would agree with every sentence above. Where it gets harder is the implication: that the fix isn't better dashboards or faster data access, but a fundamental shift in who owns the data model that CS runs on. That shift requires investment, cross-functional negotiation, and a willingness to challenge how the organization has always worked.
Before any of that, though, it requires a more basic decision. One that most companies skip.
What do you actually want from CS?
The question sounds obvious, but the answer rarely is. In practice, CS organizations tend to fall into one of two models. In the first, CS is an education and enablement function: it drives adoption, handles renewals, and serves as a trusted resource for the customer. Expansion and commercial negotiation belong to Sales or Account Management. In the second, CS is a full commercial function that owns net revenue retention, drives upsell and cross-sell, and is accountable for a number.
Both models are valid. But they have very different data requirements, and most organizations never make the choice explicitly. They end up somewhere in the middle, asking CS to surface expansion opportunities without giving it the commercial authority or the data infrastructure to act on them.
In the commercial model, the case for data ownership is direct. If CS is accountable for revenue retention and expansion, it cannot run on data definitions it didn't set. You can't commit to a retention target when someone else decides what "at risk" means at the data layer. You can't forecast expansion when the signals that indicate a customer is ready to grow — consumption patterns, multi-product adoption, stakeholder engagement — are aggregated in ways that serve Product's roadmap, not your pipeline. And in the current environment, where boards and investors have shifted from rewarding top-line growth at any cost to demanding profitable growth, the stakes are higher. CS is increasingly expected to protect and grow not just revenue but gross margin: retain the right customers, expand in ways that don't erode unit economics, and flag accounts where cost-to-serve is outpacing value. That requires visibility into gross profit at the account level, which in most organizations lives in Finance's systems, not CS's.
In the education and renewal model, the argument is less about accountability and more about operational autonomy. CS needs to know which customers are actually adopting in ways that correlate with renewal, not just which ones are generating activity metrics. And even in this lighter model, the problem doesn't disappear; it migrates. Whatever team does own expansion inherits the same data gaps, often with even less context to fill them.
The model a company chooses should shape everything downstream: team structure, comp design, tooling, and above all, who has authority over the data that powers customer decisions.
Where the data actually breaks
Three points of failure show up consistently across SaaS and CPaaS organizations.
The handoff from Sales. When a deal closes, CS typically receives an opportunity record: ARR, contract dates, perhaps expected margin profile if it's lucky, and some unstructured notes. What CS actually needs is different: what was promised in the sales cycle, what use case the customer bought for, who the internal champion is, what their technical environment looks like. That information either doesn't exist in structured form or lives in places CS can't operationalize. In CPaaS, this is compounded by the technical dimension: is the customer integrating via API or a low-code interface? Are they replacing an incumbent, and if so, what's the migration complexity? These details determine the entire engagement model, and they're almost never captured in the CRM in a way CS can use. The result is that CS spends the first weeks of every new engagement doing discovery that should have been completed before the deal closed.
The gap between product telemetry and customer intelligence. Product teams instrument for product decisions: feature adoption, funnel conversion, roadmap prioritization. CS needs customer-level intelligence: is this account's consumption growing or plateauing? Are they broadening across the platform or stuck on a single use case? Did a usage spike come from a seasonal campaign or a new workflow integration? And critically, is this account's gross margin healthy, or is consumption growth masking a cost-to-serve problem? In CPaaS, where COGS can vary significantly by channel and by carrier route, an account that looks like a growth story on revenue alone may be margin-negative on its fastest-growing product line. The raw data may be the same, but the aggregation logic, the time horizons, and the entity model are different. Product thinks in features and endpoints. Finance thinks in consolidated P&L lines. CS needs to think in accounts, use cases, and commercial trajectories, with revenue and margin together.
The consultant playbook problem. Organizations that bring in external advisors to design their CS operating model often receive frameworks built on generalized SaaS best practices. These frameworks assume seat-based licensing, predictable usage patterns, and a customer engagement model that maps to QBR cadences and adoption milestones. In consumption-based or usage-based businesses like CPaaS, these assumptions break down. The metrics that matter, the signals that indicate risk or expansion readiness, and the cadence of engagement all look different. A one-size-fits-all data model applied to a business with fundamentally different economics leads to CS teams optimizing around the wrong signals.
What ownership actually looks like
CS doesn't need to build a data warehouse or hire a data engineering team. What it needs is defined authority over a specific layer: the customer data model that sits between raw telemetry and operational tooling.
In practice, this means CS has authority over how health scores are computed and what signals feed them. CS defines the thresholds and logic for risk and expansion flags, not a BI team interpreting requirements at a distance. CS participates in the instrumentation roadmap so that product telemetry includes the events CS needs, not just the ones Product prioritizes. And the handoff schema from Sales to CS is co-designed, with structured fields that capture what CS needs to operate, not just what Sales needs to close.
This is partnership, but it's structured partnership. Defined data contracts, not standing requests in someone else's backlog. The investment isn't in new infrastructure. It's in governance: clear ownership of who defines customer-facing data models, a process for resolving conflicts when CS's definitions diverge from Sales's or Product's, and executive sponsorship that treats this as an operational priority rather than a tooling request.
The barrier to doing this is also lower than it was even two years ago. Frontier large language models have made it possible for operations-minded CS teams to take fragmented data exports from across the business — CRM extracts, billing files, usage logs, margin reports — and normalize them into structured, actionable reporting without a dedicated engineering sprint. What used to require a BI team and a quarter on the roadmap can now be prototyped in days. The bottleneck is no longer technical capability. It's whether CS has permission to access the raw data in the first place, and the organizational standing to define what it means.
The objection will be that this creates duplication and competing definitions. The reality is that competing definitions already exist — they're just implicit. CS already maintains its own spreadsheets, its own health score overrides, its own shadow tracking of which accounts are actually at risk versus what the system says. The choice isn't between one clean data model and a fragmented one. It's between fragmentation that's invisible and ungoverned, and fragmentation that's visible, intentional, and managed.
The cost of not deciding
Companies that leave CS's relationship to its data undefined pay for it in ways that don't show up on a dashboard. They pay in longer onboarding cycles because CS is rebuilding context that should have transferred at close. They pay in missed expansion signals because the data model doesn't surface them until it's too late. They pay in retention strategies that protect revenue without regard to margin, because CS never had visibility into gross profit at the account level. They pay in analyst and ops time spent stitching together workarounds that shouldn't need to exist. And they pay in the slow erosion of CS's credibility as a commercial function, because a team that can't point to its own data with confidence will always be at the mercy of whoever can.
The starting point isn't a technology decision. It's an organizational one: decide what you want CS to be, then give it the data authority that model requires.
