Build, buy or combine your customer-service AI?

A capable team can assemble a convincing customer-service agent prototype quickly, and that is why the build-or-buy question tends to be asked at the wrong moment. The demo is not the decision. The decision is who, in the second year, changes the refund rule when policy changes, repairs the connector when the shop platform upgrades, re-runs the evaluation set after a model update, and answers the auditor's question about what the agent may do. If that person does not exist, the cheapest build becomes the most expensive option you own.

This guide replaces an earlier article at this address. It keeps the question and reframes it around year two: five questions that decide between building, buying and combining, a worked scoring example with invented numbers, and the contrary cases where the standard advice does not hold. It does not rank vendors.

Where this comes from. The questions draw on five conversations Typewise held in 2026 with organisations deciding how to source customer-service AI: a facilities-management group planning an automation programme, an e-commerce retailer comparing its internal build with vendors, a travel company mid-selection, an outsourcer that had just shipped its own agent, and a telecom operator buying while building. I was in three; colleagues ran the other two. The positions below are those organisations' plans and opinions as they reported them; the five questions and the scoring example are ours, and the scores are invented.

Three options, not two

• Build. Your team assembles the agent from models, frameworks and your own integrations, and owns every part of it.
• Buy. A platform provides the agent runtime, configuration, integrations and evaluation tooling; your team owns policy, knowledge and quality.
• Combine. A platform runs the customer-facing agent while your team builds the pieces where you have an edge: a proprietary data layer, a domain model, a specialised troubleshooting tool, or the sensitive-data path you want to keep in-house.

Our recommendation for most situations is the third option, with the pieces chosen deliberately. The useful work is deciding which pieces go where, and that is what the five questions are for.

The five questions

1. Is this where you differentiate?

Build what customers choose you for; buy what they expect to just work. A company whose strategic goal is to own the software for its industry may reasonably build the customer-facing parts that express that; the same company can still buy customer-care capability it does not want to own. The facilities-management group's digital director drew the line for me like this: routine automations they would build themselves with no-code tools, and the help-desk agent they would buy from someone with the product and the knowledge, because a facilities help desk is not a banking help desk. He also insisted the help-desk manager join the next session, because his own view of the process was high level and the manager would know where the hidden steps and integrations were. Ask the question per workflow, not for "AI" as a whole.

2. Who maintains it, and with what spare capacity?

This is the year-two question, and in our view the honest answer should carry the most weight. Maintenance for a customer-service agent includes policy and knowledge changes (weekly), evaluation re-runs after any model or prompt change, connector repairs when a connected system changes, security reviews for every new action, and incident handling when an answer goes wrong. A team that has one engineer shared with the whole service organisation does not have the capacity, however good the first build was. The e-commerce retailer's service lead told my colleague that this is how she expects their decision to turn: the colleague maintaining their internal build will one day say the load has become too much, and that is the moment they would come back to an external solution. It was her own forecast, and she said her colleagues might see it differently. Decide that threshold before you reach it.

The buy side has its own version of this question: if every workflow change goes back to the provider, you have bought a dependency, not a capability. The digital director above had the same worry about a competing offer: if they wanted to change how it worked, it would be back to the supplier every time. Look for a setup in which your service team can change behaviour without a ticket, and your engineers own only what genuinely needs engineering.

3. Where does the customer data and the roadmap live?

An agent is only as useful as the data it can reach and act on. If the team that owns the shop platform and its data has other priorities, an internal build for a smaller business unit will wait behind them indefinitely; a bought platform with its own integration path may move faster, or may face the same gatekeeper. Map the owners of the data and actions each workflow needs before choosing, and ask the platform-owning team, not the sponsor, whether they will prioritise the integration.

A related split: the outsourcer that had just shipped its own agent runs real customer data on an in-house model and uses public AI services only for less sensitive work. That is a legitimate combine pattern, and it is a data-governance decision rather than a cost decision.

4. Can you leave?

Portability is the price of both building and buying. For a build, the risk is that the knowledge is in two people's heads and the evaluation cases are in a notebook. For a platform, the risk is that your policies, knowledge and conversation history cannot be exported in a usable form. In either case, insist that instructions, knowledge sources, test cases and history live somewhere you could move from. The outcome-based test cases you build for evaluation are the most valuable artefact; make sure you own them whichever path you take.

