Conversational AI for customer service

50.4%

Conversations Outlearn solves without a human

$0.99

Intercom's published price per Fin resolution

0

First-party numbers on the pages ranking above us

2 Aug 2026

EU AI Act disclosure rule started applying

Every competitor figure on this page comes from that competitor's own public page, with the URL and the date we read it recorded next to the claim. Nothing here is a round-number estimate dressed up as research, and where a number is our assumption rather than a measurement, it says so.

What conversational AI for customer service actually means

Conversational AI for customer service is software that reads a customer message for what is being asked, finds the answer in your own content, performs the action being requested where there is one, and hands the conversation to a person when it should not proceed alone. Four verbs. Everything else in this category is an implementation detail of those four.

The distinction that matters is not the model. Every serious vendor doing conversational AI for customer service is calling roughly the same handful of frontier models, and by the time you have read three pricing pages you will have noticed nobody differentiates on that any more. What differs is whether the system is connected to your knowledge and your systems, or is answering from memory with nothing behind it.

That difference has a visible signature. An answer built from your sources can name the article it came from, which means a customer can check it and an agent can correct it. An answer built from a model's recollection of the internet cannot, and its failure mode is not a blank stare. It is a fluent, confident paragraph that is wrong, which is the most expensive kind of wrong there is.

What a grounded answer looks like on screen

You do not need to inspect a system to tell which kind you are looking at. Six things are visible from the customer's side, and a demo that misses more than one of them is showing you the wrong half of the product.

• Names the article it came from, and lets you open it
• Answers the question that was asked, not the adjacent one
• Says what it does not know, in the same message
• Quotes a real number where the source has one, rather than rounding it
• Offers a person when it is close to the edge of what it found
• Is short enough that the customer reads all of it

The rest of this guide is the working version of those four verbs. If you only read one section, read what it costs per resolved conversation, because that is where most evaluations of conversational AI for customer service go wrong before they start. If you would rather see the product than read about the category, the pricing page and the comparison hub are the two shortcuts.

What we could not find anywhere else

Before writing this we read the pages currently ranking for conversational AI for customer service, all of them vendor-owned. This is what we went looking for and did not find, which is both why this page is shaped the way it is and a useful warning about what the other results will not tell you.

• A first-party number. None of the four pages holding this family of terms publishes a single measurement of its own. Every figure is either a vendor claim or an uncited round number.
• A source next to a claim. nice.com's three pages in this cluster carry zero external links between them while running keyword density up to 7.76%. salesforce.com's page carries one.
• A table. ibm.com/think/topics/conversational-ai-customer-service is 2,676 words with one image, zero tables, zero FAQ, and a datePublished field that is an empty string.
• A visible date. crisp.chat carries no dateModified anywhere across 5,711 URLs, and chatbase.co's page aimed at this term was 423 days stale when we read it.
• A score for handoff quality. Not one comparison in this category has a column for it, which is covered in detail further down.
• A definition of resolution you can hold a vendor to. botpress.com spends 2,478 words on the topic with zero structured data and never defines the word.

Every one of those lines was measured on 8 August 2026 against the live page named in it. We are not claiming those are bad companies, and two of them are considerably better at this than we are at selling. We are claiming that the reference material for conversational AI for customer service is thinner than the category deserves, and that a buyer reading five results in a row currently gets five definitions and no arithmetic.

A rule-based chatbot, conversational AI, and an AI agent are three different things

These get sold under one name and behave nothing alike in production, and the name they get sold under is usually the one with the best search volume rather than the one that describes the architecture. The cleanest way to see the difference is to run one real message down both routes, because the whole distinction is what happens to a phrasing nobody wrote down in advance.

The third category, the AI agent, is conversational AI plus the ability to call your systems. That is a genuine capability jump and also a genuine risk jump, because a system that can write to a record can write to the wrong one. It deserves the separate treatment it gets in the actions stage below.

If you take one row from that table, take the last one. A three-branch phone menu is a perfectly good use of a decision tree and always will be. What a tree cannot do is absorb your documentation and change its answers when you edit a policy, and that is the job conversational AI for customer service exists to do. It is also why the work moves: with a tree you maintain flows, and with retrieval you maintain content, which at least has the decency to help your human agents and your search traffic at the same time.

