Build, buy or partner for AI in your existing business systems

When you weigh build, buy or partner for AI, the deciding question is who wires the model into the CRM or service desk you already run. Buy when your vendor's built-in AI covers the task. Build when you employ developers who will own the connections for years. Partner when you need the connection now and lack that team.

The integration layer is the code, connectors and permissions that let an AI model read from and write to your business systems. Most of the cost, ownership and exit risk sits in that layer, not in the model. The model itself is rented by usage. Anthropic prices Claude per million tokens, and a token is a small chunk of text the model reads or writes.

The three routes differ in who builds the integration layer, who owns it afterwards and how easily you can leave. This guide follows one example throughout: a service team working in Zoho Desk, with customer records held in Zoho CRM. The same reasoning applies to any CRM or helpdesk.

Building in-house means your own staff design, write and run the integration layer between the AI model and your systems. You own every line of code, every prompt and every API key. You also own every failure, every model change and every handover when someone leaves.

The main cost of an in-house build is people and their learning time, not the model. Anthropic's own Building with the Claude API course runs to 67 lessons and 8 quizzes over about 9 hours. Its Introduction to Model Context Protocol course adds 10 lessons and about an hour. Model Context Protocol (MCP) is a standard way to connect an AI model to outside tools and data. Those courses are the starting point, before any work on your own CRM.

Organisations that build in-house invest in skills first. Defra's software development profession invested in GitHub Copilot and worked with Microsoft on remote and on-site learning. Since October 2025, its active users of AI tools have grown 11-fold. Monthly chat and agent interactions rose from 780 to more than 10,000.

Defra's developer survey also recorded concerns about using AI without enough planning or oversight. An in-house build therefore needs a senior person who owns that oversight, not only people who can code.

Buying means switching on the AI features your CRM or service desk vendor already ships, or adding a ready-made app to it. You pay through a subscription. The vendor chooses the model, writes the prompts and decides what data the feature can see.

The buy route is the fastest start and the lightest to run. Nobody on your side maintains code. When the vendor upgrades its model, you get the upgrade without a project of your own.

The limit of a bought AI feature is reach. It works inside the product that sells it. If the answer needs data from your accounts package, your stock system or a shared spreadsheet, the feature cannot use it unless the vendor built that connection. The guide to AI for small business built into your existing systems covers that gap in more detail.

Public sector rollouts show the same pattern. The Ministry of Justice marks its action to equip every staff member with a secure AI assistant as complete. Its action to automate repetitive admin tasks with AI-powered agents is still marked as progressing. A general assistant arrives quickly, while work that changes a process and its systems takes longer.

On exit, a bought feature leaves with the subscription. Whatever configuration your staff built inside it stays in that product.

Partnering means a specialist builds the integration layer with you, while your company keeps the systems, the data and the decisions. You pay a project fee plus the model usage. The work starts faster than hiring a team, because a partner brings people who have made this kind of connection before.

Ownership in a partnered AI build is whatever the contract says, so write it down. A safe arrangement has four parts:

• The code sits in a repository your company controls.
• API keys and model accounts are in your company's name.
• Prompts, test cases and settings are documented and handed over.
• Your staff can switch models or end the contract without the partner's help.

Exit is the real test of a partnership. If the partner holds the hosting and the keys, leaving means rebuilding. If everything already sits on your accounts, leaving means a handover meeting. Ask which arrangement is on offer before you sign.

Partnering suits a company that wants to own the result but not to staff a permanent AI team. It works best when one named person on your side learns the system alongside the build.

Whoever owns the integration layer also owns every model change, and the changes come often. In September 2026 alone, Anthropic announced Claude Fable 5.1 and Claude Mythos 5.1, then Claude Opus 5.5, then Claude Sonnet 5.5.

Each release changes the economics of a live system. Anthropic says Opus 5.5 performs at the level of Fable 5.1 on most work and costs 40% less to run than Opus 5. It says Sonnet 5.5 runs 30% faster than its predecessor and costs up to 30% less for most work.

Older models also retire. The Claude models overview lists Claude Haiku 4.5 for retirement not sooner than 15 October 2026. It lists Opus 5.5 at not sooner than 22 September 2027 and Sonnet 5.5 at not sooner than 28 September 2027. A system pinned to one model needs a planned move before its date.

