Resolved tickets tell you what your help centre gets wrong. The agent reads them in batches, groups them by the question asked, and compares each group with the article that should have answered it. It drafts new articles and corrections with the tickets as evidence. Article owners decide what is true; the agent never turns one agent's workaround into policy.
What is the process, and who owns it?
Every week your team resolves tickets that a good article would have prevented. Some questions have no article. Some articles exist but say something staff now routinely contradict. Some articles are correct but customers still cannot follow them. The process turns that evidence into specific changes, each with an owner.
The help centre editor owns the process and the queue of proposed changes. Each article has a named owner from product, policy or operations who answers for its content. The support team leaders own the ticket categories. The broader support position is in the AI support agent that knows when to say no.
How does it work, step by step?
- Agent, depth 1: reads resolved tickets for the period. Customer message, staff replies, resolution code, category. It removes names, account numbers and other personal data from anything it carries forward. Evidence: the ticket set read and the redaction applied.
- Agent, depth 1: groups tickets by the question asked, not by the category staff chose, because categories are often picked in a hurry. Evidence: each group with its member tickets.
- Agent, depth 1: matches each group to the help centre. It reads the live articles through the connection described in connecting an AI agent to your help centre. Evidence: the article matched, or none.
- Agent, depth 2: labels each group as one of four findings: no article; article contradicted by how staff resolved it; article correct but customers still asked; article fine, nothing to do. Evidence: the finding and the tickets that support it.
- Agent, depth 1: checks contradictions against sealed sources. If staff keep telling customers something the article does not say, the agent checks the policy library or product terms. Staff replies are declared; the policy is sealed. Evidence: the source consulted and what it says.
- Agent, depth 2: drafts the change. A new article, a correction, or a clearer rewrite, with each changed sentence linked to its source. Evidence: the draft and its source map.
- Person, article owner: decides. Approve, edit or reject, with a reason. Evidence: the decision filed against the draft.
- Agent or person: publishes. Under the separate grants set out in letting an AI agent publish help centre articles. Evidence: the publish verdict and the prior version.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read tickets | Reads and redacts resolved tickets | 1 | Nothing |
| Group | Clusters by question asked | 1 | Nothing |
| Match | Finds the relevant article | 1 | Nothing |
| Label | Assigns one of four findings | 2 | Disputed findings |
| Check | Compares staff practice with policy | 1 | Deciding which is right |
| Draft | Writes the change with sources | 2 | Wording on sensitive pages |
| Decide | Prepares the case | 2 | Approval, always |
| Publish | Per the publish grants | 2 or 3 | New and sensitive articles |
What stays with a person, and why?
The decision about what is true. When staff and an article disagree, either the article is out of date or staff have drifted from policy. Those need opposite fixes: change the page, or retrain the team. The agent can lay out the evidence for both, but only the article owner can say which one applies.
Workarounds also stay with people. A resolution like "I manually reset the flag for the customer" may have solved one ticket, but it is not something a customer can do and may not be something staff should do routinely. The agent flags it for the team leader rather than writing it up.
Pages for customers in difficult circumstances need extra care. Wording about bereavement, financial difficulty or fraud is approved by the owner and, where you have one, the vulnerability lead. See whether an AI agent can help a vulnerable customer.
Which controls matter, and what evidence do they leave?
Redaction before drafting. No ticket content reaches a draft until personal data is removed. Evidence: the redaction step logged per ticket.
Policy beats practice. A draft can only change a rule on the page if a sealed source supports it. Evidence: the source and its provenance class on each changed sentence.
One owner per decision. Every draft names the owner who must approve it. Evidence: the held verdict and the approval.
Minimum group size. A single ticket does not justify a change. Set a minimum number of tickets per finding, except where one ticket reveals a factual error. Evidence: the ticket count on each draft.
What should you measure?
- Repeat contacts on a topic in the weeks after its article changes. The direct test of whether the change worked.
- Findings by type. Many "contradicted" findings point to policy drift, not documentation.
- Drafts approved unedited, edited, rejected, by owner.
- Time from finding to published change.
- Urgent topics. A sudden spike in one question may need a same-day notice rather than the weekly cycle; the related signals are covered in can an AI agent prioritise urgent tickets.
Where does it usually go wrong?
Ticket categories are trusted. Staff file a billing question under "account" and the agent never finds it. Group by content.
Drafts are too long. The agent writes a full article for a question that needs one sentence added to an existing page. Ask for the smallest change that answers the group.
Personal details leak into examples. A drafted example uses a real customer's situation with the names changed. Examples should be invented and plainly hypothetical.
Owners do not answer. Drafts pile up and the loop stalls. Set a service level for owners and report missed ones to the editor.
Questions people ask
How often should the agent run the review?
Weekly suits most teams, with a daily check for sudden spikes. The cadence matters less than owners keeping pace with the drafts.
Can the agent use unresolved tickets too?
It can note them, but resolved tickets carry the answer. Unresolved ones show the question without showing what was true, so they are weaker evidence for a change.
What if the right fix is a product change, not an article?
The agent records the finding and sends it to the product owner as a contact driver. A help centre page explaining a confusing screen is a stopgap, and the record should say so.