One naming note, because it will save you an argument in a shortlist meeting. Two of the vendors we measured have removed the word chatbot from their marketing entirely and renamed the category an AI agent. That is a positioning decision, not a technical one, and the comparison pages put the actual capabilities side by side rather than the labels.

The twelve words everyone uses differently

Most shortlist arguments about conversational AI for customer service are vocabulary arguments wearing a technical costume. Here is the vocabulary, defined once, so the rest of this guide means the same thing to you as it does to us.

• Deflection rate. The share of conversations a human never saw. Improves every time the assistant refuses to escalate, which is why it is the most flattered number in the category.
• Containment. The same idea, usually measured per session rather than per conversation. Ask which one a vendor means before comparing two figures.
• Resolution. A conversation that ended without a human. Every vendor defines the ending differently, so this is the word to pin down in writing.
• Escalation. The conversation moving to a person. A success when it happens for the right reason, which is why escalation quality is a separate number.
• Handoff. The mechanics of that move: what arrives, where it lands, and whether the reply gets back to the customer.
• Grounding. Building an answer from retrieved passages rather than from a model's memory, so the answer can name its source.
• Retrieval. Looking the answer up in your content at the moment it is asked, as opposed to at training time.
• Hallucination. A fluent, confident answer with nothing behind it. Almost always an ungrounded answer rather than a bad model.
• Intent. What the customer is trying to do, as distinct from the words they used to do it.
• Guardrail. A rule that overrides the model: topics it must not answer, actions it must not take, phrasings it must not use.
• Action or tool call. An HTTP call to your systems, scoped by you, that the assistant may run when its trigger matches.
• Knowledge grounding gap. A question with no source behind it. Not a model problem, a content problem, and the cheapest thing on this page to fix.

The first two are the ones to be careful with. Deflection and containment both go up when a system stops escalating, which means both reward the exact behaviour that produces the Air Canada outcome. Pair either one with escalation quality or do not report it at all.

How the pipeline works, stage by stage

Five stages, and the interesting part is what each one hands to the next. Most explanations of conversational AI for customer service list the stages and skip the handoffs between them, which is where every real deployment problem lives.

Retrieve: look it up, do not recall it

This is the stage that decides whether you have a useful assistant or a confident one. An answer generated from your own sources can name the article it came from. An answer generated from a model's memory of the internet cannot, and the failure mode is not a blank stare, it is a fluent paragraph that is wrong.

Retrieval is also where permissions belong. The same question deserves different answers depending on who is asking: an anonymous visitor gets the public documentation, a paying customer gets their plan's articles, an employee gets the internal runbooks. If scoping happens after retrieval rather than inside it, the private passage has already been read by the model that is about to paraphrase it.

And it has to keep re-reading. A snapshot taken at onboarding starts drifting from your documentation the first time somebody edits a policy. Outlearn re-reads connected sources every 30 minutes on paid plans, and the source list shows a per-source sync time and a failure count, because a source that quietly stopped reading is worse than one that never ran.

Auto-Sync Sources and Manual Imports are separated on purpose. Everything in the first column keeps re-reading. Everything in the second is a snapshot that starts going stale the moment you upload it, which is the distinction the retrieval stage lives or dies on.

Synced 20 mins ago is the reassuring half. 4 failed is the useful half. A source that quietly stopped reading is worse than one that never ran, because the answers keep coming and nobody knows they are out of date.

Act: do the thing, do not describe it

Most support questions are not questions. "Where is my order" is a lookup. "Cancel my second seat" is a write. A system that can only produce prose answers those with an instruction manual, and the customer still has to go and do it.

An action is an HTTP call to your own API with your own auth headers, plus a plain-English description of when to run it. You scope each one yourself, which is the important half: the assistant can only do what you have handed it, and it cannot invent a new capability at runtime.

Read actions and write actions deserve different treatment. A lookup that returns the wrong order status is embarrassing. A write that cancels the wrong subscription is a refund, an apology and a churn risk. Ship the reads first, put the writes behind a confirmation step, and log every one with the conversation that triggered it.

Step 1 is your endpoint and your own auth headers. Step 2 is a sentence, not a rules tree: "Describe when Outlearn should run this action." Step 3 decides how the result comes back. Note the method on this one is GET, which is the right place to start.

