Conversational AI, answered straight.

Implementation

• Which department should deploy conversational AI first?2 min

  Whichever one answers the same question most often. That is usually support, occasionally inbound sales, and almost never the department that asked for it.

  Whichever department answers the same question most often.

  That is usually support. Occasionally inbound sales. Almost never the department that asked for it, which tends to be whichever one has recently read something about AI.

  The test

  Go to each team and ask what they answer most in a week.

  The department that can immediately name three questions with identical answers, sitting in a system, is your starting point. The one that says "it varies, every case is different" is not, however keen they are.

  You are looking for volume and repetition, not importance. Important and varied is exactly what humans should keep.

  Why support usually wins

  Highest volume of repetition in most businesses. Order status, account questions, billing explanations, first-line troubleshooting. Enormous quantity, small number of shapes, answers already in your CRM or billing system.

  It also has the clearest measurement. Contacts handled, resolution rate, satisfaction, recontact. You will know within weeks whether it worked, which matters more than it sounds because the first deployment is buying you evidence for the second.

  When to start with sales instead

  Two conditions.

  You have a genuine out-of-hours or speed gap on inbound, where enquiries arrive and sit. Leads contacted within five minutes qualify far better than those contacted after thirty, and 35 to 50% of sales go to whoever answers first, so the cost of the gap is quantifiable.

  Or your support contact is genuinely low-volume and varied, in which case the support case is weak anyway.

  Sales tends to show a faster commercial number. Support tends to show a more defensible one. Both are reasonable places to begin.

  The mistake to avoid

  Starting everywhere.

  Every channel, every department, every query type, on the theory that a wider launch demonstrates commitment. It does not. It produces something mediocre in six places, with nothing tuned well enough to prove the concept, and no way to tell which variable caused which result.

  Pick one lane. Two specific query types, one or two channels. Get it genuinely good. Then add.

  The second agent takes one to three weeks against four to eight for the first, because the integration layer, the knowledge layer and the escalation logic already exist. Most of the first build is foundation you only pay for once, which is why the rollout accelerates rather than repeating.

  The other thing to check before choosing

  Which department's systems can you actually get into.

  A perfect use case behind a system nobody can grant access to is worse than a decent use case behind an accessible one. In our builds the go-live date has been set by system access nearly every time, not by the AI or the conversation design.

  So the real question is a pair. Where is the repetitive volume, and where can we read the data. Where those overlap is where you start, and it is occasionally not the department with the loudest case.

  Frequently asked

  Should we not start where the business case is strongest?

  Start where the case is clearest, which is not always the same thing. A modest, unambiguous win in a high-volume queue builds more internal confidence than a larger projected return nobody can verify. You are buying evidence for the second deployment as much as the result of the first.

  Can we do support and sales at the same time?

  You can, and I would not. Two lanes at once means neither gets properly tuned, and when something underperforms you cannot tell which variable caused it. The second agent is much faster anyway because the integration layer already exists.

  What if two departments both want it?

  Pick the one with the higher volume of identical questions and the more accessible systems, then be explicit that the other is next. The second build typically takes one to three weeks against four to eight for the first, so the wait is shorter than it sounds.

  Open as its own page
• How long does it take to deploy a conversational AI agent?2 min

  Four to eight weeks for a first agent properly integrated. The variable is not the AI, it is how quickly you can get access to your own systems.

  Four to eight weeks for a first agent that is properly integrated. One to three weeks for each one after that.

  If someone quotes you a week for the first, they are selling you a widget that can talk but not act. If someone quotes six months, you are talking to a consultancy and there is a six-figure invoice attached.

  What the range actually depends on

  Almost entirely your systems, not the AI.

  Connecting to a modern platform with a clean documented API is quick. Connecting to a legacy billing system where one internal developer owns every endpoint, and that developer is busy until March, is where projects stall.

  We have learned to scope that dependency first and build everything else in parallel around it. The conversational logic is usually ready in days. The integration to pull a customer's real account data is what sets the go-live date, nearly every time.

  So when a partner asks about your stack before they ask about your use case, that is a good sign rather than an evasion.

  Roughly how the weeks go

  Week one. Discovery. Read the existing tickets, pick the two starter lanes, map the data sources, write the tone of voice guide. That last one matters more than it sounds and gets skipped constantly.

  Week two. Integration build, agent in shadow mode. It watches real traffic and generates what it would have said, without a customer seeing any of it.

  Week three. Shadow-mode tuning. Compare what the agent would have said against what your team actually said, and close the gap. This is where the value is, and where impatient projects cut.

  Week four onwards. Live on the first lane, narrow. Maybe a fifth of traffic. Monitor closely, tune daily, widen as it earns it.

  The mistake that costs the most time

  Going live too early.

  Shadow mode looks like nothing is happening, so it is the first thing squeezed when someone wants a launch date. Then the first three months become learning in public, and a public incident costs more to recover from than the fortnight you saved.

  Longer in shadow is almost always cheaper than a rebuild after a customer screenshots something wrong.

  What you can do to speed it up

  Get the system access sorted before the build starts. Names, credentials, API docs, and a person who can approve things without a two-week wait.

  Pick two ticket types, not ten. Specific ones. "Bill queries that arrive by email" and "tier-one router troubleshooting on WhatsApp" is a brief. "Customer service" is not.

  And appoint one internal owner for the first ninety days. Not a committee. Someone who sits in the weekly review and can make a call. Deployments without that go stale within a month of launch, and the timeline that matters is not four to eight weeks, it is whether the thing still works at month six.

  Frequently asked

  Why do some vendors say a week?

  Because a generic widget on a website genuinely does take a week. What takes four to eight is connecting it to your CRM, billing and helpdesk so it can resolve rather than deflect. Both are real products, they are just not the same product.

  What is the single biggest cause of delay?

  Access to your own systems. Not the model, not the conversation design. In our builds the conversational logic is usually ready in days and the go-live date is set by how long it takes to get credentials for a system one busy person owns.

  How fast is the second agent?

  Much faster, typically one to three weeks, because the integration layer already exists. Most of the first build is foundation work that every subsequent agent reuses.

  Open as its own page
• What do I need in place before deploying an AI agent?2 min

  Three things. Two named ticket types, customer data in something queryable, and one owner for ninety days. Miss any and it stalls predictably.

  Three things. If you have all three you are ready to brief a build. If you are missing one, the deployment will stall in a way that is entirely predictable from here.

  One: two specific ticket types, named

  Not "customer service". Specifically: bill queries arriving by email, and tier-one router troubleshooting on WhatsApp. Or coverage checks from web chat and post-purchase order status.

  If you can name two, you have a brief. If the only answer is "all of it", nobody can scope the work and the build will sprawl until it is bad at everything.

  The instinct to launch across every channel and every query type at once is the single most reliable way to produce a deployment that underperforms on all of them. Start narrow, get one excellent, add the next.

  Two: customer data in something queryable

  A CRM, a database, a helpdesk. Anything the agent can look a customer up in by phone number or email and get back a coherent record.

  Messy is fine. Disconnected is not. If a customer's history lives across three systems with no shared identifier, that needs joining first. The AI build will not fix that problem. It will make it very visible, usually in front of a customer.

  Three: one person who owns it for ninety days

  One. Not a committee, not "the ops team".

  Not their full-time job, but their named project. They sit in the weekly review, they decide when the agent's behaviour should change, and they are the person to call when something needs a judgment.

  This is the one people skip, and it is the one that decides whether the thing still works at month six. Deployments without an internal owner go stale within a month of launch, because the world keeps moving and nobody is watching the gap open.

  What you do not need

  A perfect knowledge base. Existing help docs, policies and past tickets are enough raw material to start from, and the tidying happens during the build.

  A technical team. Integration work sits with whoever builds it. What you need from your side is someone who can grant system access without a two-week wait.

  Certainty about ROI. You will not have it before you start, and anyone offering you a precise figure in advance is guessing. What you can have is a narrow first scope where the result will be unambiguous either way.

  If you are missing one

  Spend the few weeks fixing it rather than starting anyway.

  A build that begins before the data is joinable, or before anyone owns it, does not fail fast. It fails slowly, four months in, having consumed budget and goodwill. That is a much more expensive way to learn the same thing.

  Frequently asked

  What if our customer data is messy?

  Messy is workable. Disconnected is not. The agent needs to look a customer up by something it will actually have, usually a phone number or an email, and get back a coherent record. If your history sits across three systems with no shared identifier, join those first, because the AI build will expose that rather than fix it.

  Do we need a knowledge base already written?

  It helps enormously but it does not need to be tidy. Existing help docs, policy documents and past support tickets are usually enough raw material. What matters more is that somebody owns keeping it current afterwards, because a knowledge base accurate at launch and untouched will make the agent confidently wrong within months.

  How much internal time will this take from us?

  Less than a build, more than nothing. Expect a few hours a week from one person during the build, mostly answering questions and unblocking system access, then a standing weekly review once it is live. Deployments where nobody has that time are the ones that go stale.

  Open as its own page

Risk

