What to do when the sales robot gets it wrong

The first three minutes after you notice the mistake

While the conversation is going the wrong way, every further message from the bot makes it worse. The first move is to switch off the auto-reply and hand the deal to a live manager, not to fix the wording inside the chat. The same mechanism does this as an ordinary handover of a hot lead: the sales robot can hand the conversation to a human when it knows that it should.

The second step is to record the mistake itself: to whom, in which channel and to which question the wrong answer was given. Without that record the review turns into a retelling from memory, and the cause is found by accident. The easiest way is to save a screenshot or a link to the deal card in the CRM at the moment you notice it, before the conversation slides down the feed.

The third step is not to delete or edit the bot's message after the fact. It is the only evidence of what exactly went wrong, and without it it is hard to tell whether the bot erred in the facts, in the tone or in the logic of handing the customer over to a manager. A review without the saved original usually has to start from scratch.

What to write to the customer after a mistake

The customer does not have to work out where exactly the bot got confused — what matters to them is what happens next. The wording “sorry, a bot answered here and it got it wrong, our manager will contact you now” works better than trying to explain the technical cause. Admitting the fact without excuses removes the irritation faster than a long explanation.

Next it matters to name a concrete next step instead of leaving the customer waiting indefinitely. “A manager will be in touch during the day” sounds worse than “Maria will write to you in ten minutes” — if that time can really be kept. A vague promise after a mistake has already happened only gives the customer another reason to doubt.

If the mistake was in numbers — price, deadline, availability — the correction is better sent as a separate message rather than mixed with the apology. It is easier to read two short messages in a row than one paragraph where the apology and the new information come as one lump. This matters especially when money is involved: confusion here costs more than in any other topic.

Where to look for the cause: the prompt, the knowledge base or the CRM integration

Bot mistakes almost always happen in one of three places, and each is treated differently. The first is the prompt — the instruction by which the bot understands the question and shapes the answer: if it read the customer's wording wrongly, it is the instruction that needs refining, not the data around it.

The second place is the knowledge base: an outdated price, a service that is no longer sold, a wrong description of the terms. Here the problem is not in the bot's logic but in the source of facts that was not updated in time. Such mistakes repeat identically for different customers, and that is the first sign the prompt is not to blame.

The third place is the tool call into the CRM: the bot asked for current data on the deal and did not get it, or got the wrong data. That is a question of integration, not of text, and it has to be fixed at the level of connected channels and fields, as described in the section on CRM implementation. Mixing these three causes into a single review is the most common reason why the same mistake comes back a month later in a different form.

What to do with the deal if the customer already quoted the wrong price or terms

If the customer shows the conversation and says “your bot promised a discount”, the decision is made not by a bot and not by a script, but by a person with authority. There are three ways: record it as a one-off exception for this deal, cover part of the difference, or refuse with an explanation that the information was wrong. There is no universally right option — there is only what costs the business more: a one-time concession or a damaged relationship with the customer.

It makes sense to decide in advance what size of discrepancy a manager settles on the spot and what needs approval from above. Without such a threshold every case turns into a separate meeting while the customer waits for an answer. A clear boundary saves time for the owner and for the manager alike.

It is worth saying out loud to the team that a confirmed bot mistake is not a reason to blame the manager who carried the deal on. Otherwise the review of mistakes becomes a search for the guilty rather than a fix of the process, and next time the failure simply will not be reported.

How not to lose these cases and use them to teach the bot

Every mistake is worth marking in the CRM with a separate status or tag — “assistant error”, for example — right on the deal card and not in a separate file that nobody will open a week later. Then in a month you can see how many such cases there were and whether they repeat around one topic.

It helps to attach the fragment of the conversation itself to the card, not a retelling in your own words. A retelling loses exactly the details needed to tell whether the prompt, the knowledge base or the integration let you down. A review from memory two weeks later is almost always inaccurate.

The accumulated cases are a ready-made list of what to fix in the knowledge base or in the bot's logic at the next round of tuning. Without tagging they scatter across different chats and managers, and the update happens only when the same mistake causes enough complaints to be noticed.

What to measure to see the problem before the customers complain

For a bot that runs sales rather than just answering questions, what matters is not general satisfaction metrics but specific counters. The share of conversations escalated to a live manager shows how often the bot itself realises it is not coping. Too low a share is as worrying a sign as too high a one: it means the bot is either guessing where it should hand over to a human, or overloading managers with what it could close itself.

The second counter is the share of wrong answers found in spot checks of conversations: how many randomly chosen dialogues turn out to be factually inaccurate on review. This is not a one-off check but a regular sample, otherwise the figure goes stale fast. The third is the manager's reaction time after the bot hands the deal over: if too much time passes between the escalation and the first human reply, part of the point of the bot's speed is lost.

In the running GetGate project, a blind comparison found the assistant's answer no worse than a human's in 80% of cases — that is a reference point for a similar task, not a guarantee for any business. Exactly this check — comparing the answers of the bot and of a person on real correspondence — is worth running regularly and not once at launch. More on how it is set up as a routine is in the section on quality control.

What this looks like in practice when the rules are vague

A common cause of mistakes is not a failure of the bot but a vague rule at the entry point. If it was agreed with the head of sales that the bot handles all deals except large ones and VIP customers, but those exceptions are not fixed as a separate rule in the CRM, sooner or later the bot will pick up exactly the deal a particular manager was supposed to handle. The phrase “a colleague is working on those for now” sounds clear in conversation, but it has to be written down as a condition, not kept as a verbal agreement.

A similar situation is a change of the channel the customer writes in. If the contact in the CRM was updated and the customer now writes not in WhatsApp but in another channel, while the deal card does not reflect it, the bot may keep following the logic of the old channel or lose the history of the conversation. Such moves are worth recording in the card straight away, not keeping in one manager's head.

The third typical signal is the question “why is the bot not answering at all?”, which usually means not a mistake in the text of an answer but a failure at the level of the channel connection or the integration. It belongs in the same incident log as errors of meaning, because the cause is found the same way: by looking at where exactly the chain broke — in the channel, in the CRM or in the bot itself.

How to set the process up so that mistakes do not pile up quietly

A one-off fix of a single conversation does not solve the task — a month later a similar mistake will show up in another channel or with another manager. A stable process rests on three things: a clear escalation rule, regular spot checks of conversations, and a review of the cause across the three places — prompt, knowledge base, integration — rather than at random. Without that routine, the review of mistakes rests on one attentive employee instead of on a process.

In the GetGate project 27% of enquiries arrive in the evening and at weekends, when the customer used to wait until morning — and these are exactly the hours with the least live supervision, while the bot works without a break. This is precisely when the escalation rule and a written incident log matter most: there is nobody on the spot to catch a failure if it is not recorded automatically.

The time freed up for a manager — about an hour a day in the same project — makes sense to spend not on picking apart the same bot mistakes again and again, but on reviewing new cases and tuning the rules. Then quality control becomes part of the department's ordinary work rather than a separate fire. If the process of reviewing mistakes has to be built from scratch, that is closer to the task of building a sales department than to a one-off fix of a single conversation.