Build or buy AI for customer success? The hidden cost of building in-house.

Should we build or buy AI for customer success?

TSIA's State of Customer Success 2026 names fragmented systems as the biggest barrier to a unified view of the customer, and describes governance of AI as a strategic imperative for customer success leaders. Both findings describe work that sits underneath any AI a customer success team puts to use, and that work falls to whoever owns the AI after it launches.

The build-or-buy question usually arrives in a familiar way. Someone in revenue operations connects a large language model to the CRM over a weekend and shows a script that drafts renewal emails for every account closing next quarter. The drafts are good. Engineering estimates two sprints to make it ready to run on real accounts, which sounds cheaper than a new vendor, and the head of customer success is asked to choose.

For most customer success teams the answer is to buy. The prototype has shown that the model can write a good email. Whether AI works in customer success depends on what has to keep running after launch: a live connection to every system that holds the account's story, controls on what the agent may do and where a person signs off, and a way of learning from what happened to the accounts it touched. Those are the parts internal builds stall on, and few companies have the governance in place to run them.

Should you build AI for customer success in-house?

MIT's Project NANDA (July 2025) found that tools bought from outside reached deployment about 67% of the time, against about 33% for internal builds. Forrester's Predictions 2025 (October 2024) predicted that three of every four firms that try to build AI agent systems in-house will fail and switch to a provider. Menlo Ventures, a venture investor with an interest in the answer, found that the share of enterprise generative AI built in-house fell from about 47% in 2024 to about 24% in 2025.

The more useful part of NANDA's work is its explanation for the gap. The tools that reached deployment fitted into how the work was already done and kept context from one task to the next. Generic chat tools stalled because they did not adapt to the organization's own processes. That finding applies to bought tools as well: a general assistant bought off the shelf stalls for the same reason an internal build does. What separated the successes was whether the system learned the organization it worked in, and an internal build has to create that capability from scratch.

What does an in-house build have to keep running?

An agent that a customer success team can trust with its accounts needs three things, and each of them is ongoing work.

• A live picture of each account. A renewal draft that reads only the CRM cannot see the three support tickets that were escalated last week, the usage that fell by half last month, or the invoice that has been overdue since August. That information lives in product analytics, the help desk and billing, and TSIA's point about fragmented systems is that it rarely sits in one place. Joining it once is a project, and keeping it joined as fields change, accounts merge and new tools arrive is a job someone has to own.
• Controls on what the agent may do. Before an agent sends anything to a customer, someone has to decide which tools it may use, which accounts it may touch, which actions need a person's approval, how every action is recorded, and how the whole thing is stopped quickly when something goes wrong. Each of those is a piece of software, and each needs an owner.
• A way to learn from outcomes. An agent that drafts renewal outreach should get better at it as renewals close or churn. That requires recording what the agent did, what happened to the account afterwards, and how that compares with similar accounts the agent did not contact. Without that record, the agent makes the same judgment on its hundredth renewal that it made on its first.

The controls are the part companies are least ready to build. Deloitte's Tech Trends 2026 found that only 1 in 5 companies has a mature governance model for autonomous agents. A customer success team that builds its own agent is taking on the job of writing that model itself, for a system that speaks to its customers, and one of the hardest pieces of it is deciding where a person approves.

Why the approval step has to be designed

It is tempting to treat approval as a single checkbox, a place where a person clicks yes before anything goes out. The clearest evidence that the design of that step changes the result comes from customer service. A 2026 field experiment in Alibaba's customer service operation (arXiv 2605.14830) found that AI shortened chats but lowered customer ratings on the chats it was eligible to handle, and that the people receiving escalations the algorithm had triggered engaged less with them. Where the handoff sat, and what triggered it, changed how carefully people did their part.

For a customer success team the lesson is about where approval sits. When every routine check-in email needs a manager's approval, the manager's queue fills with near-identical messages, and the one going to an account in the middle of a pricing dispute looks like all the others. When only the messages that need judgment are routed to a person, such as outreach to an account in a renewal negotiation or anything that mentions price, each one gets read. Deciding which actions need judgment is design work, and in an internal build it falls to whoever wrote the code.

When building makes sense

The cost of an internal build rises with how much of that upkeep the use case needs. A tool that summarizes calls for one person, reads one system and never writes to a customer needs very little of it, and building that yourself can be reasonable. An agent that reads across the CRM, product data, support and billing, acts on hundreds of accounts, and sends messages in the company's name needs all of it. That second kind is the in-house agent system Forrester expects most firms to abandon.

A useful test before approving the two sprints is to write down who will own each of the three pieces after launch: the connections, the controls and the learning. If each has a named owner with time set aside for it, building is a real option. If the answer for all three is the engineer who built the prototype, working in the time left over from everything else, NANDA's numbers describe what usually happens next.

How Trig handles the parts that stall a build

Trig is built around those three pieces. It works inside the systems a team already has: when Trig sends an email, it uses the company's own email service provider, and when it creates a task, the task goes into the CRM. The Trig Context Engine, the part of the system that holds what Trig knows about each customer, brings together data from the CRM, product analytics, support tickets and billing into a single profile of every account, and keeps that history as the account changes and as people on the team move on.

The controls are part of the product. Work in Trig runs as Jobs. A Job is a defined piece of work for an agent: the goal, the accounts it targets, how long it runs, and which tools it may use, such as email, Slack or the CRM. The team approves a Job before it runs, sets guardrails on what agents can and cannot do, watches actions and results as they happen, and can pause or stop any Job at any time. Underneath that, Trig cannot access data, use a tool or take an action without explicit approval. Human approval is built into the decisions where human judgment is needed, so the people approving see the actions that need them.

The learning is built in as well. Trig records how many customers entered a Job, how many completed it and how long it took, and estimates uplift by comparing the customers a Job targeted with similar customers it did not target. Those results, along with renewal outcomes, feed back into what Trig does next. Most customers have their first Signals, which are Trig's alerts for changes in an account's behavior, and their first agents running within a few weeks.

What this looks like in practice

Consider a team of six customer success managers covering five hundred accounts, with eighty of them up for renewal next quarter. The in-house version starts with the weekend prototype: renewal drafts from CRM data, sent after a manager reads each one. By the second month the team wants the drafts to reflect product usage and open support tickets, so engineering starts connecting two more systems. Someone asks what happens if the agent emails an account that is in the middle of a pricing dispute, and a rule and an approval step get added. Finance asks whether the outreach changed renewal rates, and nobody recorded which accounts got which message. Each request is reasonable, and each one becomes a project.

In Trig the same work starts as a Job: reach every account renewing in the next ninety days whose usage has dropped, write outreach that reflects the account's recent support history, and hand any account with an open support escalation to its manager to contact personally. The team approves the Job, the agent works through the accounts, and the comparison against similar accounts that were not contacted builds up while the Job runs. The managers spend their time on the accounts that were handed to them.

What this means for the team

The build-or-buy decision comes down to who will keep the connections, the controls and the learning running after the first version ships. A team that buys puts its engineering time and its managers' time into the accounts themselves. Building is still a fair choice when the team goes in knowing it has taken on a second product to maintain, and that this product speaks to its customers.