Key Takeaways
The proposal lands in the VP of customer operations’ inbox on a Monday. RevOps wants to become the single source of truth for everything after the signature. Support tickets, onboarding milestones and help centre activity will sync into the CRM, and RevOps will own the fields, the definitions and the dashboard. The pitch is reasonable. One team, one view, one number for the board. She reads it twice and can’t say what’s wrong with it, only that the people who’d have to keep that data correct aren’t the people who’d own it.
That instinct is right, and the evidence explains why. The customer operations vs revenue operations question is usually framed as a reporting-line debate. If you need the definition first, start with what customer operations covers. The more useful framing here is narrower: the post-sale record has three partial owners today and no whole one. The fix isn’t to hand the whole record to the team that reads it most. It’s to give it to the team that produces it.
What revenue operations was built to own
RevOps has a precise origin. In April 2019, SiriusDecisions (now part of Forrester) published a revenue operations charter. It defined RevOps as “a set of operating principles shared between sales operations, marketing operations, sales enablement, and customer success” that aligns planning, processes, systems, data and measurement. Four functions are named. Support isn’t one of them, and neither are onboarding, self-service or knowledge.
Two months later the same firm described how RevOps usually shows up in practice. The most common form, it wrote, was “not a new organization composed of these teams but a ‘coalition of the willing’”. Forrester repeated the point in 2023: alignment “doesn’t necessarily mean creating a single, centralized revenue operations function”. RevOps was a charter for making the revenue functions agree, not a mandate to absorb them.
Our post on customer operations team structure covers why copying that org chart fails. This one is about something the org chart hides: data. The same 2019 framework lists data as a charter element and asks whether “data across the revenue engine support[s] consistent and interdependent planning, execution and measurement”. It’s a question about consistency. It says nothing about who produces the data or who fixes it when it’s wrong.
What RevOps teams actually spend their time on
Definitions are one thing. Duties are another. The Revenue Operations Alliance’s 2024 survey of practitioners gives the clearest picture. “The most common revenue operations responsibility is metrics and KPIs with a huge 92.25% of our respondents saying that’s a main part of their role. This is followed by pipeline strategy (78.29%).” The survey doesn’t publish its sample size; the percentages resolve to roughly 129 respondents. Almost half, 45.74%, came to RevOps from sales operations.
RevOps isn’t ignoring the post-sale world, and it would be unfair to say so. Revenue retention is the third most tracked metric in the same survey, at 65.89%, and the fastest growing, up 20.79% from 2023. RevOps increasingly reports on what happens after the signature. The question is what it reports from.
Clari’s 2024 Revenue Leak Report is a vendor survey, but a large one: 420 revenue leaders, fielded by Vanson Bourne. Its answer to where revenue leaks points squarely at the funnel. “65% of senior RevOps leaders report that a main reason their organization experiences Revenue Leak is hidden or incorrect forecast and pipeline details.” When the same leaders listed where they were spending on new technology, the top three were sales forecasting (34%), sales enablement (33%) and sales engagement (30%). No support, onboarding or customer success category appears on the list at all.
That’s not a criticism. It’s a job description. RevOps is built to make the forecast trustworthy, and it spends its time and money on the inputs closest to the forecast. The inputs furthest from it are the ones customer operations produces.
Who owns the post-sale record today
Put the verified sources side by side and a pattern appears. Every post-sale data asset has an owner, but no two assets have the same one, and one set has none.
| Post-sale asset | Who the evidence says owns it | How consistently |
|---|
| Revenue forecast and pipeline data | RevOps: pipeline strategy is a main duty for 78.29% | Consistently |
| The renewal | CS about 50%, renewal teams 15%, sales 8% (ChurnZero, n=1,027); CS 42%, account management 33%, sales 15% (Gainsight, ~400 companies) | Split three ways |
| Net revenue retention | CS 63%, shared with account management 31% and sales 24% of the time (Gainsight, 2022) | Split |
| Support interaction data | Service tools, fully integrated with customer data for only 35% of service leaders | Minority |
| The boundary between CS and support | Deliberately enforced: the one CS strategy most teams have fully implemented | Most teams |
| Onboarding, knowledge and self-service data | No owner named in any RevOps definition or survey reviewed for this post | None found |
Read the table from the top down and the distance from the forecast grows with each row. RevOps holds the forecast firmly. The renewal, which the forecast predicts, is split three ways and has been for years, which is why renewal management so often runs on whoever notices first. ChurnZero’s study notes that “an approximate but consistent 50% of CS teams have ‘owned’ the renewal process” for five years running.
Then the support row. CS has spent the same five years pulling away from support. ChurnZero reports that “aside from establishing a clear delineation between CS and technical support, most CS teams report that their strategies are only partially implemented”. Gainsight’s analyst saw the same shift: “The percentage of CSMs responsible for Customer Support is going down.” CS is becoming commercial and letting go of the service signal as it goes.
The last row is the important one, and it needs a careful label. No source reviewed here names an owner for onboarding, knowledge or self-service data. That’s an absence in the sources, not a measured finding. But it matches what anyone running customer operations sees: the questions customers asked, the answers they couldn’t find and the milestones that slipped live in tools nobody on the revenue side reads.
Why the post-sale data should be owned where it’s produced
RevOps’ proposal in that Monday email rests on an assumption: that whoever consumes the most data should own it. The assumption works for pipeline, because RevOps also defines the pipeline stages and polices how reps log them. It breaks for post-sale data, for three reasons.
Principle 1: the producer knows when the data is wrong
A ticket tagged with the wrong product, a help article that answers last year’s version, an onboarding milestone marked done that wasn’t: the support lead, the knowledge owner and the onboarding manager catch these because they work in the records every day. A team that reads a synced copy weekly can’t. Ownership without daily contact produces tidy fields and wrong data.
Principle 2: definitions belong to the people who apply them
What counts as a resolved question, a repeat contact or a completed onboarding step is decided hundreds of times a day by the people doing the work. If RevOps owns those definitions from a distance, every change needs a ticket to another team. The definitions drift from practice, and the dashboard reports a world nobody works in.
Principle 3: copies decay, and the forecast inherits the decay
Only 35% of service leaders in HubSpot’s 2024 survey of 1,537 said customer data was “fully integrated with their service tools”. Every partial sync is a copy that ages. Clari’s respondents already name bad forecast data as their biggest leak. Feeding the forecast a stale copy of the support signal adds to that leak rather than closing it.
So the division of labour that holds up is simple. Customer operations produces and maintains the post-sale record: requests, onboarding progress, knowledge and self-service activity, with owners and definitions. RevOps consumes it, joins it to revenue data and builds the forecast. That’s the same relationship RevOps already has with finance on bookings. Nobody proposes that RevOps own the general ledger.
How to split ownership without a reorg
None of this needs a new reporting line. It needs a written agreement about four things, one row per post-sale data asset.
- Name the producing team. Support for requests and resolutions. Onboarding for milestones and time to first value. The knowledge owner for articles, search gaps and self-service resolution. CS for the renewal conversation itself.
- Name the definition owner. Usually the producer. If RevOps needs a different cut for the forecast, it defines a derived field, not a replacement.
- Agree the hand-off. Which fields reach the CRM, how often, and in what state. Summaries and signals travel; raw working records stay where the work happens.
- Agree who fixes errors. When a forecast input looks wrong, the ticket goes to the producing team with the record, not to RevOps to patch the copy.
The agreement fits on one page. It also gives RevOps something the synced-everything plan never would: inputs that someone is accountable for keeping correct. The customer lifecycle management post walks through the stage hand-offs that each row depends on, and customer operations vs customer success covers where the CS boundary sits.
Where customer operations keeps the record
The weak point in the plan is usually tooling. If support lives in a help desk, onboarding in a spreadsheet, knowledge in a wiki and self-service analytics nowhere, customer operations can’t be the producer of one record. It’s the producer of four exports. That’s often why the RevOps proposal looks attractive in the first place. Our buyer guide can help you compare customer operations software.
MatrixFlows gives customer operations one foundation to produce that record on. Requests arrive through forms, chat, email and ticketing sync as items in the Conversations Inbox. Onboarding runs as a project the customer can see. Knowledge and help centre content sit in the same structured tables, with search analytics that show the questions nobody could answer. Because every record is typed and linked, the hand-off to RevOps becomes a defined sync. An automation can post a resolved request or a completed milestone to the CRM by webhook, carrying the fields both teams agreed. RevOps gets clean inputs. The people who produce them keep owning them.
Back to the Monday email. The reply that holds up isn’t “no”. It’s a one-page table: here’s what we produce, here’s the definition, here’s what reaches the forecast and when, and here’s who fixes it. That’s a better single source of truth than a synced copy owned by the team furthest from the work.
Create a Free Workspace → and map your post-sale records to their producers before the next data-ownership meeting.
.svg)
.svg)
.svg)