• Can conversational AI handle complaints?3 min

  It should capture, route and acknowledge them properly. It should not try to resolve them. That is the fastest way to turn one problem into two.

  It should capture them, route them and acknowledge them properly. It should not try to resolve them.

  That distinction is where most deployments get this wrong, and getting it wrong is expensive, because a complaint mishandled by a machine becomes a complaint about the machine on top of the original problem.

  Why automation is poor at this specifically

  A complaint is rarely only about the facts.

  Somebody is annoyed, often for accumulated reasons rather than the single incident they are describing. What they usually want first is acknowledgement that something went wrong, from someone who can do something about it.

  Accuracy benchmarks make the point. Well-defined factual tasks run around 98% accuracy. Ambiguous, emotionally loaded scenarios drop to roughly 61%. That is not a model that needs improving, it is a category of conversation where the difficulty is not informational.

  Add the trust trend. The share of people saying AI-led service costs a business their trust moved from 47% to 57% in eight months. An unhappy customer discovering they are talking to software rather than a person is a compounding problem.

  What it should do instead

  Real work, none of it resolution.

  Detect early. Explicit words are easy. The valuable signals are subtler: a customer who has contacted you three times about the same issue, an unusually long message, language carrying frustration. Recontact history is often the strongest indicator and it is already in your systems.

  Capture properly. What happened, when, what they have already tried, what outcome they want. Gathered patiently, without the customer having to compress it into a form field.

  Pull the context. Account history, previous tickets, previous complaints, what was promised last time. The person picking this up should not be starting cold.

  Route to the right team. Not a general queue where a serious complaint sits behind twenty password resets.

  Acknowledge honestly. Confirm it has been logged, say who is picking it up, give a realistic timeframe. Then meet it.

  The handover is the whole thing

  A complaint handed over badly is worse than one that never touched an agent.

  "I'll connect you to someone who can help", then a wait, then a person asking them to explain it all again, takes someone who was annoyed about one thing and gives them a second thing to be annoyed about.

  Done properly the human opens with the customer identified, the issue documented, the history attached and the transcript there. Their first sentence can be about the problem rather than about who the customer is.

  The narrow exception

  Where the fix is factual, verifiable and within an agreed limit.

  A billing error the agent can confirm against the system and correct, immediately, is better service than a two-day queue. The customer wanted the money back, not a conversation about their feelings.

  The test is whether resolving it needs judgment. If it does, it is not the agent's to resolve, however clearly the customer has explained it.

  What this is really worth

  Not deflection. Complaints should not be deflected.

  The value is that they get captured consistently, routed correctly, and arrive with a person who can act instead of someone who has to start by working out what happened. That shortens resolution time, which is the thing complainants actually judge you on.

  And it means complaints stop being lost at 9pm on a Sunday, which in most operations is where a meaningful share of them currently go.

  Frequently asked

  So the AI should just pass every complaint to a human?

  Pass every genuine complaint, yes, but do real work on the way. Capture what happened, pull the account history, identify which team owns it and route there with everything attached. A complaint that reaches a person fully documented gets resolved faster than one that arrives as a name and a grievance.

  How does it tell a complaint from a normal query?

  Partly language, partly context. Explicit words like complaint or escalate are easy. The harder signals are repetition, a customer who has contacted you three times about the same thing, or frustration in how something is phrased. Recontact history is often the strongest indicator and it is sitting in your systems already.

  Is there any complaint an agent should resolve?

  Where the fix is factual and unambiguous, such as a billing error the agent can verify and correct within an agreed limit, closing it immediately is better service than a queue. The test is whether resolving it requires judgment. If it does, it is not the agent's to resolve.

  Open as its own page
• What happens when an AI agent does not know the answer?2 min

  The question that separates a real vendor from a demo. A good answer describes a confidence threshold and a clean handover to a person.

  Ask a vendor this in your first call. The answer tells you more than any case study will.

  A good answer describes a confidence threshold and a clean escalation. A bad answer is some version of "our AI handles everything", which means either they have not run one in production or they are hoping you will not check.

  No agent handles everything. The ones claiming to are the ones that strand people in loops.

  The two ways it goes wrong

  It guesses. This is the failure everyone worries about, and it is genuinely fixable. An agent answering from a model's general knowledge hallucinates somewhere in the 15 to 27% range. One that retrieves from a verified knowledge base before responding drops to under 1.5%.

  That difference is not a better model. It is whether the thing is grounded in your actual content, and it is the single most important technical requirement in the whole category.

  It hedges. Less discussed and more common. The agent answers correctly, then adds "please confirm with a member of our team before proceeding". The customer reads that as uncertainty, asks for a human, and you have an escalation on a question the agent answered perfectly well.

  We hit this ourselves. Resolution rate sat stuck for weeks while the transcripts looked fine, because the agent was being politely unsure at the end of correct answers.

  What good looks like instead

  Three things, and they are all architectural rather than conversational.

  An explicit threshold. Above it, the agent answers directly and without hedging. Below it, it stops trying and hands over. The mushy middle, where it half-answers and half-defers, is where trust goes.

  Routing that means something. Billing goes to billing, faults go to faults. Not one undifferentiated queue where a specialist question waits behind twenty password resets.

  Context carried across. The human picks up with the customer verified, the issue captured and the transcript attached. If the customer has to start again, the handover failed no matter how good the first half was.

  Done properly, most people do not notice the conversation changed hands.

  The bit worth being blunt about

  A bad handover is worse than no agent. "I'll connect you to someone who can help", then five minutes of silence, then a person asking for the account number again, is precisely the experience that taught a generation of customers to type "agent" the moment a chat window opens.

  You are not just failing that conversation. You are confirming a suspicion they already had, and it carries into every future interaction.

  What to ask before you sign

  Ask to see the threshold. Ask what percentage of conversations cross it. Ask what the human sees when a handover lands, and ask to look at that screen.

  A partner who runs agents in production can show you all three. One who only has a demo will start talking about the technology instead, and that pivot is your answer.

  Frequently asked

  How do I stop an AI agent making things up?

  Ground it. An agent answering from a model's general knowledge hallucinates somewhere in the range of 15 to 27% of the time. One retrieving answers from a verified knowledge base before responding drops to under 1.5%. That single architectural choice moves the risk by more than an order of magnitude.

  Should the agent always offer a human?

  The route to a human should always be available and obvious, but the agent should not offer it reflexively. An agent that hedges every answer with 'please confirm with our team' trains customers to skip it entirely, which defeats the point.

  What does a good handover actually include?

  The customer already verified, the issue captured, and the full transcript attached, routed to the team that owns that problem rather than a general queue. If the customer has to repeat themselves, the handover failed regardless of how good the conversation was beforehand.

  Open as its own page

Telecoms

• Can AI reduce Ofcom automatic compensation payouts?3 min

  Not directly. Compensation is triggered by operational failure, not communication. What automation changes is whether one failure becomes three.

  No, and I would be sceptical of anyone selling it that way.

  Compensation is triggered by operational failure. A missed appointment, a late start, an unrepaired fault. None of those are caused by how you communicate, and none of them are fixed by a better conversation.

  What automation changes is what that failure costs you beyond the credit.

  The rates, so the arithmetic is concrete

  From 1 April 2026: £32.31 for a missed engineer appointment, £6.46 for each calendar day a new service starts late, £10.34 for each calendar day service stays broken after two full working days. Bill credit within 30 days, rates rising each April with CPI.

  For a growing altnet, a hundred delayed installs running five days each plus fifty missed appointments is roughly five thousand pounds in a month.

  That is the visible cost, and it is the smaller one.

  Where the real cost sits

  A delayed install means a customer who has paid and has no service. They contact you, repeatedly. Each contact costs support time. If they cannot get a straight answer about the new date, frustration compounds into a complaint, or a switch, or both.

  Their acquisition cost has not been recovered. The £6.46 a day is close to incidental next to losing them in month four.

  So the useful goal is not reducing payouts. It is stopping one operational failure becoming three commercial ones.

  What automation genuinely does

  Absorbs the chase. The dominant contact during a delayed install is "where is my order". An agent reading real provisioning data answers instantly, at any hour, with the actual date. In our own deployment this was the surprise finding: we expected billing to be the win and the install-status chase turned out to be what was consuming the team.

  Flags at-risk orders earlier. A slipped date is knowable before the customer notices. A triggered message with the new date and what happens next changes the emotional shape of the whole thing, even though the failure still happened.

  Explains the credit. Customers who discover they were owed money and never told react badly. An agent that can say what was credited and why turns a grievance into evidence you deal straight.

  The limit, stated plainly

  It does not stop your engineer being late.

  If field operations are under-resourced or provisioning is genuinely slow, no conversational layer fixes that. It handles the consequences better and surfaces the pattern sooner. The cause is untouched.

  What to measure instead of total payouts

  Total compensation moves for too many reasons to be a clean signal.

  Watch contacts per delayed order. If a slipped install used to generate four inbound touches and now generates one, that is measurable within weeks.

  Then watch ninety-day churn for customers whose install slipped against those whose did not. That gap is the number that actually matters, and most operators have never calculated it.

  The longer version, with the full arithmetic, is in Ofcom automatic compensation: what each failure costs.

  Frequently asked

  What are the current rates?

  From 1 April 2026: £32.31 for a missed engineer appointment, £6.46 for each calendar day a new service starts late, and £10.34 for each calendar day service is not repaired after two full working days. Paid as a bill credit within 30 days, rising each April with CPI.

  So what does automation actually change?

  Three things. It absorbs the repeat contact a delayed order generates, it lets you flag an at-risk order before the customer notices, and it explains a credit properly so the customer sees you dealing straight rather than discovering it themselves.

  Is there any way automation reduces the payout itself?

  Only indirectly, through better information. Automation surfaces which orders slip and where failures cluster, sooner and more consistently than a support queue does. Acting on that is what reduces payouts, and that is an operational change rather than a technology one.

  Open as its own page
