KodDeltaGuides

AI Chatbot or Live Support: Which Questions Belong to Each?

~9 min read

The question is not whether a chatbot beats live support. It is which questions each one answers. KodDelta routes questions with a written answer to the assistant, sends anything involving price, commitment or a complaint to a person, and builds a handover that carries the conversation across so the customer never repeats themselves.

Two versions of the same mistake show up on company websites. In the first, a chatbot intercepts every visitor and refuses to let go, so a buyer with a live tender spends four minutes being asked to choose from a menu before finding the word "agent". In the second, there is a live chat widget that nobody staffs after six in the evening, so a message sent at nine at night gets a reply two working days later. Both are routing failures. Neither is fixed by choosing a side.

Route by answer type, not by channel

The useful split is not "simple questions to the bot, hard questions to people". It is whether the answer already exists in writing and is the same for every customer. That test decides correctly in almost every case. In some sectors a third column appears, where the assistant neither answers nor hands over but opens a record: resident support in property management is the clearest example of that pattern.

Incoming questionRoute toWhy
"Where is my order?" Assistant One record lookup. The answer is a fact in your system, identical however it is asked.
"Does the warranty cover this failure?" Assistant The scope is written in a document. The assistant quotes the clause and names it.
"What is the lead time on this part?" Assistant Safe if the data is current. If your lead times live in a spreadsheet updated monthly, route it to a person instead.
"Can you do better than that price for twelve units?" Person A commitment with margin attached. Nothing written down decides it.
"We need this integrated with our ERP by March." Person Scope, feasibility and a date. The answer does not exist yet; it has to be worked out.
"This is the third time it has broken." Person The content is a complaint. A correct answer delivered by software still reads as a brush-off.

The middle rows are the interesting ones. "Lead time" belongs to the assistant only if the underlying data is trustworthy. Routing follows data quality, which is why this decision sits close to what an enterprise AI assistant can and cannot do.

The four triggers that build the handover point

A handover that waits for the customer to type "let me talk to someone" is already late. Define the triggers in advance and let the system act on them.

1. A request for scope or a quote

The moment somebody describes a requirement and asks what it would take, the conversation is a sales conversation. The assistant collects the detail and hands over.

2. Any discussion of price or terms

Discounts, payment terms, volume tiers, contract length. These commit the company. They belong to a person with the authority to commit it.

3. A complaint or visible frustration

Repeated failures, formal wording, escalating tone. The correct response is a named human being, quickly, regardless of whether the answer is in a document.

4. Two low-confidence answers in a row

If retrieval returns nothing solid twice, the assistant is guessing. Stop it there and pass the conversation on rather than letting it produce a third attempt.

What a handover has to carry

The customer experience that destroys trust is being asked to start again. A handover is a data transfer, not a notification, and it should carry four things:

  • The full transcript, visible to the person taking over before they type their first line.
  • A short structured summary — who they are, what they want, what has already been answered and with what source.
  • The identity of a named owner. A conversation handed to a shared inbox is a conversation handed to nobody.
  • A fallback if nobody picks it up. Out of hours, the assistant should say plainly that a person will reply, take contact details, and create a record with an owner and a due time.

That last point is where most of the actual value sits. The realistic gain from a support assistant is not replacing daytime staff; it is that a question arriving at 22:40 becomes a tracked record instead of an unread message.

The cost of a wrong answer decides the routing

Frequency is the wrong criterion for what to automate. A question asked two hundred times a month with no consequence attached is a good candidate. A question asked twice a month that commits your margin is not, however tempting it is to automate the whole page.

Wrong answerWhat it actually costsImplication
Opening hours A wasted trip and an apology Automate freely
Technical specification A wrong part ordered and a return Automate, but cite the source document in the reply
Stock or lead time A missed production slot at the customer Automate only if the data is live
Price or discount The margin on the order, because a written figure is treated as your answer Do not automate the commitment; automate the draft
A compliance or safety question Liability, and it does not matter that software said it Route to a person by default

Notice the pattern: the assistant is safe where the answer is a fact and unsafe where the answer is a commitment. The same distinction governs whether an assistant may write into your systems at all.

Designing the "I do not know" path

