Build or buy AI customer support

Q: Does building give us better quality?

Not automatically. It gives you control over quality, which is only an advantage if you use it - meaning an evaluation set and someone who reads it. A build without evaluation is usually worse than a mature platform, because the platform has been tuned against millions of conversations and yours has not.

Buy when your answers live in your help centre and your helpdesk, your volume is under a few thousand conversations a month, and you need it live this quarter. Build when answers depend on systems no platform integrates with, when you need to measure and control quality yourself, or when volume makes per-resolution pricing more expensive than an asset. Most companies should buy first and build the exception.

The build-or-buy question is usually asked as a cost question. It is really a question about where your answers come from.

Key takeaways

If a competent new hire could answer 80% of your tickets from the help centre alone, buy.
The deciding factor is rarely price. It is whether answering requires reading a system the platform cannot reach.
Buying does not remove the content work. Both paths need your documentation to be true.
The hybrid - buy the front door, build the two workflows that matter - beats both pure options more often than either vendor will tell you.
Switching cost from a platform is real but usually overstated. Switching cost from a bad build is worse.

Who this applies to

A company with an existing support operation, deciding between an off-the-shelf AI support product and a custom build. Roughly 1,000 to 30,000 conversations a month, and a budget somewhere between $15,000 and $80,000 for year one.

If you are below 500 conversations a month, neither. Improve your help centre and revisit in six months.

The question that decides it

Take your last 200 tickets. For each one, ask: could a competent new hire answer this correctly using only the public help centre and the helpdesk record?

Over 80% yes: buy. Everything you need is where platforms already look.
50-80% yes: hybrid. Buy the front door, build the integrations for the rest.
Under 50% yes: build, or fix your documentation first and re-ask.

This works because it isolates the one variable that platforms cannot flex on: where the answer lives. Pricing, quality and speed are all negotiable. Reach is not.

What each path actually gives you

	Buy (platform AI)	Build (custom)
Time to live	Days to 3 weeks	2 to 12 weeks
Year 1 cost, 5k conv/mo	$18,000-45,000	$25,000-50,000
Year 3 cumulative	Scales with volume	Mostly flat
Reach into your systems	The vendor’s connectors	Anything with an API
Quality measurement	The vendor’s dashboard	Your own eval set
Behaviour changes	Feature request	A sprint
Exit cost	Migration project	None, if you own it
Who fixes it at 2am	The vendor	You, or whoever you retain

That last row is not a rhetorical point. Buying transfers operational risk to someone with a support obligation. Building keeps it, and the running cost of keeping it is real - typically $1,000-3,000 a month for a system of this size.

One variable decides it, because it is the one platforms cannot flex on: where the answer lives. Count the tickets before reading a single vendor deck.

Five conditions that make buying correct

Your answers are in your content. Covered above. This is the big one.
Volume is under roughly 3,000 conversations a month, or unpredictable. Per-resolution pricing at $0.60-2.00 is genuinely cheap at low volume, and renting capacity beats owning it when demand is spiky. Run the three-year arithmetic at your own projected volume before deciding.
You need it live this quarter. Platforms win on speed by a wide margin and no amount of engineering discipline closes that gap.
You have no internal technical owner. A build without someone to own it degrades within two quarters. If nobody’s job description will change, buy.
Your requirements are ordinary. If what you need is what most support teams need, someone has already built it better than a first custom attempt will be.

Four conditions that make building correct

Answering requires a system the platform cannot reach. A bespoke entitlement check, an internal inventory system, a legacy database, a partner API. This is the most common genuine reason to build, and it is decisive - a support agent that cannot see the answer is not a support agent.
You need to measure quality independently. Platform dashboards report what the platform chooses to report. If you are in a regulated context, or if a wrong answer is expensive, you need your own evaluation set scored against your own criteria. See how to measure whether an AI system works.
Volume makes the variable cost dominant. Above roughly 8,000 conversations a month the per-resolution model usually costs more than a build plus maintenance, and the gap widens as you grow.
The behaviour you need is not on anyone’s roadmap. Multi-step workflows across several systems, unusual escalation logic, an approval step your industry requires.