• Can AI handle broadband support queries?3 min

  Yes, and install-status chasing is where it pays first. Not the clever diagnostics, the same engineer-date question asked four hundred times a week.

  Yes, and the place it pays first is not where people expect.

  We assumed billing and account questions would be the big win. In practice the heaviest relief came from the install-status chase. Where is my order, when is my engineer coming, why has the date moved, asked over and over during the exact period when a new customer is most fragile.

  Once the agent could read real provisioning data and answer those instantly, a large slice of the daily queue simply disappeared.

  Why install queries are the right first target

  Three reasons, and they compound.

  The volume is enormous and spiky, hitting hardest when a subscriber base is growing, which is precisely when the support team is least able to absorb it.

  The questions are nearly identical. Same shape, different customer, answer sitting in a system nobody outside operations can see.

  And the timing is brutal. This is the window where somebody has just committed money and has not yet had a working service. How it feels to ask a question during that period shapes whether they are still there at renewal. Early churn frequently traces back to the install experience rather than to the install itself.

  What it handles well

  Install and onboarding status, straight from provisioning.

  First-line troubleshooting, if it can see the line. Sync rate, signal strength, which band a device is sitting on, whether there is a known outage at that postcode. That resolves a meaningful share outright and, when it does not, the engineer who picks it up starts ten minutes ahead rather than asking the customer to describe the flashing lights again.

  Billing explanations. Itemising why this month is fourteen pounds higher, with the install fee and the pro-rata switch broken out, and sending the receipt.

  Coverage and eligibility checks for inbound prospects, which is a sales function wearing a support coat.

  What it should not touch

  Dispatching an engineer without trying a remote fix. That is expensive, and the policy should be try remote first, escalate on the follow-up if it did not land.

  Anything where the customer is upset about the service rather than confused about it. A factual outage update, fine. A complaint about three failed appointments, not fine.

  And anything genuinely novel. Regulatory change, an unusual account state, a fault pattern nobody has seen. Escalate.

  The out-of-hours point

  Worth stating separately because it is the strongest case in this sector.

  People notice their broadband is down in the evening. They research switching on a Sunday. Those hours are when a meaningful slice of both your retention risk and your acquisition opportunity turns up, and for most altnets they hit a closed door.

  The alternative to an agent handling the 9pm connection problem is not a slower human. It is nobody, until tomorrow.

  The honest limit

  None of this fixes a network that is genuinely unreliable or installs that genuinely run late. It handles the complaints faster and more consistently, which is worth something, but it surfaces the operational problem rather than solving it.

  If the underlying service is the issue, an agent buys you time and better information. It does not buy you a fix.

  Frequently asked

  Can it do actual fault diagnostics or just answer questions?

  It can run first-line diagnostics if it is connected to the systems that hold them. Line sync, signal strength, which band a device is on, whether there is a known outage at that postcode. What it should not do is dispatch an engineer on its own when a remote fix has not been tried, because that is expensive and usually unnecessary.

  What about customers who are already angry about an outage?

  Being fast helps more than being clever here. An agent that says there is a known fault at their postcode with a restoration estimate, at 9pm, beats a queue. Anything beyond a factual update on a live outage should go to a person, because that conversation is about frustration rather than information.

  Does it need access to provisioning systems?

  For install queries, yes, and that is the whole point. Without provisioning data it cannot tell a customer their actual install date, which is the single most-asked question during onboarding. An agent that cannot answer it is answering the easy half and leaving the hard half in the queue.

  Open as its own page

Retention

• Can conversational AI handle renewals?3 min

  Yes, and it is the highest-value conversation most businesses run on autopilot. The gain comes from firing on the trigger, not on spare capacity.

  Yes, and it is usually the single most valuable conversation a business is currently running on autopilot.

  Most renewal processes are a notification. A reminder goes out, the customer reads it or does not, and whatever happens next happens without you. That is a strange way to treat the moment somebody decides whether to keep paying you.

  Why the current version underperforms

  Two structural problems, and neither is about the message wording.

  It runs on capacity, not intent. A renewal window opens and whoever on the team is free that week works the list. The customer who was wavering on Tuesday gets a call on Friday, by which point they have looked at alternatives.

  It is one-directional. The customer thinking "could I get this cheaper?" has nowhere to put that thought. The reminder cannot answer, so they either do nothing and lapse, or go and ask a competitor, who will certainly answer.

  Both are fixable, and neither needs a bigger team.

  What changes with an agent

  It fires on the trigger. Renewal window, contract end, a cancellation signal, a lapse. The conversation happens when the customer is actually thinking about it, which is the only time it works.

  It is two-directional. They can reply "what are my options" and get a real answer, in the thread, at 9pm, without a queue.

  And it is consistent. Every customer gets the same well-constructed conversation rather than one that varies with who picked up the list and how their week was going.

  The tactical data on this is striking. At the point of cancellation, the right offer presented at the right moment gets accepted by a majority of customers, with one analysis citing 62% acceptance on discount offers made at the cancel moment. Recovering even a portion of customers you had written off is enormous, because the acquisition cost is already sunk.

  Where the guardrails go

  This is a conversation with commercial consequences, so the boundaries matter more than usual.

  Give it an approved set of offers and a floor. It can present. It cannot invent, and it cannot go below the line you set.

  Anything unusual goes to a person. A long-tenured customer, a large account, someone clearly upset rather than price-sensitive. Those are the conversations where a human genuinely outperforms.

  And never auto-renew silently as a retention strategy. It works precisely once and costs you the relationship and possibly a complaint.

  The part people underuse

  Silence.

  A customer who has not engaged as their date approaches is a different and worse risk than one who replied and is negotiating. Most businesses treat both identically because they have no mechanism to tell them apart.

  The trigger gives you that. It tells you where to spend limited human attention, which is usually worth more than the automated conversations themselves.

  The honest limit

  None of this saves a customer who is leaving because the product is not good enough. A better renewal conversation slows the bleeding and gives you cleaner information about why.

  If your churn is a product problem, this will surface it faster and more precisely. It will not solve it, and I would be wary of anyone suggesting otherwise.

  Frequently asked

  Should the agent be allowed to offer a discount?

  Within limits you set in advance, yes. Presenting an approved retention offer is fine and often the entire point. Inventing one, or negotiating beyond a defined floor, is not. Define the ceiling, define what needs a human, and make the agent hand over rather than improvise when it hits the edge.

  Is a renewal conversation not too important to automate?

  It is too important to leave to whoever has capacity that week, which is what most businesses currently do. The choice is rarely between an agent and a well-run human retention call. It is between an agent and a generic reminder email nobody replies to.

  What about customers who ignore the renewal message entirely?

  Silence is data. A customer who has not engaged as the date approaches is a different risk profile from one who replied, and should get a different follow-up, ideally involving a person. The value of the trigger is knowing who to spend human time on.

  Open as its own page

Compliance

• Can conversational AI work in a regulated industry?3 min

  Yes, and the constraint is scope rather than capability. Draw a hard line between explaining and advising, and a large automatable layer remains.

  Yes. The constraint is scope, not capability, and once you see where the line sits most regulated operations turn out to have a large automatable layer underneath it.

  This is not legal or compliance advice. It is how I would frame the problem before taking it to the people who give you that.

  The line that matters

  Explaining versus advising.

  Telling someone what their policy already covers, what their balance is, when their renewal falls, what documents a process needs, how long something usually takes: that is explanation. It is factual, it is in your systems, and it has one correct answer.

  Telling them which product suits them, whether they should claim, whether to switch, what is right for their circumstances: that is advice. In most regulated contexts that carries obligations around suitability, disclosure and record-keeping that an automated agent should not be discharging on your behalf.

  Draw that line explicitly, in writing, before anyone builds anything. Then the design question becomes simple: everything on the explanation side is in scope, everything on the advice side escalates.

  What sits below the line in practice

  More than people assume.

  In insurance: renewal dates and terms, what a policy covers, document requests, claim status, how the claims process works, updating contact details.

  In financial services: balances, transaction queries, how a product works, application status, what a fee is for.

  In utilities and telecoms: billing explanations, tariff mechanics, service status, appointment logistics.

  That is a large share of total contact volume in every one of those sectors, and almost none of it requires a regulated conversation. It requires accurate access to a system and a clear answer.

  The four things I would design in from the start

  Grounding. Never let it answer from a model's general knowledge. Ungrounded, models hallucinate in the 15 to 27% range. Retrieving from your verified content first drops that under 1.5%. In a regulated setting that is not a quality preference, it is the difference between defensible and not.

  Identity verification. An agent with read access can in principle read out anything on the record. What it demands before discussing an account, and what it refuses even after, should be explicit rules rather than emergent behaviour.

  Full audit trail. Every conversation retained and retrievable against the customer. Assume you will need to show exactly what was said.

  Vulnerability triggers. Explicit signals that route straight to a person, with context, no attempt to help first. This is the clearest case anywhere for escalating early.

  What I would keep away from it entirely

  Anything involving a decision on liability or a payout. Anything where the customer is in distress. Anything that would constitute a recommendation. Anything with a statutory response obligation where an automated acknowledgement might be read as the response.

  None of that is a technology limit. It is a judgment about where the risk lives, and the correct answer is usually the conservative one.

  The practical order of work

  Get the scope line agreed with your compliance function before the build, not at review. It is cheap to define upfront and expensive to retrofit.

  Start with the narrowest, most factual queue you have. Prove the grounding and the audit trail on something low-stakes.

  Then widen, slowly, with the compliance people watching the transcripts rather than reading a summary. What convinces them is not a demo. It is fifty real conversations where the agent stayed inside its lane.

  Frequently asked

  Where exactly is the line?

  Between explaining and advising. Telling a customer what their policy covers, what their balance is or what a process involves is explanation. Telling them which product to choose, whether to claim, or what is right for their circumstances is advice, and in most regulated contexts that carries requirements an automated agent should not be meeting on your behalf.

  Do we have to record what the AI said?

  Assume yes and design for it from the start. Full transcripts, retained on the same basis as your other customer communications, retrievable against a customer record. Retrofitting that after launch is painful and you will want it the first time somebody disputes what they were told.

  Can it handle vulnerable customers?

  It should detect and escalate rather than handle. Build explicit triggers for signals of vulnerability or distress and route those to a person immediately with full context. This is the clearest case in the whole category for escalating early rather than attempting to help.

  Open as its own page