A 3 Sources chip under an answer that quotes a real price. Open it and you get the three articles the answer was built from. This is the whole difference between an answer and a guess, and it is the control that makes the accuracy problem manageable rather than mysterious.

Those five stages are the whole of conversational AI for customer service. Everything a vendor calls a feature is a decision inside one of them, which makes the pipeline a surprisingly good shortlist tool: for any capability you are shown, ask which stage it belongs to and what it changes about that stage's output. Anything that does not map onto a stage is either a channel, a governance control, or a slide.

What an AI-powered customer service platform has to include

"Platform" is the most abused word in this category, so here is a usable definition: an AI-powered customer service platform is the seven layers rather than one of them. A tool gives you the understanding and knowledge layers and leaves you to assemble the other five. That is fine if you have engineers to spare and a very good reason.

The demo you get shown is almost always layers 2 and 3, because those are the ones that look impressive in eight minutes. Layers 5, 6 and 7, handoff, governance and measurement, are where deployments actually fail, and they are exactly the ones no demo covers. So the third column below is a question rather than a description. Ask all seven.

Eight things a demo will not show you unless you ask

Related, and cheaper than a pilot. If you are being walked through an AI-powered customer service platform this week, these are the tells that you are seeing layers 2 and 3 and nothing else.

• The questions in the demo are cleaner than any message your customers send
• Every answer works and none of them says it does not know
• The word resolution is used repeatedly and never defined
• Nobody escalates anything, so you never see the human side
• The content was uploaded rather than connected, so nothing is being re-read
• A write action is demonstrated in minute four with no confirmation step
• Pricing is described as flexible rather than as a unit and a rate
• The dashboard shows one resolution average and no per-topic breakdown

None of those means the product is bad. They mean the demo was built to be watched rather than to be evaluated, which is a reasonable thing for a salesperson to do and an unreasonable basis for a decision. Book a walkthrough with us and ask for the opposite: your own raw messages, one escalation, and the audit log.

Run that third column as a script and you will learn more in twenty minutes than in three demos. The pattern to watch for is an AI-powered customer service platform that answers layers 1 to 4 fluently and turns vague at layer 6, because governance is where the engineering was deferred. Ours turns vague at single sign-on, which is on the enterprise page in writing rather than discovered later.

Twenty systems, and the reason a platform is worth buying rather than building. Reading Confluence, SharePoint, Drive and four helpdesks, and keeping up with their API changes, is a permanent job rather than a project.

The reason an AI-powered customer service platform is usually worth buying rather than building is layer 3, and specifically the connector fleet. Reading Confluence, SharePoint, Google Drive, GitHub and four different helpdesks, then keeping up with all of their API changes forever, is a permanent staffed job. We have that job. It is not glamorous and it is most of the value. The build, buy or self-host section below prices all three routes honestly, including the case where building wins.

One note on scope, because it is where an AI-powered customer service platform gets oversold. Reading your content and taking actions is not the same as being your helpdesk. Outlearn has no shared inbox and no ticket queue: it sits in front of whatever your team already works in and hands the hard conversations across. If you want the AI layer replaced and the inbox left alone, that is the shape, and the use cases page has the specific jobs it fits. If you want both replaced, the comparison hub is a more honest starting point than this page, and the individual write-ups for Help Scout, Front, Zoho Desk and LiveChat each say plainly where we are not the answer.

The last thing worth saying about the word platform: an AI-powered customer service platform is not automatically better than a tool. It is better when you would otherwise be integrating five things yourself, and worse when you only needed one of the seven layers and are now paying for a governance console you will never open. Larger buyers can read our version of layers 6 and 7 on the enterprise page.

Which conversations to give it, and which to keep

Deployments of conversational AI for customer service fail on scope far more often than on model quality. The two lists below are not a maturity ladder, and the right-hand one does not become safe later. Some of those conversations should stay with a person permanently, on purpose, and saying so out loud is what stops a pilot from being judged on the wrong traffic.

The last item in the right-hand column is the one teams skip. If your refund policy page has been wrong since March, automating refund questions does not create a new problem, it industrialises the one you already had. Fix the page first. That is a morning of work and it improves the human answers too.

