How to Write Chatbot Instructions That Keep Your Bot On-Brand

Two companies can deploy the same chatbot platform, on the same underlying model, trained on knowledge bases of similar quality, and end up with bots that feel nothing alike. One is crisp and useful. The other is chirpy, over-apologetic, three paragraphs too long, and somehow keeps volunteering opinions about competitors.

The difference is almost never the model. It is the instruction layer, the block of text that tells the bot who it is, what it is for, how to sound, and where to stop. It is the one component of the system that is entirely yours to author, and it is routinely the least considered.

This guide covers how to write that block properly: what belongs in it and what does not, how to specify voice in terms a model can actually execute, what the academic literature says about how human a bot should sound, and the disclosure requirements that stopped being optional in August 2026.

The Instruction Layer Is Not the Knowledge Base

Start with the division of labour, because getting it backwards is the most common structural mistake.

The knowledge base holds facts. Prices, policies, product behaviour, hours, procedures. It is retrieved at query time and it changes when your business changes.

The instruction layer holds behaviour. Identity, scope, tone, formatting, boundaries, escalation triggers. It is constant across every conversation and it changes when your positioning changes.

Teams reliably violate this. They paste the pricing table into the system prompt, where it becomes stale within a quarter and invisible to any content review process. Or they write "always be helpful and friendly" into the knowledge base, where retrieval will surface it only if a customer happens to ask about being helpful and friendly.

The test is simple. If a fact would need updating when the business changes, it belongs in the knowledge base. If a rule should apply to every answer regardless of subject, it belongs in the instructions. Facts that end up in the prompt are also the facts most likely to end up in a wrong answer, which is one of the quieter contributors to chatbot hallucination.

The Seven Blocks of a Working Instruction Set

A production instruction layer has a predictable structure. Each block answers a different question, and skipping one leaves a gap the model fills with defaults you did not choose.

Written out, that is usually 400 to 900 words. Shorter than that and the model is improvising. Much longer and the instructions start contradicting themselves, which is worse than being brief, because a model resolving a contradiction picks unpredictably.

Writing Voice in Terms a Model Can Execute

Here is the instruction most teams write:

Be friendly, professional, and helpful. Represent our brand voice.

That has no operational content. "Friendly" is not a behaviour, it is a category, and the model resolves it to the average of every friendly assistant it has ever seen, which is why so many bots sound identical. Brand guidelines written for humans have the same problem: a copywriter reading "confident but never arrogant" knows what to do because they have taste, and a model does not.

Voice becomes executable when you convert it into four concrete things.

1. Rules stated as behaviours, not adjectives.

Answer the question in the first sentence, then add context. Use the customer's own words for their problem. Write at a reading level a busy person can scan. Never open with an apology unless something actually went wrong.

2. A vocabulary list, both directions. Say the terms you use, and the ones you do not.

Say "plan", not "package". Say "credits", not "tokens". Never say "unfortunately", "kindly", "as an AI", "I apologise for any inconvenience", or "please note".

The banned list does more work than the approved list. Most of what makes a bot sound off-brand is a small set of filler phrases that a single prohibition removes from every answer at once.

3. Two or three worked examples. A short exchange showing the register you want, and one showing what you do not, teaches more than a paragraph of description. Models follow demonstrated patterns considerably better than they follow abstract descriptions of patterns.

4. Hard limits on length and shape. "Keep answers under 120 words unless the customer asks for detail. Use a numbered list only for sequential steps. Never use more than one emoji per conversation, and none in a first reply."

The reason this works is that every one of those is checkable. You can read an answer and say whether the rule was followed. If a line in your instruction set cannot be checked that way, it is decoration, and you should delete it or rewrite it until it can.

How Human Should It Sound?

There is a real research literature here, and it does not point where marketing intuition points.

The consistent finding is that anthropomorphic design, meaning human-like names, avatars, conversational style, and social language, raises perceived warmth and social presence, and that warmth and competence together mediate satisfaction. A study in Sage Open on perceived warmth, competence, and social presence in AI chatbots found both dimensions driving engagement and satisfaction, and socially oriented communication styles producing higher warmth perceptions than task-only styles.

The important qualification arrives when the bot fails. Research on anthropomorphic design and switching intention after service failure found that a highly human-like bot sets expectations high, and when it then fails to resolve the issue, the expectation violation drives customers away harder than a plainly mechanical bot would have. The more human it seems, the more the failure costs.

The practical reading for an instruction layer:

• Warmth is worth having. Acknowledge the problem, use plain human sentences, do not write like a form letter.
• Do not manufacture a personality that implies capability you do not have. A bot with a first name, a photo, and casual banter is promising a colleague. If it cannot process a refund, it should not sound like someone who could.
• Competence reads as warmth more reliably than warmth does. Answering correctly in one sentence beats a paragraph of empathy attached to a wrong answer. The anatomy of a good chatbot response is mostly about this trade.

The Disclosure Block Is No Longer Optional

Consumers have been asking for AI disclosure for years, and most organisations have been ignoring them.

As of 2 August 2026, in the EU it is also law. Article 50 of the EU AI Act (Regulation (EU) 2024/1689) imposes transparency duties directly on providers and deployers of systems that interact with people, regardless of whether the system is classified as high-risk. In plain terms, a chatbot has to identify itself as a machine. Notably, Article 50 was left out of the Digital Omnibus package that deferred the Annex III high-risk timeline to December 2027, so its obligations applied on the original schedule and national market surveillance authorities can enforce them now. A transitional grace period runs to 2 December 2026 for the marking and detection duties on systems placed on the market before August.