Two details make that move easier. The Models API returns max_input_tokens, max_tokens and a capabilities object for every available model. Code can therefore check limits rather than hard-code them. The models are also offered through Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS, as well as the Claude API.

The three routes for adding AI to an existing CRM or service desk compare as follows. Read across a row to see where each route is strong and where it costs you.

No route wins every row. Many companies mix them: a bought assistant for general writing, and a built or partnered integration for the one process where the data matters.

Ticket triage means reading each incoming ticket, deciding its category and urgency, and sending it to the right team. Take a service team on Zoho Desk whose customer contracts sit in Zoho CRM. Good triage needs both the ticket text and who the customer is.

The buy route for ticket triage

Start by testing the AI features your helpdesk already offers on a sample of past tickets. If they classify well from ticket text alone, stop there. If the decision depends on a contract level held in the CRM, check whether the vendor's feature can see that field.

The build route for ticket triage

A developer writes a small service that receives each new ticket, looks up the customer in the CRM and sends both to Claude through the API. Model choice is then a cost decision. Claude Haiku 4.5 costs $1 per million input tokens and $5 per million output tokens, with a 200K token context window. Claude Sonnet 5.5 costs $2 and $10, with a 1M token window.

Anthropic describes Haiku 4.5 as its fastest model with near-frontier intelligence, and it is the cheaper option. Its retirement date of not sooner than 15 October 2026 means the build must plan a switch from day one. The team keeps evals, a fixed set of past tickets with known correct answers, and reruns them on each candidate model.

The partner route for ticket triage

A partner builds the same service, but on your company's accounts. The handover includes the evals, the model setting and a note on how to change it. Your team can then rerun the evals when a model retires, with or without the partner.

Each route to AI in your business systems has a typical failure, and you can check for it before you commit.

In-house builds fail at the integration layer

An in-house prototype can answer well in a chat window and still stall before production. The stall comes when it meets real permissions, field names and edge cases. At Svennis we see this most often when nobody is named as owner of the connection to the CRM and its permissions. We now settle that owner before anyone writes a prompt.

Bought features fail at the edge of the product

A bought AI feature fails when the answer depends on data the product cannot see. Staff then copy information between systems by hand. The feature saves less time than the demonstration suggested.

Partnered builds fail at handover

A partnered build fails when ownership was never written down. The system runs well until a model retires or the contract ends. Then nobody on your side can change it, and the exit becomes a rebuild.

All three failures share a cause: the integration layer had no owner on your side. Naming one person who answers for it prevents most of them, whichever route you take.

For a UK company, the government's own approach favours small, staged steps. The AI Opportunities Action Plan recommends that government generally use a flexible Scan, Pilot, Scale approach to AI adoption. The Ministry of Justice AI programme uses the same approach for its core AI products.

Scan, Pilot, Scale maps onto the three routes. Scan with what you can buy. Pilot one process, built in-house or with a partner. Scale only what the pilot proves.

Skills are the constraint on the build route in the UK. The plan recommends benchmarking pay for internal AI roles in government at no less than 75% of the private-sector rate. It also notes that the last government-funded AI labour market survey was in 2020. A small firm hiring AI developers competes with both sectors for the same people.

The gains are real but specific. The plan cites AI assistants freeing up to 20% of an employee's time on repetitive tasks. It cites cuts of 20 to 80% in final document production times in professional services. Whichever route you choose, check the rules on data and liability in the guide to AI law in the UK for businesses.

The practical next step is to choose one process and settle who owns its integration layer before you choose a route. Work through these steps in order:

1. Name one process with a clear business owner, such as ticket triage or quote drafting.
2. List every system the process reads from or writes to.
3. Test what your CRM or service desk vendor already offers on real past cases.
4. Decide who owns the integration layer: your staff, the vendor or a partner under contract.
5. Write down the exit: where the code, keys, prompts and evals live.
6. Run a time-boxed pilot and keep it only if it beats the manual process.

If you want to see which processes suit AI at all, browse AI by business task or the wider guide on how any company can use AI. When you have a process in mind and want it wired into your systems, the page on AI automation for growing businesses sets out how a partnered build works.