Automation · Customer success

How to build ticket to help article drafting

Q: What is ticket to help article drafting?

Finding the questions customers keep asking that no help article answers, grouping the solved tickets by question, drafting an article from the replies that solved them, and publishing only after a named owner reviews it.

Forty customers asked the same question last month and forty agents typed the same answer. The help center still has nothing on it. The model behind finding those gaps from the tickets themselves, the prompts that build it, and what it takes to run it.

Built with Tray Headless

System Zendesk
Step Group by question
Step Draft from answers
Step Review
System Help center

Also Slack

Solved tickets with no linked article are grouped by question, and the biggest groups become draft articles a person reviews before anything is published.

The short answer

What is ticket to help article drafting?

Ticket to help article drafting has four parts: finding solved tickets that no article answered, grouping them by the question the customer was really asking, drafting an article from the replies that actually solved it, and publishing only after a named owner reviews it. The part to protect is the review. A draft written from agents' replies can carry a workaround that is no longer true, a detail about one customer's account, or an answer that was right only once, and a person who knows the product catches those in minutes.

Stage 6 of 6: Help articles from solved tickets. Part of Customer support automation, end to end : every stage, the systems it runs on and the guide that builds it.

What matters here

The tickets show you which articles are missing. Every solved ticket with no linked article is a vote for one.
Group by the question, not the words. Customers describe the same problem a dozen ways.
Draft from the replies that solved it, not from the model's own idea of your product.
Never publish without review. A wrong help article is answered with confidence to every customer who finds it.
Measure repeat tickets on the topic after publishing. That is the only proof the article worked.

Who this is for

You run support operations or own the help center. Agents answer the same questions every week, the knowledge base is written when somebody has time, and nobody can say which articles are missing.

How it works in practice

What has to happen between a question being answered by hand again and an article that answers it for everybody.

1

Solved tickets with no linked article are collected

Every week, from the help desk, with the customer's question and the reply that solved it.
2

They are grouped by the question asked

Tickets about the same problem grouped together however each customer phrased it, with the count and the product area.
3

Groups that already have an article are checked

If an article exists but agents are not linking it, that is a findability problem, and it goes to a different list.
4

The biggest gaps get a draft

Written from the replies that solved the tickets, with account details removed and the source tickets listed.
5

A named owner reviews every draft

The product area's owner edits, approves or rejects it in the help center, with a reminder if it waits.
6

Repeat tickets on the topic are tracked

Before and after the article goes live, so the knowledge base is judged by what it saves.

What ticket to help article drafting is made of

Four parts, and the last one is what makes the rest safe.

Gap finding

Solved tickets with no linked article, collected weekly, so the missing articles are counted rather than guessed.

Grouping by question

Tickets clustered by the problem the customer had, with the count, the product area and the newest example.

Drafts from real answers

Written from the replies that solved the tickets, stripped of anything about one customer's account, with sources listed.

Named review before publishing

Each draft goes to the owner of that product area, and nothing reaches the help center without their approval.

The Tray Headless prompts

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

First, measure how many answers have no article

The size of the gap decides how much this is worth.

Headless skills build-workflow

Use build-workflow. The systems in play are Zendesk with Zendesk Guide,
Slack, Snowflake and OpenAI, or whatever we run in those seats. Before
you plan anything, tell me which of them are already authenticated in
the workspace.

From Zendesk I need solved tickets from the last ninety days with
subject, first customer message, the public replies, product area and
any linked help article. From Guide I need articles with section,
labels, owner and last updated date.

Tell me what share of solved tickets have no linked article, by product
area. That is the starting list.

Group the tickets by the question asked

Customers describe the same problem a dozen ways.

Headless skills build-workflow

Use build-workflow. Each week, take solved tickets with no linked
article and group them by the question the customer was asking, not
the words they used. For each group give me a short title, the count,
the product area and three example tickets.

Check each group against existing articles. Where an article already
covers it, put the group on a findability list for the help center
owner instead of drafting a second article.