If you serve EU customers, your instruction layer needs a disclosure block. Even if you do not, the survey data above says roughly nine in ten of your customers want one anyway.

What that block should contain:

You are an AI assistant. If a customer asks whether they are talking to a human, say plainly that you are an AI assistant for [company], and offer to connect them with a person. Do not claim to be human, do not use a human first name in a way that implies you are one, and do not deflect the question.

One nuance worth naming honestly. An academic study of chatbot disclosure and customer purchases found that disclosing bot identity before a sales conversation reduced purchase rates substantially. That finding gets cited as an argument against disclosure. It is now an argument about compliance risk rather than an option, and the practical lesson is different anyway: the drop came from disclosure that arrives as a bare warning label. Disclosure paired with immediate demonstrated competence, and with a visible route to a person, is a different experience from disclosure alone.

The Boundaries Block Is Where Money Is Saved

Voice is what people notice. Boundaries are what keeps a bot out of court.

Every business has statements that are cheap to make and expensive to have made. A short, explicit prohibition list handles nearly all of them:

• No promises the business has not made. No exceptions to policy, no discount not published, no "we can probably do that for you".
• No forward-looking statements. Nothing about upcoming releases, dates, or features, however often customers ask.
• No comparative claims about competitors. Describe your own product; decline to characterise anyone else's.
• No legal, tax, medical, or financial advice. Even when the model plainly could produce something plausible.
• No handling of individual account actions in chat. Cancellations, refunds, and data deletions route to an authenticated flow or a human.
• No repetition of customer-supplied personal data beyond what is needed to answer, and never into the transcript summary.

Each line is one sentence. Together they remove most of the categories where a wrong answer becomes a liability rather than an annoyance.

Common Instructions That Quietly Do Nothing

Some of the most-copied lines in system prompts have no measurable effect. They are worth deleting to make room for instructions that do.

The pattern is consistent. Instructions that name an abstract quality get ignored; instructions that name an observable behaviour get followed.

Test the Instructions the Way You Test the Answers

An instruction set is a hypothesis about behaviour, and it deserves the same treatment as any other change to the bot. The mechanism is a small fixed test suite, run before and after every edit.

1. Build a voice set of 15 to 25 prompts. Include an easy factual question, an angry customer, a question outside scope, a request for a discount, "are you a real person", a request for legal advice, a vague one-line question, and a question whose answer is not in the corpus.
2. Record the answers before the change.
3. Make one edit. One block, not the whole file.
4. Re-run and diff. Read for tone drift as well as correctness. Adding a rule about length routinely damages the tone of the escalation message, which nobody notices until a customer sees it.
5. Keep the file in version control with a one-line note on why each change was made.

That last point sounds bureaucratic and pays for itself the first time a bot starts behaving oddly and nobody can remember what changed. The same pre-launch testing discipline applies here, just at a smaller scale and more often, because the instruction layer is the part people edit casually.

A Worked Skeleton

Putting the blocks together, with placeholders where your specifics go:

Identity. You are the AI assistant for [company], which [one-line description]. You speak as part of the [company] team, using "we".

Scope. You answer questions about our product, plans and pricing, billing, onboarding, and integrations. Anything else goes to a human.

Grounding. Answer only from the retrieved context. Never state a price, limit, date, or policy detail that is not in the context. If the context does not contain the answer, say you do not have that information and offer a handover.

Voice. Answer in the first sentence, then add context. Plain language, active voice, no filler. Say "plan" not "package". Never write "unfortunately", "kindly", "as an AI", or "I apologise for any inconvenience". Do not open with an apology unless something went wrong.

Format. Under 120 words unless more is requested. Numbered lists only for sequential steps. Link to the source page when one exists. No emoji in a first reply.

Boundaries. No promises outside published policy. No roadmap or release dates. No claims about competitors. No legal, tax, medical, or financial advice. No account actions in chat.

Disclosure. You are an AI assistant. If asked whether you are human, say so plainly and offer to connect the customer with a person.

Escalation. Hand over when the customer asks for a human, when they are clearly frustrated, when the question is out of scope, or when you do not have the information. Say what you are doing and what happens next.

Roughly 250 words of skeleton, which will grow to 500 or so once your specifics are filled in. That is the right order of magnitude.

Where the Platform Fits

The instructions above are text, and any platform can hold text. What varies is whether the surrounding behaviour is configurable or hardcoded: whether abstention actually triggers a handover, whether the disclosure line survives a conversation, whether you can edit instructions without a deployment, and whether you can read transcripts afterwards to see which rule got ignored. Paperchat keeps the instruction layer editable in the dashboard and wires escalation to it directly, so the "offer a handover" line in the prompt corresponds to a real route to a real person rather than a sentence the bot says into the void.

The Bottom Line

The instruction layer is small, cheap to change, and disproportionately responsible for whether a bot sounds like your company or like every other bot on the internet. Treat it as a written artefact with structure rather than as a paragraph you paste once.

Separate behaviour from facts. Convert adjectives into checkable rules, a banned-phrase list, and two examples. Keep warmth but do not promise a colleague you cannot deliver. Add the disclosure block, which is now a legal requirement in the EU and an expectation nearly everywhere else. Write the boundaries down as prohibitions, because that is the block that saves money. Then test each edit against a fixed set of prompts, and keep the file under version control so the question "what changed" always has an answer.