Key takeaways
Key takeaways

Key takeaways

What this agent does

A typical Freshdesk team has between four and twelve groups: Tier 1 Support, Billing, Technical, Sales, Account Management, Trust and Safety, and so on. New tickets land in a single inbox or in a per-channel inbox. A human triages them. On a busy day the human falls behind by ninety minutes. SLAs slip. The slipping happens at the triage step, not in the responding step.

The agent eliminates the triage step. It listens for Freshdesk's ticket_created webhook, reads the subject and description, picks the right group from your routing rubric, picks a skill within that group when groups use skill-based routing, sets a priority, and writes those three fields back to Freshdesk. The whole loop takes under three seconds for ninety-eight percent of tickets, and Freshdesk's own SLA timers start with the right team already on the hook.

What the agent does not do: it does not reply, does not write private notes, does not close, does not merge with related tickets, does not contact the customer for additional information. Every responsibility outside routing stays with humans. The constraint exists because routing is a small, well-defined problem and stretching the agent's scope is how routing accuracy gets diluted. The same logic appears in how an agent handles Zendesk ticket triage.

Sources of truth

Freshdesk only, plus a YAML rubric you maintain.

The agent ignores ticket history, attachments, and the customer's past tickets. Including history sounds smart and produces inconsistent routing because the same description can have been a billing issue yesterday and a technical issue today. The new ticket, on its own, is the input.

Three fields the agent writes

Three fields and no others. Adding fields was tried; each one made routing worse because the agent began to optimise for completeness of the ticket record rather than accuracy of the route.

Group

One of the groups in your Freshdesk account. The rubric lists each group with a paragraph describing what belongs to it. The agent reads the ticket, reads the rubric, and picks one group. The choice is required. If no group fits with confidence above the threshold, the ticket routes to Triage.

Skill

Within groups that use Freshdesk's skill-based routing, the agent picks a skill. Examples: in Technical, skills are Database, Auth, API, Integrations. In Billing, skills are Plan Changes, Refunds, Invoicing, Tax. The skill list is loaded from the Freshdesk admin settings at the start of each run.

Priority

Low, Medium, High, or Urgent. The mapping is fixed in the rubric. Examples: any ticket from a plan tier above a threshold defaults to High. Any ticket mentioning data loss, security, or outage defaults to Urgent. Most tickets default to Medium. Low is reserved for tickets the rubric explicitly tags as such (welcome questions, feature requests). The agent does not invent priorities; it follows the matrix.

The custom Source field is a hidden fourth field the agent always writes, it records that the routing came from the agent, not a human. This is the audit trail. Anything routed by the agent can be filtered, audited, or rolled back. The same audit-trail principle is described under agent audit trails.

Output: routed in three seconds

The customer-visible outcome is that the ticket disappears from the inbox and shows up under the right group within a few seconds. The agent-visible outcome is a log line in your monitoring tool with the ticket id, the chosen group and skill, the priority, and the confidence score.

For tickets that land in Triage (below the confidence threshold) the agent additionally writes a private note on the ticket explaining why. The note says, for example, "Two plausible groups: Billing (0.62), Technical (0.58). Below the 0.85 threshold for auto-route. Customer mentions both 'payment failed' and 'API error'." A human reads the note, picks a group in three seconds, and moves on. The note is the difference between a Triage queue and a black box. The same idea appears in how to debug an agent that did the wrong thing.

Guardrails

Three guardrails are mandatory.

The agent rate-limits its updates to under ten per second to stay below the Freshdesk API quota even on a peak hour. The cap matters in onboarding when a customer imports a thousand tickets via the API; without the cap a sudden burst would trip rate limits and a chunk of tickets would land in Triage by default.

Common mistakes

Letting the agent set the status. Status transitions affect the customer experience. Auto-setting Pending or Closed has caused customers to feel ignored. The agent leaves status alone. If a workflow requires moving status, that is a Freshdesk automation, not the agent.

Using the rubric for replies. A rubric describes what belongs to each group. It is not a knowledge base. The temptation to let the agent paste the relevant rubric section as a customer reply produces robotic responses. Routing and replying stay separate.

Confidence threshold too low. A threshold of 0.6 puts everything ambiguous straight into a group. A threshold of 0.95 puts too much into Triage and humans complain. 0.85 is the practical default; tune it from the data after the first month.

Skipping the private note in Triage. The note is the agent's way of saying "I am not sure". Without it Triage agents have to re-classify from scratch. The note saves them at least thirty seconds per ticket and builds trust in the agent's classifier.

Counting reassignments as agent errors. Some reassignments are not corrections; they are escalations. A Tier 1 group routing a ticket to Trust and Safety after investigation is not an agent mistake. Distinguish escalations from corrections in the training loop or the agent overfits on noise. The same trap appears in agent evaluation metrics.

Frequently asked questions

Can an AI agent route Freshdesk tickets?

Yes. The agent listens for the ticket_created webhook in Freshdesk, reads the subject and description, classifies the ticket against your routing rules, and writes the group, skill, and priority fields. The whole loop completes in under three seconds for ninety-eight percent of tickets.

How is this different from Freshdesk's built-in dispatch rules?

Dispatch rules branch on keyword presence and customer fields. They work for the predictable seventy percent of tickets. The agent reads the entire ticket as text and handles the long tail where the customer describes the problem in their own words, including the cases that none of the dispatch rules anticipated.

Will the agent reply to customers?

No. The agent updates ticket fields only. It sets the group, skill, priority, and a custom Source field. It does not send a reply, send a private note, change the ticket status, or close the ticket. Customer replies belong to humans by default and to a separate response agent if you want them automated.

What happens when the agent is wrong?

When an agent in the receiving group reassigns the ticket, the agent records the correction. The routing model improves on tickets resembling that correction. After about one hundred corrections per group the agent's accuracy on that group's ticket flow exceeds ninety-five percent.

Does this work for the Freshservice and Freshdesk APIs?

Yes. Both APIs share the same v2 schema with minor differences in the priority and status enums. The routing logic and field mapping are identical between the two. A single configuration covers both products in a Freshworks workspace that uses them together.

Three takeaways before you close this tab

  1. Route only. Three fields, never more. The agent is a router, not a help desk agent.
  2. Triage is a group. The agent's "I am not sure" becomes a queue, not a guess.
  3. The rubric is plain text. If you cannot write a paragraph describing what a group is for, the group does not exist.

Sources