Event Automation

Zendesk Ticket Triage Agent: Classify, Search the KB, Route to Slack

A deterministic triage pipeline that wakes on each new Zendesk ticket, classifies it with an LLM, searches a Notion knowledge base, posts a structured alert to the right Slack channel, and writes tags, priority, and a draft reply back to Zendesk.

What This Builds

This recipe builds a support-triage agent that runs the same five steps on every new ticket and then exits — a deterministic pipeline, not an open-ended reasoning loop. That design choice (no persistent memory, same structure every run) is what makes it predictable, testable, and safe to run in production. By the time a human opens the ticket, triage is already done.

For each new ticket the pipeline: classifies it, retrieves relevant knowledge-base articles, posts a structured alert to the correct Slack channel, and writes the result back to Zendesk as tags, priority, and a private internal note with a suggested reply.

Architecture

New Zendesk ticket (poll or webhook)

Fetch new/open tickets

LLM classify: category, severity, summary

Search Notion KB (top 3 articles)

Post structured alert to team channel

Write tags + priority + internal note to Zendesk

The Stack

  • Zendesk as the ticket source and the system of record written back to.
  • Notion as the knowledge base searched per ticket (query a specific KB database for speed and precision).
  • Slack as the alert/routing surface — each category maps to a channel.
  • An LLM via OpenRouter (e.g. a small, cheap model) for the structured classification step, with a keyword-based fallback when the model is unavailable.

Step-by-Step Outline

  1. Trigger. Poll Zendesk for new/open tickets on an interval, or wire a new-ticket webhook. De-duplicate against a local processed-tickets state file so restarts do not re-triage.
  2. Classify. Send subject + description to the LLM with a structured prompt; get back category, severity, summary, and suggested response as JSON. Validate the JSON and fall back to keyword rules if it is malformed.
  3. Retrieve. For tickets that benefit from docs (bug, how-to, account), search the Notion KB using the LLM summary as the query — summaries retrieve better than raw subjects. Skip retrieval for categories like billing.
  4. Route. Post a structured alert to the category’s Slack channel (severity, summary, KB links, draft reply). If the bot is not in the target channel, retry on a fallback triage channel so no alert is lost.
  5. Write back. Update Zendesk tags and priority, and add a private internal note with the full triage context, so anyone opening the ticket in Zendesk has the same context as Slack.

Each step is independent: if Notion is down, the ticket still gets classified, routed, and tagged. The Zendesk write-back always runs last.

Why This Shape Works

The triage bottleneck is rarely a technology gap — the tools (Zendesk, a KB, Slack) are already in use. The value is running the same classify → search → route → update cycle consistently for every ticket without manual effort. Keeping the agent stateless and deterministic makes failures isolated and the whole thing easy to reason about and extend (new category = new prompt label + new channel mapping).

Source