Every guide to the customer success tech stack describes four or five neat layers. A CS platform for lifecycle operations, a customer-facing onboarding layer, product analytics, the CRM underneath. The diagrams agree with each other closely enough that the model feels settled.
Almost all of them are written by a company that sells one of the layers. And none of them draws the layer that decides whether any of it works, which is the person who keeps it running.
That is not an accusation of dishonesty. A vendor describing the stack it sits in is doing a normal thing. But it means the published picture of the customer success tech stack is a picture of what vendors recommend, and nobody checks it against what companies put in place. The two are not the same, and the gap is larger than the category admits.
So we measured it a different way. Instead of asking vendors what the stack should be, we read what companies say when they are hiring the people who have to use it.
What the standard model says
The common four-layer model is worth stating fairly, because parts of it hold up.
Layer one is the customer success platform, the system where health scores, playbooks, renewals, and account history live. Layer two is the customer-facing layer, the shared onboarding plan or portal the customer sees. Layer three is product analytics, the usage telemetry that tells you whether anyone is logging in. Layer four is the CRM, usually described as the source of truth for the account record.
The model is coherent. Its weakness is that it is presented as a description of how teams work when it is really a description of how a market is segmented. Each layer corresponds to a category of vendor, and the diagram is the category map drawn as an architecture.
The leading page on this topic runs about 1,600 words, names ten tools, and cites no data of any kind for its claims about what teams do. A longer competitor, around 3,300 words, sources its statistics to a market-data aggregator and a blog summary of someone else's research, and ranks its own product first. Neither surveyed a practitioner.
So the model has never been tested against evidence. When you test it, one layer turns out to be much heavier than the diagram suggests, one much lighter, and one is missing from the diagram entirely.
The CRM is the centre of gravity
Among the 46 requisitions that name any tool, 28 name a CRM and 12 name a dedicated customer success platform. That is a ratio of roughly 2.3 to 1 in favour of the CRM.
The company-level view is starker than the posting-level view. A CRM is named by 22 of the 51 companies in the sample, and a single CRM accounts for 21 of those 22. Every dedicated customer success platform combined is named by 10.

