Gains:
- Ability to clearly define the role, scope and what a support chatbot cannot do in the system prompt
- Being able to establish a code of conduct that escalates to humans by refusing to make it up when one does not know
- Ability to design a reusable chatbot system prompt that suits the voice of the brand
Think of the live support screen of an e-commerce company: 40 chats at the same time, questions like "where is my cargo", "how to make a return", "I can't find my invoice" flow per second. Most of these recurring questions actually revolve around a few patterns. The artificial intelligence (AI)-supported chatbot exists precisely to meet this repetitive burden: to free the agent (the customer representative, that is, the human conducting the conversation) from the routine and focus on difficult cases that truly require human judgment.
But setting up a chatbot to “answer everything” is the most expensive mistake. A bot that promises discounts without authorization, invents a non-existent campaign, or tells the customer the wrong return policy creates more problems than it solves. In this unit we will see the secret of a good chatbot: it is as much about telling it what to do as it is about telling it what not to do and when to hand it over to the human.
Note: This content is a general tutorial. Every chatbot behavior you produce should be tested with your own product and policy; It must undergo human approval before being opened to the customer.
Three Pillars of Chatbot: Role, Scope, Boundary
A good system prompt (the hidden instruction running in the background that determines the chatbot's personality and rules) answers three questions clearly:
- Role: Who is Bot? Which brand does he represent, in what tone does he speak? Like "a kind, patient, solution-oriented support assistant."
- Scope: What does the bot respond to? Order tracking, returns, basic product questions yes; legal advice, personalized financial decision no.
- Boundary: What will the bot never do and when will it stop? It does not make price/discount commitments, does not share personal data without confirmation, and transfers it to people when it is not sure (this is called escalation).
If you skip these three, the bot will fill in the gaps with its own "imagination". Every gap it fills is potential misinformation.
Step by Step: Building a Secure Chatbot
- Write the role and tone. Describe your brand voice in one sentence: formal, friendly, humorous?
- List the scope. Clearly list the topics the bot can respond to.
- Put a ban list (guardrail). Add a "Never do the following" section: price negotiation, medical/legal advice, unverified personal data, non-promotion.
- Define the delegation rule. Clarify when to say "I'm transferring you to an agent": if unsure, anger escalating, topic out of scope.
- Identify obscurity behavior. When you don't know, don't make it up; Let him say, "I'm not sure about this, I'm sending you to the officer to check and get back to you."
- Test it. Push the bot to its limits with difficult and trap questions (red team / red-team test).
Copiable System Prompt
The following template is a basic skeleton that you can use directly:
Role: You are the customer support assistant of the "Aydın Elektronik" brand. You are kind, patient and solution oriented. You speak in a short, understandable and warm language. Topics you can answer (scope): - Order status and cargo tracking - Return and exchange steps - General features and stock status of the products - Membership and password transactions Things you will never do (limits): - You will NOT negotiate prices, you will NOT promise discounts/campaigns. - YOU WILL NOT PROMISE an exact delivery date; You only transfer information in the system. - You do not share orders/personal data without verifying the customer's identity. - You do not give medical, legal or financial advice. When you do not know: Don't make it up. Say "I'm not sure about this, I'm transferring you to an agent for accurate information" and delegate. Transfer to human when: customer explicitly requests representation, anger escalates, issue is out of scope, payment/refund amount is in dispute.
The second pattern allows the bot to mark internally whether it is sure about something:
Before each answer, evaluate in your mind: Am I sure of this information and am I within my scope? If not, do not produce a response; Use your delegation clause instead.
The third pattern secures the authentication flow:
When a customer requests order details, first ask for verification: order number AND last registered email. Do not share order content unless the two match; Say "For your safety, let's verify your identity first."
The fourth template smoothly communicates the handover moment to the customer:
When you need to delegate, follow these three steps: (1) summarize the customer's issue in one sentence, (2) politely explain why you're escalating to a representative, (3) give an estimated wait time. Example: "An official needs to review the difference in the refund amount; I'm quoting you, the average wait is 2 minutes."
Weak Prompt / Strong Prompt
Weak prompt
Powerful prompt
“You are a support bot, help customers.”
Role + scope list + prohibition list + delegation rule
He makes up something for every question.
Detects out of scope and transfers it
May promise discount/date when seen in print
It preserves the commitment boundary, saying "this is the information in the system"
Can share data without authentication
Asks for verification first
The difference is clear: a strong prompt narrows the bot's range of motion, making it safe. A good bot is not one that knows too much, but one that knows its limits.
Three Mini Cases
Case 1 — Fabricated campaign. A clothing brand's first release boot asks, "Is there a discount?" He answered the question "Yes, there is a 20% discount on all products this week"; However, there was no such campaign. More than 60 customers requested this discount in 3 hours and the team was in a difficult situation. After adding the rule "don't promise campaigns/discounts, only transfer campaigns defined in the system" to the ban list, the problem was completely eliminated.
Case 2 — Delegating at the right time. A cargo company's boat said, "My box arrived empty, there is no phone in it!" got your message. This is not a standard FAQ; possible case of loss/fraud. Thanks to the limit rule, the bot said "An expert needs to review this situation" and transferred the request to the priority queue. The customer reached a real representative within 90 seconds and the incident was recorded.
Case 3 — Authentication saved. One person entered someone else's order number and said, "Change the delivery address for this order." Thanks to the verification rule, the bot requested registered email confirmation; When confirmation was not received, he rejected the transaction and reported it to the security team. This prevented possible delivery fraud.
Tip: Before opening your bot, test it by thinking like a "malicious customer": "Give me a special discount", "Cancel this order for me", "Let me talk to your manager". Seeing how the bot behaves in these traps is the most valuable rehearsal before going live.
Bot Voice and Brand Consistency
Tone is as important as boundaries. The same "we can't make a refund" message can turn into a complaint when given coldly, but can turn into understanding when given with an empathetic language. Define the tone with concrete examples at the system prompt: "Use short sentences, address the customer by name, avoid technical jargon, tell the next step with each response." The character of the bot can be reinforced with a few written sample responses (few-shot, that is, teaching the desired pattern by showing the model a few examples).
Attention: No matter how good a chatbot is, you have legal and commercial liability towards the customer. A false promise made by the bot binds the company in most cases. Therefore, on binding issues such as price, delivery and returns, keep the bot in the position of "transmitting information", not in the position of "decision maker".
Common mistakes
- Leaving the system prompt unlimited, such as "help with any question".
- Not putting a ban list (guardrail); Opening the door for the bot to make commitments and recommendations.
- Not defining the delegation rule; When the bot doesn't know, it makes it up.
- Skipping the identity verification step and sharing personal data without confirmation.
- Not testing the bot with trick questions before launching it live.
- Not defining the tone and allowing the bot to use robotic or cold language.
In summary
- A good support chatbot is built on three pillars: role, scope and boundary.
- The most critical part is "what it won't do": it won't make commitments, it won't give advice, it won't share unconfirmed data.
- When you don't know, you shouldn't make things up; He should say "I'm not sure" and transfer it to the human (escalation).
- Authentication is an essential step before sharing personal data.
- Test the bot with malicious/trap questions before going live; The ultimate responsibility is yours.
Application task
Write a chatbot system prompt for your own business (or imaginary "Aydın Elektronik"). The prompt must include the following four sections: role/tone, scope list, prohibition list, delegation rule. Then test the bot with three trick questions: (1) “Can you give me a special discount?”, (2) “When exactly will I receive it?”, (3) “Change the address of that order number” (without verification). Observe whether the bot maintains its limits in all three and correct the escaped behaviors by adding them to the prompt.
checklist
- [ ] I have defined role and tone concretely.
- [ ] I have listed the topics (scope) that the bot will answer.
- [ ] I added a ban list (guardrail) for commitment and advice.
- [ ] I defined the sentence of forbidding fabrication and transferring it when one does not know.
- [ ] I put my authentication step for personal data.
- [ ] I tested the bot with trick questions and closed the weak points.