How Should a Chatbot Tell Visitors It Is Not a Person?

Four messages into the conversation, the visitor types: "am I talking to a real person?" That question is expensive. Whatever the answer is, the visitor has now spent four messages deciding how much to trust the last three, and if the answer turns out to be no, everything said before it gets reread in a worse light.

The fix is not subtle and it is not new. Say it first. What is genuinely worth arguing about is the wording, because the three common approaches to AI disclosure produce different conversations. A disclosure is not a warning label, it is an instruction manual: it tells the visitor what kind of question to ask, which is the single biggest determinant of whether they get a useful answer.

The position taken here is that clear disclosure improves outcomes rather than costing them, and that teams who hide it are protecting a metric at the expense of the conversation. That claim needs defending, so this piece compares three wordings, covers placement and persistence, and then deals with the part most implementations skip entirely: the route to a person.

Why teams resist disclosure, and why the reasoning fails

The unstated worry is engagement. If visitors know it is a machine, some will not bother. That is true, and it is the wrong thing to optimise, because the visitors who leave on seeing the word "automated" were mostly going to leave two messages later anyway, having asked something the assistant could never answer and formed a poor opinion of the company on the way out.

The second worry is tone. Teams have been told for a decade to sound human, so a flat statement of machine-ness feels like a step backwards from a brand voice they worked hard on. It is not, provided the sentence is written rather than generated. A disclosure can be warm, brief and confident. What it cannot be is buried.

The third worry is regulatory, and it is the only one with a real deadline attached. Disclosure requirements are tightening in several jurisdictions, and a widget built to hide its nature is a widget you will rewrite. We would rather write the sentence once, in your voice, than have it added later by whoever is holding the compliance list. Our own position sits on the responsible AI page, and it is deliberately short.

Three wordings, compared on clarity, tone and trust

Almost every chat widget on the web uses one of these three. They are not equally good, but the reasons are more interesting than the ranking.

One: the persona with no disclosure

A human first name, a photograph or an illustrated avatar, and an opening line written in the first person. "Hi, I am Maya. What brings you here today?" No statement of what it is, on the theory that nobody asks and everybody prefers it that way.

It works until it does not, and the failure is expensive because it is a failure of honesty rather than capability. A visitor who believes they are talking to Maya, then discovers otherwise when the assistant loops on a question a person would have understood, does not think "that assistant was limited". They think they were misled. That impression attaches to the company, not the widget, and it survives the conversation.

Two: the badge

A small label near the name reading "AI", "bot" or "automated assistant". Technically present, visually quiet, and often set in the smallest type on the page. This is the most common approach because it satisfies a checklist without changing anything else.

A badge answers the question "is it disclosed" and fails the question "did anyone read it". It carries no information about what the assistant can do, so the visitor still has to discover the boundaries by hitting them. And it degrades badly: when the conversation is summarised into an email or a support ticket, the badge does not travel with the words.

Three: the plain first message

One or two sentences, sent as the opening message, naming what it is, what it draws on, and how to reach a person. Something like: "This is an automated assistant. It answers from what is published on this site, and can pass you to the team at any point." Plain, unfussy, and it teaches the visitor what to ask in the same breath as what it is.

This is the one we recommend and the one that changes conversations, because it converts an unbounded expectation into a bounded one before the first question is typed. It is also the only version that survives being copied into an email.

The four things a disclosure has to carry

Most disclosures contain one thing and need four. Each of the missing three is what turns a label into something useful.

• What it is. An automated assistant, in words a person uses. Not "conversational agent", not a product name nobody knows, and not a wink.
• What it draws on. Published pages, documentation, a product catalogue. This one sentence prevents a whole category of disappointed question, because it tells the visitor where the edges are.
• What it cannot do. It cannot see an account, change an order, quote a price for bespoke work or make a commitment. Say so before it is asked, not after it has guessed.
• How to reach a person. Present from the first message, not offered as a consolation after two failures. This is the part that makes the other three safe to say.

Getting the second and third right depends on knowing what the assistant genuinely handles, which is an evidence question rather than a copywriting one. If you have not yet built the set of questions you expect it to answer correctly, start there instead: building an evaluation set before you trust a model describes the work, and it is what lets you write a specific disclosure rather than a vague one.

Placement, and staying disclosed after the first message

The three places it belongs

Placement is simple and usually done wrong. The disclosure belongs in the first message of the conversation, in the accessible name of the widget itself, and in the header that stays visible while the visitor scrolls. Three places, because each covers a different arrival: the person who reads the opening, the person using a screen reader, and the person who scrolled past it and came back an hour later.

