Build vs buy for AI customer service: the full inventory
The demo takes a week. This is everything that comes after it: what you would build, what you would run for years, what it costs, and when building is still the right call.
22 min read
A team with good engineers and access to a cloud AI model can show a convincing customer service agent within days. The board then asks a fair question: why pay a vendor for something our own team just built?
This report answers it in full. It lists every component a production system needs, what each one costs to run after launch, the line items most build cases forget to count, and the cases where building is the better choice. It is written for CIOs, COOs, CX leaders and heads of engineering who have to make the call and defend it.
On this page
The short answer
Unless customer service is your product, buy the platform and build only the thin layer that makes you different. The model is the cheap part. A production system needs fifteen components that must be built, tested and run for years. Most of the cost arrives after go-live, when every model, policy or channel change restarts some of the work.
The comparison at a glance
Three options, scored from 1 (weak) to 5 (strong) on the criteria that decide this. The scores are our judgement for a typical service operation of 200 to 5,000 agents where customer service is not the product itself. Re-score them with your own weights: if control matters three times more than anything else to you, building closes most of the gap.
| Criterion | Build on a cloud model | Buy a specialist platform | Hybrid: buy the platform, build the thin layer |
|---|---|---|---|
| Time to first live customer | 2: days to a demo, months to a governed launch | 4: the platform exists; knowledge and integrations still take work | 4: same as buying, plus your own layer in parallel |
| Three-year cost | 2: people-heavy, and most of it lands after launch | 3: fees grow with volume | 3: fees plus a small team |
| Skills and hiring risk | 1: ML, voice, security, reliability and on-call, often held by a few people | 4: you need owners, not specialists | 3: a small team that knows your systems |
| Ongoing maintenance | 1: every component is yours to keep current | 4: you still own knowledge, scope and testing | 3: you maintain only your layer |
| Control and customisation | 5: anything is possible | 2: you work inside the vendor’s roadmap | 4: you control the parts that differ |
| Data residency and security | 4: you decide, and you also do all the paperwork | 3: depends on the vendor’s deployment options | 4: choose a vendor that deploys where you need it |
| Integration with your systems | 2: every connector is yours to build and keep working | 3: standard connectors, some custom work | 3: standard connectors, your own tools where needed |
| Who proves the outcome | 2: you build the measurement and grade yourself | 3: vendor reporting, which you should check independently | 3: vendor reporting plus your own checks |
| Exit and switching | 3: no vendor to leave, but your own platform is hard to retire | 2: switching takes work | 3: your layer moves with you |
| Total (equal weights) | 22 | 28 | 30 |
Why does the demo mislead?
A prototype answers the questions its builders thought of, on clean data, in one language, on one channel, with nobody trying to break it. Production is everything else: the customer who asks two things at once, the policy that changed yesterday, the caller who interrupts, the refund that needs approval, the regulator who asks what the AI said to whom last March.
The gap is not a matter of polish. It is a different system. The prototype is a model, a prompt and a few documents. The production system is a set of components around that model, each with its own failure modes, owners and upkeep. The model is the part you rent; almost everything else is the part you own.
The record so far says the gap is real. In July 2024, Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs or unclear business value.
The same pattern is forecast for AI agents. In June 2025, Gartner predicted that over 40% of AI agent projects would be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls.
And the route you take seems to matter. In MIT NANDA’s 2025 research, tools from external partners reached deployment about 67% of the time, against about 33% for internally built tools. The authors are careful: the figures are self-reported, come from interviews with 52 organisations, and may reflect the organisations as much as the approach. It is still the clearest signal available on this exact question.
A demo proves the model can answer. It does not prove you can run the system around it.
What would you have to build and run? The full inventory
Fifteen components. For each: what it is, why it is harder than it looks, and what keeps costing after launch. If you build, you own all fifteen. If you buy, you still own parts of some (your knowledge, your scope, your tests), and the list shows which.
The demo is the tip. Fifteen components sit below the waterline, and each one keeps costing after launch.
Source: OnClarity analysis of the components a production AI customer service system needs.
1. Model access, routing and switching
What it is. The layer that calls one or more language models, picks the right one for each task, handles timeouts and rate limits, and falls back when a provider is slow or down.
Why it is harder than it looks. One model for everything is either too slow, too expensive or not good enough somewhere. Real systems route: a small model to classify, a stronger one to reason, a specialised one for speech. Each route needs its own prompts and tests.
What keeps costing. Models are released and retired on the provider’s schedule, not yours. Every new version means re-running your tests, re-tuning prompts and checking cost and speed again. Switching is never a one-line change.
2. Knowledge and retrieval
What it is. Getting your help articles, policies, product data and past resolutions into a form the model can search, with the right answer found for the right customer.
Why it is harder than it looks. Knowledge bases are written for people, not models. They contain old versions, contradictions, regional variants and gaps. Retrieval that works on twenty documents behaves differently on twenty thousand.
What keeps costing. Knowledge changes every week. Someone has to own each article, retire the old one when policy changes, find the conflicts and fill the gaps the AI keeps hitting. This is the line that never ends, whether you build or buy. When you buy, the tooling to find gaps and conflicts usually comes with it.
3. Tools and integrations with back-office systems
What it is. The connections that let the AI do things, not just say things: look up an order, change an address, issue a refund, book an appointment, write back to the CRM and the ticketing system.
Why it is harder than it looks. Every action needs authentication, permission checks, approval rules for sensitive steps, retries that do not refund twice, and a clear record of what was done. Back-office systems were not designed to be called by a model.
What keeps costing. The systems on the other end change their APIs, their fields and their rules. Each change breaks something quietly. Every new use case is another integration to build, secure, test and keep alive.
4. The voice stack
What it is. Speech to text, text to speech, telephony and SIP trunks, call routing, and transfer to a person: warm (with a handover) or cold.
Why it is harder than it looks. Voice is unforgiving. Callers interrupt, so the agent must stop talking when they do (barge-in). Silence of more than a moment feels broken, so every step must be fast. Accents, background noise and names break transcription. A transfer that drops the context makes the customer start again.
What keeps costing. Each piece usually comes from a different supplier with its own contract, pricing and release cycle. Quality varies by language and accent, so every new market needs its own testing. Telephony incidents happen at the worst times and need someone who understands them.
5. Guardrails, validators and confidence thresholds
What it is. The checks that stop the AI answering outside its scope, inventing a policy, leaking data, or being talked into something by a creative customer.
Why it is harder than it looks. A single filter on the final answer misses most problems. Checks are needed on what comes in, what is retrieved, what tools are called and what goes out. Each one is a trade-off between blocking too much and too little, and the right threshold differs by topic.
What keeps costing. New attacks appear, new topics are added, and every model change shifts how the old guardrails behave. We set out the controls that matter most, with a test for each, in How do you stop an AI agent from making things up?
6. Handover to a person, with full context
What it is. Recognising when the AI should stop, and passing the customer to the right person with the whole conversation, what was tried and what the customer wants, so they never repeat themselves.
Why it is harder than it looks. It touches routing, queues, staffing, the agent desktop and every channel. “When to hand over” is a policy question as much as a technical one, and it changes as trust in the AI grows.
What keeps costing. Every change to your contact centre setup, queues or desktop tools has to be reflected here. A broken handover is the failure customers remember most.
7. Quality assurance on every conversation
What it is. Scoring what the AI said (and what your people said) against your own standard: was it accurate, compliant, on policy, and did it solve the problem?
Why it is harder than it looks. Sampling a few conversations a week was never enough for people, and it is far from enough for a system that talks to thousands of customers a day. Scoring every conversation needs its own models, its own rubric, evidence for each score, and a way for reviewers to disagree.
What keeps costing. The rubric changes with policy. The scoring itself needs checking against human reviewers so you know it can be trusted. Someone has to act on what it finds, or it is just another dashboard.
8. Analytics and voice of the customer
What it is. Knowing what customers contact you about, why, what is rising, what the AI could not handle, and what to fix at the source so the contact never happens again.
Why it is harder than it looks. Containment and handle time are easy to count. Understanding why customers came back, which topics drive repeat contact and which fix would remove the most demand needs topic models, a taxonomy that stays current, and links to outcomes.
What keeps costing. The taxonomy drifts as products and policies change. Leaders keep asking new questions. Every new question used to mean a new report built by an analyst.
9. Admin: roles, permissions, audit logs and single sign-on
What it is. Who can change what, who approved it, what the AI did and when, and logging in through your company’s identity provider.
Why it is harder than it looks. None of it is visible in a demo, and all of it is in your security team’s questionnaire. Audit logs must be complete, tamper-resistant and searchable. Permissions must match how your teams actually work, across countries, brands and outsourcing partners.
What keeps costing. Every new team, partner, brand and regulation adds roles and rules. Access reviews, joiners and leavers, and audit requests never stop.
10. Languages
What it is. Serving customers in every language you support, at the same quality, with knowledge, tone and policy that are right for each market.
Why it is harder than it looks. A model that is excellent in one language can be mediocre in another, and speech recognition varies even more. Translating the knowledge base is not the same as having one written for that market.
What keeps costing. Every language multiplies the testing. Each new market adds knowledge to maintain, reviewers who speak the language, and quality checks of its own.
11. Evals and regression testing for every change
What it is. A library of real past conversations (the common ones, the hard ones, the hostile ones and the ones that went wrong) that every change must pass before it reaches customers.
Why it is harder than it looks. Language models are not deterministic, so “it worked when I tried it” proves little. Good evals need expert judgement on what the right answer is, a way to score at scale, and enough cases per topic, channel and language to catch a regression.
What keeps costing. Every prompt edit, article update, new tool and model version is a change. The test set must grow with every failure you find. This is the component most in-house builds underestimate, and the one that decides whether the system gets better or quietly worse.
12. Monitoring, incident response and on-call
What it is. Watching the live system (answers, errors, speed, cost, handovers, customer outcomes) and having someone ready to act when it goes wrong.
Why it is harder than it looks. A customer service system fails in ways that do not raise an error: confidently wrong answers, a policy misapplied, a spike in customers asking for a person. You need monitoring for meaning, not just for uptime.
What keeps costing. An on-call rota with people who understand the AI, the integrations and the telephony, every week of the year, including the peaks when your customers need you most.
13. Security, privacy and compliance paperwork
What it is. Removing personal data before it reaches a model where needed, setting retention, keeping data in the right country, encrypting it, and proving all of it to auditors, customers and regulators.
Why it is harder than it looks. Each requirement is reasonable on its own. Together they shape the whole architecture: where models run, what is logged, what is stored, and what can be sent to which provider.
What keeps costing. Penetration tests, certifications, audit evidence, security questionnaires from your own enterprise customers, and new rules for AI in more jurisdictions each year. For a security review list with a control and a test for each item, see Build vs buy AI agents: an ownership decision, not a coding decision.
14. A workspace your service team can change without engineers
What it is. The screens where your CX team updates knowledge, edits instructions, changes routing, reviews conversations and approves changes, without filing a ticket.
Why it is harder than it looks. Internal tools are always last in the queue. Without them, every policy change at five on a Friday becomes an engineering request, and the people who know the answer cannot fix it.
What keeps costing. Product design, testing and support for an internal product that has real users with real deadlines.
15. Keeping up: model churn and the pace of the field
What it is. Re-evaluating your system as new models, features and techniques arrive, and deciding what to adopt.
Why it is harder than it looks. New models arrive often and the benchmarks published with them say little about your conversations. Each one has to be tested on your own cases before it is trusted with customers. The ones you rely on are eventually retired.
What keeps costing. A permanent research and migration budget. If you skip it, your system falls behind. If you fund it, it competes with everything else your engineers could be doing.
The inventory in one table
| # | Component | If you build | If you buy |
|---|---|---|---|
| 1 | Model access, routing and switching | Build and keep current | Vendor; check you can bring your own model if you need to |
| 2 | Knowledge and retrieval | Build; own the content | Vendor runs retrieval; you own the content |
| 3 | Tools and integrations | Build every connector | Standard connectors; you own your custom actions |
| 4 | Voice stack | Assemble and run several suppliers | Vendor |
| 5 | Guardrails and thresholds | Build and tune | Vendor builds; you set scope and thresholds |
| 6 | Handover with context | Build across every channel | Vendor; you set the rules |
| 7 | QA on every conversation | Build and validate | Vendor; you own the rubric |
| 8 | Analytics and voice of the customer | Build | Vendor; you own the questions and the fixes |
| 9 | Roles, permissions, audit, sign-on | Build | Vendor; check what is live today |
| 10 | Languages | Build and test each one | Vendor; you test your markets |
| 11 | Evals and regression tests | Build the harness and the cases | Vendor harness; you own your cases |
| 12 | Monitoring and on-call | Staff it every week of the year | Vendor for the platform; you for your layer |
| 13 | Security and compliance | Do all of it, and prove it | Vendor’s evidence plus your own review |
| 14 | Workspace for the service team | Build and support | Vendor |
| 15 | Model churn | Fund it forever | Vendor |
What does it cost over three years?
Build cost is usually estimated as a project: a team, a few months, a launch. Most of the real cost is not the project. It is the run that follows it, and it is mostly people.
The cost lines
| Cost line | What goes in it | Build: year 1 | Build: years 2 and 3 | Buy |
|---|---|---|---|---|
| Build team | Engineers for the components above, product, design | High | Low (rebuilds and new channels) | Implementation only |
| Run team | Evals, knowledge tooling, integrations, reliability, on-call | Starts mid-year | High, every year | Your thin layer only |
| Service-side owners | Knowledge owners, QA reviewers, CX operations | Yes | Yes | Yes (the same in every option) |
| Inference | Model usage, which grows with volume and with every extra check | Grows | Grows | Usually inside the fee |
| Infrastructure | Hosting, search indexes, storage, logging, environments | Yes | Yes | Inside the fee |
| Third-party services | Speech, telephony, monitoring and testing tools | Yes | Yes | Mostly inside the fee |
| Security and compliance | Penetration tests, audits, evidence, questionnaires | Yes | Yes | Your review of the vendor |
| Licence or usage fees | Per conversation, per resolution or per seat | None | None | Yes, grows with volume |
| Opportunity cost | What your engineers would otherwise ship | Highest | Ongoing | Low |
| Exit cost | Retiring or replacing what you chose | Low (little to retire yet) | Grows the longer it runs | Switching work, data export |
The formula
Write your own numbers into these two lines. Use fully loaded people costs (salary, benefits, equipment, management time) and your own volumes.
Three-year cost to build = (build team × loaded cost × years to a governed launch) + (run team × loaded cost × remaining years) + inference + infrastructure + third-party services + security and compliance + opportunity cost
Three-year cost to buy = fees over three years + implementation + (internal owners × loaded cost × 3) + exit reserve
Service-side owners appear in both, because someone must own your knowledge, your scope and your quality whichever way you go. Leave them out of the comparison or put them in both.
One worked example (illustrative, people only)
Say a team of six builds for the first year to reach a governed launch, and a run team of four keeps it going in years two and three. That is 6 person-years in year one and 8 in years two and three: 14 person-years, more than half of them after launch. Multiply by your own loaded cost. Then add everything on the list above that is not people.
The point of the example is the shape, not the size. Year one is a project, visible and budgeted. Year three is a run cost, less visible and competing with your roadmap. When a build case shows only year one, ask for year three.
Year 1 and year 3 side by side
Building, year 1: a project budget, a launch date, a team with momentum.
Building, year 3: a platform with users, on-call, a test set to grow, models to re-qualify, and the original team partly moved on.
Buying, year 1: fees, implementation, and your people learning a new tool.
Buying, year 3: fees that follow your volume, and a platform that has shipped two years of improvements you did not pay to build.
What does buying give you that nobody puts in the spreadsheet?
A build case compares a vendor’s price with the cost of building what the demo showed. That leaves out the things a vendor’s other customers have already paid for. These are the discounted features: real, valuable, and almost never counted.
Other people’s failures, fixed before you meet them. A platform used by many teams finds edge cases, attacks and failure patterns long before any one company would. The fix reaches you as an update.
Model evaluation done for you. When a new model appears, someone else tests it on many kinds of conversation, decides whether it is better, and migrates. Your team does not spend a quarter on it.
A roadmap funded by more than your budget. New channels, languages, voice features and analytics arrive without a business case from you.
Security evidence that already exists. Certifications, penetration tests and completed questionnaires are ready for your review. Built in-house, each is a project of its own.
On-call that is not your team. The platform’s incidents at 3am are someone else’s rota.
Tools for the people who run service. Workspaces, reviews, analytics and approvals designed for CX teams, with documentation, training and support.
Implementation patterns. People who have connected these systems before, and know where projects stall.
Accountability in the contract. Uptime commitments, support terms, and in some pricing models (per resolution, for example) the vendor carries part of the risk of the AI not working.
No key-person risk. A system built by three engineers is fragile when two of them leave. A vendor’s platform does not depend on your retention.
Your engineers on your product. The work they do not do on customer service infrastructure is work they do on what makes your company different.
None of these is free: they are inside the fee. The point is that they are inside it, and a fair comparison counts them.
Where does buying cost more?
Buying is not the right answer by default, and a fair report says where it costs more.
Fees at very high volume. Usage-based fees grow with your contacts. At very large volumes, a well-run in-house team can cost less per conversation, if you count everything it runs.
Less control over the roadmap. The feature you need may be on someone else’s schedule.
Model choice. Some platforms decide which models you use. If you need your own model, or one hosted in a particular country, check before you sign.
Dependency. Your service runs on someone else’s platform, so their outages, price changes and strategy affect you.
Switching cost. Configurations, test sets and history have to move with you, so check what you can export.
Custom builds sold as products. Buying a bespoke system built for you by a vendor’s engineers is closer to outsourcing a build than buying a product. In September 2026, Gartner predicted that by 2028, 70% of enterprises will abandon AI agent systems built by a vendor’s forward-deployed engineers, pointing to rising costs and the inability to evolve those systems independently. Buy a product that improves for everyone, and make sure what is built for you can be maintained without the vendor in the room.
When is building the right call?
Sometimes building is right, and it should be said plainly. Build when most of these are true:
Customer service is your product, or the service conversation is a core part of what customers pay you for.
You have data or workflows no platform supports, and they are the reason customers choose you.
You have a strong ML and platform team with capacity for years, not for a project, and leadership that will keep funding it after launch.
The scope is narrow and stable: one channel, one language, a small set of tasks that will not grow much.
You have control or residency needs no vendor can meet, after you have checked vendors that offer private cloud and on-premise deployment.
Your volume is very high and your unit economics favour owning the stack, counting the run team and the on-call, not just inference.
If none of these are true, you are not building a differentiator. You are building a platform you will have to run.
The hybrid path: buy the platform, build the thin layer
For most teams the best answer is in between. The platform holds what is the same for everyone: the control plane (permissions, security, testing, audit trails and reliability), the voice stack, QA, analytics, and keeping up with models. Your team builds what is specific to you: custom actions in your own systems, business logic for routing and approvals, your own model where you need one, and the knowledge only you have.
What to check before you choose this path:
Can you bring your own model, or a model hosted where your data must stay?
Can you add custom logic and tools without waiting for the vendor’s roadmap?
Can you export what you build: configurations, test sets, conversation history and audit logs? Our earlier guide, Build vs buy AI agents: an ownership decision, not a coding decision, has four portability tests to run before you sign.
Can you run it where you need to: cloud, in-region, private cloud or on-premise?
Who owns the proof? Decide who measures whether customers’ problems were actually fixed, and who grades it. Our Proof Standard sets out one way to do that.
Questions to ask before you decide
Take these into the room. If the build case cannot answer them, it is not finished.
Time
When does the first real customer get an answer from this system, and when is it governed: tested, monitored, audited and on-call?
Can your engineering team commit that time without moving other priorities?
Ownership
Who prioritises new features after launch, and who writes them up for engineers?
Who owns knowledge upkeep, the test set and the QA rubric, by name?
What happens when two of the three people who built it leave?
Breadth and depth
How many of the fifteen components above are in the plan, and which are missing?
What is your annual budget for this, against what specialist vendors spend on the same product every year?
Cost
What is the fully loaded three-year cost, including the run team, on-call, compliance and model migrations?
What will your engineers not build while they build this?
Security and control
Does the plan include role-based access, audit logs, single sign-on and data retention that meet your own policies, on day one?
Can you prove to an auditor what the AI said to a given customer, and why?
Scale and exit
Will it hold up at your peak volume, in every channel and language, with the same quality?
If you change your mind in two years, what can you retire, what can you move, and what does it cost?
For the business case that sits around this decision, see The AI bill is due. Customer service is where it gets paid.
What to do this week
Write down the fifteen components and mark each one: in the plan, not in the plan, or someone else’s job.
Ask whoever built the prototype which of your last month’s hardest conversations it would get wrong, and test them.
Fill in the three-year formula with your own loaded costs, for years one and three separately.
Name the owner of knowledge, testing, QA and on-call for each option.
Score the comparison table with your own weights, and keep the result for the board.
Questions people ask
Should I build or buy AI for customer service?
Buy the platform and build the thin layer that makes you different, unless customer service is your product, your scope is narrow, and you have a strong ML and platform team funded for years. Most of the cost of building arrives after launch: evals, knowledge upkeep, QA, on-call, security evidence and model changes.
How do you evaluate build vs buy for AI?
List every component a production system needs, not just what the demo shows. For each, decide who builds it, who runs it and what it costs every year. Compare three-year costs, including people after launch and opportunity cost, then score build, buy and hybrid on time, control, security, maintenance and exit.
Should you build or buy AI voice agents?
Voice is the hardest part to build well. It needs speech recognition, speech synthesis, telephony, interruption handling, fast responses and warm transfer to a person, usually from several suppliers. Unless voice is core to your product, buy the voice stack and build your own actions and logic on top of it.
Sources
Gartner, Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025, press release, 29 Jul 2024.
Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, press release, 25 Jun 2025.
Gartner, Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028, press release, 29 Sep 2026.
Challapally, Pease, Raskar and Chari, MIT NANDA, The GenAI Divide: State of AI in Business 2025, July 2025 (preliminary findings; interviews with 52 organisations, survey of 153 senior leaders, review of over 300 public AI initiatives, January to June 2025).
The scores and the worked example above are illustrative. Use your own weights, costs and volumes.
