Best practices for creating use cases for advanced AI agents

What's my plan?

Add-on

AI agents - Advanced

Use cases are the mechanism by which zero-training AI agents and agentic AI agents (EAP) understand what a customer is asking about and connect them with the right dialogue or procedure (EAP).

A use case’s name and description provide the necessary context for an AI agent to understand the customer’s messages and connect them with the right dialogues to help them. As such, it’s important to write clear and specific use case names and descriptions in order to get the best performance possible from your AI agent.

This article contains the following topics:

• Best practices for use case descriptions
• Best practices for use case names
• Use case examples for different industries

Related articles:

• Creating use cases for advanced AI agents
• Managing use cases for advanced AI agents

Best practices for use case descriptions

When creating use case descriptions, keep the following best practices in mind:

• Write use case descriptions in English.
• Start all of your use cases in a consistent way (for example, “Customer wants to…”).
• Avoid any punctuation except commas.
  • Do this: Customer is looking for advice on a product or service
  • Don’t do this: Product / service advice
• Avoid including keywords in the description.
  • Do this: Customer wants to schedule a collection for their return
  • Don’t do this: Customer wants to schedule a collection for their return. Keywords: pick-up, collection
• Write descriptions that are concise (around 120 characters, including spaces) yet detailed enough to connect the customer to the right dialogue.
• Avoid acronyms, or write the acronyms to provide additional context.
  • Do this: Customer requests do it yourself instructions
  • Don’t do this: Customer requests DIY instructions
• Create distinct use cases and ensure they don’t overlap. Overlapping use cases cause confusion and worse results in the AI model.
• Don’t create use cases for small talk or for recognizing a specific language.

Best practices for use case names

When creating use case names, keep the following best practices in mind:

• Write use case names in English.
• Keep names short, ideally 3-5 words.
  • Do this: Username or password change
  • Don’t do this: How do I change my username or password?
• Choose names that are as clear as possible.
• Avoid any punctuation except commas.
  • Do this: Issues with Klarna
  • Don’t do this: Issues - Klarna

Use case examples for different industries

The tables below collect well-performing use case names and descriptions for various industries. Feel free to use these in your own AI agent.

Use case name	Description	Insights and tips
General industry
Refund status	Customer asks for an update on the status of their refund
Login issues	Customer can’t log in due to incorrect password or username	In this use case, “login issues” and “password reset” have been merged together due to semantic similarities with customers having trouble logging in.
Update account information	Customer asks how to update personal or account information	Most often, customers want to update either their personal details (name, phone) or account information (delivery, billing address). Due to semantic similarities, these topics have been merged.
Payment methods	Customer wants to know what payment methods are supported
Email confirmation	Customer didn’t receive an email confirmation for their order	This use case can be adjusted according to your use case (for example, order, booking, etc.).
E-commerce industry
Order status	Customer wants to know the status of their order
Lost order	Customer hasn’t received their order despite delivery
Sizing enquiries	Customer asks about product sizing	This can be further iterated to be more product-category-specific, like shoe or clothing sizing.
Incorrect item received	Customer claims they received an item they did not order
Return request	Customer wants to return their order, or part of their order
Travel industry
Cancel booking	Customer requests to cancel their booking	The use case name and description are unified and not overly lengthy. It clearly expresses the user's desire to cancel their booking.
Changes to booking	Customer wants to change the date, destination or departure for their booking.	This use case covers three different changes: arrival, departure, and date for travel. Customers can change these details themselves depending on their ticket type, whereas a name change would require agent attention, which is why that’s covered in a different use case (below).
Change the name on booking	Customer needs to change the name on their booking	As mentioned above, this use case has been excluded from the more general “Changes to booking” use case as they’re semantically different enough, and we were able to write clear names and descriptions without strong confusion.
Recommendations for activities	Customer wants to know what activities are available at their location
Financial services industry
Status of transfer	Customer needs information on the status of their money transfer	Customer has concerns about whether the recipient has received a money transfer, and wants to check the status of it. This use case doesn't cover lost or unsuccessful transfers, as these are covered in a separate use case (below).
Unsuccessful transfer	Customer is concerned about a money transfer that didn’t reach the recipient	As mentioned above, this use case covers instances where a money transfer has been made but never arrived at the recipient account.
Card activation issues	Customer expresses issues with credit card activation
Failed payment	Customer wants to understand why their card payment failed