Plain Language in the Assistant: Answers Everyone Understands

A chat answer is usually read once, often on a phone, often in passing. Whatever is not understood on first reading comes back as a follow-up question, as a phone call or not at all. Plain language starts right there: short sentences, familiar words, one statement per sentence, technical terms with an explanation, numbers and deadlines without arithmetic. This article first shows how plain language differs from Easy Language and what the law says about comprehensibility and what it does not. It then covers rules in the system instruction and in the sources that produce understandable answers. Finally, it shows how test questions and feedback reveal whether the answers land.

Enlarge graphic

Labels in the illustration

• Before: one sentence from the source
• After: one statement per sentence
• Returns must be made using the
• enclosed returns slip within the
• return period, whereby the costs of
• return shipping shall be borne by
• the buyer unless otherwise agreed.
• One sentence, five items:
• action, document, deadline,
• cost and exception
• split up
• Action
• Return the item as follows:
• Document
• Use the returns slip from the parcel.
• Deadline
• Send it within the return period.
• Cost
• You pay for the return shipping.
• Exception
• Agreed otherwise? Then the agreement applies.
• The exception stays: plain does not mean shortened
• Language levels: from hard to easy to access
• Technical language
• contracts, data sheets
• Standard language
• typical website copy
• Plain language
• default for chat answers
• Easy Language
• only from checked texts

One long sentence, five clear ones

What plain language means in a chat

Plain language is understandable standard language. It does not do without content, it does without detours: a sentence carries one statement, the verb comes early, the person acting is named, and a word that not everyone knows is explained or replaced. A chat adds a particular situation. The answer appears in a narrow window, often on a phone, and is read while the visitor is actually doing something else: completing an order, reporting damage, looking for an appointment. Anyone who has to read a sentence twice at that point asks a follow-up question or gives up.

More people benefit from understandable answers than one might first assume. They include people with reading difficulties or cognitive impairments and people reading in a second language. They also include older people, people under stress and experts for whom a clear answer saves time. This article deals with the language of the answer. How the chat window itself becomes operable, with keyboard, screen reader, contrast and zoom, is described in the article on the accessible AI chat assistant.

Plain language and Easy Language: two levels

In everyday use the two terms are often confused. Easy Language is the stricter level. It is aimed mainly at people with learning difficulties and follows a fixed rulebook. Sentences are very short, usually without subordinate clauses. Long words are visibly split, and pictures support the text. Often people from the target group check the text before it is published. Plain language is less strictly regulated. It stays closer to standard language, allows the occasional subordinate clause and addresses a broad audience. The German Disability Equality Act also distinguishes the two levels, there for federal public bodies:

According to the next sentence, they should on request explain decisions and forms in particular in a simple and understandable way. If that is not sufficient, subsection 2 of the same provision says that they should, on request, explain decisions, general rulings, public-law contracts and forms “in Easy Language”. The provision applies to public authorities, not to businesses. For a company with a chat assistant it is therefore not an obligation, but it is a useful pattern: first simple and understandable, and where that does not suffice, a version written specifically in Easy Language.

What the law requires on comprehensibility

For services covered by the German Accessibility Strengthening Act (BFSG), comprehensibility is part of accessibility. The act requires that people with disabilities can use an offering in principle without outside assistance. That comprehensibility is part of this is laid down in the ordinance implementing the act. The provision in the act reads:

The ordinance implementing the act refers explicitly to this provision. Under Section 12 no. 2 (c) BFSGV, information about how a service works must be “presented in an understandable way”, and under no. 3 websites including their associated online applications must be designed to be “perceivable, operable, understandable and robust”. Section 12 names no language level for this. The ordinance does draw a line for consumer banking services: information on how they work must not exceed the difficulty of language level B2 (BFSGV Section 17, subsection 2) of the Common European Framework of Reference for Languages. That limit applies to banks and cannot be transferred to every shop or service provider. In addition, Section 3(3) BFSG exempts micro-enterprises that offer or provide services from the obligation under subsection 1.

Independently of the BFSG, a duty to use clear language applies wherever the chat informs about the processing of personal data. Article 12(1) GDPR requires the prescribed information to be provided “in a concise, transparent, intelligible and easily accessible form, using clear and plain language”. This concerns the privacy notices that the widget displays or links to. How such notices fit into the narrow chat window is described in the article on consent in chat.

Rules for understandable answers

The following rules apply to any text that is meant to be read. In a chat they carry more weight, because space is tight and nobody scrolls back. They can be written into the system instruction and applied in the sources; both follow further below.

• Short sentences: a sentence that runs over several lines in the chat window can usually be split.
• One statement per sentence: action, condition and exception each get a sentence of their own.
• Familiar words first: “send back” rather than “initiate a return”, “invoice” rather than “billing document”.
• Explain technical terms where they have to stay: the first time they appear, in a few words.
• Active voice and direct address: “You will receive an email” rather than “An email will be sent”.
• Most important first: the answer to the question first, then reasons and details.
• Resolve negations: “We take the goods back if …” rather than “A return is not excluded provided that …”.
• Name steps one at a time, in the order in which the visitor carries them out.
• Spell out abbreviations that not everyone knows: “excluding” rather than “excl.”.

