How to Write Chatbot Use Cases
A chatbot without written use cases answers everything a little and nothing properly. Here is a template you can copy, a filled example, use case examples by industry and what a chatbot use case diagram needs to show.
Short version: A chatbot use case describes one situation from start to finish: who asks, what triggers it, what the person wants, how the bot gets there and when it hands over to a human. Write five of those before you build anything. They decide what the bot has to know, which systems it needs and how you will measure it.
What is a use case for a chatbot?
A use case for a chatbot is one concrete task a specific person completes with the bot, written from trigger to result. "Customer service" is not a use case. "A customer asks at 9 pm where her order is and gets the shipping status without waiting for the next morning" is one.
The term comes from software engineering: Ivar Jacobson introduced it in 1987 to describe what a system does for its users. For a chatbot the idea stays the same, with one addition that classic templates rarely stress: every use case needs an exit. The moment a question leaves the bot's ground, it has to hand over, and that moment belongs in the description.
What makes a good chatbot use case?
A good chatbot use case is frequent, answerable from content or systems you already have, and cheap to get wrong. If one of the three is missing, start with a different one.
- Frequent. It shows up every week in your inbox, on the phone or at the counter. A question asked twice a year is not worth the setup.
- Answerable. The answer is in your website, your documents or a system the bot can query (order status, calendar, product data). If the answer lives only in a colleague's head, write it down first.
- Low cost of error. A wrong opening hour annoys. A wrong dosage or a wrong legal assessment does damage. High-risk questions get a use case too, but its goal is a clean handover, not an answer.
- A clear end. You can say when the conversation was successful: shipping status shown, appointment booked, lead with email and budget saved.
Lead qualification on a website is the textbook example of a good use case. Visitors arrive at all hours, the questions are always similar (what do you need, by when, which budget), the answers can be stored as structured data, and a mistake costs little because a salesperson looks at every lead anyway. More on that in our guide to how chatbots qualify leads.
How to write use cases for a chatbot
To write use cases for a chatbot, start from real questions, not from features. Five steps are enough:
- Collect 50 real requests. Emails, contact forms, call notes, chat logs from the last weeks. Copy them as they were written, typos included.
- Group them. Usually five to eight groups cover most of them: order status, opening hours, prices, appointments, returns, "do you offer X".
- Pick three to five groups that pass the four criteria above. Start there.
- Fill in the template below for each one.
- Write two sample dialogues per use case: one where everything goes well and one where the bot has to hand over. These later become your test cases before launch.
The chatbot use case template
The fully dressed template by Alistair Cockburn has 13 fields, including stakeholders, preconditions and guarantees. For a chatbot, six fields do the job:
| Field | What goes in |
|---|---|
| Actor | Who writes? New customer, existing customer, applicant, employee. One per use case. |
| Trigger | What makes them write, and on which page or channel? "Parcel not here after five days, writes on the order status page." |
| Goal | What the person wants in their own words, not yours. "Know when my parcel arrives." |
| Flow | The steps of the happy path: what the bot asks, what it looks up, what it answers. Three to six steps. |
| Success criterion | A result you can count: status shown and no follow-up email within 48 hours; appointment saved; lead with email saved. |
| Limit and handover | When the bot stops and who takes over: "Parcel marked as delivered but not received: hand over to the team with order number." |
A filled example: order status in an online shop
- Actor: customer with an existing order.
- Trigger: parcel has not arrived after the expected date; writes in the chat on the shop page.
- Goal: "Where is my order and when will it arrive?"
- Flow: the bot asks for order number and postcode, queries the shop system, shows status, carrier and tracking link, and offers to answer follow-up questions.
- Success criterion: status shown; no email or call about the same order within 48 hours.
- Limit and handover: order not found, parcel marked as delivered but missing, or the customer wants to cancel: the bot collects order number and email and passes the case to the team.
This one example already tells you what to build: a connection to the shop system, a rule for checking the customer's identity (order number plus postcode) and a handover route. A use case like "answer shipping questions" would have told you none of that.
Chatbot use case examples
The most common chatbot use cases are answering recurring questions, checking a status, booking appointments, qualifying leads and helping employees find internal information. Here is what that looks like per industry.
E-commerce
Order status, return policy, size and compatibility questions, product advice ("which of these two fits my use?"). The order status example above is the most frequent one. See our article on AI chatbots for e-commerce.
Healthcare
Opening hours, how to get a prescription renewed, which documents to bring, booking and cancelling appointments. The limit is strict: no diagnoses, and anything that sounds like an emergency gets the emergency number at once. More in AI chatbots for medical practices.
Banking and financial services
Which documents a loan application needs, how a product works, booking an advisory appointment. Account data and individual advice stay with people unless the bot works behind a login. See AI chatbots for financial services.
HR and recruiting
Applicants ask about open positions, salary range, remote work and the status of their application. Internally, employees ask about holiday rules and expense reports. See AI chatbots for HR and recruiting.
Real estate
Is the apartment still available, what does it cost including service charges, can I book a viewing. The bot asks the qualifying questions (move-in date, household size, income proof) before an agent spends time on it. See AI chatbots for real estate.
Restaurants
Table reservations, menu and allergen questions, opening hours on public holidays, group bookings. See AI chatbots for restaurants.
Internal knowledge
New colleagues ask where the travel expense form is, how to request software access or what the process for a customer complaint is. The actor is an employee, the content comes from internal documents. See an AI agent for your internal knowledge base.
Chatbot use case diagram
A chatbot use case diagram shows who uses the bot, what they can do with it and which outside systems are involved. In UML it consists of actors (stick figures), the system boundary (a box labelled "Chatbot") and the use cases inside it (ovals). You do not need a modelling tool for a first version; a table with the same content works just as well.
| Actor | Use case | Relationship |
|---|---|---|
| Customer | Check order status | includes "identify order" (order number plus postcode) |
| Customer | Book appointment | uses the calendar as a secondary actor |
| Visitor | Ask about prices | extended by "qualify lead" if the visitor shows buying interest |
| Customer, visitor | Hand over to a human | extends every use case; the support team is the receiving actor |
| Shop system, calendar | (secondary actors) | deliver data, never start a conversation |
Two details are often missing in chatbot use case diagrams found online: the systems the bot queries, drawn as secondary actors on the right, and the handover to a human as its own use case. Without them, the diagram looks complete but hides the two places where most chatbot projects get stuck.
Common mistakes when writing chatbot use cases
- Features instead of situations. "FAQ bot" or "24/7 support" describe a product, not a use case. Nobody can test them.
- No exit. Use cases without a handover produce bots that improvise. That is where wrong answers come from.
- Twenty at once. Start with three to five, measure them for a month, then add more. Real questions will surprise you anyway.
- No test. The sample dialogues from step 5 are exactly what you should run before going live. Our checklist for testing an AI chatbot before launch picks up from there.
If customer service is your main use case, the next step is a plan for the whole support flow: how to automate customer support.
Turn your first use case into a working chatbot
Connect your website and documents, write your use cases into the instructions and test the sample dialogues before a single customer sees the bot.
Common questions about chatbot use cases
Collect around 50 real customer requests, group them, pick the three to five groups that are frequent, answerable from your content and low-risk, and describe each with six fields: actor, trigger, goal, flow, success criterion and handover. Then write two sample dialogues per use case and use them as tests.
Answering recurring questions, checking an order or application status, booking appointments, qualifying leads and helping employees find internal information. Which one comes first depends on what your inbox and phone show most often.
Three to five. That is enough to cover most incoming questions in a small business and few enough to test each one properly before launch.
A user story is one sentence ("As a customer I want to see my order status so that I know when my parcel arrives"). A use case adds the flow, the success criterion and what happens when things go wrong. For a chatbot, the use case is more useful because the handover is where most problems start.
Not necessarily. A diagram helps when several actors and systems are involved, for example customers, staff, a shop system and a calendar. For a first chatbot, a table with actor, use case and connected systems shows the same thing.