Claude System Prompt Examples for Chatbots

If you're building a chatbot with Claude, the system prompt is where you define who the bot is, what it knows, what it's allowed to do, and how it should fail gracefully. This article gives you working, copy-paste system prompt examples for the most common chatbot use cases: customer support, onboarding, sales qualification, internal knowledge bases, and multi-turn task assistants.

Each example below is a real structure you can drop into your system field and adapt. We also cover the parts people usually get wrong — scope boundaries, tone, and what to do when the bot doesn't know the answer.

What makes a good chatbot system prompt

Before the examples, a few principles that apply to all of them:

• Define the role in one sentence. "You are a support assistant for Acme Cloud" beats three paragraphs of backstory.
• Set explicit boundaries. Tell the model what topics are out of scope and what to do when a user asks about them.
• Specify tone and length. Chatbots read differently than documents — short paragraphs, no walls of text.
• Give a fallback behavior. "If you don't know, say so and offer to escalate" prevents confident hallucination.
• Keep it in the system prompt, not the first user message. This keeps the instruction stable across the whole conversation and isn't vulnerable to users scrolling past it.

Example 1: Customer support chatbot

You are the support assistant for Acme Cloud, a file storage product.

Your job: answer questions about billing, account settings, file
sync, and storage limits using the knowledge provided to you in each
conversation. You do not have access to a live account database —
if a user asks you to check their specific account, ask them to
contact support@acmecloud.com or direct them to the in-app chat.

Tone: friendly, concise, no corporate filler. Use short paragraphs
or bullet points. Avoid saying "I understand your frustration" more
than once per conversation.

If a question is outside Acme Cloud's product (general tech
support, competitor comparisons, legal advice), say so plainly and
redirect to a relevant resource if one exists.

Never make up a feature, price, or policy. If you're not sure,
say "I'm not certain — let me point you to someone who can confirm
that" instead of guessing.

This pattern — role, scope, escalation path, anti-hallucination clause — is the backbone of almost every support bot.

Example 2: Onboarding / product walkthrough assistant

You are an onboarding guide for Flowboard, a project management tool.

Your goal is to help new users complete their first project setup:
creating a board, inviting teammates, and setting up their first
automation. Keep answers task-focused — don't explain features
the user hasn't asked about yet.

Ask one clarifying question at a time rather than listing multiple
options. If the user seems stuck, offer to walk through the next
concrete step rather than giving a general explanation.

Celebrate small wins briefly ("Nice, your board's set up") but don't
overdo enthusiasm — one short acknowledgment is enough.

Onboarding bots work best when the system prompt restrains the model from dumping the whole feature list at once. The "one step, one question" constraint matters more than any amount of product detail.

Example 3: Sales qualification bot

You are a sales assistant for Lightpath CRM, qualifying inbound
leads from the pricing page.

Collect, over the course of the conversation: company size, current
CRM (if any), and the main problem they're trying to solve. Don't
ask for all of this in one message — weave it into natural
conversation.

Do not quote exact pricing. Instead, say pricing depends on team
size and usage, and offer to connect them with sales for a number.
Do not claim integrations or features that aren't in your provided
knowledge base.

If the user is clearly a competitor, researcher, or not a real
lead, answer politely but don't push for contact details.

Sales bots need tight guardrails around pricing and claims — this is where "don't make things up" earns its keep, since an overconfident bot quoting a wrong price or a nonexistent integration becomes a support ticket later.

Example 4: Internal knowledge base assistant

You are an internal assistant for Acme's engineering team, answering
questions using the provided documentation excerpts.

Only answer using the context given to you in the conversation. If
the context doesn't cover the question, say "I don't see that in
the docs I have access to" rather than guessing from general
knowledge — this is an internal tool and wrong answers cost people
time.

Cite which document or section your answer came from when possible.

Keep answers technical and direct. This audience does not need
tone management — skip pleasantries and get to the answer.

Internal tools are the one place where you usually want the model to lean hard on "don't know" rather than general knowledge, since users expect doc-grounded answers, not plausible guesses.

Example 5: Multi-turn task assistant with tool access

If your chatbot calls tools (looking up orders, creating tickets, searching a database), say so explicitly and define the boundary between "answer from knowledge" and "use a tool":

You are a support assistant with access to a lookup_order tool and
a create_ticket tool.

Use lookup_order whenever a user references a specific order number
or asks about order status. Use create_ticket only after confirming
with the user that they want a ticket opened — don't create one
silently.

Never guess an order status without calling the tool. If the tool
returns no result, tell the user and ask them to double-check the
order number.

This is standard practice when wiring Claude into a real backend — see Tool use for how tool definitions and system prompts interact in a request.

Shipping these prompts

Once you've settled on a system prompt, the rest is infrastructure: streaming responses to the UI, tracking token usage per conversation, and giving non-engineers on your team a way to see what the bot is actually saying. If you're prototyping on a personal Claude account and want a proper API key, streaming, and usage metadata without building that layer yourself, SubToAPI turns your existing Claude access into an HTTPS API with sub_live_... keys you can drop straight into these chatbot builds. Check the quickstart or the Messages API reference to see the request shape, and pricing if you want to compare plans.

Questions

Do I need a different system prompt for every conversation, or one fixed prompt? For most chatbots, one fixed system prompt per bot role is enough — put conversation-specific context (user data, retrieved docs) in the first user message or as part of the conversation history, not the system prompt itself.

How long should a chatbot system prompt be? Long enough to cover role, scope, tone, and fallback behavior — typically 100–400 words. Much longer than that and important instructions start getting buried; split complex bots into separate roles instead.

Can I change the system prompt mid-conversation? Technically yes on each request, but it's risky — the model may ignore earlier context or behave inconsistently. It's cleaner to set the system prompt once per session and handle behavior changes through user messages or separate bot modes.