• Is conversational AI GDPR compliant?2 min

  The technology is neither compliant nor not. Your deployment is. It turns on where data is processed, what is retained and what you can delete.

  The technology is neither compliant nor non-compliant. Your deployment is one or the other, and it comes down to decisions you make rather than to conversational AI as a category.

  This is not legal advice. It is the set of questions I would want answered before putting an agent in front of customers, and the ones a serious partner should answer without being chased.

  Where is the data processed

  The first question, and the one with the clearest practical consequence.

  UK or EU processing is materially simpler to reason about than US processing. Not impossible either way, but the paperwork and the internal argument are different, and it is worth knowing before you are three weeks from launch.

  Ask specifically where the model runs, where transcripts are stored, and whether either changes depending on load.

  What is retained, and by whom

  There are usually two separate answers here and people conflate them.

  What your agent platform stores, meaning transcripts, customer records, conversation history. And what the model provider stores, which is a different company with different terms.

  Enterprise tiers from the major providers offer zero-retention modes built for exactly this concern, where prompts are not stored and not used for training. Consumer tiers often do not. That distinction matters more than almost anything else in this list, and it is settled in a contract rather than in a settings panel.

  What the agent is allowed to say

  An agent with read access to your CRM can, in principle, read out anything in the record.

  So identity verification is not a nice touch, it is the control that stops someone getting another person's details by claiming to be them. What does the agent require before it discusses an account. What does it refuse to say even after verification. Is there a category of data it simply never touches.

  Those should be explicit rules, not emergent behaviour.

  Can you delete it

  If a customer exercises their right to erasure, you need to find every trace of that conversation and remove it.

  That means knowing where transcripts live, what the retention period is, and whether the model provider holds a copy. If nobody can answer that in a sentence, it has not been designed for.

  The practical read

  Most of this is settled in the contract and the architecture rather than in the conversation design, which is why it should be discussed early rather than at legal review.

  A partner who talks fluently about hosting, retention, verification flows and deletion without being prompted has done it before. One who gets vague precisely where the specifics live has not, and that hesitation is the most useful thing you will learn in the call.

  Get your own legal advice on your specific situation. What I would push back on is the idea that this is a blocker. It is a set of decisions, and they are all answerable.

  Frequently asked

  Does customer data get used to train the model?

  It depends entirely on the provider and the tier you are on. Enterprise tiers from the major model providers offer zero-retention modes precisely for this, where prompts are not stored or used for training. Consumer tiers frequently do not. This is a contract question, and it should be answered in writing before anything goes live.

  Do we need to tell customers they are talking to AI?

  Disclosure is good practice and increasingly expected, and there is a practical case for it beyond compliance: customers who work it out themselves feel handled. Whether it is strictly required in your situation is a question for your own legal advice, not for a vendor.

  What happens to a conversation if a customer requests erasure?

  You need to be able to find and delete it, which means knowing where transcripts live, how long they are kept and whether the model provider holds a copy. If a vendor cannot answer that quickly, they have not thought about it, and that is the useful signal.

  Open as its own page

Sales

• Can conversational AI qualify inbound leads?3 min

  Yes, and it is usually the fastest payback in the deployment. Leads contacted within five minutes qualify far better, and most firms take hours.

  Yes, and in most deployments it pays back faster than anything on the support side.

  The reason is timing rather than intelligence. Leads contacted within five minutes are dramatically more likely to qualify than leads contacted after thirty, and roughly 35 to 50% of sales go to whichever provider responds first.

  Meanwhile most businesses take hours. One synthesis found the top decile responding in around three minutes and the bottom quartile taking over 47 hours.

  That gap is the opportunity, and it has almost nothing to do with how clever the conversation is.

  What qualification actually means here

  Not a scoring model. A short, useful conversation that establishes whether this person is worth your sales team's time, while they are still interested.

  For a broadband provider that is a postcode and a coverage check. For an insurer it might be cover type and renewal date. For a B2B service, company size, timeline and whether they have a budget.

  The agent asks, checks what it can against real systems, answers their questions honestly, and passes a qualified lead across with everything captured.

  Where it earns most

  Out of hours. Same argument as support, sharper. A Sunday-evening enquiry answered immediately, versus one sitting until Tuesday, is often the difference between a customer and a competitor's customer.

  Volume spikes. Campaign launches, seasonal peaks, a piece of coverage. Your sales team has a fixed capacity and the enquiries do not arrive evenly.

  Filtering. A meaningful share of inbound is not qualified and never will be. Every one of those a rep works through is time not spent on someone who would have bought.

  The line I would draw

  Qualify and hand over. Do not close.

  An agent that confirms availability, explains current pricing and captures the details is doing genuinely useful work. An agent that negotiates, commits to a bespoke price, or agrees terms is creating a liability, because you will end up honouring whatever it said.

  We learned a version of this the hard way early on, with an agent quoting a price from a stale source. The architectural fix was to read live rather than from anything cached, and the policy fix was that the agent presents options and a person agrees deals.

  What good looks like on the CRM side

  This is where most lead-qualification bots fall down. They have a nice conversation and then dump a name and an email into an inbox.

  The version that works writes to your CRM. Lead created, source attributed, qualifying answers stored on the record, transcript attached, and the right rep notified on whatever channel they actually watch.

  Your rep opens a conversation that is already half done. That is the difference between a chat widget and a sales system, and it is entirely a question of integration depth rather than conversational quality.

  The honest caveat

  If your sales problem is that you have too few leads, this does not fix it. It converts more of what you already get, which is a different thing.

  And if your leads are genuinely complex, high-value and consultative from the first sentence, the agent should be booking the call rather than trying to qualify it. Knowing which of those you are is worth more than any amount of tuning.

  Frequently asked

  Should the AI try to close, or just qualify?

  Qualify, capture and hand over. An agent presenting options and checking eligibility is doing useful work. An agent negotiating terms or committing to a price is creating a problem, because you will end up honouring something it should not have offered.

  Will it put serious buyers off?

  Not if it is fast and useful and the route to a person stays obvious. What puts buyers off is a form that promises contact within one working day. Speed is the thing they are actually judging, and an instant substantive answer beats a slow human more often than sales teams like to admit.

  What does the sales team actually receive?

  A qualified lead with the qualifying answers already captured, the conversation attached, and ideally a record already created in the CRM. The point is that the rep opens a conversation that is already partly done rather than starting from a name and an email.

  Open as its own page

Cost

• What ROI should we expect from conversational AI?3 min

  Our flagship deployment returns roughly five to one monthly. That figure is real, and it is the wrong number to plan your own business with.

  Across a five month reporting window, our flagship deployment returned roughly five to one monthly. Thousands of conversations, over a thousand support tickets automated a month, and a meaningful new revenue line from business that would otherwise have been missed. Those were point in time figures from one operation rather than a live running total, and we go through the detail on a call.

  Those are real, banked figures from one operation. They are also the wrong number for you to plan with, and I would rather say that than let you build a business case on somebody else's context.

  Why one company's ROI does not transfer

  That return came from a specific mix: a subscriber business with heavy repetitive contact, a large out-of-hours gap, and systems the agent could actually read from.

  Change any of those and the number moves. A business with lower volume, or contact that genuinely needs judgment, or customer data spread across three systems with no shared key, will not see the same thing. Not because the technology differs, but because the inputs do.

  Anyone quoting you a sector-wide ROI multiple is guessing with confidence.

  How to work out your own

  Four corrections, and vendor figures usually skip at least two.

  Apply the benefit only to the work automated. If the agent handles 40% of contact, the saving applies to that 40%. Not to your total support cost. This single error is responsible for most of the inflated numbers in the category.

  Use gross margin, not revenue. An agent that drives fifty thousand in sales is not a fifty thousand benefit if your margin is thirty percent.

  Subtract the full running cost. Platform, model usage, ongoing tuning, integration maintenance. The tuning is the one people forget, and it is the one that keeps the thing working past month three.

  Do not double count. If a contact is a containment saving, it is not also sitting in your average-handle-time reduction pool.

  Do that and you get a figure you can defend to a finance director. Usually still good. Never as good as the slide.

  Where the return actually comes from

  Rarely where people expect.

  Out-of-hours conversion is often the loudest line, because the alternative is nobody answering. Leads that used to die overnight get engaged at the moment of intent.

  Volume absorbed at the boring end. Not the clever conversation, the same question asked four hundred times. In our deployment the biggest relief was the repetitive status chase, which we had not predicted.

  Capacity released, not headcount removed. Your team stops clearing identical queries and starts on retention and complex cases, which is work with a higher return attached. Harder to put on a spreadsheet, usually worth more.

  The number I would actually watch first

  Contacts per resolved issue.

  If something that used to generate four inbound touches now generates one, that is real and measurable within weeks, before any annual ROI calculation is meaningful. It is also very hard to fake, which is more than can be said for containment rate.

  The honest framing

  The economics of automating high-volume repetitive contact are genuinely favourable. That much is not in doubt.

  What is in doubt is any specific multiple, including ours. Build the case on your own contact mix, apply the corrections above, and if the number still works with all four applied, it will survive contact with reality.

  Frequently asked

  How do I calculate ROI honestly?

  Apply the benefit only to the contact the agent actually handled, never to total volume. Use gross margin rather than revenue for any sales uplift. Subtract the full running cost including platform, model usage, maintenance and integration. And do not count the same contact twice across two different savings categories.

  How long before it pays back?

  Expect the first measurable return within the first quarter of going live, and treat anything faster with suspicion, because it usually means someone counted deflection as resolution. The compounding return comes later, once the second and third workflows are built on a foundation you have already paid for.

  Why are published ROI figures so inconsistent?

  Because most apply the benefit to total volume rather than to the work automated, and few subtract running costs. The credible number is almost always smaller than the marketing one and still comfortably worth doing, which is a less exciting story than the slide.

  Open as its own page