5. How fast do you need to be in market, and for how long?

The telecom operator's transformation lead described this sequencing to me: their internal AI team was at an early stage, the market was not waiting, so they buy customer-facing capability from experienced vendors now and grow the team in parallel, with the aim of taking over later. That is not a permanent decision. It is a sequencing decision with a review date, and the review should look at whether the internal capability actually matured.

A worked scoring example

The numbers are invented to show the method. Score each question for each workflow from 1 (favours buying) to 5 (favours building), weight by what matters to you, and read the pattern rather than the total.

The pattern says: buy the service runtime for order handling and returns, and combine for troubleshooting, where the domain knowledge is the differentiator and the data lives in an internal tool. In practice the troubleshooting row often becomes "platform runs the conversation, internal tool answers the technical question", which is the combine option in one workflow.

Whatever the scores say, run the comparison on the same evidence: parallel proofs of concept on the same anonymised cases, judged on whether the answers were correct and the customer was served, not on which demo looked most like the slide. The e-commerce retailer's service lead said as much: she wanted to see whether it works, whether the answers are right and whether the customer is satisfied, and cared less about how. Keep the exploratory proof of concept separate from the production pilot; they answer different questions. The travel company's selection lead had done it that way: hands-on proofs of concept with several vendors on the same exercise, with the production pilot a separate, later step.

Contrary cases

The usual advice ("buy unless it is your core business") has exceptions worth listing; each is a conditional case, not a finding about how common it is.

• You already shipped one. If you have built an in-house agent and it is in use without known problems, there may be no reason to pilot an external one. The outsourcer told my colleague its own multichannel agent had gone live days earlier and it saw no reason to experiment with an external one. The right move is to measure the thing you have, not to re-open the decision.
• The maintenance is the point. Where the organisation's strategy is to build a software capability, maintaining the agent is the investment, not the overhead. Just be clear that this applies to the differentiated workflows, not to the generic ones.
• Subsidised model pricing shifts the economics. If external model costs fall faster than internal costs, dependence on paid platforms looks different in year three than in year one. This is a speculative argument; treat it as a reason to keep portability, not as a reason to build.
• The platform cannot reach your data. A bought agent integrated with one business unit's systems may be unable to see another unit's customers at all without a new integration; then the "buy" is partly a build anyway, and the decision is who does that work.
• The sponsor and the technical approver disagree. The budget holder may want the platform while the technology owner objects to adding to the stack. At the travel company, the budget sat with the commercial chief while the technology chief had to agree because the platform would enter the stack; their selection lead mapped every scorecard criterion to quality, cost and effort so the executives could see the trade-off, and noted that an outsourced build looked cheap partly because of a low-cost engineering location while the maintenance would be theirs. Neither can decide alone; the fix is a shared rubric that maps the proof-of-concept findings to quality, cost and effort so the trade-off is explicit.

Decision checklist

• [ ] Scored per workflow, not for "AI" as a whole.
• [ ] Named the maintainer for year two and checked their actual capacity.
• [ ] Confirmed with the data-owning team, not the sponsor, that the needed integration will be prioritised.
• [ ] Established what is exportable: instructions, knowledge, test cases, conversation history.
• [ ] Set a review date for any "buy now, build later" sequencing.
• [ ] Compared options on the same cases, judged on answer correctness and customer outcome.
• [ ] Agreed a shared rubric between the business sponsor and the technical approver.

Limits

This is a decision method, not a cost model; for the money side, see customer-service AI ROI. It also assumes the organisation can describe its own workflows well enough to score them; where it cannot, the permissions exercise is a good forcing function. And a platform's capabilities change; verify any specific feature with the vendor at decision time rather than relying on a guide.

Related reading

• Who owns customer-service AI after the pilot?: the roles the maintainer question points to.
• Is your customer data ready for an AI agent?: the data-ownership question in detail.
• Taking a customer-service AI agent live: running the comparison as a proper pilot.

FAQ