The system prompt is the part you actually control
An AI assistant answering questions on your website draws on two things: the content you have pointed it at, and the standing instructions you have written for it. The content decides what it knows. The instructions decide how it behaves when it knows, when it half-knows, and when it does not know at all.
Most teams spend their effort on the first and almost none on the second, then find the assistant is technically accurate and somehow wrong: too long, too eager, too confident, answering questions it should have handed over, or introducing itself in a way that does not sound like the company at all. Nearly all of that lives in the standing instructions, and nearly all of it is fixable in an afternoon.
Start with who the assistant is and who it works for
Open with the plainest possible statement of identity: what this assistant is, which company it works for, and what it is there to do. It sounds too obvious to write down, and it is the single highest-value line in the whole prompt, because everything else is interpreted through it.
Give it the company name and the website. This is not decoration. An assistant that knows the name of the business will use it naturally, will not invent a different one, and will handle who are you far better than one left to infer it from articles.
Say what it is, honestly. An assistant instructed to present itself as an AI assistant will do so consistently, which is what you want both for trust and because pretending otherwise tends to collapse the moment somebody asks directly.
Say what it may talk about, and what it must refuse
The second block is scope. Two questions decide most of it: which subjects are in bounds, and what should happen at the edge.
Keeping the assistant to your own business is the default worth starting from, because a support assistant that will happily discuss anything is both off-message and an easy target for people who want to make it say something quotable. Where you want the line drawn is a product decision rather than a wording one, and there is a separate guide on that below; what belongs in the prompt is the result of that decision, stated concretely.
Be specific about the categories you will not touch. Personalised legal, medical or financial advice, anything that commits the company to a price or a date, and anything requiring identity verification are the usual four. Name them rather than gesturing at sensitive topics, because a vague instruction produces vague refusals.
Then say what a refusal should do. A refusal that dead-ends is worse than no assistant. A refusal that says this needs a person and hands the conversation over is a good outcome, and the assistant will only do it reliably if you tell it to.
Write the procedures, not just the personality
The part teams most often miss is procedures: the small number of things that must happen in a particular order for a particular request. How a refund enquiry should be handled. What to collect before a conversation reaches a human. Which question always needs an order number first.
These are not tone instructions and they are not general knowledge. They are the operating rules a new colleague would be told in their first week, and writing them down is what turns an assistant that answers questions into one that handles requests.
Keep them short and testable. Two lines per procedure, phrased as a sequence, beats a paragraph of context. And keep them out of your public articles, because a procedure is an internal instruction and your knowledge base is not the place for it.
Set the presentation: name, greeting, starters, disclaimer
Around the prompt sits a set of smaller settings that shape the first ten seconds, and they matter more than their size suggests because they are what a visitor meets before anything is answered.
The display name is the assistant's name in the conversation. Pick something that does not imply a human being. There is a separate question about what names your human agents use, covered elsewhere, and the two decisions should be made together so the pattern is consistent.
The welcome message and the opening greeting set expectations. Short, specific and honest beats warm and vague: telling someone what this assistant can help with in one line prevents the questions it cannot handle better than any refusal instruction.
Starter prompts are the suggested questions offered before the visitor types. Treat them as a menu of your best-supported answers rather than a list of what you wish people asked. Three or four, drawn from what your content actually covers well, will lift the quality of the whole conversation because they steer people toward the areas where the assistant is strong.
The disclaimer is one short line saying the assistant can get things wrong. Write it plainly and leave it visible.
Keep answers short on purpose
Length is a setting, and the default instinct is wrong. A long, thorough answer reads well in a review and badly in a chat window, where it arrives as a wall of text on a phone and the visitor scrolls past the part that mattered.
Cap the answer length deliberately and instruct the assistant to lead with the answer rather than the context. A useful test is to read a reply on a narrow screen and ask whether the first sentence would be enough on its own. If the answer genuinely needs more room, the better pattern is a short reply plus a link to the page that covers it in full, which also sends the visitor somewhere they can return to.
The same applies to hedging. An assistant told to avoid unnecessary qualification will give shorter and more useful answers, and will make the cases where it genuinely is unsure stand out instead of blending into a general fog of maybe.
How MyLiveChat fits
MyLiveChat's AI assistant answers from the content you point it at, and the settings described above are all available in the dashboard: a system prompt and a separate procedures field, a business-only scope toggle, a bot display name, a welcome message, an opening greeting, starter prompts, a disclaimer line, your company name and website, business hours text, a maximum answer length, and controls for when the AI replies and when it hands over to a person.
Two behaviours are worth knowing because they change what you need to write. The assistant replies in the language the visitor used by default, so you do not need an instruction for that, though you can pin a preferred language if you would rather it always answered in one. And handoff to a human is a setting rather than something you have to engineer in the prompt, so your instructions can say when to hand over and let the product handle the mechanics.
Everything here is content-bound: the prompt shapes how the assistant uses what it has, and it cannot supply knowledge the content does not contain. When an answer is wrong because the material is missing or stale, the fix is in the content, not in a firmer instruction.
What to measure
- Share of conversations handed to a person, and why. A handoff rate that never moves after a prompt change usually means the change did not reach the behaviour you were aiming at.
- Median answer length. Track it after you set a cap; this is the change visitors notice fastest.
- Refusals that dead-ended. Sample them. Every one is a conversation that should have been routed and was not.
- Starter prompts actually used. If nobody picks them, they are describing questions your visitors do not have.
- Answers contradicted by your own content. Read a sample weekly at first. This separates a prompt problem from a content problem, and they need opposite fixes.