• How much does conversational AI cost?2 min

  Anyone quoting a single figure is guessing. The useful benchmark is what an in-house AI engineer costs, because that is the real alternative.

  Nobody can give you a real number without seeing your systems, and anyone who does is guessing. What I can give you is the benchmark that actually helps.

  A capable in-house AI engineer in the UK runs around £90,000 a year fully loaded, so call it £8,000 to £10,000 a month. Most businesses that go the in-house route end up needing a second one, because an agent nobody maintains freezes in place and starts underperforming within months.

  That is the number to hold everything else against.

  The four routes, roughly priced

  Off-the-shelf platforms. Low setup, predictable monthly fee, usually with a per-resolution or per-message component that can move around more than you would like. Right call if you are already on that platform's stack and your needs are generic.

  Build it in-house. No vendor fee, full control, and the full engineering cost sits with you. Plus the ongoing operating burden, which is the part that gets underestimated.

  A specialist partner. Structured build fee plus a managed monthly retainer. The honest benchmark is that this tends to land at less than the cost of one to two in-house engineers, with the ongoing tuning included.

  Big consultancy. Six figures across a multi-phase programme. Correct answer if you are a FTSE 250 with formal procurement. Heavy for a mid-market operator who needs something working next quarter.

  What actually drives the number

  Not the model. Model cost is a rounding error next to the rest.

  It is how accessible your systems are. Connecting to a platform with a clean, documented API is quick. Connecting to a legacy billing system where one internal developer controls every endpoint and is busy until March is where the money and the timeline go.

  In our own builds, the slowest part has never been the AI. It has been waiting on access to a client-side system that one person owns. The conversational logic is usually ready in days.

  That is why the first question a serious partner asks is about your stack rather than about your use case.

  The number people forget

  Ongoing tuning. Prices change, policies change, real customers find corners no test anticipated. An agent built on a knowledge base that was accurate at launch and never touched again will be confidently wrong within a few months.

  If a quote does not include that, you are being quoted for a project rather than a service, and you should budget internal time to cover the gap.

  How to make a quote comparable

  Ask for three things in writing: what is in the setup fee, what is in the monthly fee, and what triggers the monthly fee going up. More agents, more channels, more volume, all reasonable, all worth knowing before you sign.

  Then ask what leaving costs. A partner who answers that without flinching is relying on results rather than lock-in.

  If a vendor cannot answer those crisply, the pricing is not going to get clearer after you have signed.

  Frequently asked

  Why will nobody publish a price list?

  Because the number depends almost entirely on how accessible your systems are, and that is invisible until someone looks. Connecting to a modern platform with a clean API is fast. Connecting to a legacy billing system that one person owns is where timelines and budgets move. A published price would be a guess dressed up as a quote.

  What ongoing costs should I expect after the build?

  Hosting, model usage, and the tuning that keeps the agent accurate as your prices and policies change. That last one is the cost people forget, and it is why agents that were excellent at launch are confidently wrong six months later.

  Is it cheaper than hiring?

  Usually, but that is the wrong comparison on its own. A hire gives you judgment and can handle the complex conversations an agent should escalate. The fair comparison is against hiring for the repetitive contact specifically, which is where the economics are clearly favourable.

  Open as its own page
• Is conversational AI worth it for a small business?2 min

  Below a certain volume, honestly no. The threshold is not revenue or headcount, it is how many repetitive conversations arrive out of hours.

  Below a certain volume, no. And I would rather say that than sell you something that sits idle.

  The threshold is not revenue and it is not headcount. It is how many repetitive conversations you handle, and how many of them arrive when nobody is working.

  The test

  Can you name a question your team answers several times a day, where the answer is the same every time and lives in a system you already have?

  If you cannot, the case is weak. Buy nothing, revisit in a year.

  If you can name three, you are already paying for it. Just in salary and attention rather than in software.

  Where the maths usually turns

  Two places, in my experience, and neither is the one people expect.

  Out of hours. This is the strongest case for a small business, because the alternative is genuinely nothing. Not a slower human, nobody. The enquiry sits until morning, and a meaningful share of the people who sent it have moved on by then. Sub-one-hour response is associated with substantially better retention than a next-day reply, and a small team simply cannot cover evenings and weekends without it costing more than it returns.

  The same question forty times a week. Order status, opening hours, whether you cover a postcode, how to reset something. Individually trivial. Collectively they are somebody's whole morning.

  Where it does not turn

  If your enquiries are genuinely varied, high-value and low-volume, you are better off with a person. Twenty bespoke conversations a week that each need judgment is not an automation problem.

  If your customer data lives in spreadsheets and inboxes with no shared identifier, fix that first. An agent with nothing to look up is a chatbot, and you already know how those went.

  And if you are hoping it will replace a hire you cannot afford, be careful. It will absorb the repetitive contact, not the judgment.

  The honest recommendation for most small businesses

  Start with what your existing tools already offer. If you are on a helpdesk or CRM with AI features included, switch theirs on and see what it takes off your plate. That costs you an afternoon.

  Come back for a bespoke build when you hit the specific wall that off-the-shelf hits: when the generic answer would be wrong, because your pricing or your process or your eligibility rules are particular, and a wrong answer costs you more than no answer.

  That is the point where paying for integration starts to make sense, and not really before.

  Frequently asked

  What volume do I need before this makes sense?

  There is no universal number, but the useful test is whether you can name a question your team answers several times a day that has the same answer every time. If you cannot, the case is weak. If you can name three, it is probably already costing you more than you think.

  Is an off-the-shelf tool enough for a small business?

  Often, yes. If your needs are generic and you are already on a platform that offers AI features, turning theirs on is usually the right first move. A bespoke build earns its cost when your process or your systems are specific enough that generic answers would be wrong.

  What is the cheapest useful version of this?

  Cover the out-of-hours gap on one channel for one question type. It is the narrowest scope that still produces a measurable result, because the alternative to an agent answering at 9pm is nobody answering until the morning.

  Open as its own page

Channels

• Can conversational AI work on WhatsApp?2 min

  Yes, through the WhatsApp Business Platform, often with the highest response rates. The constraint is not technical, it is Meta's messaging rules.

  Yes, through the WhatsApp Business Platform, and for a lot of operations it becomes the strongest channel fairly quickly.

  The reason is not the technology. It is that people actually read WhatsApp, and they will reply to it days later without losing the thread.

  What makes it different from web chat

  Web chat is synchronous. Someone is on your site, wants an answer now, and the conversation dies when they close the tab.

  WhatsApp is asynchronous and persistent. The thread survives. A customer can ask about an install date on Tuesday, ignore you until Thursday, and pick up exactly where they left off with all the context intact.

  That suits a whole category of conversation that web chat handles badly. Install updates, delivery windows, renewal decisions, anything where the customer needs to go and think or go and check something.

  The constraint that shapes everything

  Meta controls who can message first, and it is the rule that dictates how you design outbound flows.

  You cannot simply start a conversation. Business-initiated messages have to use a pre-approved template, and you need consent. Once the customer replies, a 24-hour window opens where the conversation can be free-form and natural. When that window closes, you are back to templates until they message again.

  So an outbound flow that assumes you can just chat whenever will not survive contact with the platform. Design for the window: the template opens the door, the real conversation happens inside 24 hours, and anything after that needs another approved template.

  That constraint is also why WhatsApp works so well for triggered moments. A renewal notice, a failed payment, an install update. Something has genuinely happened, the template is legitimate, and the customer replies because it is relevant.

  One agent, several channels

  The mistake is building a WhatsApp bot separately from your web chat bot.

  You end up with two sets of logic, two knowledge bases drifting apart, and customers getting different answers depending on where they asked. The same underlying agent should serve web chat, WhatsApp, SMS, email and voice, with the channel affecting presentation rather than substance.

  The practical test: can a customer start on your website and follow up on WhatsApp without repeating themselves. If not, you have built two things.

  What to know before starting

  You need a WhatsApp Business Platform account through Meta or a provider, a verified business, and a number that is not already tied to a personal WhatsApp account. That last one catches people out.

  Template approval takes time and templates get rejected for being too promotional, so build that into the schedule rather than discovering it the week before launch.

  And consent needs to be real and recorded. This is a channel where getting it wrong is both a compliance problem and a fast route to being blocked by customers, which does more lasting damage than the compliance issue.

  Frequently asked

  Can we message customers first on WhatsApp?

  Only with an approved template message, and only where you have consent. Once the customer replies you get a 24-hour window in which the conversation can be free-form. Outside that window you are back to templates. This shapes the design of any outbound flow more than anything technical does.

  Do we need a separate agent for WhatsApp?

  No, and you should not want one. The same underlying agent should serve web chat, WhatsApp, SMS and email, so a customer who starts in one place and follows up in another is not explaining themselves twice. Separate agents per channel is how you end up with inconsistent answers.

  Is WhatsApp better than web chat for support?

  For anything asynchronous, usually yes. A customer can leave and come back hours later with the thread intact, which suits install updates, delivery questions and renewals. Web chat suits someone already on your site who wants an answer now. Most operations want both.

  Open as its own page

Trust