Scope also varies by channel, which is the second thing demos hide. The same pipeline behaves differently in a widget, in an email thread, in Slack and inside your product, mostly because of what the customer will tolerate and what context you already have.

The practical advice is to start on one channel and finish it. Get resolution and escalation right in a widget, or in email, before adding the second, because every channel you add multiplies the number of places a bad handoff can happen. A conversational AI for customer service rollout that goes live on four channels in week one is not four times as ambitious, it is four times as hard to debug. The six-week rollout below is written for exactly one, and the LiveChat handoff guide is the worked example for the escalation half.

The same pipeline in Slack, which is usually an internal audience asking about internal runbooks. Helpful and Retry under the reply are the cheapest feedback loop in the product, and the source of the unanswered-question list.

Handoff is the axis nobody scores

Here is a measurement rather than an opinion. Across the four ranked listicles competing for this keyword family, thecxlead.com, lindy.ai, wonderchat.io and zendesk.com, checked on 8 August 2026, not one has a column, a heading or a rubric line for how well a system hands a conversation to a human. Chatbase names cold handoffs as a failure mode in a blog post and then scores nothing. The thing that most reliably breaks in production is entirely absent from every comparison a buyer is likely to read.

It matters because a bad handoff undoes the automation retroactively. A customer who explains a problem in four paragraphs, gets escalated, and is greeted with "Hi, how can I help?" has now had a worse experience than if nothing had been automated at all. That single moment is where "we tried this and our satisfaction scores dropped" comes from, and it is almost never a model problem.

The behaviour to look for is a ladder rather than a switch. Confidence is a continuous quantity and there are at least three useful bands in it, plus two policy rules that override confidence entirely.

What should actually arrive on the human side

"We pass the transcript" is where most vendor answers stop, and it hides most of the difference. Hand this list to whoever is running your evaluation and ask them to tick it off against the agent view rather than the marketing page.

• Every message in the conversation, in order, including the assistant's
• Which sources the assistant retrieved, so the human can correct the source
• Which actions it ran and what they returned
• Why it escalated: low confidence, a topic rule, or the customer asked
• The customer's identity, if they were signed in when they started
• The channel it came from, so the reply goes back to the right place
• A link back to the live conversation rather than a static copy

Then score it. Five rows, ten minutes, and it will tell you more about a conversational AI for customer service vendor than any demo. Outlearn passes three of these five cleanly, and the LiveChat handoff guide documents exactly what arrives on the agent side, which is the row most products fail.

Two of Outlearn's own answers here are worth saying out loud. Duplicate suppression works: if a customer already has an open conversation on the other side, the escalation joins it rather than opening a second one, and the LiveChat walkthrough shows the setting that controls it. Confidence-threshold tuning is coarser than we would like, so the honest version of the medium-confidence rung on our product today is closer to a switch than a dial.

Handoff is also the reason we think this whole category is measured wrongly. The industry reports deflection, which counts the conversations a human never saw, and deflection improves every time the assistant refuses to escalate. Escalation quality is the corrective and almost nobody publishes it. If you take one procurement habit from this guide, make it scoring the exit rather than the entrance.

The six ways these deployments fail

Every one of these is something we have watched happen, and none of them is about model quality. If you are building the risk register for a conversational AI for customer service pilot, this is the register.

It is worth being explicit about that first sentence, because the industry defaults to blaming the model. Here is a list of things that are never the model:

• Answers that are confidently wrong about a policy you changed in March
• A customer who explained the problem twice, once to software and once to a person
• A resolution rate that plateaued in month two and never moved again
• An assistant that answers billing questions it should be refusing
• Three vendors quoting three resolution rates that cannot be compared
• A pilot that ended without anybody being able to say whether it worked

The seventh failure, which is the quiet one

The pilot that ends without a verdict. Nobody cancels it, nobody renews it, it just stops being mentioned. It happens because success was never defined, so there is no sentence anyone can disagree with in a review meeting. Fix these seven things in writing before you connect a single source.

• The definition of a resolution, in one sentence, agreed by support and finance
• The window: which weeks count, and what happens to a partial week
• The channel, singular, and the explicit decision to ignore the others
• The topic list, and which topics are excluded on purpose
• The escalation rules, written down before anyone tunes a threshold
• The number that means continue, and the number that means stop
• The date the decision gets made, and the person who makes it

