Key Takeaways
A customer at a 600-person SaaS company asks one question three ways on the same Tuesday. She searches the help centre and finds an article from last year that says the feature is coming. She asks her onboarding manager, who answers from a Google Doc the onboarding team keeps for itself. She opens a ticket, and support replies with a macro written by someone who left in March. Three answers. None of them wrong on the day they were written. None of them the same.
Nobody on your side lied. Three teams answered from three records, because that’s how the teams are drawn. In 1968 Melvin Conway put it in one sentence that still holds: an organisation “will stamp out an image of itself in every design it produces.” He was writing about software. It applies without edits to the customer operations team structure. The customer never sees the org chart. She meets it anyway, every time she asks a question.
Customer operations team structure is the lever nobody actually pulls
Start with what changes in practice. Intercom interviewed 166 support leaders and frontline staff between January and October 2025. 94.6% had lived through a workflow change, 82.5% a change in roles and responsibilities, and 6.0% a change in team structure or reporting lines. The margin of error is 6.4 points, which is more than most surveys in this space admit to at all. Reporting lines are the last thing that moves, and role definitions are where the real reorganisation happens.
That matches what the retention data says about the levers leaders argue over. Mostly Metrics surveyed 132 tech companies, half of them above $25M ARR, and found no meaningful correlation between CS staffing ratio and revenue retention or renewal rate. Staffing by revenue instead of by customer count made no difference either. ChurnZero’s 2024 study of 1,000 CS leaders found the ownership orthodoxy inverted: in the highest-NRR band fewer than 35% of CS teams owned expansion; in the lowest band 56% did. Some of that is deal size. Bigger contracts fund separate account-management teams. Even after that discount, the finding that “put the number under CS” is what good looks like doesn’t survive contact with the data.
And most teams haven’t drawn the chart anyway. The Customer Success Collective reports 62.2% of customer success teams have no formal structure, and 48.5% have a dedicated CS Ops function, down 11.8% year on year. That’s the better-documented half of customer operations. Support, onboarding and knowledge are less mapped still. If you inherited a chart, you inherited someone’s best guess.
So the question isn’t which boxes go under which VP. It’s which team owns which customer question, and whether the answers come from one record or three. See what customer operations is for the definition this post uses, and how it differs from customer success if the two words are being used interchangeably in your building.
In a customer operations team structure, the customer meets the record, not the reporting line
Go back to the Tuesday customer. Gartner surveyed 5,728 customers and found self-service fully resolved 14% of issues, and 36% of the ones customers themselves called “very simple”. The reasons it failed are the interesting part: 45% said the company didn’t understand what they were trying to do; 43% couldn’t find content relevant to the issue. Neither of those is a search-engine problem. They’re ownership problems. Somebody knew the answer. It lived in a team that doesn’t publish to the help centre.
The cost of the third wrong answer isn’t a ticket. Zendesk’s survey of 5,100 consumers found 63% would switch to a competitor after one bad experience. That’s consumer data, and B2B switching is slower. But the mechanism is the same: the customer doesn’t experience “support” and “onboarding” as separate departments with separate content. She experiences a company that told her three things.
Here is the structural fault under all of it. Support’s knowledge lives in the ticketing tool’s help centre. Onboarding’s knowledge lives in a project tool or a Doc. Product’s knowledge lives in a wiki. Each team’s record is complete from its own chair. The customer’s question crosses all three. Conway’s law is about communication structure, and the communication structure of most customer operations teams is three tools that don’t share a data model. You can reorganise the people every quarter. Until the record is shared, the chart just changes who owns which copy.
The four questions a customer operations team structure has to answer
Define the structure around the customer’s questions, in the order she asks them. Each one has a natural owner, a metric that only that owner can move, and a failure mode when nobody owns it.
| Customer question | Job | Owner | The number only this owner moves | When nobody owns it |
|---|
| Can I find this myself? | Knowledge and self-service | A named knowledge owner | Self-service resolution rate | Questions arrive as tickets |
| How do I get to value? | Onboarding and setup | Onboarding lead | Time to first value | Tickets, then churn risk, then an escalation |
| Who fixes this? | Resolution | Support lead | Resolution time, reopen rate | Support absorbs the other three jobs in disguise |
| Does anyone know this keeps happening? | Feedback to product and knowledge | Whoever owns the record | Repeat-contact rate | The pattern evaporates when the ticket closes |
Two things about the table. First, the fourth job has no team in most companies. It belongs to whoever can see the whole record, which is why it disappears when the record is split. Second, the first job is the one most orgs leave unowned, and it’s the one that decides how much of the other three you need. Name the knowledge owner before you name the queue manager. What that knowledge role looks like is a post of its own.
What’s not on the table: a headcount number, a span of control, a career ladder. Those follow. If you assign them first, you get a support org with a beautiful tier structure and a help centre nobody owns.
Centralised, distributed or hybrid: choose by record, not by headcount
Three shapes show up in practice, and the usual advice is to pick by company size. Pick by record instead.
Centralised. One leader owns all four jobs with a person under each. It works while one head can hold context on all four, usually below 300 employees. Past that, every content decision, escalation and onboarding exception routes through one desk, and the desk gets slower exactly when volume climbs.
Fully distributed. Knowledge sits inside support, onboarding sits inside CS, nobody coordinates. It scales headcount cleanly and recreates the Tuesday problem by design: support writes its help centre, onboarding writes its Doc, and the fourth job has no owner because nobody sees both teams’ inputs.
Hybrid. A small central team owns the knowledge structure, the self-service surfaces and cross-team reporting. Support and onboarding stay close to the customer and read from the same record. It’s the shape most 200–800-person companies end up in, and it has a specific failure mode that the org-design research names precisely: when the boundary is unclear, “hybrid structures degrade into the worst of both: central teams that slow execution without adding standardization, and business units that operate inconsistently”.
The rule that resolves all three: teams that read and write one record can be organised any way you like. Teams that don’t will fragment however you draw the chart. Hybrid works when the shared thing is the record and the distributed thing is the judgment. It fails when the central team owns a tool and everyone else keeps their own copy.
The best-documented example of the rule is a knowledge programme, not a reorg. ServiceNow’s support organisation moved article writing from a small dedicated authoring group to all 500-plus technical support engineers, with coaches mentoring up to five engineers each for two to three months. Cases with an attached article closed 52% faster; 10,000 new articles landed in a year. The percentage has selection bias in it, because easy cases get articles. The structural fact doesn’t: contribution became everyone’s job, and the coaching ratio, not a department, is what made it stick. Set expectations on timing honestly. The Consortium’s own adoption guide puts resolution-time gains in the first three to nine months and the self-service and ramp-time gains at nine to eighteen. Anyone promising a self-service jump in one quarter from a knowledge reorg is selling the chart.
The benchmarks you’ll be handed, and what’s behind them
Any structure conversation gets a deck of ratios thrown at it. Most of them decay on inspection, and knowing which ones is part of the job.
The swarming case studies are the honest exception. Ping Identity’s first ten weeks of collaborative support, published by the Consortium for Service Innovation, showed time to first response down 75%, backlog down 25% and resolution time on complex cases down 81%, held at the six-month check. No control group, one company. But the numbers are real, dated and attributed, which is more than the ratio deck can say. Structure decisions deserve that standard of evidence, and mostly don’t get it.
Two metrics that measure the customer operations team structure, not the effort
Every team in customer operations reports activity: tickets closed, articles published, onboardings completed. None of those tell you whether the structure works. Two numbers do, because neither can be gamed by one team working harder.
Self-service resolution rate. Not deflection, not article views: the share of customer questions that end without a person. Gartner’s 14% is the market’s starting line, and the reasons it’s that low are ownership reasons. The number rises only when the team that knows the answer and the team that publishes it are reading the same record. That makes it a structural metric. Why it plateaus around 15% is mostly the story of that gap.
Repeat-contact rate. How often the same customer comes back about the thing that should have been settled the first time. It’s immune to the vanity that inflates ticket counts. A structure that works drives it down quarter on quarter as the customer count climbs. One that doesn’t shows healthy resolution times while repeat contacts quietly rise, because the same question is answered differently by whichever team picks it up. That’s the Tuesday customer, measured.
Both metrics fail for the same structural reason. When knowledge, onboarding records and support history sit in three systems, nobody can see a repeat contact as a repeat. Each team sees a new ticket. On one record the repeat is visible for what it is: a knowledge gap with an owner, not another item for the queue. That’s the difference a customer operations foundation makes. In MatrixFlows the article, the onboarding milestone, the request and the account are one linked record, and the help centre, the onboarding hub and the agent workspace read from it rather than from three copies. The onboarding manager’s Doc becomes the same page the help centre shows and the agent’s reply cites. Reorganise the people however the next growth quarter demands; the answer stays one answer.
Conway’s law runs in both directions. Draw the chart first and you’ll ship three help centres. Build the record first and the chart stops mattering to the customer. The customer never meets your org chart. She meets your record.
Create a Free Workspace → and put the four questions against the knowledge your teams already hold, before the next reorg memo.
.svg)
.svg)
.svg)
