Chatbot System Prompt Examples for Website Support

A system prompt describes how a chatbot should behave: its role, audience, sources, boundaries, tone, and next steps. A useful prompt is specific enough to guide a real conversation and modest enough not to claim abilities the product does not have. It cannot make an outdated knowledge base accurate or create an integration that is not configured. Start with our guide to creating a grounded AI customer support agent, then adapt the examples below to the business's approved content and actual workflow.

Explore our free chatbot system prompt generator.

For the complete guide, read AI customer support agent that answers from your own content.

A general support assistant can begin with a role statement such as: 'You are the website assistant for [business]. Help visitors understand the services described in the approved knowledge sources. Use those sources as the authority for business-specific facts. If the information is missing, conflicting, or unclear, say that you cannot confirm it and offer [human contact route].' Replace the bracketed text with accurate, maintained details. If a team does not monitor a channel continuously, do not describe it as live support.

For grounding, define what evidence is acceptable: 'Answer business-specific questions only when the supplied content supports the answer. Do not invent prices, availability, eligibility, policy exceptions, or guarantees. If only part of the answer is supported, state the supported part and explain what needs confirmation.' Add an instruction to preserve qualifications and exceptions from the source. Avoid vague phrases such as 'always give the right answer'; they do not describe what the model should do when the source is silent.

For uncertainty, use a direct fallback: 'When you cannot find a reliable answer, do not guess or fill the gap with general assumptions. Explain briefly that the information is not available here and offer [approved next step]. Ask at most one clarifying question if it could locate the relevant source; otherwise hand off.' Test the wording with an unanswered question and with a question whose premise is false. The chatbot should neither invent a response nor reinforce a mistaken assumption merely to sound agreeable.

For lead capture, a respectful instruction might say: 'Answer the visitor's question first. If they request a quote, callback, or follow-up, ask only for the contact fields enabled in this chat and explain what the team will do next. If the visitor declines, accept that and continue helping without asking again.' Make sure the prompt agrees with the actual product settings and data destination. Do not ask for sensitive information unless the business has specifically approved and verified the entire collection and handling process.

For handoff, specify the trigger and the honest expectation: 'Offer a human when the visitor asks, when the answer depends on their individual account or circumstances, or when the knowledge sources are insufficient. Tell them how to contact [team] and state the published response hours. Do not claim that a ticket was created or that a person will reply within a specific time unless the connected workflow confirms it.' Test whether conversation context is actually shared with the recipient before promising that a person will see earlier messages.

For regulated or sensitive services, prompts should state a firm boundary reviewed by qualified staff. A general pattern is: 'Provide only the approved general information in the knowledge sources. Do not diagnose, recommend treatment, interpret a legal position, make a financial recommendation, or decide eligibility. For personal advice, direct the visitor to [qualified professional or approved channel].' This is not a substitute for legal or compliance review. If the service is not approved for protected or sensitive data, instruct visitors not to share it and provide an alternative route.

Keep the tone guidance small and observable: 'Use plain language, answer the question first, keep routine replies concise, and use bullets only when they improve clarity. Be courteous without exaggerating certainty. Do not claim to be human.' Add language preferences only if the business can support the resulting answers. If the chatbot should respond in the visitor's language, test important product terms and policy details with a fluent reviewer; the prompt cannot guarantee accurate translation.

Test every prompt with a repeatable set: a straightforward question, a paraphrase, an exception, missing information, a false premise, an angry visitor, a request for a human, and an attempt to elicit a prohibited answer. Record the expected behavior and revise one instruction at a time. Check that the bot still answers normal questions after adding safety rules. Store the approved prompt with an owner and revision date, and retest it whenever the source content or settings change.

A prompt template is a starting point, not a substitute for verifying product configuration. Translate each instruction into observable behavior and check that the system supports the required settings. If you ask the bot to offer a callback, make sure an actual human contact route exists. If you ask it to save an email, verify lead capture is enabled and that the data goes where the team expects. If it should answer only from approved sources, test a question whose answer is absent and confirm it does not make one up.

Keep separate prompts or instructions for roles that have genuinely different boundaries. A public sales assistant may explain product fit and request a callback; a support assistant may help visitors navigate public documentation; an internal assistant could have a different audience and access model. Combining every use case into one long instruction can create ambiguity and expose content to the wrong audience. Define scope, source permissions, and who is allowed to use the bot before sharing an internal configuration externally.

A prompt should be reviewed like other customer-facing policy. Store an approved copy, owner, revision date, and the reason for material changes. Avoid embedding credentials, private customer details, confidential policies, or personal data in the prompt. If the model or provider changes, rerun the test set rather than assuming the same wording behaves identically. A version history makes it possible to identify which instruction was active when a behavior changed and to restore a known configuration if needed.

For a starting draft tailored to business type, tone, exclusions, and lead fields, try the free chatbot system prompt generator. Treat its output as a draft: replace placeholders with approved business details, remove behavior the product cannot perform, and have the relevant owner review sensitive boundaries. Paste the final instruction into the configured chatbot and run the test cases above. A generated prompt is not a substitute for source maintenance, integration testing, or professional review.

Store prompt examples separately from production instructions so an employee does not accidentally paste a placeholder into a live bot. Mark every field that requires business approval, such as response hours, contact details, data collection, and professional boundaries. After editing, test an ordinary supported question and a boundary case before publishing. If several people can edit the chatbot, agree on a review process and keep a known-good version available for recovery. Prompt changes should be treated as configuration changes, not casual copy edits.

Want the full picture? Read our guide on ai customer support agent that answers from your own content.