Ten minutes of writing, and it is the difference between a pilot that produces a decision and a pilot that produces a slide. The six-week rollout below puts it in week two on purpose, before any number exists to argue about.

Accuracy, hallucination, and the two cases worth reading

The question every executive asks about conversational AI for customer service is "what if it is wrong", and the honest answer has two halves. The engineering half is that grounding an answer in a retrieved source and showing that source is what turns accuracy from a mystery into a control you can inspect. The legal half is that being wrong is your problem, not the vendor's, and there is now a decision that says so.

An airline argued its assistant was not its problem

In Moffatt v. Air Canada, 2024 BCCRT 149, decided on 14 February 2024, the British Columbia Civil Resolution Tribunal considered an airline whose website assistant told a customer he could apply for a bereavement fare after travelling, which contradicted the airline's own policy page. The airline argued it was not responsible for what its assistant said. The tribunal called that submission remarkable, held that the assistant was part of the airline's website like any other page, found the airline had not taken reasonable care to ensure it was accurate, and awarded damages plus interest and fees. It also held that a customer cannot be expected to cross-check one part of a website against another.

An AI company's own assistant invented a commercial term

The second case is smaller and more useful, because it happened to a company that builds AI. In April 2025 the code editor Cursor's support assistant told users their subscription was limited to one device, a policy that did not exist, and users cancelled on the strength of it. The co-founder apologised, confirmed there was no such policy, and committed to labelling AI responses as such. Forbes reported it on 22 April 2025. An unretrieved answer did not just annoy somebody. It invented a commercial term and cost revenue.

Both are arguments for the same three controls. Ground every answer in a retrieved source. Show the source to the customer, the way the 3 Sources chip above does. Escalate rather than guess when retrieval comes back empty, which is the third rung of the handoff ladder. Everything else people say about hallucination in conversational AI for customer service is downstream of those three, and none of the three requires a better model.

There is a fourth control that is really a business decision: do not put irreversible actions behind an assistant. Refunds, cancellations and account closures are exactly the conversations the scope section says to keep human, and the reason is not that software is bad at them. It is that the cost of being wrong is asymmetric, and asymmetric costs are a policy question rather than an accuracy question.

Governance: disclosure, PII, GDPR, SOC 2 and HIPAA

This is the section every vendor page on conversational AI for customer service skips and every security review opens with. None of it is exotic and all of it is cheaper to decide before launch than after the first complaint.

Redaction, as a list rather than as a promise

"We redact PII" is a sentence. This is a list you can check against, and asking for it in writing takes one email. Confirm which of these is stripped from a message before it reaches a model, and confirm separately what happens to whatever is left.

• Full payment card numbers, and the three digits on the back
• Bank account and routing numbers
• National identifiers: social security, national insurance, tax file
• Passport, driving licence and national ID numbers
• Dates of birth, which are an identifier rather than a detail
• Full postal addresses, as distinct from a city or a country
• Health conditions, prescriptions and anything a clinician wrote
• Passwords, API keys and tokens customers paste in by accident
• Photographs and attachments, which carry all of the above invisibly
• Anything a customer volunteers about a third party who did not consent

The last item on that list is the one nobody plans for. A customer describing somebody else's medical situation, or pasting a colleague's bank details, has handed you data about a person who never agreed to anything. Retention has a related trap: a retrieval index is a second copy of your content and a transcript store is a second copy of your customers' words, so a deletion request has to reach both. Our own answers are in the privacy policy rather than paraphrased here.

Disclosure, which now has a date on it

The cheapest control on this list is a sentence. Article 50 of the EU AI Act requires that AI systems intended to interact directly with people are designed so those people are informed they are interacting with an AI system, unless it is obvious. That started applying on 2 August 2026, so if you have EU users it is no longer a nice-to-have.

Outside the EU it is still the right default, for a commercial reason rather than a legal one. The customer who works out afterwards that they were talking to software does not remember the answer, they remember being handled, and that is the complaint that reaches your CEO. Cursor's own commitment after its incident was precisely this: label the AI responses. Say it once, at the start, in plain words, and skip an entire category of escalation.

The certification words, used precisely

