Customer support knowledge bases drift. Tickets surface new failure modes daily, but articles get updated only when someone notices the gap. A Dock-attached agent reads recent tickets across Zendesk Guide, Help Scout, and Confluence, drafts article updates, and routes them to a human editor for sign-off. The platforms stay the source of truth for tickets and published articles. Dock stores the drafts, the linked tickets that prompted them, and the editor who approved each change. Nothing publishes until a named person reviews it.
Zendesk Guide, Help Scout, and Confluence 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 KB Drafts table
The agent writes one row per proposed article change. The editor opens the row, reads the supporting tickets, and approves, edits, or rejects.
| draft_id | source_tickets | target_article | change_type | agent | reviewer | status | published_at |
|---|---|---|---|---|---|---|---|
| kb-2041 | ZD-88412, ZD-88503, HS-11209 | confluence:/kb/sso-okta-loop | update | mei-cs-kb | jordan.h | approved | 2026-05-28T15:02Z |
| kb-2042 | HS-11241, HS-11244 | (new) /kb/billing-proration-q2 | create | mei-cs-kb | pending | draft | null |
| kb-2043 | ZD-88611 | confluence:/kb/api-rate-limits | update | mei-cs-kb | maria.l | rejected | null |
Each draft row links out to the original ticket IDs in Zendesk and Help Scout, the Confluence page slug, and the diff the agent proposes. The reviewer column is a human handle, never the agent. Rejected drafts keep the reasoning so the next pass learns from it. See agent audit and compliance for the attribution model that backs this.
One workflow, end to end
Every weekday at 09:00, the agent pulls tickets closed in the last 24 hours from Zendesk Guide and Help Scout. It clusters them by topic, checks each cluster against the matching Confluence article, and writes a Dock draft row when an article is stale, missing, or contradicts the resolution pattern. The draft row contains the proposed diff, the ticket IDs it learned from, and a confidence note.
Jordan, the docs editor, opens Dock at 10:00 and sees the queue. For kb-2041, the agent has noticed three tickets where the documented Okta SSO loop fix no longer applies because Okta changed the consent screen in April. Jordan opens the linked tickets, reads the proposed diff, edits two sentences, and clicks approve. Dock writes the new content to Confluence via API, stamps published_at, and posts the diff plus reviewer name back to the Confluence page history. The Zendesk and Help Scout tickets get a comment linking to the updated article.
For kb-2042, Jordan needs another opinion on a brand-new billing article and assigns it to Maria. For kb-2043, the proposed change conflicts with the API team's plan, so Maria rejects with a one-line reason. The agent will not redraft that topic for 30 days. See how to run customer support with AI for the broader operating loop.
Why this matters
Knowledge-Centered Service (KCS Academy) is built on the principle that knowledge becomes a byproduct of solving problems. Most teams cannot sustain this because manually translating tickets into articles is expensive. Agents make the translation cheap; Dock makes the review trustworthy. Zendesk's 2026 guide on knowledge management lists "continuously updating content" as the hardest of the five core steps. A reviewable draft queue, not autopublish, is the answer. Read agent identity for why the agent handle must be distinct from any human's, and IT knowledge base for the same pattern applied to internal docs.
FAQ
Q: Why not let the agent publish directly to Confluence? A: Because published articles carry organizational authority. The reviewer column in the Dock table is what gives each change a human owner of record. The audit trail needs that name.
Q: What happens when Zendesk and Help Scout describe the same issue differently? A: The agent clusters on resolution pattern, not wording. The draft row lists all source ticket IDs across both platforms, and the editor sees them side by side before approving.
Q: Does the agent overwrite human edits to Confluence? A: No. Before drafting an update, the agent re-fetches the current Confluence page via API. If the page changed since the last draft, the agent opens a fresh diff against the new version rather than overwriting.
Q: How does this differ from a Zendesk macro generator? A: Macros are response templates for agents. This workflow updates the public knowledge base that customers and support staff both read. The Dock row tracks article provenance, not reply text.