• Can customers tell they are talking to AI?2 min

  Often yes, and increasingly they mind. Trust in AI-led service fell ten points in eight months. The deployments that survive stop trying to hide it.

  Often, yes. And the number who mind is rising.

  The share of people who say AI-led service costs a business their trust went from 47% to 57% in eight months. That is a fast move on a question this fundamental, and it should change how you think about deployment rather than whether to deploy.

  What people are actually objecting to

  Not the software. Being stuck.

  Nobody minds a machine that resolves their problem in twenty seconds at 11pm. What people object to is the experience they have been trained to expect: a bot that cannot help, will not let them past, and asks them to rephrase.

  That is a decade of decision trees teaching customers a reflex, and any new deployment inherits it whether it deserves to or not.

  The tells

  In a badly built agent, people spot it within two exchanges. Repetition, a suspiciously uniform tone, an inability to handle anything specific about their account.

  In a well built one, the tell is usually not the language at all. Modern models write fine. It is the moment the conversation needs something real, a live balance or an actual install date, and nothing comes back.

  Which is another way of saying: the thing that makes an agent convincing is the same thing that makes it useful. Integration, not phrasing.

  Why hiding it is the wrong instinct

  The temptation is a human name and no disclosure. It works right up until it does not, and the moment a customer works it out, the deception becomes the story rather than the service.

  Being told upfront costs you almost nothing. Being caught costs you the interaction and some of the relationship.

  Our own position is that the agent says what it is and the route to a person stays visible. That is partly principle and partly self-interest, because the alternative fails badly at exactly the moment a customer is already annoyed.

  What the satisfaction data says

  More encouraging than the trust numbers suggest. Industry-average CSAT for AI support agents sits around 78%, with leaders above 85%, roughly level with live chat. One large analysis put pure-AI handling at 4.1 out of 5 against 4.3 for human agents, and hybrid flows with a clean handover narrowed that to almost nothing.

  So the ceiling is high. The variance is what should worry you, and it tracks integration depth rather than model quality.

  The practical read

  Assume they can tell. Design as if they can.

  That means disclosing it, keeping the human route obvious, grounding every answer in real data so the agent can actually help, and escalating early enough that nobody feels trapped.

  Do that and the fact it is AI stops being the point. Fail on the last one and no amount of conversational polish saves it.

  Frequently asked

  Should I disclose that the agent is AI?

  Yes. Customers who work it out on their own feel handled, and that is a worse outcome than being told upfront. Disclosure also costs you very little, because what people actually object to is being stuck, not being served by software.

  Does giving the agent a human name help?

  It tends to backfire once the customer works it out, because the name reads as an attempt to deceive rather than a friendly touch. A branded assistant name is fine. A fake colleague is a risk you do not need to take.

  Does AI service actually satisfy customers?

  In well-built deployments, roughly. Industry-average CSAT for AI support sits around 78%, with leaders above 85%, which is close to live chat. The gap narrows further when escalation is clean. Poor deployments score far worse, and the variance is mostly integration depth.

  Open as its own page

Operations

• Do we need a 24/7 support team?3 min

  Probably not a team. You almost certainly need the coverage. The alternative to answering at 9pm is usually nobody answering until tomorrow.

  Probably not a team. Almost certainly the coverage.

  Those are different things, and conflating them is why this question usually gets answered with either an expensive night shift or nothing at all.

  Check before you decide

  Most operators guess at their out-of-hours volume. You do not have to.

  Pull last month's inbound across every channel and count what arrived outside your staffed hours. In consumer-facing businesses it is routinely a third or more, concentrated in evenings and Sunday afternoons.

  That is not a small tail. It is a meaningful proportion of your customer contact, and right now it hits a closed door.

  Why it costs more than it looks

  The response-time data is unambiguous, and it is worse than most people expect.

  Around 89% of customers expect a response within an hour. One analysis found sub-one-hour response achieved 71% retention against 48% for a 24-hour response, which is a 23-point gap created by speed alone. Satisfaction tracks the same curve, from roughly 92% at sub-five-minute response down to about 51% at a day.

  Now apply that to an enquiry arriving at 9pm on a Sunday. By the time anyone reads it on Monday morning, you are already at the wrong end of every one of those curves.

  On the acquisition side it is starker still. Leads contacted within five minutes are far more likely to qualify than leads contacted after thirty, and roughly 35 to 50% of sales go to whoever responds first. The Sunday-evening prospect comparing three providers has signed with one of them by Tuesday.

  The thing people miss

  The alternative to an agent handling the 9pm question is not a slower human.

  It is nobody, until tomorrow.

  That is what makes out-of-hours the strongest single case for automation in most operations. During working hours an agent competes with your team and has to be better than them at something. Outside them it competes with silence.

  Where a night shift is still right

  Where the contact genuinely needs judgment.

  Emergency faults with a safety dimension. Anything involving vulnerability or a duty of care. Regulated situations with a response obligation. Sectors where an out-of-hours call is by definition serious rather than routine.

  The mistake is staffing overnight to answer questions with a single correct answer. That is an expensive way to do something a system does better, and the people doing it get bored and leave.

  What good coverage actually looks like

  Answer what can be answered, properly, with real data rather than a holding line.

  Be straight about what cannot wait and what can. "This needs someone from the faults team and they start at eight, I have logged everything and they will have it first thing" is a genuine service. An auto-reply promising contact within one working day is not, and customers read it as a queue.

  And make sure the morning team inherits something useful. The value of overnight coverage is not only the customers you resolved. It is that your team starts the day with context instead of a wall of unread messages.

  Frequently asked

  How much of our contact actually arrives out of hours?

  More than most operators assume, and you can check rather than guess. Pull the timestamps on last month's inbound across every channel and count what landed outside your staffed hours. In consumer-facing businesses it is routinely a third or more, weighted heavily to evenings and Sunday.

  Is a night shift ever the right answer?

  Where the out-of-hours contact genuinely needs judgment, yes. Emergency faults, safeguarding, anything with a duty of care. The mistake is staffing a night shift to answer questions that have the same answer every time, which is an expensive way to do something a system does better.

  Does an out-of-hours agent need to resolve, or just acknowledge?

  Resolve where it can, and be honest where it cannot. An acknowledgement with a real answer attached is worth far more than an auto-reply promising contact within one working day, which most customers read as a queue rather than a response.

  Open as its own page

Measurement

• How do I know if my AI agent is working?2 min

  Containment rate on its own tells you nothing. Read it alongside satisfaction and recontact, or you cannot tell resolution from customers giving up.

  Containment rate on its own tells you almost nothing, and it is the number most vendors lead with.

  Containment measures that a conversation was not escalated to a human. It does not measure whether the customer got what they needed. Someone who gives up in frustration and closes the window counts as contained, and so does someone whose problem was solved perfectly. The number cannot tell them apart.

  The three you need together

  Containment. Did the agent handle it without a human.

  Satisfaction. Did the customer feel served. If containment rises while CSAT falls, you are not automating, you are deflecting, and the trend line is telling you so.

  Recontact rate. Did they come back with the same issue within a day or three. This is the clearest evidence that a contained conversation was not actually resolved, whatever the first number said.

  Read as a set they are meaningful. Read alone, containment is a vanity metric and everyone in the industry knows it.

  Benchmarks worth holding against

  Most chatbots contain 20 to 40%. Mature well-integrated agents reach 70 to 90%. Industry-average CSAT for AI support sits around 78%, with leaders above 85%, roughly level with live chat.

  Median tier-one deflection lands nearer 41% than the numbers on vendor slides, with the top quartile around 59%.

  And aggregate figures mislead badly, because simple intents like password resets deflect above 70% while nuanced complaints rarely break 25%. A headline rate without the query mix underneath is close to meaningless.

  What I would actually watch in the first month

  Not the dashboard. The transcripts.

  Read fifty conversations a week, properly. You will find the failures before any aggregate does, and they will be specific and fixable: a question phrased in a way the agent did not expect, a policy it does not know about, a hedge at the end of a correct answer that is pushing people to ask for a human.

  We had exactly that one. Resolution sat flat for weeks while transcripts looked fine, because the agent was adding "please confirm with our team" to answers that were already right.

  You do not find that in a chart.

  The commercial number

  Eventually you want this in money, and the honest version is smaller than the marketing version.

  Apply the benefit only to the contact the AI actually handled, not to total volume. Use gross margin rather than revenue for any sales uplift. Subtract the running costs, meaning platform, model usage, maintenance and integration work. Do not count the same contact twice across two different savings categories.

  What you get is a figure you can defend to a CFO. Usually still good. Never as good as the slide.

  Frequently asked

  What is a good containment rate?

  Most chatbots contain 20 to 40% of conversations and mature well-integrated implementations reach 70 to 90%. But containment alone only tells you the customer did not escalate, not that their problem was solved, so a number without CSAT and recontact beside it is unreadable.

  What is the difference between containment and resolution?

  Containment means the conversation was not passed to a human. Resolution means the customer's problem was actually fixed. A customer who gives up and closes the window counts as contained. Conflating the two is the most common measurement error in the category.

  How soon should I expect the numbers to look good?

  Not immediately, and be suspicious of a deployment that looks perfect in week one. Expect a few weeks of tuning after go-live where you are watching transcripts rather than dashboards, because the early wins and the early failures are both visible in the conversations well before they show up in aggregate.

  Open as its own page

Foundations

• What industries is conversational AI best suited to?2 min

  Any business with high conversation volume, recurring relationships and repeat questions. Telecoms, insurance, utilities, property, healthcare.

  Sector matters less than shape.

  The businesses this works for share three traits: a lot of inbound conversation, a relationship that recurs rather than ending at the sale, and a meaningful slice of questions where the answer is the same every time and already lives in a system.

  If that describes you, your industry is close to irrelevant.

  Where it fits naturally

  Telecoms and broadband. High volume, spiky during onboarding, and a subscriber economics model where every avoidable churn strands an acquisition cost you have not recovered. This is our flagship deployment, so it is the one I can speak to in most detail.

  Insurance. Renewals, policy questions, document requests, and the first stage of a claim. The volume is enormous and highly repetitive, and the renewal window in particular is a moment where a fast answer changes the outcome.

  Utilities and energy. Meter readings, billing explanations, tariff questions, move-in and move-out. Almost entirely questions with a single correct answer sitting in a billing system.

  Property and lettings. Maintenance reporting, tenancy questions, viewing arrangements. Small teams, relentless inbound, most of it procedural.

  Healthcare administration. Appointments, prep instructions, referral status. The admin layer, explicitly not the clinical one.

  Subscription and SaaS. Billing, plan changes, renewals, onboarding. The classic case.

  The common thread

  Look at that list and the pattern is obvious. Every one of them has a customer who stays for years, contacts you regularly about a small number of predictable things, and forms a judgment about you based on how easy that was.

  British Chambers of Commerce data puts 54% of UK businesses using AI in some form but only around 11% using it to run any operations. Most of the rest are writing faster emails. The operational layer, the tickets and the qualifying and the renewals, is harder to build and it is where the return is.

  Where it is a poor fit

  Low volume, high value, genuinely bespoke.

  If your team handles twenty enquiries a week and each one needs a specialist to reason about something particular, you do not have an automation problem. You have a hiring question, and an agent would sit idle while adding a layer between your customers and the person they actually need.

  Same for anything where the first conversation is the sale and there is no ongoing relationship. The economics rely on volume and repetition, and one-off transactional businesses have neither.

  The test that beats any sector list

  Forget your industry for a second and ask this instead.

  Can you name a question your team answers several times a day, where the answer is identical every time and already exists in a system you own?

  If you can name three, this works for you regardless of what you sell. If you cannot name one, it does not, regardless of how well your sector appears on somebody's use-case page.

  Frequently asked

  Does industry matter more than company size?

  Less than people expect. The shape of your contact matters more than your sector or your headcount. A small business fielding four hundred identical questions a week is a better fit than a large one handling forty bespoke conversations that each need judgment.

  Is conversational AI useful in insurance?

  Yes, and the strongest cases are renewals, policy questions and the early triage of a claim rather than claims decisions themselves. Anything involving an assessment of liability or a payout decision should stay with a person, both for regulatory reasons and because those conversations carry real emotional weight.

  What kind of business is it a poor fit for?

  Low-volume, high-value, highly bespoke work. If every enquiry is genuinely different and needs a specialist to reason about it, you are looking at an automation problem that does not exist. Consultancies, bespoke manufacturers and specialist advisers usually fall here.

  Open as its own page