On certification language, precision helps. SOC 2 is an attestation report produced by an auditor against criteria, not a certification you either have or do not, so the useful request is the report and its scope rather than a logo. If you handle US health data, the question is whether the vendor will sign a business associate agreement, and a vendor who has not heard the term is answering the question by not answering it.

If you need a framework to hang all of this on, the NIST AI Risk Management Framework 1.0, published on 26 January 2023, organises it into Govern, Map, Measure and Manage. It is voluntary, it is free, and it is the cheapest way to have a structured answer ready when procurement asks. Larger buyers will find more of this on the enterprise page.

And the habit we would rather you build here than in a security review: put every hard requirement to every vendor in writing, us included, and hold the answers to the same standard. The comparison hub exists so you can see the same questions answered side by side instead of one features page at a time.

What it costs, normalised to one unit

This is where most evaluations of conversational AI for customer service go wrong, and it is arithmetic rather than judgment. Every vendor in this category bills in a different unit. Per resolution, per ticket, per AI reply, per seat, per automated interaction, and in at least one case two of those at the same time. A shortlist compared on headline rates is not compared at all.

So convert everything to one number: cost per resolved conversation. Total monthly bill divided by the number of conversations that ended without a human. It is unit-free, it survives a change of vendor, and it is the only figure that answers the question you actually have.

Reading the meters, one by one

A few observations from having read all of those pages. Intercom's unit is the cleanest on the list and their published definition of a resolution is unusually specific. Help Scout's meter is more forgiving than ours: they do not charge when the customer escalates and we do bill every reply, which is a genuine point against us and we have written it up on the Help Scout comparison. Gorgias runs two meters at once, so a conversation their assistant fully resolves bills both, which is the odd situation of success costing more than failure, and it is set out on the Gorgias comparison.

The meters that need the most care are the ones counting something other than an outcome. Tidio's Lyro bills per conversation it replies in whether or not it resolved anything, so you divide by your resolution rate to get a real unit cost, and the working is on the Tidio comparison. Helply bills every ticket that reaches it, resolved or not, which is the same arithmetic with a different label, and the Helply comparison does the division. Front publishes a "starting at" per-conversation floor rather than a rate, which the Front comparison treats as a minimum rather than a quote.

The seat question, which is separate and often larger

A ten-seat floor at $75 is $9,000 a year before a single automated answer, which is a price shaped around ten people reading tickets rather than around how much work gets done. Outlearn charges nothing per seat and everything per AI reply. At three agents that trade is not obviously in our favour and we say so on the comparisons, including the Chatbase and Front write-ups where the seat cliff is the whole story. Our own tiers are on the pricing page, and the comparison hub has all eight side by side.

One last piece of arithmetic that catches people out. The cheapest cost per resolved conversation is not always the best buy, because a system resolving 40% of your traffic leaves 60% for humans and a system resolving 55% leaves 45%. Multiply the leftover by what an agent-handled conversation costs you and add it to both columns. That total is the number a finance team recognises, and no conversational AI for customer service vendor will calculate it for you, including us.

The numbers that tell you whether it is working

Five numbers, and one instruction: write down the definition of each before the pilot starts. Every vendor selling conversational AI for customer service has a slightly different definition of resolution, so yours is the only one that can compare them.

What the published outcome numbers actually say

There is exactly one large, specific, first-party figure in wide circulation, and it is worth reading carefully rather than quoting. In February 2024 Klarna published that its assistant was handling two-thirds of its customer service chats, doing the equivalent work of 700 full-time agents, with repeat enquiries down 25% and resolution time falling from 11 minutes to under 2.

Three caveats before you put that in a business case. It is one company's own announcement rather than an audited figure. Klarna has enormous volume concentrated in a small number of transactional topics, which is the easiest possible shape for this technology. And the number that moved most, 11 minutes to 2, is time to resolution rather than accuracy. It is a real result and it is not a forecast for you. That is precisely why the rollout starts by measuring your own top twenty questions instead.

Why the average is the least useful number you have

The first one has to be broken down per topic. A single resolution average is the most reassuring and least useful number in the category, because one badly covered topic hides comfortably inside a good mean. Resolution at 60% overall can be 85% on shipping questions and 15% on billing, and the second half of that sentence is your entire roadmap.

Escalation quality is the one people get backwards