More telling is what appears without a partner. 17 of the 46 tool-naming requisitions name a CRM and no customer success platform, which is 37% of everything that names tooling. The reverse never happens. All ten companies that name a dedicated customer success platform also name a CRM, without exception. The platform is never the thing that replaces the account record. It is always the thing added on top of it.
This does not mean the CRM-only teams have no customer success platform. A posting is a hiring document, not an inventory, and plenty of teams run tools they never mention. What it does mean is that when a company chooses one system to name as the one a new CSM must know, the CRM wins by a wide margin, and that no company in this sample treats a CS platform as a substitute for it.
The practical question that follows, whether you should run customer success on your CRM or add a platform built for it, is a real decision with costs on both sides, and we have worked through it in detail. The short version is that the two are rarely either/or, which is what the 10 out of 10 above shows.
The platform layer is thinner than the category implies
Of the dedicated customer success platforms, one has meaningful presence and the rest barely register.
One platform accounts for 11 of those 12 requisitions, across 9 of the 10 companies. The next appears in 2 requisitions at 2 companies, and two more appear once each, at a single company apiece. Three of the platforms we searched for are named in none of the 172 requisitions at all.
Treat the small numbers with appropriate suspicion. The difference between one mention and zero is not a meaningful gap, and a vendor absent from this sample may be widely used in companies whose boards we could not reach, or that name no tools at all. These counts are a floor, not market share, and they say nothing about product quality.
Where the platforms appear is more informative than how often. All ten companies that name one are established technology businesses, six of them publicly traded, and not one is a company anybody would describe as small. The dedicated platform layer in this sample is concentrated at the top of it.
There is a plausible and unflattering reading of that, which is that our sample skews toward large, well-known technology companies, exactly the companies most likely to have bought a customer success platform. If the sample is biased, it is biased toward finding more platform adoption than the wider market has, not less. The 7% of all requisitions naming a platform is therefore more likely an overstatement than an understatement for smaller companies.
The analytics layer is real but concentrated
The data layer shows up clearly and then dissolves when you look at who it belongs to.
SQL is named in 13 requisitions, which makes it the second most-named item in the entire sample. But those 13 requisitions come from just 4 companies. A cloud data warehouse appears in 8 requisitions from 2 companies. Two business intelligence tools appear in 6 requisitions each, from 5 companies and 4 companies, with several others named three times or fewer.
So the apparent conclusion, that customer success is becoming a data-literate function, is not supported in that form. A small number of employers ask their CSMs for SQL and ask repeatedly across many openings. Most employers never mention it. The reading the data supports is that a data-heavy customer success role is a real and distinct job at a few companies rather than a general direction of travel for the function.
This matters for anyone building a stack on the assumption that their CSMs will query a warehouse. At most companies in this sample, that assumption has no support in how they describe the job. If your stack design requires a CSM to write SQL, you are designing for a role that four employers out of fifty-one are hiring.
Product analytics tools are thinner still. One is named a single time. Of the others we searched for, one never appears at all, and one appears only in postings written by its own maker, which is a company describing its product rather than a team naming a tool it uses. A conversation intelligence tool, which belongs to no layer of the diagram, appears in 7 requisitions across 5 companies, more than every product analytics tool in the sample put together.
Layer two is missing entirely. We searched the 172 requisitions for ten named customer-facing onboarding and client-portal products, the category the diagram places between the platform and the customer, and not one appears. Hiring documents are an imperfect instrument for a tool the customer uses rather than the CSM, so read it as a floor. But it is the one layer of the four that no employer in the sample asked anybody to know.
The layer the diagram leaves out
Every version of the four-layer model describes what to buy. None of them describes who keeps it running, and that is the variable the hiring data speaks to most clearly.
We swept all 358 listings for operations-titled roles inside the customer success family. There are two. One company is hiring a senior customer success operations manager, another a lead customer success operations analyst. Two requisitions, at 2 of the 51 companies.
Then we searched the 172 requisitions for anyone asked to configure the customer success stack itself. The word "configure" appears in 16 requisitions across 10 companies, and in 15 of them it means configuring the customer's instance of the product that company sells, not the team's own tooling. Exactly one requisition in 172 asks the hire to do customer success platform configuration, and it is one of those two operations roles, at a company that names three different platforms across its openings.
So the platform layer and the person who runs it appear at the same companies and almost nowhere else. Of the 41 companies that name no dedicated platform, exactly one is hiring an operations role. The remaining 40 show no sign of a platform and no sign of anyone to run one.