• What is the difference between a chatbot and an AI agent?3 min

  A chatbot follows a script. An AI agent reads intent, pulls live data from your systems and takes action. The difference shows up in resolution rate.

  A chatbot answers questions. An AI agent resolves them. That sounds like marketing, so here is the concrete version.

  A chatbot works from paths somebody drew in advance. Press 1 for billing, press 2 for faults. Every branch is hand built, and the moment a customer phrases something the script did not anticipate, it apologises and offers to find a human. Published benchmarks put most of these at 20 to 40% of conversations handled without escalation.

  An AI agent works the other way round. It reads what the customer actually said, in their own words, decides what that means, pulls the relevant record from your systems, and does something with it. Raises the ticket. Checks the line. Books the engineer. Sends the invoice.

  The test that separates them

  Ask what happens when a customer says something nobody planned for.

  A chatbot falls off the tree. There is no path, so there is no answer, and it hands over. An agent has no tree to fall off, so it reasons from what it knows and either answers or escalates deliberately.

  That is the whole distinction. Everything else follows from it.

  Where the difference actually shows up

  Not in conversation quality. Modern chatbots can be perfectly polite. The difference lands in three places.

  Can it act, or only talk. A chatbot can tell a customer how to check their balance. An agent checks it for them. That requires an integration layer wired into your CRM, billing and helpdesk, which is the part nobody puts on a slide and where most of the build time goes.

  Resolution rate. Well integrated agent deployments reach 70 to 90% of conversations handled end to end. The gap between that and the 20 to 40% band is almost entirely integration depth, not model choice.

  What it does when unsure. A chatbot escalates because it ran out of script. A good agent escalates because it has a confidence threshold and dropped below it, and hands over with the customer already verified and the issue captured.

  Where the line gets blurred

  Plenty of products marketed as AI agents are chatbots with a language model bolted on the front. They understand the question fine and then have nothing to do about it, because there is no integration underneath.

  The way to tell is to ask a vendor to show you a live one and describe what happens after it understands. If the answer is about conversation quality rather than about systems it writes to, you are looking at a chatbot in a better coat.

  Why this matters commercially

  Customers learned to distrust the first category. Most people type "agent" the moment a chat window opens, because a decade of decision trees taught them that the bot is an obstacle between them and a person.

  That trained reflex is the real cost of the chatbot era, and it is why a badly built agent is worse than none at all. It confirms what the customer already suspected.

  Across our own deployments the pattern has been consistent: the volume that disappears first is not the clever conversation, it is the boring high-frequency question that was quietly eating the team alive. Where is my order. When is the engineer coming. Why is this bill different.

  None of that needs a tree. All of it needs live data.

  Frequently asked

  Is an AI agent just a better chatbot?

  No. A chatbot picks a reply from paths someone wrote in advance. An AI agent works out what the customer wants, fetches the relevant data from your systems, and takes an action such as raising a ticket or checking an account. The chatbot answers. The agent resolves.

  Do I need to replace my existing chatbot to get an AI agent?

  Usually yes, because the limitation is architectural rather than a matter of configuration. A decision-tree bot has no integration layer to fetch live data and no way to reason about an unanticipated question. You can keep the same channels and the same widget position, but the thing behind it gets rebuilt.

  What resolution rate should I expect from each?

  Published benchmarks put most decision-tree chatbots at roughly 20 to 40% of conversations handled without a human, while well-integrated agent deployments reach 70 to 90%. The spread is driven by integration depth rather than by which model is used.

  Open as its own page
• What is conversational AI?2 min

  Software that holds a real conversation on a channel your customer already uses, and does something about it. That last part separates it from a chatbot.

  Conversational AI is software that holds a real conversation with a customer on a channel they already use, works out what they actually want, and does something about it.

  That last clause is doing most of the work. Plenty of things hold a conversation. Very few do anything at the end of it.

  What it does, step by step

  Five things, in order, fast enough that the customer perceives a person.

  It reads the inbound message, whatever channel it arrived on, and works out the intent. Not keyword matching, actual intent, including when the customer is vague or annoyed or has buried the real question in paragraph three.

  It pulls the context. Their account, their plan, their billing history, the last few conversations they had with you, the relevant policy. From your live systems, not a static FAQ page written eighteen months ago.

  It decides what to do. Sometimes answer directly. Sometimes ask one clarifying question. Sometimes hand to a human with everything already gathered.

  It acts. Replies on the same channel, logs the interaction, raises the ticket, books the engineer, sends the invoice.

  And it learns, in the sense that failures get captured and fed into the next round of tuning rather than repeating quietly forever.

  What it is not

  It is not the thing you had in 2021.

  A decision-tree chatbot follows paths a person drew in advance and falls over the moment somebody phrases things unexpectedly. Those resolve roughly 20 to 40% of what reaches them, which is why so many got switched off within a quarter and why customers now type "agent" reflexively.

  The distinction is not a matter of degree. Different architecture, different failure modes, different outcome.

  Where the value actually sits

  Not in the clever conversation. In the boring high-frequency one.

  Where is my order. When is the engineer coming. Why is this bill different this month. Can I change my plan. Those questions are enormous in volume, identical in shape, and eat a support team alive.

  British Chambers of Commerce data puts 54% of UK businesses using AI in some form, but only around 11% using it to run any operations. Most of the rest are writing quicker emails, which is fine as far as it goes. The return is in the operational layer, and that is harder to build, which is exactly why fewer people have done it.

  The honest limitation

  It is poor at the conversations that need a person. Bereavement, hardship, a genuine complaint, a negotiation, anything unprecedented.

  A good deployment knows that and escalates cleanly. A bad one tries to handle everything and confirms every suspicion the customer already had about talking to a machine.

  Frequently asked

  Is conversational AI the same as a chatbot?

  No. A chatbot follows a decision tree somebody drew in advance and breaks on anything unanticipated. Conversational AI understands natural language, reasons about what the customer needs, and can take actions in connected systems. The practical difference shows up in how many enquiries actually get resolved.

  What channels does conversational AI work on?

  Web chat, WhatsApp, SMS, email and voice are the common ones. The same underlying agent can serve all of them, which matters because a customer who starts on web chat and follows up on WhatsApp should not have to explain themselves twice.

  Does conversational AI need to connect to my systems?

  To be useful, yes. Without integration it can talk about your business but cannot look anything up or do anything. That distinction is the single biggest predictor of whether a deployment performs, ahead of which model sits underneath.

  Open as its own page

Build vs buy

• Is ChatGPT good enough for customer service?2 min

  The model is not the limitation. ChatGPT cannot see your customer's account and cannot act in your systems. That gap is the entire job.

  The model is not the limitation. That is the thing worth getting straight first.

  Modern language models write better replies than most support teams manage on a Friday afternoon. Tone, clarity, patience, all fine.

  What ChatGPT cannot do is tell your customer anything about your customer.

  The three gaps

  It does not know who it is talking to. No account, no plan, no history, no open tickets. Every conversation starts from nothing, which means it can discuss your returns policy in general terms and cannot tell someone whether their return was processed.

  It cannot do anything. It can explain how to book an engineer. It cannot book one. Nothing it says results in a row changing anywhere in your business, so every conversation ends with the customer still needing to contact you.

  It is not grounded in your content. Answering from general knowledge, a model hallucinates somewhere in the 15 to 27% range. Retrieving from a verified knowledge base first drops that under 1.5%. In front of customers, that difference is the whole ballgame.

  Why the distinction gets blurred

  Because the demo is genuinely impressive, and the gap only shows up on real questions.

  Ask a raw model something generic about broadband and it will answer well. Ask it why this month's bill is fourteen pounds higher and it has no path to an answer, so it either hedges or invents. Customers reach the second category within about two exchanges.

  What you would end up building anyway

  If you started from the API and worked toward something usable, you would build a retrieval layer over your knowledge base, an integration layer into CRM and billing, escalation logic with a confidence threshold, and a tuning process to keep it accurate as your business changes.

  At which point you have built a conversational AI agent, and the model is the smallest component in it. That is not an argument against doing it. It is an argument for knowing what the work actually is before you scope it as "we'll just use ChatGPT".

  Where it genuinely is good enough

  Internally, right now, today.

  Drafting replies for a human to check. Summarising a long thread. Turning a rough note into something sendable. That is real productivity and it needs no integration at all.

  ONS data has 35% of UK businesses reporting they use AI while 55% of employees say they use it for work, which suggests a lot of this is already happening in your business whether it is sanctioned or not.

  The line I would draw is this. Assisting your team, yes. Facing your customers unsupervised with no access to their data, no.

  Frequently asked

  Can I just put ChatGPT on my website?

  You can, and it will answer general questions fluently while being unable to tell a customer anything about their own account. It also has no grounding in your policies unless you provide them, and an ungrounded model hallucinates in the 15 to 27% range, which is not a risk worth taking in front of customers.

  What about the OpenAI API rather than the consumer product?

  That is closer to the right idea, because the API is a component you build around. It is not a customer service system on its own. What you would then build is the retrieval layer, the integration layer, the escalation logic and the operating discipline, which is the actual work.

  Is a purpose-built agent using a different model?

  Usually the same class of model, sometimes literally the same one. The difference is everything wrapped around it. Model choice is close to a rounding error next to whether the thing is grounded in your knowledge and wired into your systems.

  Open as its own page
