---
title: "Dock for CS: ticket-routing workflow with attributed support-team owner"
excerpt: "Dock runs ticket routing as an agent-drafted, human-approved decision. The agent reads the Zendesk, Intercom, or Freshdesk ticket plus customer signals, proposes a queue and owner, and a support-team lead approves before the routing fires."
author: mei
category: Use Cases
date: "2026-05-30"
---

Ticket routing is the first decision in every support workflow. In Dock, that decision is drafted by an agent, attributed to a named identity, and approved by a support-team owner before it lands. The agent reads the inbound ticket from Zendesk, Intercom, or Freshdesk, pulls customer signals, proposes a queue and assignee, and waits. Nothing reroutes until a human signs off.

Zendesk, Intercom, and Freshdesk stay the system of record for the raw data. Dock is the system of record for what the AGENT INTERPRETS. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.

## The routing-decision table

One Dock table holds the agent's drafts. The support-team owner column is the approver, not a label.

| Ticket | Customer tier | Agent draft | Proposed queue | Proposed owner | Reviewer | Status |
|---|---|---|---|---|---|---|
| ZD-48211 (billing error) | Enterprise | Refund-eligible, needs Tier 2 billing | Billing-T2 | priya.r | morgan.lee | Approved |
| INT-9032 (login loop) | SMB | Likely SSO regression, route to auth | Auth-T1 | dan.k | morgan.lee | Approved |
| FD-1177 (feature ask) | Free | Not a ticket, convert to product feedback | Feedback-intake | (n/a) | morgan.lee | Rejected, kept in queue |

The agent identity (`triage-bot@dock`) is on every row. The reviewer is a human lead. Rejected drafts stay visible so the team can see what the agent guessed wrong.

## The workflow

A ticket arrives in Zendesk. A webhook posts the ticket ID to Dock. The agent fetches the ticket body and customer record through the API, pulls the account tier, recent history, and any active incident flags. It drafts a routing decision with queue, owner, reason, and confidence. The draft writes to the table above with status `Pending`.

Morgan, the support-team owner on shift, sees the pending row. She reads the agent's reason, checks the linked ticket, and clicks Approve. Dock calls the Zendesk API and applies the assignment. The row flips to `Approved` and the timestamp locks. If Morgan rejects, the ticket stays in the general queue. Either way, the decision is attributed: agent drafted, human owned.

## Why this matters

Routing used to vanish into macros and trigger chains. When something went wrong, nobody could reconstruct who made the call. Dock keeps the draft, the reasoning, the approver, and the platform pointer in one row. Audit becomes a query. Training the next version of the agent becomes a filter on rejected rows.

Zendesk's 2026 CX Trends report finds [95% of consumers expect an explanation from AI-made decisions](https://cxtrends.zendesk.com/), and only 37% of CX leaders provide it today. Forrester argues [agentic customer service depends on structured knowledge and operational readiness](https://www.forrester.com/blogs/category/customer-experience/), not just model quality. The routing table is where both land: reasoning logged, structure enforced, human on the hook.

This is the routing layer of the broader pattern in [Dock for customer support](/blog/dock-for-customer-support) and the playbook in [how to run customer support with AI](/blog/how-to-run-customer-support-with-ai). The attribution model comes from [agent audit and compliance](/blog/agent-audit-and-compliance) and [agent identity](/blog/agent-identity). For the upstream triage step that feeds this table, see [AI ticket triage](/blog/ai-ticket-triage). For why a named agent, not a service account, owns the draft, see [agent identity](/blog/agent-identity) again.

Spin up the routing-decision table in your Dock workspace and point your Zendesk, Intercom, or Freshdesk webhook at it.

## FAQ

**Does the agent ever route without human approval?**
No. The agent drafts; an owner approves. The platform API call only fires after approval.

**What if the platform record changes after the draft is written?**
The agent re-fetches the ticket and customer record at approval time. The reviewer sees any delta before signing off.

**How does this differ from native Zendesk triggers or Intercom rules?**
Triggers fire on conditions. Dock attributes the decision to a named agent and a named reviewer, with reasoning stored.

**Can the same workflow run across all three platforms at once?**
Yes. Each row points to its source platform record. The agent identity and schema are shared across queues.