Chat widget greeting: prompt and first sentence

An assistant greets its visitor twice, and most operators only notice this when both greetings say the same thing. One sits next to the closed button and argues for the click. The other sits inside the open window and sets the frame for everything that follows. In XICBOT these are two separate fields with two separate jobs, two lengths and two maintenance paths – this article describes what belongs in which.

Enlarge graphic

Labels in the illustration

• Before the click: the prompt
• Questions about delivery? I can
• check which date applies to your
• postcode.
• x
• Delayed, once per visit,
• with a way out of it.
• After the click: the first sentence
• Hello, I am the assistant of this
• business and I answer from the
• material stored here.
• For contracts and invoices I bring
• in a person.
• Part of the version, shown only in
• an empty conversation.
• What the prompt has to do
• Name an occasion that fits the page it appears on. A
• bare hello is an interruption without a return, and the
• visitor is right to close it away.
• What the first sentence has to do
• Say who answers here, what the answers rest on and
• where the limit runs. It is the only place where the
• frame is set before the first question is asked.
• Where both of them fail
• For the same reason: one text is written for both
• places. Then the opening advertises instead of
• explaining, and the prompt explains instead of asking.
• Two fields, two jobs, two maintenance paths: the prompt on the assistant, the first sentence in its published version.

Two greetings: beside the button and inside the window

Why there are two greetings

Between the closed button and the open window sits a decision by the visitor. Before that decision the assistant knows almost nothing about them: which page they are reading, and no more. After the decision the visitor has declared an intent, and the question is no longer whether they want to talk but what they can talk about. Two situations that different need two different sentences.

That is why XICBOT keeps them apart. The prompt belongs to the assistant itself and takes effect as soon as it is saved. The first sentence belongs to the published version and travels with it – alongside persona, tone, topic scope and handover rule, as described in the article on the system instruction.

The prompt beside the button

The prompt is a small speech bubble that opens next to the closed button after a configured wait. It has its own close control, disappears as soon as someone opens the window, and does not return within the same page view. Dismissing it means dismissing it – that is half the work for an overlay that does not read as harassment.

In substance it is not a greeting but an offer. „Hello“ costs the visitor attention and returns nothing. „Questions about delivery? I can check which date applies to your postcode“ names an occasion that fits the page the bubble sits on. The difference is not politeness, it is occasion. How the placement itself works is covered in the article on placing the chat widget.

• It names an occasion that actually exists on this page – not a general invitation.
• It speaks in the assistant's own voice, not as a marketing line from the company.
• It fits into two short lines. Anything longer is cut off on a phone or covers the content.
• It does not ask a question the assistant cannot then answer.
• It promises information, not processing.

The first sentence in the window

As soon as the window is open and no message is in it yet, the assistant posts its first sentence as its own bubble. It appears only in an empty conversation: someone who changes pages and returns with a running conversation does not read it a second time. That makes it not a greeting ritual but the opening of a record.

Its job is the frame. At that moment the visitor does not know whether they are writing to a person, what the answers rest on, or what happens when their question goes beyond that. All three points fit into a pair of sentences shorter than it sounds.

• Who is answering: the assistant of this business, explicitly named as a machine.
• What the answers rest on: the material stored in the knowledge base, not the general world knowledge of a language model.
• Where the limit runs: which matters go to a person, and that this route is open.
• What the visitor can do: ask a question – no form, no sign-up, no precondition.

What belongs in neither greeting

Both fields are short, and brevity invites filling them with whatever seems important at the moment. Some of that belongs somewhere else, some of it does not belong in the chat at all.

• Legal text. Consent for contact data is its own gate before the first conversation, not a subordinate clause in the greeting – see consent in chat.
• Opening hours and availability. They go stale faster than the version and are better placed in the knowledge base, where the assistant reads them while answering.
• Lists of topics. Naming six areas turns the bubble into a menu; the visitor does not read it, they close it.
• A name that suggests a person. A first name with no hint of the machine is exactly the confusion the disclosure duty is meant to prevent.
• Numbers and commitments. Anything here stands without a source and without context – both belong on the page, not in a speech bubble.

The converse matters just as much: what the assistant can back up belongs in the answer, not in the greeting. What a sourced answer looks like is covered in the article on citing sources in chat.

Delay and intrusiveness

The prompt has a wait, and the wait is the real lever. At zero no bubble appears – that is quiet operation, where the button stands on its own. Any value above it is a claim about when a visitor is ready to be interrupted. The upper bound is ten minutes; beyond that nobody is still on the same page.

Too early and the bubble reads like a pop-up and is closed by reflex. Too late and it only reaches those who were staying anyway. The usable range is where someone has read the page and starts to hesitate – and that is a different point on a pricing page than in an advice article.

Greeting and accessibility

An overlay that appears on its own is an event for a screen reader. If it appears unannounced, the visitor hears nothing; if focus jumps into it, they lose the place they were at. Both are avoidable, and both happen when a speech bubble is thought of purely as a design element.

In XICBOT the prompt is emitted as a status message: it is read out when it appears, without moving focus. Its close control is reachable by keyboard and labelled. The first sentence in the window is an ordinary message in the transcript and needs no special handling – it sits where all messages sit. The wider frame is on the accessibility page and in the article on the accessible assistant.

• The prompt announces itself as a status, without stealing focus.
• It can be closed with the keyboard and stays closed.
• It does not appear while the window is open – two simultaneous addresses would be two simultaneous speakers.
• The first sentence sits as a normal message in the transcript and is therefore readable without detours.

Greetings in two languages

An assistant that answers in two languages has to greet in two languages as well. The version carries its language as its own property, and the first sentence belongs to it – a German version greets in German, an English one in English. Maintain only one field and you get a greeting that does not match the answering language.

For the prompt at the button the situation is simpler, because it belongs to the assistant and not to the version: anyone running a site in two languages usually runs two assistants anyway, each with its own knowledge base. The route is described on the multilingual assistant page and in the article multilingual assistant.

The first sentence belongs to the version

The first sentence does not sit beside the system instruction, it is part of the same version. That has a consequence that matters day to day: it does not change while a conversation is running, and it can later be read back together with everything else that belonged to that version. A conversation records which version it was held under, even when that version is long since not the active one.

This makes a greeting verifiable. If someone asks months later what the assistant said about itself on the day in question, the answer is not a memory but a record. That does not hold for the prompt at the button – it applies from the moment it is saved and carries no history. That is the price of being changeable without an approval run.

How we go about a new greeting

The order is not arbitrary. Starting with the prompt means writing an invitation to a conversation whose limits nobody has set yet – and having to walk it back later. Starting with the frame means knowing, while writing the prompt, what may be promised.

• First define the topic scope and the handover rule. Both live in the same version as the first sentence.
• Then write the first sentence: who answers, what from, and where the handover goes. Two sentences are enough.
• Then phrase the prompt per page type, with an occasion the frame covers.
• Set the wait and look at the bubble on a narrow screen, not only in the preview pane.
• Publish the version and hold a test conversation – the first sentence only appears in an empty conversation, a running test will not show it.
• After the first conversations, read where visitors turn away; a badly chosen occasion looks like a lack of interest in the analysis.

Where the prompt and the version sit in the admin area is shown in the documentation under assistants. If you want to try both on an assistant of your own, create an account for it.

Frequent questions