• Should I build conversational AI in-house or use a partner?3 min

  It turns on one question, and it is not cost. Is running an AI agent going to be a permanent internal capability for you, or something you want handled?

  This turns on one question, and it is not cost.

  Is running a conversational AI agent going to be a permanent internal capability for you, or is it something you want handled? Answer that honestly and the route picks itself.

  Why cost is the wrong first question

  Because the build is the cheap part and the visible part, and neither of those makes it the important part.

  A capable in-house AI engineer in the UK runs around £90,000 fully loaded. Most teams that go this way end up needing a second, because an agent nobody maintains freezes in place. So the real comparison is not one-off build cost against a retainer, it is a permanent two-person function against a managed service.

  People compare the wrong two numbers constantly and then wonder why the maths stopped working in month eight.

  The risk nobody prices in

  Key-person risk, and it is severe.

  A production agent is four layers. The conversation, the knowledge, the integrations, the handover. All four need ongoing attention. Knowledge goes stale as prices and policies change. Integrations drift as the systems around them get updated. Edge cases surface that no test anticipated.

  The moment the person who built it leaves, or gets pulled onto the thing the CEO cares about this quarter, all four start decaying quietly. A large share of internal AI builds reach roughly 60% complete and freeze there, and what is left is a liability nobody wants to inherit.

  That is not a hypothetical failure mode. It is the most common one.

  When in-house is genuinely right

  Three conditions, and you want all three, not two.

  Conversational AI will be a standing competency rather than a project. You can hire and retain that talent against everyone else currently trying to. And your integration surface is specific enough that an outside party could not reasonably learn it.

  Businesses with an existing engineering team, unusual internal systems and a long-term view do meet all three. If that is you, build it, and budget for the operating rather than the launch.

  When a partner is right

  When you want the outcome without standing up a function to produce it.

  The trade is dependency, so the thing that matters is choosing one who stays embedded rather than one who hands over a build and leaves. Ask what happens after launch. If the answer trails off after go-live, you are buying a project with a service label on it, and you will own the decay.

  I run one of these, so treat that as disclosure rather than neutral advice. The logic holds regardless of who you pick.

  The middle option people forget

  Buy a platform and run it yourself.

  You get a toolkit and the obligation to wield it. Fine if you have the team, which puts you back in the in-house column with a shorter build. For a great many operators the platform ends up half-configured, which is the worst of both.

  Worth being honest with yourself about which of those you are before the licence renews.

  Frequently asked

  Is building in-house cheaper?

  Rarely, once you count the operating cost rather than just the build. A capable in-house AI engineer in the UK runs around £90,000 a year fully loaded, and most teams need a second to keep the thing maintained. The build is the visible cost and the smaller one.

  What is the real risk of building it ourselves?

  Key-person risk. The four layers of an agent all need ongoing attention, and the moment your specialist leaves or gets pulled onto something else, the knowledge base goes stale and the integrations start breaking against system updates. A large share of internal AI builds reach roughly 60% complete and freeze there.

  When does building in-house genuinely make sense?

  When conversational AI is going to be a permanent competency rather than a project, when you can hire and retain the talent, and when your integration needs are specific enough that no outside party could reasonably learn them. Some businesses meet all three. Most do not.

  Open as its own page

Objections

• Will AI replace my customer service team?2 min

  Almost certainly not, and those trying hardest are damaging the thing they need most. What changes is which work reaches your people.

  Almost certainly not. And the businesses pushing hardest for it tend to damage the exact thing they were trying to protect.

  Here is the honest version. A well built agent will take a large share of your inbound contact, and in the deployments we run that share sits somewhere around half. What it takes is the repetitive end: order status, password resets, the same billing question over and over, first line troubleshooting, anything arriving at 11pm.

  What it does not take is the conversation where somebody is angry, or bereaved, or negotiating, or describing a fault nobody has seen before.

  The reallocation, not the reduction

  The teams getting real value from this are not the ones counting roles removed. They are the ones who noticed their best people were spending the morning on password resets.

  Move that volume and the same headcount is suddenly available for retention calls, complex faults and complaints, which is work that was previously getting whatever attention was left over at 4pm on a Friday.

  That is a better use of a person, and it shows up in numbers that matter more than support cost.

  Why the cutting approach backfires

  Retention depends on the conversations AI is worst at. If you thin the team to the point where nobody has capacity for a genuine complaint, you have automated the cheap contact and degraded the expensive one.

  There is a trust cost too, and it is moving in the wrong direction. The share of people who say AI-led service costs a business their trust went from 47% to 57% in eight months. That is not a reason to avoid automation. It is a reason to be deliberate about which contact you automate and how obviously the human route stays open.

  What actually changes for the team

  Three things, in our experience.

  The work gets harder. Everything easy is gone, so what reaches a person needs judgment. That is a real change and worth acknowledging rather than selling as pure upside.

  The volume gets less brutal. Nobody is clearing a queue of two hundred identical install questions.

  And the job starts needing a different skill, because the person picking up a handover is stepping into a conversation already in progress with context attached, not starting from scratch.

  The honest caveat

  If your customer operation is overstaffed for reasons unrelated to AI, this will make that visible. That is not the AI making a decision, but it would be dishonest to pretend the information does not surface.

  What I would push back on is treating that as the goal. We do not sell headcount reduction and we do not measure a deployment by roles eliminated, because the businesses that use AI to gut a support team usually find out within two quarters that they cut the wrong thing.

  Frequently asked

  Has anyone actually cut headcount with conversational AI?

  Some have, and a number have quietly reversed it. The pattern we see is reallocation rather than reduction: the agent absorbs the repetitive contact and the same people move onto retention, complex faults and complaints. Those conversations were previously getting the leftovers of everyone's attention.

  What happens to my team's job if the AI handles half the tickets?

  The half it handles is the half nobody enjoyed. Password resets, order status, the same billing question forty times a week. What is left is harder and more valuable, which usually means the role gets more skilled rather than disappearing.

  Should I tell my team we are deploying AI?

  Yes, early, and be specific about which queues it takes. Teams work out what is happening the moment a tool appears in their workflow, and a vague rollout reads as the start of redundancies. The deployments that go badly are usually the ones where nobody explained the intent.

  Open as its own page

Integration

• Can conversational AI integrate with my CRM?2 min

  If it has an API, a webhook, a database or even a scheduled CSV, then yes. The harder question is how fast someone will grant you access.

  If your CRM has an API, a webhook, a database connection or even a scheduled CSV drop, then yes. That covers essentially every CRM in commercial use.

  So the interesting question is not can it. It is how fast, and that has almost nothing to do with the AI.

  The bit that actually determines the timeline

  Access.

  Connecting to a modern platform with clean documented endpoints is quick. Connecting to a legacy billing system where one internal developer owns every endpoint, and that developer is busy until March, is where projects stall.

  In our own builds the slowest part has never been the AI. It has been waiting on credentials for a client-side system that one person controls. The conversational logic is usually ready in days. The integration sets the go-live date.

  We now scope that dependency first and build everything else in parallel around it, because discovering it in week four is expensive and discovering it in week one is just a plan.

  Read access versus write access

  Worth separating, because they carry different risk and different value.

  Read lets the agent answer properly. Their actual plan, their actual balance, their actual install date. This is the difference between an agent that helps and one that recites your FAQ page back at people.

  Write is where the compounding value is. Logging the interaction, raising the ticket, updating the record, creating the qualified lead. Without it your team spends the afternoon rekeying what the agent already collected, which quietly eats the time you thought you had saved.

  Most deployments start read-only on a narrow scope and earn write access as confidence builds. That is a sensible sequence rather than a limitation.

  What integration depth buys you

  This is not a nice-to-have. Independent benchmarks put most chatbots at 20 to 40% of conversations resolved and well-integrated agents at 70 to 90%, and the variance tracks integration depth rather than model choice.

  Same model, completely different outcome, decided by whether the thing can see your data.

  Which is why the first question a serious partner asks is about your stack, not your use case. If a vendor glosses over integration in the sales conversation, that is exactly where their timeline will collapse later.

  What to have ready

  Three things make the build faster, and you can start on all of them before choosing anyone.

  Know which systems hold the answers your customers actually ask for. Usually CRM, billing and helpdesk, occasionally provisioning or an internal tool nobody documented.

  Find out who can grant access, and whether they have the time.

  And make sure a customer can be looked up by something the agent will actually have. A phone number or an email. If your customer history lives across three systems with no shared identifier, that is worth fixing first, because the AI build will not fix it. It will expose it.

  Frequently asked

  What if our CRM is old and has no modern API?

  Usually still workable. A database connection, a webhook, an overnight export or even a scheduled CSV drop can back a read-only agent. What changes is the freshness of the data and therefore what the agent can safely promise, so an agent reading a nightly export should not be quoting live balances.

  Can the agent write to the CRM or only read from it?

  Both, and write access is where most of the value is. Reading lets it answer. Writing lets it log the interaction, raise the ticket, update the record and create the lead, which is what stops your team rekeying everything the agent just gathered.

  Do we have to replace our helpdesk to make this work?

  No, and a vendor pushing rip-and-replace is optimising for their convenience rather than your outcome. The sensible approach integrates with the CRM, helpdesk, billing and telephony you already run, and reduces its own scope where an existing tool already covers part of the job.

  Open as its own page