Escalating correctly is a success. If you optimise a system towards never escalating, you have optimised it towards guessing, and you will find out in a month from the complaints rather than from the dashboard. Report it next to resolution, not underneath it, and treat a rising escalation rate on a new topic as the system working rather than failing.

This is a freshly created account, which is why Auto-Solved reads 0.0% and Satisfaction reads N/A. We would rather show you that than a dressed-up demo. The point is which four numbers are on the wall, and that Common Topics below them is where the unanswered-question list comes from.

Cost per resolved conversation belongs on the same wall as the other four, because it is the one that changes the decision. A system resolving 40% of conversations at a third of the unit cost is beating one resolving 55% at full price, and no vendor's dashboard will volunteer that comparison for you. The cost section above has the arithmetic and the pricing page has our side of it.

Whatever you do, measure it on your own traffic rather than against a published benchmark. Our 50.4% is a real measurement of our own install base and it is still the wrong number to plan with, because your topic mix is not ours. The only benchmark that predicts your resolution rate is the audit in week one of the rollout: how many of your top twenty questions already have a page behind them.

Build it, buy it, or self-host it

Three routes, and the honest way to price them is in engineering attention rather than licence fees, because attention is the thing that actually runs out.

Building is more defensible than vendors admit

If support is a product surface rather than a cost centre, and your data model is unusual, owning retrieval end to end is a reasonable call. What sinks these projects is never the model plumbing, it is the connectors: twenty content systems, twenty auth models, twenty sets of API changes arriving on somebody else's schedule forever.

Self-hosting is real, and the licence is the easy part

Rasa on GitHub ships under Apache-2.0 with over 21,000 stars, and Botpress ships under MIT, both verified on 9 August 2026. If data residency or procurement rules out hosted vendors, that route is real and it works. It just does not remove any of the work described in the rest of this guide, and the operational half is a standing commitment rather than a setup cost.

Buying makes sense in the common case

Support volume is real, your content already exists in systems somebody else maintains, and you want an answer this quarter rather than a roadmap. That is the case Outlearn is built for, and the use cases page describes the shapes it fits. If you would rather see it running against your own content than read about it, book a walkthrough and bring your twenty questions, or start on the free tier and skip us entirely.

The comparison that actually decides this is not build against buy in the abstract. It is your engineers' next quarter against a monthly bill you can read. If the bill is smaller than one engineer-month and the connectors are somebody else's problem, buying an AI-powered customer service platform is the boring correct answer. If it is not, build, and use the seven layers as the specification.

A six-week rollout, in the order that keeps the mistakes at the end

Six weeks is realistic for one channel when the content already exists, and this is the shortest honest timeline we would put in writing for a first deployment of conversational AI for customer service. It is not realistic if week one turns up eight missing articles, and week one usually does, so add two weeks and write them rather than pretending the timeline held.

The ordering principle is that everything reversible happens early and everything expensive happens late. Reads before writes. One channel before four. Handoff before anything clever.

1. 1

   Week 1: pick one channel and twenty real questions

   Export a month of tickets, group by the underlying question rather than the tag, and take the top twenty verbatim. Do not clean them up. Pick the single channel where those twenty arrive most often and ignore the others.

2. 2

   Week 1: audit which of the twenty have a source

   For each of the twenty, find the page that answers it. The ones with no page are your content backlog, and they will cap your resolution rate no matter which vendor you choose.

3. 3

   Week 2: connect content, read-only, and let it sync

   Point the system at your existing systems rather than uploading exports. Confirm the sync interval and confirm what a failed source looks like on the dashboard.

4. 4

   Week 2: write down what a resolution means

   Fix the definition, the window and the exclusions before any number exists. Every vendor uses a different one, so yours is the only one that can compare them.

5. 5

   Week 3: configure handoff before you configure anything clever

   Set the confidence threshold, the red-flag topic list, and the explicit-request path. Then test all five rows of the handoff rubric end to end.

6. 6

   Week 3: turn on disclosure and redaction

   Label the assistant as software in its first message and confirm what is stripped from a message before a model sees it. Both are cheaper now than after the first complaint.

7. 7

   Week 4: go live on that one channel, shadowing your team

   Keep humans answering. Let the assistant answer alongside them and compare on your own traffic rather than on a benchmark from a vendor blog.

