What are Use Cases?
Use cases use our advanced AI engine, utilizing generative AI to create AI agents without the time-consuming activity of training expressions. This zero-training approach simplifies setup and maintenance while enhancing the AI agent's understanding and performance.
What are the benefits?
- Quick time to value: Setting up a Use Case only takes a few minutes and requires no prior experience.
- Smarter automation: this cutting-edge technology increases Ticket Understood rates to over 80% on average.
- Easy ongoing maintenance: Minimal upkeep is required due to the elimination of expression training.
Supported channels
- Ticket (Early Access Program)
- Chat (Coming Soon)
Getting Started
Since Use Cases are replacing “traditional” Intent and expression training, we wanted to provide some guidance and initial best practices on writing clear and well-performing use case names and descriptions.
Basic guidelines
- Language: Write use case names and descriptions in English for the best and most accurate results.
- Clarity and consistency: Avoid punctuation (except commas) and overly lengthy names and descriptions. Aim for coherence across your entire use case structure.
- No "small talk" Use Cases: Do not create Use Cases for small talk or for recognizing a specific language (e.g. change language).
- Create distinct Use Cases: Ensure Use Cases do not overlap. For example, distinguish between "return status" and "refund status."
Creating your Use Case
In our advanced AI engine, two crucial elements provide context for understanding visitor messages: 1) Use Case name and 2) Use case description. The name provides a concise label, while the description offers detailed context, enabling the AI to accurately identify and respond to inquiries without traditional training.
1) Use Case name
- Meaningful and correlated: Names should be meaningful and correlate with the use case description. Clearer names result in better performance.
- No punctuation: Avoid punctuation use words instead; commas are allowed.
- Concise: Keep names short, ideally 3-5 words.
Examples:
| Avoid punctuation | |
| ✅ Do this | ⛔️ Don’t do this |
| Issues with Klarna | Issues - Klarna |
| Feedback on products and services | Feedback on products / services |
| Be concise | |
| ✅ Do this | ⛔️ Don’t do this |
| Active promotions | Questions about active promotions or discounts |
| Username or password change | How do I change my username or password? |
2) Use Case description
- Start consistently: Descriptions should start with "Customer asks / requests / seeks information..."
- Avoid punctuation: Use words instead of punctuation, but commas are allowed.
- No keywords: Avoid including keywords in the description. Clearly explain the Use Case instead.
- Concise yet detailed: Descriptions should be concise yet detailed enough to identify the Use Case correctly. Aim for around 120 characters (including spaces).
- Avoid acronyms: Write out acronyms to provide additional context.
Examples:
| Consistent descriptions | |
| ✅ Do this | ⛔️ Don’t do this |
| Customer received an order with a missing item | The order that was received was missing one or multiple items |
| Customer asks about payment methods | Questions regarding supported payment method |
| Avoid punctuations | |
| ✅ Do this | ⛔️ Don’t do this |
| Customer expresses dissatisfaction towards a product | Negative opinion of a product about size/appearance/performance. |
| Customer is looking for advice on a product or service | Product / service advice |
| Don’t use keywords | |
| ✅ Do this | ⛔️ Don’t do this |
| Customer needs support with Klarna payments | Customers need support with Klarna payments. Keyword: Klarna |
| Customer wants to schedule a collection for their return | Customer wants to schedule a collection for their return. Keywords: pick-up, collection |
How many Use Cases are needed?
An AI agent can start supporting customers with as little as one Use Case. You can define the number of processes the AI agent should handle.
Conflict Resolution
The Use Case approach makes it easy to get up and running. However, overlaps in Use Cases can confuse the AI, leading to poor performance. The Conflict Resolution tool helps identify and fix these overlaps, ensuring the AI functions smoothly and provides a good experience.
Types of Conflicts
- Overlapping Use Cases: These conflicts can be resolved by modifying the name and description of the use cases.
- Duplicated Use Cases: These Use Cases are identified by the AI as being nearly identical.
Resolving Overlapping Use Cases
- Automatic identification: Conflicts will be identified automatically.
- AI suggestions: Our Generative AI engine will suggest changes to your Use Case names and/or descriptions to avoid overlaps.
- Resolution options: You can accept the proposed changes with a one-click resolution or review and modify the proposed changes before saving.
Resolving Duplicated Use Cases
- True duplicates: If the AI correctly identifies duplicates, deactivate the Use Cases you no longer need.
- False duplicates: If Use Cases are wrongly identified as duplicates, modify their name and description to provide more context and differentiate the scenarios.
Best practices from different industries
We have collected a small list of well-performing Use Case names and descriptions below. Feel free to use these in your own AI agent.
General
| Use Case name | Description | Insights and tips |
| 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, we see customers wanting 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 (e.g. Order, Booking etc) |
eCommerce
| Use case name | Description | Insights and tips |
| 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
| Use case name | Description | Insights and tips |
| Cancel booking | Customer requests to cancel their booking | As you can see, the Intent name and descriptions 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 Intent covers 3 different changes: arrival, departure and date for travel. Customers can change these details themselves depending on their ticket type, whereas name change would require agent attention - which is also why it’s covered in a different Intent. |
| Change the name on booking | Customer needs to change the name on their booking | As mentioned above, this Intent has been excluded from the more general Changes to booking Intent as they are 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
| Use case name | Description | Insights and tips |
| 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 / unsuccessful transfers as these are covered in a separate Intent. |
| Unsuccessful transfer | Customer is concerned about a money transfer that didn’t reach the recipient | As per below, this Intent is used to cover use cases where the money transfer has been made, but it never made it to the recipient account. |
| Card activation issues | Customer expresses issues with credit card activation | |
| Failed payment | Customer wants to understand why their card payment failed |
FAQ
How could I use industry and country specific terminology in use cases?
Identify the abbreviations, acronyms or country specific terminology in the text. Ensure the expanded term is placed right after the first occurrence of the terminology.
Example:
Customer requests DIY (DIY: Do it yourself) product instructions.