A CSM finishes a call with a strategic account. She does everything right. The recorder fires, the notes land in the CS platform, the health score ticks green to yellow, a CTA is created, a task appears in her queue. By every measure the platform was sold on, this worked.
Then she spends the rest of Tuesday doing the actual job.
She messages the support lead, because the customer said the latency ticket is why procurement has gone quiet. She pings the PM, because the integration commitment made in the last QBR isn’t on any roadmap she can find. She forwards the thread to the AE, because there’s an expansion signal buried in the second half of the call. She drops a note in the exec channel, because the champion who has carried this account for two years just said she’s leaving in March. And she answers three Slack messages from people who wanted to know what was going on with this customer and had no way to find out except by asking her.
None of that is in the CS platform. Almost none of it ever will be, because typing it in would take longer than the work itself, and the only people who’d see it are the four already on the call.
That Tuesday is the job. The health score is a byproduct.
And the platform that captured the byproduct and missed the job didn’t fail on execution. It executed its design exactly. The design was to build the customer success team an application — which means the most complete picture of the customer in the entire company now lives in a system that exactly one department opens.
That’s a silo. You know the word; it’s the thing every system you’ve bought in the last decade and a half claimed to be solving. Your CS platform solved it for CS. It is the last silo: a complete picture of the customer, visible to one department, kept alive by that department’s typing.
One job, two titles
A note on vocabulary first, because otherwise half the people this is written for will assume it’s about somebody else.
CSM and AM are different titles with different comp models, different reporting lines and — in a lot of companies — a quiet unresolved argument about who owns the renewal. Those differences are real. But they’re differences of incentive, not of shape. Put the two weeks side by side:
- One person holds the whole story of a named account over time. Not a deal, not a ticket, not a cohort.
- Their output is produced by other departments. Neither fixes the bug, ships the feature, approves the credit or writes the contract.
- So the job is persuasion and routing — getting seven or eight functions to act on something the customer said.
- And both are the only route into the account’s reality. When anyone else needs to know what’s going on, they don’t run a query. They message a person.
Where AMs differ, they differ in a direction that makes this argument stronger. They usually carry an explicit number, are measured on expansion rather than retention alone, and in most companies have less tooling than their CS counterparts — because the platform budget went to the CS org. Same connective work, quota attached, thinner stack.
So this post says CSMs and AMs, and means both.
The job is a network position, not a workflow
Ask a CS or AM leader what their team does and you rarely hear “maintain the health score.” You hear some version of we’re the people who make the rest of the company act on what the customer needs.
That’s not a workflow. It’s a network position.
CSMs and AMs are the super connectors — the highest-degree nodes in the company’s internal graph. In a normal week one of them moves information between support, engineering, product, sales, finance, legal, the exec team, and the customer’s own internal factions. Nobody else talks to that many functions about that many things with that much specificity. The AE goes deep and then stops. The support engineer sees one ticket. The PM sees a hundred accounts shallowly. The CSM or AM is the only person holding the whole story of one account over time.
The output of that role isn’t a record. It’s alignment — support reprioritises, the roadmap absorbs a commitment, the AE knows to call, the CFO understands the risk, and the customer experiences a company that looks like one thing rather than nine.
Which is why Customer Success was never only a department. At companies that grow well it’s an ethos: the reflex that the customer’s reality is everyone’s problem. Now put the two sentences together.
The job is to rally the entire company around the customer.The tool bought to support that job can only be opened by one department.
You cannot rally a company from inside a silo.
How the category got here honestly
Be fair to the platforms — pretending the mis-step was stupid makes the argument weaker.
In 2013 the CS team had no system at all. Spreadsheets, an inbox, a quarterly panic. Building that team a dedicated application was a genuine advance, and the category professionalised a function that had no vocabulary, no conference and no career path.
But the shape encoded three assumptions, and all three have aged badly.
One: customer success is a function with its own workflow. So the product is an application with its own login and its own adoption problem — and the reach of the tool is bounded by the org chart. The connective work, which by definition requires seven other functions to see the same thing, falls outside the product boundary by construction. It’s also why AMs were largely left out: they sit on the other side of an org line, so they were outside the boundary from day one.
Two: the record can be maintained by hand. This generates the whole hidden cost structure — implementations that commonly run 12–24 weeks with professional services, a dedicated or fractional admin to keep connectors and playbooks alive, hours per person per week logging activity and maintaining score inputs. It also generates the failure mode every practitioner recognises: inputs depend on humans remembering, so scores drift from reality, so people quietly stop trusting them, so the team drifts back to spreadsheets and Slack while the dashboards keep rendering.
Three: the relationships that matter are the ones somebody typed into a field. They aren’t. The dependency between a case and a renewal, the reason a champion went quiet, the roadmap commitment made verbally in a QBR — those get declared constantly in calls, threads, forwards and doc comments, and almost never in a CRM field, because there’s no field shaped like blocks or this is why she stopped replying. (We’ve written about that class of missing relationship in detail.)
None of these were stupid. They were the only assumptions available before the action layer was readable. But they compose into one architectural fact: the platform’s picture is one department’s typed derivative of a story that happened somewhere else.
The three costs
The typing tax
Everyone knows this one, so: briefly. The license is one of four line items and it’s the one people quote. Underneath sit implementation, admin coverage, and the hours per person per week that go into feeding it. Our true-cost calculator sums all four from your own numbers; most teams find the license is less than half the bill.
The important part isn’t the money. It’s that the typing tax and the trust problem are the same problem. A record maintained by hand is only as current as the last person who remembered — which is why the health score gets discussed as a ritual rather than a fact.
The asking tax
This one is larger and never appears in a business case, because there’s no invoice for it.
Every time someone outside the account team needs to know what’s happening with an account, they can’t look. They ask the person who owns it. The AE before a call. The support lead before an escalation. The PM before writing the quarter’s roadmap. The CFO before the forecast meeting. A new AM inheriting an account. Every one is a person who couldn’t see, so a person who could had to stop and explain.
Watch what that does to the super connector. Their scarce asset is judgment about the account. The asking tax spends it on retrieval. The most connected people in the company become a lookup service for the story instead of deciding what the company should do about it.
And then the second-order effect, which every CS and AM leader feels in budget season: when the only route to customer context runs through a person, the function starts to look like overhead. It gets described as reactive. The scarcity of the context is precisely what makes the department look like a cost centre — and the tool that produced that scarcity was sold as the fix.
The last silo doesn’t just hide the customer from the company. It hides the value of the account team from the company.
The AI tax
For most of the category’s life the last silo was a chronic condition. It became acute the moment your company started deploying agents.
A CS platform’s data is a derivative: scores, CTAs, lifecycle stages — structures computed from what a human typed into a form built for one department’s workflow. Put an agent on top and you’ve built something that sees one department’s typed derivative of the truth, bounded by that department’s login, lagging by however long since someone last logged something. It will answer “what’s the risk on the Contoso renewal?” fluently and wrongly. It will summarise the fields. It will not know the renewal is blocked by a six-week-old case, because nothing it can see says those two things are related.
Meanwhile the same thing is happening everywhere else. Support is standing up agents against the ticketing silo. Sales against the CRM silo. Product against the roadmap silo. Four agents, four partial views of one customer, none of them able to see what the others see. The org chart is being faithfully reproduced in the AI layer, one credentialed integration at a time.
Which is why “our CS platform added AI features” isn’t the reassurance the vendor thinks. AI features on a silo produce a smarter silo. The constraint was never the model’s intelligence — it was the boundary of what the model can see.
The good news has the same shape. This is a context layer problem sitting underneath an agent problem, so it gets fixed once and every agent deployed afterwards inherits the fix. That’s unusual leverage, and in most companies it’s sitting unclaimed. Whoever fixes the customer context layer isn’t delivering a CS tool — they’re delivering the foundation the company’s entire customer-facing AI strategy has to stand on. There’s no rule saying that person has to be in IT.
Measure your own silo rate
Don’t take any of this on assertion. One account, one hour.
Write down the ten things that are actually true about that account right now — the things you’d tell a new CSM or AM inheriting it Monday. Not fields; facts. The champion is leaving in March. The renewal is blocked by the latency ticket. They’re evaluating a competitor for reporting. Procurement went quiet after the security review.
Then, for each one, ask a single question:
Could someone outside the account team have found this out today, without asking the CSM or AM who owns it?
Not “is it written down somewhere.” Could a support lead, a PM, an AE or a CFO have found it on their own, this morning.
Noes ÷ ten is your silo rate.
Most teams find the majority of the list comes back as noes, and the items that score worst are consistently the most consequential — the reasons, the dependencies, the politics inside the account. The facts that got typed into a field are the ones everyone can see, and those are mostly the facts that matter least.
Two caveats. A high rate is normal — it’s the expected result of the architecture, not a surprising one. It measures the shape of your architecture, not the diligence of your people; they’re documenting constantly, just where documenting costs nothing. And don’t convert it into money. The temptation is to multiply the asking tax by a loaded salary and put it on a slide. The number will be fictional and the person you most need to convince will know.
One caveat on method: this is deliberately qualitative, not a sampled statistic. Ten hand-picked facts aren’t a random sample, and the categories that matter most are the ones least likely to have ever been a field. It’s built to make a structural point vivid, not a defensible percentage — the dark join rate is the rigorous, sampled version of the same idea. The list itself is what wins the argument: ten specific true facts about a real account, each with a checkbox next to anyone outside the account team could see this. That page is what you forward.
What to build instead: a nervous system, not a platform
So what should exist instead? Not a better CS platform. Something with a different shape.
A platform is a place you go. It has a boundary, a login, an adoption curve and an owning department. Its value is capped by how many people will open it — which is why every CS platform business case eventually becomes an adoption conversation.
A nervous system is a thing that reaches everywhere. No destination. It doesn’t ask you to go anywhere because it’s already where you are. Four properties follow — treat them as a spec: the thing to build if you’re building, and the thing to interrogate if you’re buying.
It assembles itself from the work. If the story has to be typed in, you’ve rebuilt the typing tax and the trust problem behind it. The system has to read the action layer — calls, email threads, Slack and Teams, shared docs and their comments, ticket bodies — because that’s where people actually declare what’s true. They do it there because it costs nothing: no required fields, no validation rules, no admin asking why a picklist is blank. Nobody experiences a Slack message as data entry. Doing it well needs three signals: interaction rank (PageRank over enterprise work — importance is a property of the link structure, so nobody has to flag anything), temporal decay (importance fades unless renewed, so the graph never becomes an archive), and an intent filter (“blocked by NOD-231” chains a record in; “closing as duplicate of NOD-231” keeps it out). Interrogate that last one hardest, of whoever builds it, including us: a wrong edge in a customer graph costs more than a missing one, and if nobody can show you the sentence behind an edge, be sceptical of the edge.
It is not another store of record. This is the test that disqualifies most things calling themselves a customer 360. If the answer to the silo is a new database everyone has to be persuaded to populate and govern, you’ve built silo number two and called it consolidation. Hold pointers, not copies. Salesforce stays the system of record; so does Zendesk, so does Jira. Disconnect tomorrow and everything is exactly where it always was — which also makes the decision reversible, and reversible decisions are much easier to make.
It appears where people already are. Reach is the whole value, so the delivery surface isn’t a detail. Slack, where the support lead already is. Email. Claude, ChatGPT and Gemini, where a growing share of your colleagues now start every question. And for agents, one governed MCP layer over the whole customer stack — you define what’s exposed, to whom, and how it’s described — instead of a credentialed integration per app per department.
It makes everyone else’s systems better. Because it’s reading the work anyway, it writes the durable parts back into the systems the other departments live in: the champion change into the CRM, the blocking dependency onto the ticket, the next step onto the opportunity. Opt-in, attributed, reviewable. Sales’ CRM gets cleaner without an AE typing. Support sees renewal context on the ticket. Every one of those is a department that got something for free from a system you brought in.
That’s what rallying the company around the customer looks like when it’s implemented in architecture instead of asked for in a meeting.
What changes when you have one
The company conversation. Customer context stops being something the company gets by asking your team and becomes something the company has. The function stops being described as reactive, because the evidence of what it knows is visible to everyone who used to wait on it.
The AI conversation. Every company is working out where its customer-facing AI strategy stands up. In most, the honest answer is “on top of whatever each department already had.” The context layer is the missing foundation and it’s genuinely unclaimed. Walking in with it already running is a different kind of meeting from asking for headcount.
The budget conversation. The argument is structural, not a discount. Every cost in the middle of this post is a consequence of one design decision: that a human maintains the record. Remove that assumption and the implementation, the admin coverage and the data-entry hours don’t get optimised — they stop existing as line items. That’s why a system with this shape can cost a fraction of a platform with the other shape without being a worse product. It’s doing less work, because there’s less work.
The question under the resistance
One objection deserves a straight answer rather than a reassuring one: if everyone can see the account, what is my team for?
The scarcity model — where context flows through a person — feels like job security and functions as the opposite. It’s precisely what makes the function look like overhead, keeps CSMs and AMs doing retrieval instead of judgment, and caps the book each of them can carry. Nobody was ever promoted for being the only person who knew something.
The connector’s value was never the lookup. It was deciding what the company should do and making eight functions do it. Visibility is how that ethos scales past the number of hours in your team’s week.
Build it, or buy it
So that’s what you need: a system that assembles the account story from the work, keeps pointers rather than copies, shows up where your colleagues already are, and improves every other department’s systems as a side effect. Not a place your team goes — a layer the company reasons on.
You can build it. The design above isn’t a secret, and for some organisations building is the right call. Build it honestly: connectors across the full action layer including email and doc comments (the two everyone skips and the two that hurt most to skip); interaction rank over a continuously updating edge stream; a decay model tuned to your business cycle, which you’ll get wrong twice; an intent classifier with a labelled eval set so you can prove precision rather than assert it; permission-aware resolution so the graph never becomes a lateral disclosure path; and a cached serving layer, or token spend collapses the business case on its own. That’s a platform team and several quarters — genuinely doable, and genuinely expensive.
Or you can buy it. We built Noded because these are the problems we kept hitting, and this is the shape we concluded was the only one that solves them. It reads the action layer rather than the storage layer, assembles a live Context Graph per account from pointers rather than copies, and shows up in Slack, in email, in Claude, ChatGPT and Gemini, and behind one governed MCP layer for your agents. Data stays where it lives, write-backs are opt-in and attributed, nothing is ever trained on, SOC 2 audited. Because there are no fields to maintain there’s no admin role to staff and no implementation project to fund — which is why it’s priced like a productivity tool: per seat from $20/month, Growth at $1,000/month with unlimited users, reading and asking always free.
If you already own a CS platform, you don’t have to choose on day one. Extend — keep it and fix what feeds it, so the frameworks you invested in stop being fed by hand. Or replace — run the post-sale motion in Noded and retire the admin instead of maintaining it. Most teams don’t decide up front; they run Noded alongside what they own and make the platform call at renewal with months of evidence about where the work actually happened. Specifics per platform: Gainsight · Planhat · ChurnZero.
Run the silo-rate exercise first, though. One account, ten facts, an hour. Find out how much of your most important customer your company can actually see.
Because the job was never to keep the record. It was to rally the company around the customer — and you cannot rally a company from inside a silo.