Integrating a chatbot: the widget is the easy part

The short version

• The chat window is the quickest part of a chatbot integration. Identity, permissions and write access are the project.
• A chatbot needs a short list of named actions, not an admin API key. If it can call anything the key can call, the model is your permission model.
• Handover is an integration, not a fallback. The human who picks up needs the transcript, the resolved identity and what the bot already tried.
• Pricing for AI support agents is moving to a charge per conversation outcome, so the share of conversations your integration can close is the number on the invoice.
• Every connected system is something that can change underneath you, so the smallest integration that answers the real question is usually the one still running a year later.

What does chatbot integration actually mean?

Three separate connections, usually built in the wrong order. A chatbot integration joins the bot to a channel (your website, WhatsApp, Slack, the helpdesk inbox), to a source of answers (documentation, a knowledge base, product data), and to the systems where something can change (CRM, billing, ticketing, order management). Buyers almost always mean the third when they ask about integration. Demos almost always show the first.

The distinction matters because the three fail in different ways and on different timescales. A broken channel is obvious within minutes, because nobody can reach you. A stale knowledge source produces answers that are confidently wrong, and nobody notices for a month. A misfiring action path changes a customer's record, and that one you cannot take back with a deploy.

So treat them as three pieces of work with three sets of tests, even when one vendor sells all three behind a single toggle. The vendor's integration is the plumbing. Deciding what flows through it is yours, and it is not a configuration question.

The three layers, and how each one fails

What should you connect first?

Identity, then one read-only source of answers. The bot has to resolve who is asking before most answers mean anything, because 'where is my order' has no answer in general and a precise answer for a known customer. If the channel can pass a signed-in user, use it. If it cannot, decide deliberately what the bot may say to an anonymous visitor, and keep that set small.

One read-only source is enough to find out whether the bot is useful at all, and it is cheap to withdraw if it is not. Teams that begin by wiring four systems and a write path spend their first fortnight debugging authentication instead of reading transcripts, which is the only activity in this project that reliably tells you what to build next.

Write access comes third, one action at a time. 'Integrate the CRM' is not a task, because nobody can say when it is finished or test that it works. 'Create a ticket with these five fields' is a task. It has a scope, a failure mode and a test, and it can ship on a Tuesday.

How do you connect a chatbot to a CRM without giving it too much access?

Give it named actions, not credentials. A chatbot does not need an admin API key for your CRM. It needs a short list of operations it is permitted to perform, each with its own scope and its own validation of the arguments. If the bot can call anything the key can call, then your permission model is whatever the model decides to do next, which is not a model you can describe to a customer.

Four rules hold up in practice. Read endpoints before write endpoints. An idempotency key on every write, so a retry cannot create a second record. A confirmation turn before anything irreversible, phrased so the customer agrees in their own words rather than a button the model presses on their behalf. A hard limit per conversation, so a loop cannot become a thousand records at three in the morning.

Then log every call with the conversation identifier, the arguments and the response. When a customer says the bot did something strange, that log is the difference between a fix and a guess. It also shows you which action the bot reaches for too often, which is usually the first sign that a prompt is doing work a bit of code should be doing.

A working order for a chatbot integration

1. Resolve identity: decide how the bot knows who is asking, and what it may say to someone it cannot identify.
2. Connect one read-only source of answers, and nothing else.
3. Put it in one channel, with a visible route to a person.
4. Read a week of real transcripts before adding anything.
5. Add one write action, scoped to that action, with an idempotency key and a confirmation turn.
6. Instrument it: log every tool call against the conversation identifier.
7. Add the second write action only once the first has run a week without surprises.

What happens when the chatbot cannot answer?

It hands over, and that path is an integration in its own right. 'We will escalate to a human' is a promise, not a design. The person who picks up needs the transcript, the resolved identity, the actions the bot already took and the reason it stopped, delivered into the tool they already work in. Without that, escalation makes the customer repeat themselves, which is worse than having no bot at all.

Decide the unhappy paths before launch, because they are most of the traffic you will be judged on. What happens outside business hours. What happens when the queue is long. What the bot says when it is not confident, which should be short and should not guess. How a customer asks for a person directly, which they will do, and which should work on the first attempt rather than the third.

The best-documented study of generative AI in support is about this shape rather than about bots answering alone: a conversational assistant introduced in stages across 5,179 customer support agents at a software firm, with a control group of agents who never received the tool. A model that helps the person answering is easier to integrate, easier to supervise and easier to switch off than a model answering by itself.

What drives the running cost of an integrated chatbot?

Two things: how many conversations the bot finishes without a human, and how often the systems it connects to change. The first sets the vendor bill. The second sets your engineering bill, and it is the one nobody forecasts.

Pricing for AI support agents has moved towards charging per outcome rather than per seat. Intercom's published list price for its Fin agent bills an outcome once per conversation and sets a minimum of 50 outcomes a month. Read that as a design brief rather than a price. The share of conversations your integration can actually close is the number on the invoice, and that share depends on which systems the bot can read and write, not on which model is underneath it.

The maintenance side is quieter and more expensive. Documentation goes stale. An upstream API renames a field. A product launch creates a question the retrieval source has never seen, and the bot answers it anyway. Somebody has to read transcripts every week and fix what they find. If nobody is going to own that job, build less than you can.

Is a chatbot integration worth it for a small team?

Sometimes, and the adoption statistics you are shown are probably not describing you. The US Census Bureau's Business Trends and Outlook Survey reports that larger firms, those with at least 20 employees, are the biggest users of AI. Eurostat's enterprise survey covers enterprises with 10 or more employees. The UK government's 2025 adoption survey interviewed 3,500 private sector businesses with at least five employees.

If you employ four people, none of those pictures includes you, and that cuts both ways. There is no evidence that everyone like you is already doing this, and none that they are not. Decide from your own volumes instead. A team answering the same few questions all day has a case for automating them. A team answering a handful of varied ones a week does not, and should spend the money on documentation.

The national figures also carry caveats their own publishers state plainly. The Office for National Statistics calls its results on extensive AI use early indications and does not define extensive. Anyone quoting a single adoption percentage at you has usually dropped that sentence on the way.