A customer writes, “Where is order 4821?” Your support agent has four possible paths: answer from a policy page, ask for an order number, call an order-status API, or send the conversation to a person. Customer support chatbot intents help you choose the right path before an answer is written.
The practical goal is not to create a giant chatbot taxonomy. It is to map each recurring customer goal to a source of truth, the information required, and a resolution path your team can trust.
What are customer support chatbot intents?
A customer support chatbot intent is the goal behind a customer’s message. “Where is my order?” expresses an order-tracking intent. “Can I get my money back?” expresses a refund intent. “Does this plan include SSO?” expresses a product or policy question.
The intent matters because it determines what happens next. An AI agent may answer from a knowledge base, trigger an Agent Action, collect contact details, or use human handoff. The wording of the message is only the starting point. The support operation needs to know what the customer is trying to finish.
Consider this message: “I was charged twice for order 4821 and need it cancelled.” It contains a billing concern, an order reference, and a cancellation request. A safe workflow should not pick the first matching label and send a generic cancellation policy. It should identify the immediate issue, gather the missing context, and route the case if a person must decide what happens to the charge.
That is the difference between recognizing a message and resolving it. The first is classification. The second is useful support.
Intent, entity, and resolution path
An intent describes what the customer wants to accomplish. An entity is a detail that helps the support agent complete that task.
In “Where is order 4821?”, order tracking is the intent. 4821 is the entity. Without the order identifier, the agent may know what the customer wants but still cannot check the order.
A useful intent record contains these fields:
| Field | What to record |
|---|---|
| Intent name | A customer goal such as order_tracking or refund_request |
| Example messages | Real messages that express the goal in different words |
| Required entities | Details needed for the next step, such as an order number or account identifier |
| Trusted training source | The policy page, product documentation, API, or exact Q&A pair that supports the response |
| Resolution type | Knowledge-base answer, Agent Action, lead capture, or human handoff |
| Escalation rule | The condition that stops automation and sends the conversation to a person |
Required entities keep an intent from becoming a label with no practical use. Order tracking normally needs an order identifier. A refund request may need account and purchase context. A product question may need the plan name or product version. The agent should ask for the smallest missing detail that allows the next step.
The Bitext customer-support dataset is a useful reference when you are naming categories and collecting examples. It includes 27 customer-support intents across 10 categories, along with question-and-answer pairs and entity types. Treat it as a starting point for vocabulary, not as your final map. Your own conversation logs should decide which intents deserve automation.
Last verified: August 2026
The Helpshift explanation of intent in chatbots also makes the basic distinction clear: intent captures the customer’s goal, while entities provide details about the request. In a support operation, both need to connect to an actual resolution.
A practical customer-support intent library
Group intents around customer goals. Labels such as “transactional” or “informational” are too broad to tell a support team what to do with the next message.
Product and policy questions
Examples include:
- “Does the Pro plan include priority support?”
- “How long does delivery take?”
- “What is your return policy?”
- “Can I use this with an existing account?”
Use a knowledge-base answer when the policy is documented and the answer can be given without account-specific judgment. Create exact Q&A pairs for wording that should not be casually paraphrased, such as refund terms, legal language, or eligibility rules.
Order and delivery status
Examples include “Where is order 4821?”, “Has my package shipped?” and “Why has tracking not updated?” These requests often need an order identifier and an Agent Action that calls an order-status API.
Do not treat “my order is late” as the same outcome as “where is my order?” The first may need a delivery exception or human review. The second may be resolved by a current tracking result.
Account access
Account access includes password problems, login failures, verification issues, and questions about changing account details. Some requests can use a documented troubleshooting answer. Requests involving identity, account ownership, or private data should use human handoff or a verified user flow rather than guessing.
Billing and subscriptions
Separate “What does this plan cost?” from “Why was I charged?” and from “Cancel my subscription.” The first is a product or policy question. The second may require account and payment context. The third changes the customer’s service and may require a clear cancellation workflow.
A billing intent should carry an escalation rule for disputed charges, unclear authorization, and cases where the agent cannot verify the account.
Refunds and cancellations
Keep these intents distinct:
| Customer message | Intent | Likely path |
|---|---|---|
| “Cancel my order before it ships.” | Order cancellation | Check order state, then use an action or handoff |
| “Cancel my subscription.” | Subscription cancellation | Follow the documented cancellation process |
| “I want a refund for my purchase.” | Refund request | Collect purchase context and use human review when judgment is required |
The words overlap. The consequences do not. A refund request, complaint, or disputed transaction should be marked for human review when the agent lacks authority or context.
Technical problems
Technical support messages include “The widget is blank,” “I get an error when I upload a file,” and “The integration stopped working.” Ask for the product area, visible error, or desired outcome when “It does not work” is all the customer provides.
A documented fix can stay automated. A recurring error with no known fix should collect the details your support specialist needs and hand off the conversation with its history attached.
Complaints
A complaint is an outcome and a tone signal, not simply another product question. A customer may also ask for a refund, report a billing issue, or describe a technical failure.
Route complaints for human review when the message involves harm, a disputed charge, repeated failed attempts, or a request for an exception. A correct policy paragraph can still be the wrong response to an angry customer who needs a person to take ownership.
Pre-sales questions
Pre-sales intents include plan fit, implementation questions, security questions, and requests for a demo. Answer documented product questions from approved content. Use lead capture when the next step needs a name, email address, company, or meeting request.
Lead capture belongs after the agent has answered what it can. Asking for contact details before addressing a simple product question adds friction.
Lead requests
Lead requests include “Can someone show me how this works?” and “I need support for 10,000 conversations a month.” The resolution may be lead capture or a meeting booking through an integration. Keep a separate intent for a request to speak with sales, since it has a different handoff or booking path from a general product question.
How to map each intent to an operational response
Use one record for each intent and make the resolution path explicit. The table below shows the level of detail a support or CX lead can use when reviewing real conversations.
| Intent | Example message | Entity needed | Source of truth | Automated response or action | Handoff condition |
|---|---|---|---|---|---|
| Product policy | “Can I return this after 30 days?” | Purchase date, product type | Return policy and exact Q&A pair | Give the approved policy answer | Eligibility is unclear or an exception is requested |
| Product information | “Does this plan include SSO?” | Plan name | Product documentation | Answer from the knowledge base | Documentation does not cover the customer’s setup |
| Order tracking | “Where is order 4821?” | Order number | Order-status API | Run an Agent Action after collecting the order number | The API returns an exception or the order needs investigation |
| Refund request | “I need my money back.” | Account and purchase context | Refund policy and account records | Explain the next step and collect required details | Dispute, unclear authorization, or judgment is required |
| Pre-sales qualification | “Can I book a demo?” | Name, email, company details | Sales qualification content | Capture the lead or book a meeting | The prospect asks a question outside approved content |
| Technical problem | “The widget does not load.” | Site, browser, error details | Troubleshooting content | Give the documented fix | No known fix, repeated failure, or sensitive data is involved |
| Complaint | “I have contacted you three times.” | Conversation history | Prior support records | Acknowledge and gather the immediate issue | Human review is required |
| Account access | “I cannot log in.” | Account identifier, verification context | Account help content | Give the approved recovery steps | Identity or account ownership cannot be verified |
For policy and product questions, point the agent to exact knowledge-base content. AssistLoop training sources include uploaded files, a crawled website, pasted text, and exact Q&A pairs. Q&A pairs are useful when a refund rule or legal phrase should stay close to the approved wording.
For order status, connect the intent to an Agent Action that calls your API after the required order information is available. The action should sit behind a clear entity check. “Where is my order?” is not enough to call an endpoint if the endpoint needs an order number.
For pre-sales questions, lead capture can collect details inside the conversation. That keeps the customer from leaving the chat to find a separate form. For complaints, ambiguous requests, and cases requiring account judgment, use human handoff for support conversations. The team receives the conversation history instead of starting from a blank inbox.
Your intent map should also state what the agent must not do. A high-risk intent is not a failure of automation. It is a routing decision. The right outcome may be a person.
Where intent recognition breaks
Intent recognition fails in predictable ways. Build the recovery path before you measure classification quality.
Overlapping intents. “I need to cancel because I was charged again” could be subscription cancellation, billing, or a refund request. Ask one focused question that separates the paths: “Do you want to stop future renewals, dispute the latest charge, or both?” Do not choose the first plausible label.
Vague messages. “It does not work” gives you no reliable path. Ask for the product area, the error, or the outcome the customer expected. That separates a technical problem from an account-access issue or a billing problem without making the customer repeat the whole story.
Multiple intents in one message. Start with the issue blocking the customer now. If the customer cannot access an account and also wants to change a subscription, address access first. Preserve the second request for the next response or for the human who receives the handoff.
Missing entities. Request only the detail needed for the next step. An order number may be enough for tracking. An account identifier may be needed for account-specific help. Avoid collecting a long form before you know which resolution path applies.
Low-confidence or high-risk messages. Stop guessing. Use human handoff when the request remains unclear, involves sensitive account information, or requires a judgment call. A fallback that reaches a person is better than a confident answer that sends the customer in the wrong direction.
Review conversation logs by intent. Look for messages that were routed to the wrong source, repeated clarification questions, and handoffs where the agent lacked one training document. Those patterns tell you whether to add a Q&A pair, change an escalation rule, or split one broad intent into two narrower ones.
How to measure intent coverage and support outcomes
Intent coverage is the share of recurring support goals represented by a tested intent and a documented resolution path. It is not the number of labels in a spreadsheet. An intent counts as covered when the team has examples, required entities, a trusted source, and a decision about automation or handoff.
Start with your own conversations. Pull a representative set of support messages, group them by customer goal, and record how each one was resolved. Establish that baseline before changing automation rules. Unsupported industry benchmarks will not tell you whether your particular policy content or API flow works.
Track these measures together:
- Deflection rate: how often customers get help without a human response.
- Escalation rate: how often conversations move out of automated handling.
- Handoff rate: how often a person receives the conversation.
- Fallback rate: how often the agent cannot select a safe path.
- First response time: how long customers wait for the first response.
- CSAT: how customers rate the support interaction.
A higher deflection rate is not useful if refund requests, complaints, or account issues are being mishandled. Review resolution quality by intent. The customer should receive the right answer or complete the intended action without unnecessary repetition.
Conversation logs make this review practical. Sort by intent, inspect failed or repeated conversations, and compare the requested entity with the entity your workflow actually collected. A spike in fallback messages may point to missing training content. A high handoff rate for one product question may mean the knowledge base does not contain the exact answer.
Putting the intent map into AssistLoop
Set up the first version from real support messages, not from an abstract taxonomy. Train the AI agent on your support content, embed the website widget, test representative messages, and review conversation logs for missed or overlapping intents.
AssistLoop supports training from uploaded files, website content, pasted text, and exact Q&A pairs. The agent can answer from that content inside the widget. When the request needs work beyond an answer, Agent Actions support REST API calls, meeting bookings, lead capture, and order-status checks.
Use human handoff for requests that need judgment or a support specialist. The agent can pass the full thread to your team with its history, country, browser, and device details. Do not force every intent into automation. The intent map is working when it sends simple questions down a fast path and difficult cases to the right person.
AssistLoop setup takes approximately five minutes.
Last verified: August 2026
Create your AI agent and build the first intent-to-resolution map from real support messages. Start with the questions your team sees every week, then add the missing entities and handoff rules that determine what happens next.
FAQ
What are customer support chatbot intents?
Customer support chatbot intents describe the goal behind a customer’s message, such as checking an order, requesting a refund, or asking about a product. The intent helps determine whether the agent should answer, take an action, collect details, or involve a person.
How do you map intents for a customer service chatbot?
Group real support messages by customer goal, then assign each goal its required entities, trusted source, resolution type, and escalation rule. Test the map against conversation logs before expanding automation.
What is the difference between an intent and an entity in a chatbot?
An intent is what the customer wants to accomplish. An entity is a detail needed to complete it, such as the order number in “Where is order 4821?”
What should a chatbot do when it cannot identify the customer’s intent?
It should ask one focused clarification question when two paths are plausible. If the request stays unclear or requires judgment, it should stop guessing and use human handoff.
Which support chatbot intents should be automated?
Automate goals with clear rules, reliable source content, and low risk, such as common product questions or order-status checks. Route disputes, complaints, sensitive account issues, and judgment calls to a human when the agent lacks the required context or authority.
Written by