Ignore groups smaller than a threshold support sets, and anything about
billing amounts, refunds, security incidents or one customer's
contract. Those are not help articles.

Draft from the replies that solved it

The agents already wrote the answer, forty times.

Headless skills tray-patterns

Use tray-patterns. For the five largest groups each week, draft a help
article from the public replies on tickets that were solved without
reopening. Use only what those replies say. If the replies disagree,
say so in a note to the reviewer instead of picking one.

Remove names, email addresses, account ids, and anything specific to
one customer's setup. List the source tickets at the bottom of the
draft for the reviewer, not in the article.

Save each draft in Guide as an unpublished article in the right
section, and never publish it.

Drafting only from replies on tickets that stayed solved is the guard against copying a workaround that did not work.

Send every draft to a named reviewer

A wrong article is wrong for every customer who reads it.

Assign each draft to the owner of its product area, from a table
support ops keeps. Message them in Slack with the draft link, the
ticket count behind it and the reviewer note. Remind them after three
working days, then tell the help center owner.

Report weekly: drafts created, approved, edited and rejected, time to
review, and for each published article the number of tickets on that
topic in the four weeks before and after it went live.

Validate, then hand the thresholds to support ops

Because what counts as worth an article is support judgement.

Run the per-step schema checks and the whole-workflow audit before this
touches production. Check a sample of drafts for anything customer
specific before the first reviewer sees one.

Then open the same workflow in Tray Build so support operations can
change the group size threshold, the excluded topics and the reviewer
table in the visual canvas.

What it connects to

The tickets hold the answers, the help center holds the articles, and a person decides what is published.

Zendesk

Read solved tickets, their replies and linked articles, and save drafts in Guide as unpublished articles.

Reads and writes

OpenAI

Group tickets by the question asked and draft articles from the replies, with nothing published by the model.

Reads and writes

Slack

Send each draft to its reviewer by name, with reminders when a draft waits.

Writes

Confluence

Read internal runbooks where a product area keeps its source of truth outside the help center.

Reads

Snowflake

Land ticket groups, drafts and review outcomes, so repeat tickets before and after an article are a query.

Writes

Same build, other stacks

The design does not change if you run something else in one of these seats. The same prompts build it against Google BigQuery, Microsoft Teams, Jira, Databricks, Google Chat or ServiceNow.

Connections in this build

Field mapping, templates and common problems for each pairing: Slack + Zendesk and Confluence + Slack.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Running it in production

This writes words customers will read and trust. The review step is the product.

It runs on the platform, not on a laptop

The weekly run reads months of tickets and drafts articles on the same engine as everything else, with every run recorded.

Every draft shows its sources

The tickets it was written from are listed for the reviewer, so a claim in the draft can be checked against what the agent said.

Credentials are managed, never written into the build

The help desk credential reads customer conversations. It lives in your workspace, scoped to solved tickets and unpublished articles.

Support ops owns the rules

Thresholds, excluded topics and the reviewer table open in Tray Build, maintained by the team that owns the help center.

Nothing is published by the workflow

Drafts are saved unpublished and only a named reviewer can publish them. That line does not move.

Questions people ask

How do you find missing help articles?

Look at solved tickets with no linked article, grouped by the question asked. The largest groups are the articles you are missing, and the count tells you which to write first.

Can AI write the help articles?

It can draft them from the replies your agents already wrote. It should not publish them. A person who knows the product reviews each draft, because a wrong article is wrong for every customer who reads it.

What if an article already exists?

Then the problem is findability, not content. Those groups go to the help center owner to fix titles, search terms or linking, instead of becoming a second article.

How do you know an article worked?

Count tickets on that topic in the four weeks before and after it goes live. Page views say people found it. Fewer tickets say it answered them.

How is this different from syncing the knowledge base to an AI assistant?

That sync makes existing articles available to an assistant. This finds the articles that do not exist yet. The two work well together: every article this adds is one more thing the assistant can answer from.

Related guides

AI operations