Developer Handover Pack
Everything needed to build the automation from scratch: current state, full agent specs, data flow, and the build stack.
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.
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.
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.
// 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.
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.
// 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.
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.
// 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.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.
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.
More documents for this process
Every document generated for Support Ticket Triage & Routing.