Surviving the second visit

Persistence is the part almost everyone skips. A conversation is not a single moment. It gets reopened after a page change, resumed the next day, emailed as a transcript, pasted into a ticket, and read by a colleague who was not there. If the disclosure lives only in a message that has scrolled away, none of those readers have it. Put it in the header, carry it into the transcript, and repeat it plainly whenever the assistant resumes after a gap.

One more transition deserves the same care, in the opposite direction. When a human does take over, say so with the same clarity. Silence at that moment produces a visitor who keeps typing to the machine, or one who assumes a colleague read everything above when nobody has. A single line, in the transcript, in both directions. A chat interface that behaves properly for everyone is part of the accessibility commitments this site holds itself to.

The handoff is the load-bearing part

Disclosure without a route to a person is just a disclaimer. The reason a plain first message works is that it comes with an exit, and the exit is what makes the honesty affordable. Here is the sequence worth implementing.

1. Detect the trigger early. A repeated question, a rising tone, an explicit request, a topic on your escalation list, or two consecutive answers that did not resolve anything. Do not wait for frustration to become obvious.
2. Offer the person, do not hide the offer. A visible control, present throughout, worded as an option rather than an admission of failure.
3. Say what happens next, honestly. Whether someone is available now or the message goes into a queue. Never promise a response time the team has not agreed to, and never imply live coverage that does not exist.
4. Carry the context across. The person picking it up should see the conversation, not a subject line. A handoff that makes the visitor repeat themselves is worse than no handoff, because it wastes the trust the disclosure just bought.
5. Ask only for what is needed to reply. Every extra field at this moment is a reason to abandon, which is the same argument that governs how many fields a contact form should have.

A widget that carries contact and conversion actions alongside its answers makes this straightforward rather than bolted on. Flidu takes that shape: website-informed assistance plus contact and information actions in one lightweight widget, so the route to a person is a control rather than a dead end. Our parent company covers the moment an answer stops being sufficient in when an answer is not enough.

Why disclosure improves outcomes instead of costing them

The mechanism is behavioural, not ethical, which is why the argument holds even for teams who only care about results. People ask a machine different questions from the ones they ask a person, and the machine-shaped questions are the ones an assistant can actually answer.

Told it is automated, a visitor asks shorter, more factual things: delivery times, specifications, whether a service covers a particular case. Believing it is a person, the same visitor writes a paragraph of context, buries the question in the middle, adds an emotional register the assistant cannot interpret, and expects judgement rather than retrieval. Same visitor, same intent, two completely different hit rates.

Disclosure also changes how a wrong answer lands. A labelled assistant that gets something wrong is a tool with limits, and the visitor asks for a person. An unlabelled one that gets the same thing wrong is a company that gave bad information. The failure is identical; the interpretation is not. Where wrong answers come from in the first place is a separate subject, treated directly in why a chatbot gives wrong answers.

An assistant that says what it is gets asked the questions it can answer. That is not a compliance benefit. That is the whole design.

The concession: disclosure does not repair a bad assistant, and it can make a bad one look worse, because a stated boundary the assistant then fails inside is a promise broken in public. If yours cannot reliably answer the things the disclosure claims it covers, fix that before writing the sentence. Honesty raises the standard you are held to, which is exactly why it works.

Where we would start, and what we would not build

Write four sentences before writing any code: what it is, what it covers, what it cannot do, and how to reach a person. Show them to somebody in support, because they will delete the third one and replace it with the two things people actually ask that the assistant cannot handle. That edit is the most useful hour in the project, and it is closer to conversion work than to engineering.

Then decide what stays manual. An assistant that answers published questions and routes everything else to a person is a smaller, more defensible system than one attempting judgement, and it is the pattern we argue for in what to safely automate in a small team. Turning that from a demo into something dependable is a separate discipline again, covered in prompt to production.

What we would not build: a persona with a human name and a stock photograph, a disclosure that appears only after the visitor asks, or an escalation path that requires two failed answers before it unlocks. Each of those spends trust to protect a number, and the trust does not come back on the schedule the number does.

The reversal condition, since every rule has one: if your assistant exists purely to collect a name and a message, with no attempt to answer anything, a long disclosure is theatre. Say it is a form, make it a form, and stop. If you are somewhere between those two shapes and want a view on which one you are building, describe what it is meant to handle and what happens today when it cannot. The integration work that follows should be scoped from that answer, not from a feature list.