Ask any support agent what they dislike most about picking up an escalated conversation, and a common answer is: not knowing what already happened. The customer's frustrated, the agent's starting cold, and the first two minutes go to reconstructing a conversation that already took place somewhere else. That reconstruction is what the Freshdesk integration is built to remove.
The "please repeat your issue" problem
When AIVA can't or shouldn't finish a conversation on its own — a policy exception, an upset customer, something outside what it's configured to handle — the handoff itself becomes part of the experience. Done badly, it's a dead end: the customer repeats themselves to a human seeing the conversation for the first time, and whatever goodwill AIVA built in the first two minutes gets spent undoing the frustration of starting over.
What actually lands in Freshdesk
Connected to Freshdesk, AIVA routes unresolved conversations from voice, chat, or SMS to your agents as a ticket that already contains what happened — the full conversation across whichever channel it came in on, what AIVA already tried, and any customer or order details it pulled up along the way. An agent opening the ticket isn't starting from a blank field. They're starting from where AIVA left off.
Say a customer calls to cancel and rebook an appointment, but also mentions they were charged twice last month. AIVA handles the reschedule itself and hands the billing question to Freshdesk as a ticket — the reschedule noted, the billing concern flagged, and the full transcript attached, so the agent picking it up isn't guessing which part of the conversation is actually why the ticket exists.
Getting escalations to the right team
Beyond creating a ticket, AIVA routes based on what the conversation was actually about — a billing question to your billing group, a product issue to support, anything urgent tagged accordingly. That routing uses the groups and rules you've already set up in Freshdesk; AIVA feeds the triage system you have rather than introducing a second one to maintain.
For teams running SLAs by ticket type, a ticket that's correctly tagged the moment it's created starts its clock in the right place, instead of losing time to manual re-routing.
What AIVA needs from Freshdesk to route well
Getting routing right depends on AIVA actually knowing the shape of your Freshdesk setup, so it's worth being clear about what it reads versus what it produces. On the read side: your existing groups, the priorities your team already uses, and enough of a customer's history to recognise a returning contact and avoid creating a duplicate ticket for the same issue. None of that requires rebuilding anything — AIVA maps to the groups and priority levels you already have, rather than asking you to adopt a new set to accommodate it.
On the write side, a ticket AIVA opens carries the conversation, the group and priority it's been tagged with, and any order or account detail pulled up along the way — populated the moment the ticket's created, not filled in by a follow-up sync. What it doesn't do is touch anything upstream of the ticket itself: existing scenario automations, dispatch'r rules, and any other automation you've already built in Freshdesk keep running exactly as configured. AIVA's ticket is an input to those systems, the same as a ticket created by a customer emailing in directly — it doesn't bypass or duplicate the routing logic your team already built, it feeds it.
This is also where the SLA answer in the FAQ above actually comes from mechanically: because AIVA reads your priority and group definitions rather than picking arbitrary values, a ticket it opens starts its SLA clock against the same policy any other ticket in that group would — there's no separate, AIVA-specific SLA track running in parallel that your team would need to track differently. That distinction is what makes this safe to turn on without an implementation project: connecting Freshdesk doesn't mean re-deciding how your support team is organised, it means making sure the tickets landing in that structure already have the right information attached the moment they arrive.
What a busy afternoon looks like
A customer texts asking to reschedule, then mentions in the same conversation that a part they were promised hasn't arrived. AIVA handles the reschedule directly — no ticket needed for that part — and opens a single Freshdesk ticket for the missing part, tagged to whichever group handles fulfilment issues, with the reschedule noted as context rather than treated as a second problem. The agent isn't juggling two tickets for one conversation, and isn't missing the fact that the customer is already sorted on the scheduling side.
When a conversation doesn't map cleanly to one group
Most conversations that need a human sort neatly into one group — a billing question, a product issue, a fulfilment delay. Some don't. A customer might raise two unrelated things in the same call, or describe an issue that sits right at the boundary between two teams — is a payment that went through twice a billing issue or a technical one? Worth deciding in advance how AIVA should handle that rather than leaving it to guess in the moment.
The practical approach most teams land on is a default or fallback group for genuinely ambiguous cases — somewhere a generalist or a team lead does a quick first read and redirects, rather than AIVA forcing a specific-but-possibly-wrong group just to avoid the ambiguous one. That's a better outcome than a confidently-wrong routing decision, because a ticket that lands in the wrong specialist group can sit longer than one that lands in a general queue precisely built to catch what doesn't fit cleanly elsewhere.
Where a single conversation genuinely covers two separate issues — the reschedule-and-billing-question pattern is the common version — AIVA's approach is to handle what it can resolve directly (the reschedule) and open a ticket only for the part that needs a person (the billing concern), tagged to the group that fits that specific part rather than the conversation as a whole. The ticket reflects the actual open question, not a bundle of everything that came up along the way, which matters for whoever picks it up: they're working one clear issue, not untangling which part of a multi-topic conversation is the reason the ticket exists. Whichever fallback group you choose is worth revisiting after the first few weeks live — it's the kind of thing that's hard to get exactly right before you've seen what your actual ambiguous cases look like, and easy to adjust once you have a handful of real examples instead of a hypothetical one.
Considerations before you connect
Worth deciding upfront: how AIVA's escalation categories should map onto your existing Freshdesk groups and priorities — getting this right the first time avoids a stretch of tickets landing in a generic queue while the mapping gets refined. It's also worth agreeing on which conversations are urgent enough to notify an agent directly the moment a ticket's created, versus which can simply sit in the queue at normal priority. And if your team already tracks customers by phone number or email in Freshdesk, confirm AIVA is matching against the same identifying details, so a returning customer's ticket lands against their existing profile rather than a fresh one.
Setting it up
Connect your Freshdesk account, map AIVA's escalation categories to your existing groups and priorities, and decide which conversations should notify an agent directly versus simply queue. Setup takes one session and doesn't require changing routing rules you've already built.
If escalations on your team currently start with "can you tell me what happened so far," this closes that gap. See it next to similar options — Zendesk, Intercom — in AIVA's other integrations, read how handoffs work more broadly, check pricing, or start free and connect Freshdesk in your first setup session.