An assistant that never admits a boundary is not more capable, it is less honest, and every wrong answer costs more to undo than the question cost to answer. Three settings make the difference:

  1. 1. A confidence floor

    If retrieval does not return a passage that clearly answers the question, the assistant does not compose an answer from general knowledge. It says what it could not find and offers the handover.

  2. 2. A source on every factual answer

    Naming the document or record does two jobs: the customer can check it, and your own team can spot within a day that the assistant is quoting a superseded price list.

  3. 3. A logged escalation, not a dead end

    Every unanswered question is recorded with its text. That log is the specification for the next month of work — either the document is missing, or the routing rule is wrong, and both are cheap to fix once you can see them.

What to measure

Take a baseline before go-live or you will not be able to prove anything afterwards. Four numbers are enough:

  • First-response time, split by hour of day. The out-of-hours column is where the change should be visible.
  • Share of conversations closed without a handover — and separately, how many of those came back within a week, which is the number that tells you whether they were really closed.
  • Escalations by trigger. If almost everything escalates on the low-confidence rule, your documents are the problem, not the routing.
  • Corrections issued. Every answer a person had to walk back. This should trend to zero; if it does not, narrow what the assistant is allowed to answer.

Measuring properly is the same discipline as any other automation project, covered in the ROI guide.

When not to add a chatbot

  • Your inbound volume is low and every enquiry is a real sales conversation. Answer them yourself; the routing overhead exceeds the saving.
  • Nothing is written down. The assistant has nothing to retrieve, and writing the answers down is the actual project.
  • Your product answers genuinely differ per customer — bespoke engineering, negotiated frameworks. Automate order status and document requests instead, and leave the rest with people.

Cost and timeline

  • Assistant grounded in your own documents and records: $5,000–12,000.
  • Single focused module connected to an existing system: $3,000–6,000 over 2–4 weeks.
  • Multi-department system: $8,000–15,000 over 4–8 weeks.
  • Annual maintenance: optional, 12–25% of build cost. Licence: perpetual, unlimited users, source code delivered.

A working prototype arrives within the first two weeks, tested against real questions from your own inbox rather than invented ones. Bring one month of inbound messages and we will sort them into the three columns above before anyone writes code. Request a quote, read the AI integration page, or compare bands on the pricing page.

Frequently asked questions

Which questions should an AI chatbot answer, and which should go to a person?

The assistant should answer questions whose answer is already written down and identical for every customer: opening hours, specifications, order status, warranty scope, document requests. A person should take anything involving a price commitment, a negotiation, a complaint, or a case where the customer has already been given a wrong answer once.

How do you build the handover point from a chatbot to a human?

Define explicit triggers rather than waiting for the customer to ask. The common four are a request for a quote or scope, any pricing or terms discussion, a complaint or clear frustration, and two consecutive low-confidence answers. When a trigger fires, the conversation is passed with its full transcript to a named person, not to a shared inbox.

What does it cost when a chatbot gives the wrong answer?

It depends entirely on what the answer commits you to. A wrong opening time costs a wasted trip. A wrong lead time costs a missed production slot. A wrong price quoted in writing can cost the margin on the order, because the customer reasonably treats it as your answer. Route questions by that cost, not by how often they are asked.

Should the chatbot be allowed to say it does not know?

Yes, and it should be the designed behaviour rather than an accident. An assistant that admits the boundary and offers a person keeps the conversation. An assistant that fills the gap with a plausible sentence produces a support ticket, a correction, and a customer who no longer trusts the channel.

Does an AI chatbot let us reduce the support team?

Treat it as a coverage decision rather than a headcount decision. The assistant answers outside working hours and absorbs repeat questions, so the same team handles more inbound volume and spends more of the day on cases that need judgement. Reducing headcount on the strength of a pilot is how the exception queue becomes unstaffed.

What does a support assistant cost at KodDelta?

An assistant grounded in your own documents and records is $5,000–12,000. Connected to an existing system as one focused module it is $3,000–6,000 over 2–4 weeks. Annual maintenance is optional at 12–25% of build cost, the licence is perpetual with unlimited users, and the source code is delivered.

Let's talk about what you need.

The 30-minute discovery call is free and carries no commitment.