Stating numbers, deadlines and amounts unambiguously

Numbers are the point in a chat where misunderstandings become particularly costly. A misunderstood deadline leads to a late return, a misread amount to a complaint. A number is understandable when the visitor does not have to calculate, look anything up or guess what it refers to.

• Digits for quantities, dates and amounts: “3 working days” is usually taken in faster than “three working days”.
• State a reference point: not “in 3 working days” but “3 working days after dispatch”.
• Define terms that are understood differently: whether a “working day” includes Saturday has to be stated in the source, otherwise the answer cannot say it.
• Where possible a day instead of a period: if the day is fixed, the answer names it together with the weekday.
• Amounts with what they refer to: one-off or per month, with or without shipping, with or without VAT.
• One number per sentence, if several numbers together would add up to a calculation.

System instruction and brand voice

The system instruction is the place for rules that apply to every answer. It states the form in which the assistant answers, not what it says in substance; that comes from the sources. Language rules can be phrased so that they can be checked against an answer. “Write clearly” cannot be checked, “Give the answer to the question first” can. How a system instruction is structured as a whole and where its limits lie is covered in the article on the system instruction. Checkable language rules might read like this:

• Start with the answer to the question, then add the details.
• Write short sentences with one statement each.
• Address the visitor directly and politely, and say who does what.
• Explain a technical term the first time it appears, using the words from the source.
• State deadlines with a reference point and amounts with what they refer to.
• If the visitor asks for a simpler explanation, give the same information more briefly without dropping a condition.
• List steps one at a time, in the order in which they are carried out.

The brand voice determines how a business sounds: formal or warm, brief or detailed. Comprehensibility is independent of that. A warm voice can be convoluted, a matter-of-fact one very clear. The two can be combined as long as the voice is not built from stock phrases: an “Of course, we will be happy to help you” before every answer costs a line without saying anything. How a voice can be defined is described in the article on brand voice. Every instruction has a limit: if the source is written in bureaucratic language, it usually shows through in the answer, because an assistant that is bound to its sources stays close to their wording.

Clear sources as the most important lever

An assistant that answers from a knowledge base adopts its terms, its order and often its sentence structure. It can rephrase, but every rephrasing is an opportunity to shift the meaning, especially with conditions, deadlines and exceptions. It is more reliable to write the source itself in an understandable way. The assistant then has little to translate, and what it says stays close to what was checked. Which content belongs in the knowledge base in the first place is shown in the article on building the knowledge base.

• Headings as questions in the customers’ language: “How do I send something back?” rather than “Returns processing”.
• The first sentence of a section answers the question in the heading.
• Technical term and everyday word stand side by side: “instalment, that is, the monthly advance payment”.
• Conditions and exceptions are separate sentences, not insertions.
• Numbers carry a unit and a reference point; terms such as “working day” are defined once.
• Recurring technical terms also appear in a section of their own with a short explanation.

Multilingual answers as a complement

Plain language helps people reading in a second language, and an answer in their own language can help even more. The two do not exclude each other. An assistant that answers in the language of the question translates from the sources as it does so, and the same applies here: a clear source text can usually be rendered more reliably than a convoluted one. XICBOT determines the language of each message before the answer is generated and answers in that language from the same knowledge base; if detection remains uncertain for very short messages, the language of the conversation applies. The page on the multilingual assistant describes how this works.

Checking with test questions and feedback

Whether answers are understandable cannot be decided at the author’s desk: whoever wrote the source understands it. Test questions that sound like real visitors are what tells you something: everyday words, short, with typos, without the technical term from the source. Add a second question in the same conversation: “Can you put that more simply?” The second answer shows whether the assistant can simplify without losing a condition. Such questions belong in the fixed acceptance test, as described in the article on test cases before go-live.

In live operation, visitor feedback is added. A “no” to the question of whether an answer helped does not on its own say what went wrong. The transcript often shows it. If an answer is followed by the question “What does that mean?”, it was probably not wrong but unclear. Such follow-up questions can be searched for specifically and grouped by topic. How ratings are collected and evaluated in the chat is described in the article on feedback in chat.

What XICBOT brings to this

With the default setting, XICBOT answers exclusively from your documents and usually names the excerpts it used. The excerpts go into the request numbered, and the instruction requires the number of the source location used to appear in the answer text. An answer without a source reference is recorded as a gap. If no excerpt supports the answer, the assistant says that nothing on the topic is stored. The operator can relax this setting per assistant version. For the language of the answers this means: it depends on your sources. What is clearly written there can go out clearly; an explanation that is missing there is not covered. Technical terms that are to be explained therefore belong in the knowledge base together with their explanation.

The search works on words, not on meanings. A section that contains only the technical term may not be found by a question in everyday words, which is one more reason to write the everyday word into the source. For information that should go out exactly as you wrote and checked it, you store a maintained question-and-answer pair using the words visitors actually use. Its wording usually goes out unchanged, without a model call. Where an answer names its source location, the way to the original remains open. During setup we test typical questions from your customers, check the answers against the sources and sharpen wording and tone. If you would like to review your sources for comprehensibility, get in touch via contact.

Frequent questions