Key Takeaways
- A customer success tech stack isn’t a shopping list of categories. It’s five or six tools claiming the same few records: the account, the onboarding plan, the request, the help article and the health signal.
- Every record with two owners becomes a reconciliation job. Enterprises connect only 29% of their applications, and 95% of IT leaders say they struggle to integrate data across systems.
- Switching between tools has a measured cost. Knowledge workers in one study toggled nearly 1,200 times a day, losing just under four hours a week. Contact-center and operations staff in another made 28% more errors when working across 30 or more apps.
- The vendors know about the overlap. Gainsight has bought community, conversation AI and a customer-education LMS since 2022. Totango, renamed Odie in September 2026, now calls every CS platform “a secondary CRM with better manners”.
- Decide which tool owns each record before deciding which CS platform to buy. The system-of-record map below does that in one page.
A new customer signs. Within a week their details exist in six places. The CRM has the account. The CS platform has a copy of the account with a health score attached. The help desk creates a third version the first time someone files a ticket. The onboarding plan lives in a project tool, the setup guides live in the knowledge base, and the in-app walkthroughs have their own copy of the same instructions. Then the customer asks why their onboarding call covered a feature the help centre says doesn’t exist yet. Nobody can say which version of anything is current.
That’s the ordinary state of a customer success tech stack. Most guides to building one list categories, recommend a tool in each and draw the CS platform in the middle. They skip the question that decides whether the stack works. Which tool is the system of record for which piece of customer data? And what happens where two tools both think they are? For the wider stack view, see customer operations software.
Why the usual customer success tech stack diagram misleads
Open the top-ranking guides and a pattern appears. Each is written by a vendor that wants to be the hub. The diagram has the vendor’s product in the centre and every other category as a spoke that “integrates”. None of them says which record each spoke owns, and none names the places where two spokes claim the same thing.
The independent data suggests those places are expensive. MuleSoft’s 2025 connectivity benchmark, based on 1,050 IT leaders at large enterprises, found that “95% of respondents struggle to integrate data across systems. Moreover, only 29% of applications are typically connected within organizations, on average.” A spoke drawn on a diagram is not a connection that exists.
Company-level sprawl is also real, though the numbers need care. Zylo’s 2026 index, built from 40 million licences, puts the median portfolio at 305 apps and finds business units, not IT, now control 81% of SaaS spend. BetterCloud’s surveys of IT professionals count SaaS apps differently and show the number peaking at 130 in 2022 and falling to 106 by 2024, with consolidation slowing sharply. These sources measure different things, so they shouldn’t be charted as one trend. None of them counts tools per customer success team. What they agree on is that the tools multiply faster than the connections between them.
The records a customer success tech stack actually manages
Strip the categories away and a CS stack manages a short list of records. The question for each one is simple: where is it created and maintained, and where is it only copied or read?
| Record | CRM | CS platform | Help desk | Knowledge base | LMS / academy | In-app guidance | Project tool |
|---|
| Account and contract | Owns | Copies | Copies | — | Copies | Reads | Copies |
| Health signal | Reads | Owns | Produces inputs | Produces inputs | Produces inputs | Produces inputs | Produces inputs |
| Onboarding plan | — | Often owns | — | — | — | — | Often owns |
| Customer request | Copies | Copies | Owns | — | — | — | Sometimes owns |
| How-to content | — | — | Often owns | Owns | Owns | Owns | — |
| Conversation history | Partial | Partial | Owns | — | — | — | Partial |
The map is an illustration of a typical stack, not a survey result, and yours will differ. The useful part is the rows with more than one bold cell. Each of those is a record with two or more owners, and every one of them turns into a person reconciling versions by hand.
Overlap 1: the onboarding plan lives in two tools
CS platforms ship success plans and onboarding playbooks. Project tools ship task lists and timelines. Implementation teams usually pick the project tool because it handles dependencies, while CSMs read the CS platform because that’s where the health score is. The plan exists twice, updated at different speeds.
Overlap 2: how-to content exists in four places
The same setup instruction is written as a help article, a course lesson, an in-app tour step and, often, a canned help desk reply. Each has its own editor and its own review cycle. When the product changes, four updates are needed, and in practice one or two get made. The cost of that drift is covered in what scattered tools cost knowledge work. This is the overlap customers notice first, because it’s the one they read.
Overlap 3: the account is copied into every tool
The CRM owns the account and contract, and almost everything else keeps a copy. Each copy needs a sync, each sync needs someone to maintain it, and each gap becomes a support ticket about the wrong plan level or the wrong contact.
Overlap 4: the health score reads what other tools produce
The CS platform owns the health signal. Most of its inputs are produced elsewhere: requests in the help desk, course completions in the LMS, walkthrough completions in the in-app tool, milestone status in the project tool. The score is only as current as the slowest sync, which is part of why health scores so often disagree with what the team sees. A health score architecture that reads inputs where they’re produced avoids part of that lag.
The vendors have been buying the overlaps
The clearest evidence that these overlaps are real comes from the vendors. Gainsight, owned by Vista Equity Partners since a 2020 majority investment, has since bought three adjacent categories: community with inSided in January 2022, conversation signals with Staircase AI in August 2024, which “connects to a company’s email, meetings, chat, Slack, and ticketing systems”, and customer education with Skilljar in April 2025. Each deal moves the CS platform into one of the overlap rows above.
Totango and Catalyst merged in February 2024 to compete with Gainsight. In September 2026 the combined company renamed itself Odie, and its CEO’s announcement said the quiet part plainly: “At its core, every Customer Success Platform is essentially a secondary CRM with better manners.” The same letter described CS platforms as “dozens of objects, hundreds of fields, and a permanent part-time job for whoever inherits the admin seat.” That’s one vendor’s opinion, written to explain its own repositioning, and it should be read that way. It’s still notable that a CS platform company now describes its category as duplication of the CRM.
TSIA’s 2025 state-of-the-field report put the consequence in one line: “As the number of customer success tools grows, so does the struggle over customer data ownership.” For a comparison of the CS platforms themselves, the customer success software guide grades them one by one. This post is about the architecture around them.
What the overlaps cost the team
There’s no published study of tool switching among CS teams specifically, so the numbers here come from adjacent populations and should be read as indicative.
The best-measured study is Harvard Business Review’s 2022 analysis of 137 users across three Fortune 500 companies, based on 3,200 days of activity data. “The cost of a switch is little over two seconds and the average user in the dataset toggled between different apps and websites nearly 1,200 times each day.” Over a year, the authors calculated, that adds up to “five working weeks, or 9% of their annual time at work.” The sample was mid- and back-office staff in finance, HR and supply chain, not customer-facing teams.
The closest thing to a service-team sample is older vendor data. Pega’s 2018 analysis of about five million hours of desktop activity among operational-support and contact-center workers found they “switch between up to 35 job-critical applications nearly once a minute”, and that those using 30 or more applications in a shift had a 28% higher error rate. The widely quoted “1,100 switches a day” is Pega’s figure, often misattributed to HBR.
Neither study measures CSMs. Both describe the mechanism a CS team lives with. The more tools hold a piece of the same customer, the more time goes to finding the right version, and the more often the wrong one gets used.
How to design the customer success tech stack around records
The alternative to category shopping is a short design exercise, done before any purchase.
- List the records. Account, contact, onboarding plan, request, how-to content, conversation history, health signal. Add any your business has, such as renewals or training certifications.
- Assign one owner per record. For each, name the single system where it’s created and maintained. Everything else reads or receives a copy, and the copy is never edited.
- Remove double owners first. Where two tools own the same record, retire one of them for that record before adding anything new. How-to content is usually the biggest win: one source, published to every surface, as described in moving from separate tools to unified enablement.
- Connect only what must be connected. Keep the CRM as the owner of accounts and contracts. Connect the rest to it with defined, one-way syncs. Integrate where you must; consolidate where you can.
- Buy the CS platform last. With owners assigned, the choice narrows to what the platform must own and what it must read. That’s a smaller, clearer requirement than “be the hub”.
The exercise also exposes cost. Zylo found organisations leave 36% of their SaaS licences unused across the whole portfolio. Records with two owners often mean two paid tools doing one job.
Where MatrixFlows fits in the map
Several of the overlap rows are the same kind of record: content and work that a customer operations team produces for customers. Setup guides, help articles, in-app help, onboarding plans and requests all describe the same customer journey, and in most stacks they live in four or five tools.
MatrixFlows is built to own those records on one foundation. Knowledge, onboarding projects and requests are structured tables with a shared taxonomy. The help centre, customer portal and in-app assistant all publish from the same records, so one update reaches every surface. Requests arrive in the Conversations Inbox with the account’s context attached. The CRM stays the owner of accounts and contracts; MatrixFlows reads from it and sends records back by webhook where the team needs them there. In the map above, that collapses most of the how-to content row and the onboarding plan row to one owner each, which are the two rows customers feel most directly. Formal courses and certifications still belong in an LMS if you run one.
Back to the customer asking about the feature. On a stack with one owner per record, the answer is in one place, and so is the fix.
Create a Free Workspace → and draw your own system-of-record map before the next tool review.
.svg)
.svg)
.svg)
