Back to Support Ticket Triage & Routing

Developer Handover Pack

Everything needed to build the automation from scratch: current state, full agent specs, data flow, and the build stack.

4 pagesPDF · Technical
FS-DOC-04Technical

Developer Handover Pack

Support Ticket Triage & Routing

[YourCompany.com] · Customer Support Department · Prepared by FullSpec · [Today's Date]

This document provides the technical foundation for building and deploying the Support Ticket Triage & Routing automation. It contains the current-state process map, detailed agent specifications with implementation logic, end-to-end data flow diagrams, and the recommended build stack. Use this pack to guide development of the Ticket Analyzer and Smart Router agents, configure integrations with Zendesk, Slack, and HubSpot, and validate the build against the process map. FullSpec has designed and tested all agent logic; your role as developer is to implement these specifications in your chosen automation platform, test against real ticket samples, and prepare the system for handoff to the support team.

01Process snapshot

The current support ticket triage process is manual and distributed across seven distinct steps. A support agent or team lead performs each step sequentially for every incoming ticket. The table below maps each step, names it, describes what happens, and flags bottlenecks.

Step
Name
Description
Time
1
Check Ticket Inbox
Agent opens Zendesk and reviews new tickets in chronological order with no pre-sorting.
5 min
2
Read Ticket Body
Agent opens each unassigned ticket and reads the customer message, subject, and attachments to understand the problem.
8 min (BOTTLENECK)
3
Identify Issue Category
Agent mentally matches ticket content against known categories: billing, technical, account access, feature request, or complaint. Judgment is inconsistent.
5 min (BOTTLENECK)
4
Assess Urgency Level
Agent scans for keywords and context clues like payment failure, service outage, or angry tone to decide if ticket is low, normal, or high priority.
4 min
5
Tag and Categorize in Zendesk
Agent manually adds priority tags, category tags, and custom fields to the ticket record. Tags must match company standard list.
3 min
6
Route to Queue or Agent
Agent assigns the ticket to a specific queue (billing, technical, premium) or directly to a team member based on availability and specialization.
4 min (BOTTLENECK)
7
Notify Assignee via Slack
Agent manually sends a message to Slack channel or assigned agent to alert them that a new ticket is waiting. Notifications are often delayed or missed.
2 min
8
Monitor for Reassignment
Team lead periodically checks if misrouted tickets need to be moved or if high-priority tickets are still waiting. Catch-and-fix cycle repeats throughout the day.
6 min
Manual triage takes 37 minutes per ticket. At 350 tickets per month, the team spends 9.5 hours per week reading, categorizing, and assigning tickets. The three bottlenecks (read, categorize, route) account for 17 of those 37 minutes and introduce routing errors that cascade into re-work and customer frustration.
Developer Handover PackPage 1 of 4
FS-DOC-04Technical

02Agent specifications

Two AI agents replace the manual triage cycle. Each agent is described below with its trigger, connected tools, implementation notes, and input/output flow.

Ticket Analyzer

Reads the incoming ticket body and extracts the issue type, customer sentiment, and any critical keywords that signal urgency or special handling. Uses natural language understanding to categorize the problem and flag emotional tone. This agent replaces the manual steps of reading the ticket body, identifying the category, and assessing urgency.

Trigger
A new ticket arrives in Zendesk from email, web form, or chat channel.
Tools
Zendesk API (read ticket), Gmail API (if forwarded), NLP/LLM service
Replaces steps
2 (Read Ticket Body), 3 (Identify Issue Category), 4 (Assess Urgency Level)
Estimated build
50 hours, Moderate complexity
// Input
Zendesk ticket object {
  ticket_id: string,
  subject: string,
  description: string (full body),
  requester_email: string,
  created_at: ISO8601,
  custom_fields: object
}

// Agent processing
1. Tokenize and clean ticket text
2. Extract named entities (product, payment status, keywords)
3. Apply category classifier (billing | technical | account | feature | complaint)
4. Compute sentiment score (negative, neutral, positive) via LLM
5. Identify urgency signals (service down, payment failed, angry tone, multiple messages)
6. Assign priority: high (urgency signals + negative sentiment), normal (neutral tone), low (feature/question)

// Output
Classification object {
  ticket_id: string,
  category: 'billing' | 'technical' | 'account' | 'feature' | 'complaint',
  sentiment: number (-1.0 to 1.0),
  urgency_signals: string[],
  priority: 'low' | 'normal' | 'high',
  confidence: number (0.0 to 1.0),
  reasoning: string (human-readable explanation)
  timestamp: ISO8601
}

Implementation notes:

  • Use a pre-trained LLM (GPT-4, Claude, or equivalent) fine-tuned on a sample of 50-100 classified tickets from [YourCompany.com]'s historical data.
  • Store category taxonomy and confidence thresholds in a config JSON file so the support team can add or rename categories without code changes.
  • If confidence score is below 0.70 or the ticket matches multiple categories with similar probability, flag it for manual review in a 'low_confidence_queue' rather than guessing.
  • Cache the tokenized ticket text and embeddings to speed up re-classification if a ticket is re-submitted or updated.
  • Log all classification decisions to a central audit log (timestamp, ticket_id, category, confidence, human override if any) for accuracy tracking and retraining.
Smart Router

Takes the categorized ticket from the Ticket Analyzer and matches it against routing rules and team availability. Selects the best queue or agent based on expertise, current workload, and SLA targets. Escalates edge cases to a human reviewer. This agent replaces the manual assignment step and optimizes for speed and accuracy.

Trigger
After the Ticket Analyzer completes classification and returns a priority and category.
Tools
Zendesk API (read queue depth and agent availability), HubSpot API (customer tier and history), internal routing rules database
Replaces steps
5 (Tag and Categorize in Zendesk), 6 (Route to Queue or Agent)
Estimated build
40 hours, Moderate complexity
// Input
Classification object from Ticket Analyzer {
  ticket_id: string,
  category: string,
  priority: 'low' | 'normal' | 'high',
  confidence: number,
  sentiment: number,
  requester_email: string
}

// Agent processing
1. Query routing rules table: category -> queue or agent pool
2. Look up customer tier in HubSpot by email (enterprise, premium, standard, free)
3. Apply SLA from rules: e.g., high + enterprise = 2hr response time
4. Poll Zendesk queue depth and agent availability (agents with < 5 open tickets)
5. Score each eligible agent: (expertise match + capacity + recent assignment history)
6. If high priority, bypass normal queue and assign directly to senior agent or escalation queue
7. If category is uncertain (low confidence from Analyzer), route to triage team lead instead
8. Return assignment decision and SLA deadline

// Output
Routing decision object {
  ticket_id: string,
  assigned_queue: string,
  assigned_agent_email: string | null,
  sla_target_hours: number,
  sla_deadline: ISO8601,
  assignment_reason: string (human-readable),
  escalation: boolean,
  timestamp: ISO8601
}

Implementation notes:

  • Routing rules are stored in a JSON or CSV file with columns: category | queue_name | sla_hours | preferred_agent_pool. Maintain this file in a version-controlled repo so the team can update rules without re-deploying the agent.
  • Polling agent availability is a lightweight read on the Zendesk queue endpoint; cache the result for 2-3 minutes to avoid rate-limit issues.
  • If no available agent is found in the preferred pool, fall back to the secondary pool or queue the ticket with an SLA bump (add 2 hours to the deadline).
  • High-priority tickets (service down, payment failed) bypass normal queue assignment and go directly to a dedicated escalation queue or team lead. This queue is checked every 5 minutes.
  • Log all routing decisions including the rule matched, agent selected, and any overrides applied by the team lead (for accuracy auditing).
  • Implement a 'low_confidence' routing path: if Ticket Analyzer confidence is below threshold, route to team lead for manual triage rather than auto-routing.
Developer Handover PackPage 2 of 4
FS-DOC-04Technical

03End-to-end data flow

The diagram below traces a ticket from ingestion through automation, showing field names, agent handoffs, and data writes to downstream systems.

Complete trigger-to-outcome data flow with agent handoffs and field mappings
// TRIGGER: Zendesk webhook fires on new ticket creation
POST /webhook/ticket-created
Payload: {
  ticket_id,
  subject,
  description,
  requester_email,
  channel (email | web | chat),
  created_at
}

// AGENT 1: Ticket Analyzer
Input: ticket object from Zendesk API GET /tickets/{ticket_id}
Process: NLP classification on subject + description
Output: {
  ticket_id,
  category: 'technical' | 'billing' | 'account' | 'feature' | 'complaint',
  priority: 'high' | 'normal' | 'low',
  sentiment: float (-1.0 to 1.0),
  confidence: float (0.70 to 1.0)
}

// AGENT 2: Smart Router (receives Analyzer output)
Input: Classification from Agent 1 + requester_email
Lookup 1: HubSpot GET /crm/v3/objects/contacts (filter by email)
  Returns: customer_tier, customer_id, account_name
Lookup 2: Zendesk API GET /queues or /agent_groups
  Returns: agent availability, queue depth, SLA rules
Process: Match category to routing rule, select best agent/queue
Output: {
  ticket_id,
  assigned_queue: 'billing_queue' | 'technical_queue' | ...,
  assigned_agent_email: 'agent@company.com' | null,
  sla_deadline: ISO8601,
  escalation: boolean
}

// WRITE 1: Update Zendesk ticket
PATCH /tickets/{ticket_id}
Fields: {
  custom_field_category: category from Analyzer,
  custom_field_priority: priority from Analyzer,
  custom_field_sla_deadline: sla_deadline from Router,
  assigned_group_id: queue_id from Router,
  assigned_user_id: agent_id from Router (if direct assign),
  status: 'assigned' (was 'new')
}

// WRITE 2: Send Slack notification
POST https://hooks.slack.com/services/YOUR_HOOK_ID
Message: {
  channel: '#support_' + assigned_queue,
  text: ':ticket: New ' + priority + ' ticket',
  blocks: [
    { type: 'section', text: { type: 'mrkdwn', text: 'From: ' + requester_email } },
    { type: 'section', text: { type: 'mrkdwn', text: 'Issue: ' + subject } },
    { type: 'section', text: { type: 'mrkdwn', text: 'Category: ' + category } },
    { type: 'section', text: { type: 'mrkdwn', text: 'SLA: ' + sla_deadline } },
    { type: 'actions', elements: [ { type: 'button', text: 'Open in Zendesk', url: zendesk_ticket_url } ] }
  ]
}

// WRITE 3: Log to HubSpot CRM (customer context)
POST /crm/v3/objects/tickets
Fields: {
  hs_ticket_id: ticket_id,
  hs_ticket_subject: subject,
  hs_ticket_category: category,
  hs_ticket_priority: priority,
  hs_ticket_assigned_to: assigned_agent_email,
  hs_ticket_sla_deadline: sla_deadline,
  hs_ticket_triage_timestamp: now(),
  associated_contact: customer_id
}

// DECISION: Is priority == 'high'?
If yes:
  POST /notify-team-lead
  Message: Urgent ticket {ticket_id} assigned to escalation queue

// OUTPUT: Automation complete
Time elapsed: ~2-3 seconds (vs 37 minutes manual)
Result: Ticket is categorized, assigned, notified, and logged.
Developer Handover PackPage 3 of 4
FS-DOC-04Technical

04Recommended build stack

This section specifies the technology stack for implementing and hosting the Support Ticket Triage automation. Use these recommendations to select tools, configure APIs, and set up the development and production environments.

Orchestration layer
A workflow automation platform (n8n, Make, Zapier, or similar) that can listen for Zendesk webhooks, invoke LLM APIs, call Zendesk/HubSpot/Slack APIs, and execute branching logic. Must support long-running workflows (up to 30 seconds per ticket) and error retry with exponential backoff.
Webhook config
Configure Zendesk to POST to your automation platform whenever a new ticket is created. Webhook event: ticket.created. Include full ticket object in payload (subject, description, requester_email, custom_fields). Use HMAC-SHA256 signature validation to verify webhook authenticity. Set up a dead-letter queue for failed webhooks; re-process them every 5 minutes for up to 24 hours.
Templating
Use Jinja2 or Handlebars templates for Slack message formatting and email notification bodies. Store templates in a version-controlled repo (Git) so the support team can adjust wording without code changes. Example templates: slack_new_ticket.json, slack_escalation.json, email_assignment_confirmation.txt.
Error logging
Log all agent decisions, API calls, and errors to a centralized service (CloudWatch, Datadog, Sentry, or equivalent). Include timestamp, ticket_id, agent_name, input data, output data, and any exception stack trace. Set up alerts for: API rate limits exceeded, Zendesk/HubSpot/Slack connection failures, LLM timeout, and classification confidence below threshold. Retention: 90 days for logs, 1 year for audit trail.
Testing (sandbox-first)
Use separate Zendesk, HubSpot, and Slack workspaces for development and staging. Test all agents with 50+ real ticket samples in staging before deploying to production. Sandbox tests must cover: normal tickets (all 5 categories), high-priority scenarios (payment failure, service down), low-confidence edge cases (spam, threats, multi-product issues), and error paths (API timeouts, missing customer in HubSpot). Test Slack message rendering across desktop and mobile. Use load testing to verify the platform handles 350 tickets per month (avg 12/day, peak 30/day) without delays.
Estimated total build time
120 hours (50 hours Ticket Analyzer + 40 hours Smart Router + 20 hours integration, testing, and documentation + 10 hours API credential setup and runbook review)

API credentials and secrets must be stored in environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault, or equivalent). Never commit API keys to version control. Rotate Zendesk, HubSpot, and Slack API tokens every 90 days. Grant the automation platform the minimum permissions required: Zendesk (create/update tickets, read queue/agent data); HubSpot (read contacts); Slack (send messages). Log all API calls with timestamp and response code for audit purposes.

Before launching to production, run a 1-week pilot on a 50% sample of incoming tickets (approximately 175 tickets). Monitor classification accuracy, routing correctness, and Slack notification delivery. Collect feedback from 2-3 support agents and the team lead. If accuracy is below 90% on first-try routing, adjust category rules or confidence thresholds and re-test before full rollout.
Developer Handover PackPage 4 of 4

More documents for this process

Every document generated for Support Ticket Triage & Routing.

Launch Plan
Operations · Owner
View
ROI and Business Case
Finance · Owner
View
Process Runbook / SOP
Operations · Owner
View
Integration and API Spec
Technical · Developer
View
Test and QA Plan
Quality · Developer
View