Quick answer: A digit-menu IVR routes on what a caller pressed; an intent-driven IVR routes on what a caller said. Devotel Orbit's IVR intents surface lets you declare a named catalog of caller goals ("billing", "upgrade", "outage report") and routes each inbound call to the queue or agent behind the goal a spoken utterance actually matches — the classifier reads the description you wrote, handles synonyms and phrasing drift on its own, and falls through to a branch you designed when nothing matches. You administer the whole thing under Voice → IVR Intents: name the intent, write its description, point it at a queue or an agent, and test utterances against the live classifier before it hears a real caller.
The first-IVR setup walkthrough covered the digit-tree shape end to end — greeting, menu, fallback, terminals. This post picks up where a fixed menu stops being the right tool: the moment callers describe a problem in a sentence instead of navigating toward it one digit at a time.
What natural-language routing actually changes
A digit menu encodes a guess about how callers categorize their own needs, then trains them to translate. "Press 2 for billing" works when the caller agreed they were a billing call; it sheds everyone who described something the menu author never pre-recorded. The caller who says "I was double-charged" is a billing call, but nothing about the word "double-charged" arrives as a digit.
Natural-language routing removes the translation step. The caller speaks; a speech-to-text pass turns the utterance into text; an intent classifier matches the text to a named intent and routes the call to the destination that intent points at. The operator's job moves from designing a tree to designing a catalog.
On Orbit the two shapes coexist deliberately. The IVR Builder still owns the digit tree — and for fixed, pre-recordable answers it is the right terminal. The first-IVR walkthrough already makes the argument that not every inbound call belongs on a scripted menu; IVR intents are the catalog half of that argument. Most tenants run a hybrid: the menu handles the callers who know their digit, and the intent layer handles the callers who would otherwise press "everything else."
The intent catalog: names, descriptions, and targets
An intent on Orbit is three things, and the Voice → IVR Intents page is the whole lifecycle — create, edit, deactivate, delete:
- A name. A short lowercase slug used to identify the intent in the classifier's decision —
billing,upgrade-plan,outage-report. Slugs take lowercase letters, digits, hyphens, and underscores, up to 64 characters. - A description. The part that does the work. Write it as what the caller wants in plain language — "Caller wants to dispute a charge or ask about an invoice" — not as a keyword list. The classifier matches on the description, so synonyms and phrasing variations you never typed still arrive: "I got double-charged" and "there's a weird second payment on my card" both land on the billing intent without you enumerating either.
- A target. Each intent routes to exactly one place — a queue, or a specific agent. The two are mutually exclusive, and both are optional: an intent with no target is a log-only intent, matched and recorded without moving the call. Log-only is how you measure demand for a category before you staff a queue behind it.
Descriptions carry up to 500 characters, which is enough to write the intent as a sentence about the caller's goal and a boundary about it — "billing dispute or invoice question, not a payment-method update." The boundary sentence is what keeps two intents from drifting into each other; billing and payments should split on that edge, not overlap on it.
Keep the catalog small. Two intents route better than twenty: every overlapping description is a coin flip the classifier has to take. Start with the three to five categories your "everything else" queue actually receives, run the intent layer log-only if you want the evidence first, and add a category only when the fallback report shows a class of calls with nowhere to go.
Fallback paths: what happens when nothing matches
No classifier matches everything, and the failure mode that matters is the one you designed for. Orbit's fallback behavior is explicit on two axes:
- No match falls through, never dead-ends. When an utterance matches no active intent, the call falls through to the default no-match branch — the same discipline the first-IVR walkthrough lays down for a wrong digit: an unmatched input needs a designated owner, not a dropped call. Deleting an intent removes it from the classifier prompt, and calls that used to match it take exactly that fall-through — so the fallback owner has to exist before you prune the catalog.
- Inactive intents stop matching without deleting the record. Every intent carries an active flag; an inactive intent leaves the classifier prompt and keeps its history. Deactivation is the reversible version of deletion — the right move when a seasonal category goes quiet, because the intent and its description come back instead of being rewritten from memory.
Design the no-match branch with the same care as the intents themselves. Point it at the queue a human answers, or at a voicemail capture with a callback offer — never at a dead announcement. The fallback is also your demand signal: a no-match cluster that keeps recurring is an intent you have not written yet, and the conversation search and call records carry the actual utterances that fell through, so writing it is reading what callers already told you.
Testing the classifier before callers do
Under the intent table on Voice → IVR Intents, the test-classifier panel runs a sample utterance against the live classifier with no call involved. Paste "I'd like to upgrade my plan" and the panel returns the matched intent id, a confidence score, and the classifier's reasoning. A No match result on an utterance you expected to match is a description problem, not a caller problem — rewrite the boundary sentence and run it again.
Testing is how the boundary sentences get written in the first place. Run the utterances your two closest intents both plausibly own; where the match flips back and forth, the descriptions overlap and the fix is one clarifying sentence per side. The panel is also the pre-prune check: before you delete an intent, run the utterances it used to catch and confirm the fall-through destination is where you want them.
Intents meet skill-based routing
An intent decides what the call is about. Skill-based routing decides who can take it. The two layers compose in one direction: the intent picks the destination queue, and the queue's skill requirements pick the agent inside it — an utterance that classifies as billing-dispute lands on the disputes queue, and the queue only serves it to an agent certified for the skill that queue requires.
That split keeps each layer legible. The intent catalog stays about caller language — it should never encode agent attributes. The skill layer stays about agent capability — it never interprets utterances. Governance for the skill half lives on two surfaces the intent page hands off to: the Skill Catalog, which registers the canonical skill slugs every queue and agent skill assignment is validated against, and Skill Certifications, where supervisors issue, renew, and revoke the expiry-dated certifications a regulated queue (HIPAA, FINRA, insurance-producer traffic) depends on. A certified agent whose certification lapses drops off that queue's routing silently — the expiry sweep on the certifications page is where that gets caught before a billing-dispute call finds no eligible agent.
Route the uncommon case deliberately: an intent pointed directly at one agent bypasses the queue's skill logic entirely. For a regulated category, point the intent at the queue and let the queue's certification gates decide who is eligible.
The measurement loop
Intents that are never measured degrade quietly — descriptions drift, caller language moves, and the fallback queue absorbs the difference. Three shipped surfaces close the loop:
- Post-call surveys. The CSAT/NPS digit-capture explainer walks the in-call survey that plays after the call ends. Read the scores per destination queue: an intent whose routed calls score below the menu-routed branches is routing accurately to a bad destination, or routing inaccurately to a good one — the next two surfaces tell you which.
- Sentiment analytics. The conversation roll-up at
/insights/sentimentscores recorded conversations into a trend with by-queue and by-agent breakdowns, so each intent's destination queue carries a quality read instead of a raw call count. - The fallback report's informal form — conversation search. The utterances that fell through to the no-match branch are the catalog's backlog. Read a week of them; the recurring shape is the next intent to write.
The loop is: classify, measure the destinations, read the fall-through, revise the descriptions. A quarter of that keeps a five-intent catalog honest.
EU AI Act Article 50: disclosure when a machine interprets your caller
A digit-menu IVR is not an AI system in the Act's sense — the caller knows they are pressing keys on a recorded menu. A conversational IVR that transcribes what a caller says and lets a language model classify it is a different posture: a person is interacting with an AI system, and for callers in the EU the Act's transparency tier applies. Article 50 has been enforceable since August 2, 2026: the person must be informed they are interacting with an AI.
Orbit ships this as a tenant-owned control, not a platform mandate. The EU AI Act explainer maps the full control set; the two that attach directly to intent-based routing:
- The spoken intro. Announce the conversational layer in the greeting the caller hears before they speak — the same slot the digit menu uses for "calls may be recorded," and just as short. "You can tell us what you're calling about, and an automated system will route you" is the whole sentence the caller needs.
- The evidence trail. Audit records already cover the intent lifecycle — created, updated, deleted, and each classifier test — and the conformity dossier compiles the disclosure configuration into the evidence pack an EU caller-facing deployment assembles.
Whether your deployment is in scope is your counsel's call, not your vendor's. The controls ship off by default; enabling them is the posture decision the deployer owns, and the platform enforces what you set rather than picking a posture for you.
Frequently asked questions
Do IVR intents replace the digit-menu IVR?
No — they sit next to it. The IVR Builder owns the scripted tree; the intents page owns the spoken-utterance catalog. Fixed, pre-recordable answers stay on the tree; the callers who would have pressed "everything else" are the ones the intent layer routes.
How many intents should I start with?
Three to five, drawn from the categories your general queue actually receives. Every intent is a classification boundary the classifier has to hold, and overlapping descriptions are what misroutes are made of. Add an intent when the fall-through calls show a recurring shape, not ahead of the evidence.
What does the test panel not tell me?
It predicts the classifier's decision on one utterance; it does not simulate call audio. Accents, line noise, and a caller who rambles across two categories are live-traffic phenomena — that is what the measurement loop (surveys, sentiment, fall-through review) catches after the panel has done its pass.
Can an intent route to both a queue and an agent?
No. A target is one queue or one agent, never both — and both can be empty for a log-only intent. If you need queue-level skill filtering, target the queue; the skill layer handles who inside it is eligible.
Do deleted intents break live calls?
Calls in progress keep their route; future calls that would have matched the deleted intent fall through to the no-match branch — which is why the fall-through destination has to be a place a human answers, designed before the first deletion.
Who has to enable the AI-disclosure intro?
Any tenant whose intent-based routing faces callers in the EU, as a starting read — the scope determination is yours to make with counsel. The control is tenant-owned, off by default, and the EU AI Act explainer walks the full configuration.