Intents library

An intent is a labelled conversation outcome — what the conversation was about, or what the customer wanted. Define the intents you care about, attach them to an assistant, and the platform classifies every conversation against the list at close. The result lands on the conversation record, drives filters and analytics, and fires as part of the conversation.closed webhook.

Use intents to route outcomes downstream automatically: qualified-lead notifications, refund queues, support escalations, missed-booking follow-ups.

What an intent has

Field	What it is
Name	Machine label — qualified_lead, booked_appointment, support_escalation.
Description	Natural-language description of when this outcome applies. The classifier reads only the description, so this is the load-bearing field.
Active	Toggle off to retire an intent without deleting it.

System vs. user intents

Every workspace sees two layers:

• System intents — shipped with the platform. Cover universal outcomes like voicemail detection, call hangup, transfer-to-human. Automatically applied to every assistant.
• User intents — your custom outcomes. You opt assistants into them one by one.

To see the current system intent list: GET /api/v1/intent/system_intents_list.

Four business use cases

B2B SaaS — qualified-lead routing. An analytics startup defines a qualified_lead intent with a tight description ("user has 10+ person team, real use case, contact info captured"). The conversation.closed webhook fires on every conversation; their backend filters on intent_name == qualified_lead and posts to Slack. Outcome: SDRs see their queue in real time.

E-commerce — refund queue. A meal-kit company defines refund_requested and subscription_cancelled intents. Both fire conversation webhooks into the finance review queue. The CX team works the queue daily; nothing falls through the cracks.

Real estate — buyer vs. seller analytics. A brokerage defines buyer_intent and seller_intent. The Analytics page shows the volume split between the two on a rolling 30-day chart, helping the broker decide which side to invest more agents in.

Dental clinic — missed-booking follow-up. Bright Smile Dental defines booking_attempted_failed (the caller tried to book but no slot fit). A workflow watches for this intent in the webhook and texts the caller a self-service rebooking link the next morning. Outcome: 22% of failed bookings convert later.

Defining a user intent

Open Build → Library → Intents → New intent. The description is everything — the classifier reads only that.

A weak description:

A qualified lead.

A strong description:

The user expressed clear buying intent (asked about pricing, requested a demo, or asked to speak to sales), provided at least an email or phone number, and represents a business with 10+ employees. Conversations where the user only asked general product questions without contact info should NOT be classified here.

Strong descriptions:

• State the positive case in one sentence.
• List the required signals.
• Include a "NOT" clause for the most common false positive.

Assigning intents to an assistant

Open the assistant under Build → Assistants → [your assistant] → Intents and tick the intents you want classified on that assistant's conversations. System intents are typically applied automatically.

How classification fires

Classification happens at conversation close. The platform asks the LLM to pick the best-fitting intent from the assistant's attached set (system + user). The selected intent is written to the conversation record. A conversation that doesn't match any intent confidently is left with no captured intent.

You can opt every workspace assistant into your most important intents (e.g. qualified_lead) by attaching them at the workspace level.

Where intents show up

• Conversations view. Each row has an intent column with a filter — slice by intent to read recent transcripts.
• Analytics. Time-series of intent counts by day.
• CSV exports. Intent name is a column on every conversation export.
• Webhooks. conversation.closed and conversation.updated events carry the intent name in their payload.

Using intents as webhook triggers

Wire the conversation.closed webhook into Zapier, Make, n8n, or your own backend and branch on intent name:

// In your webhook handler
if (event.data.intent_name === "qualified_lead") {
  postToSlack(event.data);
  syncToHubspot(event.data);
} else if (event.data.intent_name === "refund_requested") {
  enqueueFinanceReview(event.data);
}

Common recipes:

• qualified_lead → Slack alert + CRM sync.
• booked_appointment → confirmation SMS + calendar invite.
• support_escalation → Zendesk ticket creation.
• refund_requested → finance review queue.

Iterating on intent quality

Treat intents like code — they need testing and tuning.

1. Define the intent with the best description you can write.
2. Let it run for a few hundred conversations.
3. Filter to that intent in Conversations and skim 10 transcripts.
4. Tighten the description — add an exclusion clause, add a clarifying example.
5. Repeat.

Overlapping descriptions cause the classifier to pick at random. Keep your intent set mutually exclusive — if two intents could plausibly fit the same conversation, you have a tagging problem, not a classification problem.

Where to next

• Forms library — capture structured data alongside outcome classification.
• Prompts library — reference intent names in your prompt so the assistant consciously aims for them.
• Webhooks — the delivery channel for intent-driven automation.