This is the question the diagram cannot answer, and it is the one that decides whether a stack survives contact with a small team. Not which layers you need. Who owns each layer on a Tuesday, when the scores are three weeks stale and the person who built them is deep in renewals.
What this data cannot tell you
A page that only reports its strongest numbers is not worth trusting, so here is the full set of limits.
It covers one job-board platform. Companies that run their careers page on a different applicant tracking system are not represented at all. Ninety-six of the 178 boards we tried returned nothing, so the responding set is partly a sample of who uses this one system.
Most postings name nothing. With 26.7% naming any tool, the majority of the sample is silent. Silence is not absence.
The operations count is a floor too. Our sweep captured roles whose titles sit in the customer success family, so an operations hire titled "Revenue Operations Manager" or "GTM Systems Analyst" would not appear, even if customer success tooling were part of the job. The two we found are the operations roles that a customer success jobseeker would see, not every person at these companies who touches the stack.
The spreadsheet question is unresolved. After correcting the verb problem, Excel appears as a named tool in 9 requisitions across 5 companies, and the word "spreadsheet" appears in 8 requisitions that all come from one company. That is far too concentrated to support any claim about how common spreadsheets are in customer success. Hiring documents are a poor instrument for detecting spreadsheet use, because nobody advertises it. If you want the argument about when a spreadsheet stops being enough, it is set out in when to buy customer success software, which approaches the question from cost rather than from hiring.
Named counts are a floor. Every number here is "how often a tool was written down", not "how often it is used".
The sample skews large. These are mostly well-funded technology companies. A ten-person SaaS business is not represented, and its stack almost certainly looks different and smaller.
Running customer success out of the CRM, with the rest of the data in three other places?
What this means if you are choosing a stack
The useful takeaway is not a shopping list. It is that the four-layer diagram describes a market, and your team is not obliged to fill every layer because a diagram has a box for it.
Four things follow from the evidence. Start with the owner rather than the layer, because the one thing every company that runs a dedicated platform has in common is scale, and two of them hired somebody to run it. Build on the CRM rather than beside it, because no company in this sample replaced the account record and 37% of tool-naming requisitions named the CRM alone. Treat the platform layer as a considered purchase rather than a default, because treating it as a default is how teams end up paying for a system nobody opens. And do not buy for the warehouse-native future before you have anyone to run it, because the data layer is a real requirement at four employers and an aspiration at the rest.
For a small team the sequencing question matters more than the architecture. Which tool to add first, and at what stage, depends on headcount and book size rather than on the diagram, and we have set out stage-by-stage guidance in customer success platforms for startups. If the question is whether to assemble it yourself instead, the cost model is in build vs buy.
The stack for a team with no admin
Put the three findings together and a specific gap appears. The CRM is where the post-sale record lives. The dedicated platform layer shows up at 10 of 51 companies, all of them large. The role that configures that layer shows up at 2. For 40 of the 51, the platform box on the diagram has no owner at all.
That gap is the case GainTrace was built for, and it is why the product is shaped the way it is rather than like the platforms above it.
It reads the systems you already run instead of asking you to maintain a second system of record, so the CRM stays the record and the scoring sits on top of it, alongside billing, support, and product data. Health scores arrive with the reason attached and refresh every six hours, which removes the rebuild-the-dashboard task that the data shows nobody is hired to do. Churn risk is flagged up to 45 days before the renewal date. A CSM or a CS leader configures the scores and the playbooks, because the evidence says there is no administrator to hand that to.
Pricing follows the same logic. It is free forever on your first 25 companies, and paid plans start at $99 a month priced by companies tracked rather than per seat, so adding a teammate or giving your founder a login does not change the bill.
The exclusion is as clear as the fit. If you look like the one company in this sample that has a customer success operations analyst in post and three platforms named across its openings, you have the owner the diagram assumes, and you should buy the heavy platform or build on your warehouse. GainTrace is built for the 40 that have neither.
Want health scores on top of the CRM you already run?
Free forever on your first 25 companies | No credit card required
Frequently Asked Questions
- What is a customer success tech stack?
- A customer success tech stack is the set of systems a post-sale team uses to track accounts, measure health, and run renewals. It is usually described as four layers: a CS platform, a customer-facing onboarding layer, product analytics, and the CRM. In practice most teams run a subset, built around whichever system already holds the account record.
- What tools do customer success teams actually use?
- Across 172 unique customer success requisitions from 51 companies, 46 named a specific tool. Among those, 28 named a CRM and 12 named a dedicated customer success platform. A CRM was named by 22 of the 51 companies, and the most common dedicated platform by 9. Most postings name no tool at all, so these counts are a floor rather than a market share.
- Is the CRM the system of record for customer success?
- For most companies in this sample, yes. Among requisitions that named tooling, 37% named a CRM and no customer success platform, and the CRM was named 2.3 times as often as a dedicated platform. Every company that named a CS platform also named a CRM, so the platform layers on top of the CRM rather than replacing it.
- Who administers a customer success platform?
- At most companies, nobody has that job. Only 2 of the 51 companies in this sample were hiring a customer success operations role, and exactly one requisition in 172 asked the hire to configure the CS platform itself. A small team should therefore weight the admin burden heavily when choosing, or pick a tool like GainTrace that a CSM or CS leader configures without an administrator.
- Do customer success managers need SQL?
- At most companies, no. SQL appeared in 13 of 172 requisitions, but those came from only 4 employers who ask for it repeatedly across openings. It is a genuine requirement for a specific kind of data-heavy customer success role rather than a general expectation of the function.
- How many tools does a customer success team need?
- Fewer than the standard diagram implies. The four-layer model maps vendor categories rather than team needs, and the evidence shows most companies name one central system, usually the CRM, rather than a full stack. Add a layer when a specific job is failing, not because a box on a diagram is empty.
- What is the smallest workable customer success stack?
- For a team without a customer success operations function, the evidence points to the CRM you already run plus one layer that scores accounts on top of it and needs no administrator. That covers the two jobs the diagram's four layers exist to do, knowing which accounts are at risk and knowing what to do next, without adding a system that only a dedicated owner can keep current.
- How common is a dedicated customer success platform?
- Less common than the category implies. Twelve of 172 requisitions named one, across 10 of the 51 companies, and a single platform accounted for 11 of those 12 mentions. Three of the platforms we searched for were named in none of the 172. These are floors drawn from hiring documents, not market share, and they say nothing about product quality.