Articles

Letting AI answer customers: where the line is

Three tiers of customer-facing answers, the four facts a model must never produce, and the log that makes a wrong answer findable after the complaint.

By Anes Hamdaoui6 min read
  • ai
  • support
  • customers
All articles

An answer to a customer is a promise, and a promise needs a person who can be held to it. A model writes the sentence; it cannot carry the consequence, so the line is not how good the writing is but who answers for it when it is wrong. The tool that may explain how to track an order must not be the one that says when the order arrives, even when both questions arrive in the same minute.

Which questions may be answered without a person?

One class: questions whose correct answer is a page you already publish, in its own words, and where being wrong costs the customer a second question rather than money. Opening hours, the documents needed for a return, what a product includes — each has an owner, a page and a version, and the assistant's job is to find that page and hand it over.

The class shrinks the moment the answer depends on this customer. Their order status, their balance, whether the item is on the shelf in Blida this afternoon: the words exist, but the number they rest on moves while the page stays still.

What are the three tiers?

Three, and they differ in what leaves the building, not in how capable the tool is.

Tier What the customer receives Where it belongs
Draft only Nothing, until a person sends it Complaints, negotiation, anything about money
Answer with its source The answer and the page it came from Published procedures, product facts, hours
Answer freely A paragraph nobody checked Nowhere a customer can quote back

Draft-only is where most businesses should start. The middle tier is the only one that scales, and its source is not decoration: a customer who can open the page stops arguing, and you can audit the answer later. The third is not a tier; it is a decision to accept whatever comes.

Why must four facts never be generated?

Price, availability, delivery time and refund policy. Each is a fact the customer will repeat back to you as your own words, and each changes without the sentence describing it changing.

Price. It lives in a price list, a quotation and a discount agreement, and the assistant reads whichever the search returned. The catalogue price is what it quotes to the customer who negotiated something else.

Availability. Stock is a number that moves all day. The assistant answers from an index built last night; the shop had four this morning and has none now.

Delivery time. It depends on the courier, the wilaya and the shelf, and it becomes a date in the customer's calendar the second it is written.

Refund policy. Legal text with conditions. A paraphrase is a new policy, offered by a business that never agreed to it.

The rule: these four are looked up in the system that owns them and quoted exactly with that record's timestamp, or the question goes to a person. Naming whoever can confirm is a pointer, not a promise.

How do you make "I do not know" cheap?

Build the refusal as a route, not a failure. It says what it looked for and did not find, offers what it can still do — pass the question to a person, or show the nearest page it found — and does not ask the customer to rephrase.

A wrong answer and a right one look identical: same length, same confidence, no visible seam. The customer cannot tell them apart, and the business learns about the wrong one only when it comes back quoted. A refusal is visible to both sides at once.

It also has to be cheap internally: a refusal that lands in a dashboard as a failure gets tuned away by whoever is measured on it. Count refusals as a category of answer with an owner, not a defect.

What must the human see at handover?

The whole exchange, not the last message: the first question, the answer that missed, the sources used, what it could not find, the order or complaint already open on the account, and the tier the answer came from.

A handover that arrives as "customer has a question" is worse than no assistant: the customer has explained twice and waits for someone who starts from zero. It needs a promise attached — who replies, and by when.

What has to be in the log?

The question as typed, the answer as sent, the sources retrieved, the tier, the timestamp, and the name of whoever approved it. NIST's AI Risk Management Framework places accountability and monitoring inside the system rather than around it, and a log is the smallest form that takes.

The test is a complaint you have not received yet. A customer says we told them something, and someone who was not there has to establish in minutes what we said, on what basis, and whether a person approved it. Without the log that becomes an argument about memory. Keep it at least as long as the promise could be enforced: the warranty, the refund window, the delivery date.

How do you put this in place?

  1. Write down the twenty questions customers actually ask, in their words.
  2. Mark each: answerable from a published page, or dependent on this customer's record.
  3. Assign a tier per group; send price, stock, delivery and refund questions to a lookup or a person.
  4. Attach the source to every middle-tier answer, and turn the refusal into a route.
  5. Route the handover with the full exchange, to a queue with one named owner.
  6. Switch the log on before the first customer is served.
  7. Read twenty logged exchanges a week for the first month, and fix the source pages rather than the instruction.

Where this goes wrong

A policy written as prose. Someone adds a paragraph about returns to the knowledge base as ordinary text; weeks later the assistant paraphrases it into a promise the business does not offer, and the first to notice is a customer holding a screenshot.

The refusal rate gets "fixed". A manager reads refusals as failure, the instruction is loosened, and the confident wrong answers return with nobody connecting the two events.

The source changed after the answer. The reply cites a page edited since. The customer opens it, finds a contradiction, and concludes they misread.

Formal Arabic to a customer writing in dialect. Nothing is factually wrong and the exchange still reads as a brush-off — the failure nobody measures, because no rule was broken.

What this does not cover

Nothing here is about choosing a model, writing the instructions, or which channel to put the assistant on, and nothing about what counts as a binding statement in your jurisdiction, which is a question for a lawyer. It also assumes the pages it answers from are current: if the published policy is out of date, no tier and no log rescues the answer.

We build customer-facing assistants that answer from published pages, refuse with a route, and hand the rest to a person who can see the whole exchange.

Services in this article

Start a project

Have something to build?

One short brief is enough. You get a written scope and a fixed quote before anything starts.