8. 8

   Week 5: add read actions only

   Order status, subscription state, licence checks. Nothing that mutates a record. Measure action success rate separately from resolution rate.

9. 9

   Week 6: read the unanswered list and write the top five articles

   This is the step that compounds. Then, and only then, consider a second channel or a write action.

Week two carries the item most teams skip, which is writing down what a resolution means. It takes ten minutes and it is the difference between a pilot that produces a decision and a pilot that produces a slide. Pricing is the other week-two conversation, because the unit you are billed in should be a deliberate choice rather than a discovery, and the comparison hub is where you find out what the alternative units look like.

Weeks five and six are where the compounding starts, and they are the two most teams never reach because something more urgent arrived in week four. If you protect one thing on this schedule, protect week six. A conversational AI for customer service deployment that reads its own unanswered-question list every month gets better on a schedule. One that does not plateaus, and the plateau gets blamed on the technology rather than on the calendar.

Migrating off a bot you already have

Most teams evaluating conversational AI for customer service are not starting from nothing. They have a decision tree somebody built in 2022, it deflects a bit, everyone quietly routes around it, and nobody wants to be the person who switches it off. The migration is straightforward and the order is the whole trick.

Step one is the one worth arguing about. The instinct is to migrate the flows, because somebody spent months on them. Do not. The valuable artefact is the pile of messages that fell through those flows, because those are precisely the phrasings a tree could not handle, which makes them the best evaluation set you will ever get for free.

Step five is the one that gets broken. Two weeks in, something will be answered badly and somebody will suggest adding a scripted flow to catch it. Every flow you add is a place the system stops learning, and the unanswered-question list is a better fix. If the old bot lives inside a helpdesk you are also reconsidering, the comparison hub has the eight platforms we have written up, each with their own published pricing and the date we read it. Switching a bot and switching a helpdesk are separate projects and should be separate months.

The one migration case worth treating differently is moving from a scripted flow inside a helpdesk you intend to keep. There you are replacing the AI layer only, which is the shape Outlearn is built for: an AI-powered customer service platform sitting in front of the inbox your team already works in, handing the hard conversations across. The write-ups for Zoho Desk, LiveChat and Helply each cover that specific case, and the pricing page prices it.

Twelve questions to ask every vendor

Print this, or copy it into the shortlist spreadsheet. Every one of them is answerable in a sentence by anyone selling conversational AI for customer service, and a vendor who needs a call to answer number one has told you something about number one.

1. 01What exactly is your definition of a resolution, in one sentence, and does an escalated conversation count?
2. 02How often do you re-read my content, and what does the dashboard show me when a source fails?
3. 03Can an answer be scoped to what a specific signed-in customer is allowed to see, and does that scoping happen before or after retrieval?
4. 04Show me your handoff. What arrives on the agent side, and does replying there reach the customer without a refresh?
5. 05If I escalate twice from the same customer, do I get one conversation or two?
6. 06What is redacted from a message before it reaches a model, and can I see that list?
7. 07Where are transcripts stored, for how long, and does a deletion request also clear the retrieval index?
8. 08Is your assistant disclosed as software to the customer by default, or is that a setting somebody has to remember?
9. 09For a write action, show me the audit log entry and tell me how I reverse it.
10. 10Can I see resolution rate broken down per topic rather than as one number?
11. 11Do you charge me for an answer that failed, and do you charge me for the fourth message in a conversation that ends with a human?
12. 12Will you put the answers to all of the above in writing before the pilot starts?

Ask us all twelve. Our answers to the awkward ones are already on this page: we bill every AI reply including the ones that miss, and our confidence tuning is coarse. If you want them alongside somebody else's answers, the comparison pages put both columns next to each other, the enterprise page covers the procurement half, and the pricing page has the meter. For number nine specifically, the Gorgias write-up and the Tidio write-up show what happens when the answer to the billing question is a second meter.

A note on how to use the twelve. Send them by email before the call, and read the shape of the reply rather than only the content. A vendor of an AI-powered customer service platform who answers eleven in writing and books a call for the twelfth has told you where the soft spot is, which is more useful than eleven confident yeses. That is the same reason our own comparisons carry rows where we lose: a page with no losing rows is not a comparison, it is a brochure.