The hybrid most companies should actually run

Presenting this as binary suits both vendor types and suits few buyers.

The version that works in practice: buy the platform for the front door and the long tail, build the two or three workflows that carry your actual cost.

Concretely, a subscription business might use a platform product for general questions, password resets and policy answers, and build a single custom path for “where is my order and can I change it”, because that one requires reading three internal systems and is 30% of contact volume.

This gets you live in weeks, keeps the platform’s operational guarantees for the easy majority, and spends engineering effort only where reach genuinely requires it. It also produces a much better second decision, because after six months you have real data on which paths matter.

The cost is an integration seam and two systems to reason about. That is a real cost. It is usually smaller than the cost of building the easy 70% badly.

Content work happens either way

The most common misconception is that buying avoids the documentation problem. It does not.

Both paths need your help content to be accurate, current and structured enough for a machine to retrieve from. If your real answers live in a Slack channel and three people’s heads, someone is writing them down before either path works. Platforms fail on stale content exactly as reliably as custom builds do, and slightly more quietly, because you cannot inspect their retrieval.

Budget this explicitly. It is often two to four weeks of someone’s time, it is not an AI cost, and it improves your self-service deflection whether or not you ever deploy an agent.

How we advise on this, including against ourselves

We build custom AI support agents. Our published starting figure is $12,000. So it is worth being explicit about how often we recommend not doing that.

On the two-day diagnosis, the 200-ticket test above is one of the first things we run, because it is cheap and it settles the argument. When it comes back above 80%, the recommendation is usually to buy a platform product, and the roadmap you keep says so in writing.

The reason is not modesty. A custom build for a company whose answers already live in their help centre is a project that will be technically successful and commercially pointless - it will do, more expensively and later, what a subscription would have done in a fortnight. Those engagements produce a working system and a client who quietly regrets the spend, which is a bad trade for both sides.

Where we do think a build is right is narrower than the market implies: reach into systems platforms cannot see, independent quality measurement, or volume economics. If your case is not one of those, the honest answer is usually a platform.

When neither is worth it

Under about 500 conversations a month. The fixed costs of either path do not amortise. Improve the help centre.

When most contacts are caused by an upstream defect. A confusing checkout or a broken notification generates support volume that neither buying nor building should absorb. Automating the response hides the signal that would have let you fix the cause.

When tickets are mostly novel. Common in technical B2B. If the repetitive share is 10%, automating it is a rounding error on a real budget.

When nobody will own it. Repeated deliberately, because it is the most common cause of failure and the least discussed at purchase time.

Frequently asked questions

Can we start with a platform and build later?

Yes, and this is usually the right sequence. Six months of platform data tells you exactly which workflows justify a build, which is information you cannot get by speculating. Keep your ticket data exportable so the eventual build has training and evaluation material.

How hard is it to migrate off a platform?

Moderate. The conversation history and configuration usually export; the tuning does not. Budget a few weeks. It is a real cost but it is smaller than the cost of committing to a build before you know what you need.

Does building give us better quality?

Not automatically. It gives you control over quality, which is only an advantage if you use it - meaning an evaluation set and someone who reads it. A build without evaluation is usually worse than a mature platform, because the platform has been tuned against millions of conversations and yours has not.

What about open-source support agents?

They shift cost from licence to engineering rather than removing it. Treat them as a build with a head start, and apply the build conditions above unchanged.

Should the decision change if we are already on a major helpdesk?

It shifts toward buying, because integration is done and procurement is a line item. Check the tier boundaries before assuming the pricing scales the way you expect.

Next step

The 200-ticket test takes an afternoon and settles most of this. If you want it run properly alongside the cost arithmetic, that is what the two-day diagnosis produces - including the version that says buy.