Every conversation AIVA finishes — a call, a text thread, a widget chat — gets filed into a category automatically: booking, reschedule, pricing question, hours and location, complaint, and so on. That breakdown is what shows up on a business's dashboard as an intent chart they can read in five seconds. Getting there automatically, across every channel and every language we support, was a harder problem than it looks from the dashboard side.
The easy version doesn't survive contact with 12 languages
The straightforward way to categorize intent is keyword matching — if the transcript contains "reschedule" or "change my appointment," tag it as a reschedule. That approach falls apart almost immediately once you're not operating in a single language. A reschedule request in Marathi doesn't share keywords with one in Tamil. A code-switched sentence — Hindi and English mixed in the same breath, which is how a large share of our calls actually happen — won't reliably match a keyword list built for either language alone, the same underlying multilingual-text problem W3C's internationalization work has documented for web content generally, long before you get to a specific pairing like Hindi and English. We'd have needed a separately maintained keyword set per language, per channel, that would drift out of sync the moment any one of them got updated.
We categorize by meaning instead of matching by words. The model that classifies a conversation is working from the same semantic understanding that lets it hold the conversation in the first place — the same layer that knows a Gujarati caller asking "kal availability che?" is asking about tomorrow's availability is the layer that tags that call as a booking inquiry. One understanding layer, applied consistently, rather than a translation step bolted in front of a categorizer that only really works in English. This is the same reasoning behind why we built each language natively instead of translating into English and back — a categorization system inherits the same weaknesses as the conversation engine it sits on top of, and a translation layer's blind spots become the categorizer's blind spots too.
The code-switching problem shows up here in a specific way: a sentence that mixes Hindi and English mid-clause isn't ambiguous to a native speaker, but it can be genuinely ambiguous to a system trying to first decide "what language is this" before it can even start matching keywords. Skipping that decision entirely — understanding the mixed sentence as its own coherent thing, the way a bilingual listener does — is what keeps categorization accurate on the calls that don't fit neatly into one language box, which in our experience is a lot of them.
What "automatic" has to handle
Real conversations rarely fit one clean box. A customer might open by asking about pricing, get an answer, and then book — that's two intents in one conversation, not one. We tag a primary intent (what the conversation was fundamentally about) and track secondary intents where they exist, rather than forcing every conversation into exactly one bucket. A dashboard that only showed primary intent would undercount a business's actual booking volume, because a fair number of bookings start as a different question first.
Categories aren't fixed at launch and left alone. We review clusters of "other" periodically — conversations the model couldn't confidently place in an existing category — and when a real pattern shows up often enough, it becomes its own category going forward. The taxonomy is closer to something we grow than something we designed once.
Where categorization gets genuinely hard
A few situations don't have a clean answer, and it's worth being honest about them rather than pretending the taxonomy is tidier than it is.
Conversations that pivot hard. A customer calling about a routine reschedule who, mid-call, brings up an unrelated complaint about a previous visit is having one conversation with two very different centers of gravity. Primary and secondary intent tagging handles the common version of this — one dominant topic with a smaller one attached — but a genuine 50/50 split between two unrelated topics is a harder case, and we lean toward flagging it as both rather than forcing an arbitrary primary.
Sarcasm and indirect complaints. "Wow, third time I've had to call about this" is a complaint, but it isn't phrased as one the way "I want to file a complaint" is. Catching intent that's implied rather than stated directly is a meaningfully harder problem than matching an explicit request, and it's an area where the semantic approach earns its keep — a keyword system built around words like "complaint" or "refund" would miss this kind of sentence entirely, since none of the trigger words are actually present.
Short, ambiguous replies. A conversation that ends with the customer just saying "ok thanks" gives the categorizer very little to work with on its own. This is one of the reasons categorization looks at the conversation as a whole rather than the final message in isolation — the intent was established earlier in the exchange, and the closing message doesn't need to re-establish it.
One shared taxonomy, not one dashboard per business
A related design question was whether every business should get its own custom category list from day one, tuned to their specific industry, or whether everyone should start from the same shared taxonomy. We went with a shared starting set — booking, reschedule, pricing, hours and location, complaint, and a handful of others — because most of what a clinic, a salon, and a coaching institute get asked about actually maps onto the same small number of underlying categories, even though the specific words are completely different.
Where it gets interesting is the long tail. A dental clinic gets a real, recurring volume of insurance verification questions that a salon never sees at all; a driving school gets asked about test-slot availability in a way that doesn't map cleanly onto generic "booking." Rather than pre-building an exhaustive category list per industry before we'd seen real conversations, we let those categories emerge the same way any new category does — from clusters of "other" that show up often enough, for a specific business or a specific type of business, to be worth splitting out on their own. A shared taxonomy that grows targeted branches turned out to be more accurate than trying to guess every industry's specific questions in advance.
Why this feeds the dashboard and not just a report
The point of automatic categorization isn't a research exercise — it's that a business owner can open their dashboard and see, without listening to a single call, that reschedules spiked this week or that a new pricing question is showing up repeatedly that isn't answered well yet. That only works if the categorization is trustworthy across every channel a customer might have used and every language they used it in. A business running AIVA across Hindi voice calls, English SMS, and a Gujarati web chat needs those three channels rolling up into one consistent picture, not three separate, slightly-different ones that happen to share a dashboard.
That consistency — one meaning, tagged the same way regardless of what language or channel it arrived in — is the actual engineering behind a chart that looks, on the surface, like a simple pie of categories. It's also the layer underneath resolution rate, since knowing whether a conversation resolved is only meaningful once you know what it was actually trying to resolve — a category is the unit resolution rate gets measured against, not an independent number sitting next to it. And because intent data is retained for 90 days by default and fully exportable like the rest of AIVA's analytics, a business comparing this quarter's intent breakdown to last quarter's is comparing categories that were tagged the same consistent way both times, in whichever of the twelve languages each conversation happened to be in.