Skip to content

Resolution Learning

Resolution Learning lets ZAI learn from how your team actually closes tickets. As tickets are resolved, ZAI captures the closure notes, distills recurring patterns into draft knowledge articles, and — once a human approves them — feeds that knowledge back into future triage as "similar resolutions" for matching tickets.

Off by default

Resolution Learning ships disabled. An administrator needs to turn on the closure sweep and distillation jobs in your ZAI configuration before any capturing or learning happens. See Enabling the feature below.

Overview

Resolution Learning runs in three stages, entirely in the background:

  1. Capture — a scheduled sweep watches your PSA for tickets that have closed since the last check, and stores the ticket's problem text and resolution notes.
  2. Distillation — a separate scheduled job groups similar captured closures together (by ticket type/sub-type and content) and asks the configured AI model to turn each group into a draft knowledge article.
  3. Review — a person reviews each draft in the Knowledge area before it becomes live. Only approved articles are ever used.

Approved articles are then available to triage as a Similar Resolutions reference, and to ZAI's other AI assistants through the same knowledge search, so a matching article can surface outside of triage too.

What gets captured

When a tracked ticket disappears from your PSA's open ticket list, ZAI treats it as closed and records:

  • The ticket title and description ("problem text").
  • The concatenated resolution/closure notes from the ticket's activity.
  • Classification at close (type/sub-type), the resolving employee, and the close date.
  • Time to resolve and, if available, the ticket's CSAT score.
  • Whether ZAI's own triage suggestion was used to resolve it (so AI-assisted resolutions are weighted differently when the corpus is distilled — the system doesn't get to grade its own homework).

If a captured ticket is later reopened and closed again, ZAI records the reopen against the same entry and re-queues it for distillation with the newer resolution text — the repeat closure is treated as evidence the first resolution may have been incomplete.

Per-client opt-out

Each client has a Knowledgebase toggle under Configuration → Clients → [client] → Client Features. Turning it off stops that client's ticket closures from being captured, and stops that client's articles (and any global articles) from being suggested when triaging their tickets. It's on by default.

From capture to draft article

On its own schedule, the distillation job looks at everything waiting to be processed and:

  • Clusters captured closures that share a type/sub-type and look similar, scoped per client so a cluster never mixes tenants.
  • Sends each cluster to the AI model to produce a draft article: a title, problem statement, symptoms, resolution, and any caveats.
  • Runs the result through a redaction check before anything can be saved as a global (cross-client) article. If the check finds client-identifying detail in what the model offered as a global article, the draft is automatically forced down to that one client instead, and the reviewer is shown what was flagged.
  • Checks for duplicates/near-duplicates against existing articles, and if a new draft supersedes a live one, links the two so a reviewer can compare them side by side.
  • Small clusters are only turned into an article if they look high-value — for example, an unusually long resolution time, a strong CSAT score, or a resolution that had to survive a reopen.

Everything written at this stage is a Draft. Nothing distilled is retrievable by triage or chat until it is reviewed and approved.

Reviewing draft articles

Go to Knowledge in the main navigation to reach the review area (requires the Knowledgebase permission — currently admin-only until dedicated knowledgebase roles are added).

  • The Knowledge landing page shows a card per lifecycle stage (Draft, Approved, Rejected, and so on) with counts, and flags how many drafts have been held back by the redaction check.
  • The draft queue lists articles awaiting review, with search by title, problem statement, type/sub-type, or client name.
  • Opening a draft shows the proposed article alongside the actual source ticket closures it was distilled from — including any prior AI-assisted or reopened closures — so you can check the article's claims against what really happened.

From a draft you can:

  • Approve as written — the article goes live immediately.
  • Edit and approve — adjust the title, problem statement, symptoms, resolution, or caveats before approving.
  • Reject, with an optional reason — the article stays in the corpus (so the same cluster isn't proposed again blindly) but is never served.
  • Scope down a global article to a single client, if it isn't safe to share more broadly than the redaction check already forced it to be.

Check the redaction warning before approving

If a draft shows a "Held back by the redaction check" banner, the model's attempt to produce a shareable, sanitised version still contained client-identifying detail. Review the wording carefully — the article has already been scoped to one client, but the underlying language may need editing.

Once approved, an admin (or pod lead, for their own clients) can also publish the article to IT Glue, which creates a linked document there.

How learned knowledge reaches triage

Approved articles are embedded for semantic search. When a ticket is triaged, ZAI's Similar Resolutions triage variable searches the approved knowledgebase for articles that match the new ticket's title and content, scoped so a ticket only ever sees:

  • Global articles (sanitised, safe for any client), and
  • That ticket's own client-specific articles.

Matches are returned with a confidence score and fed into the triage prompt as citable reference material, the same way IT Glue document suggestions are. A client with the Knowledgebase feature turned off is excluded from this search entirely, even for global articles.

Historical backfill

Because the closure sweep only sees tickets that close while it's running, a newly enabled deployment starts with an empty corpus. From the Knowledge area, an administrator can run a one-off Backfill over a chosen window (90 days by default) to harvest historical closures from the PSA and seed the corpus, without waiting for tickets to close naturally.

Enabling the feature

Resolution Learning is switched off by default. To have it enabled for your deployment, contact ZAI support.

Once it's on, the per-client Knowledgebase toggle (see above) is the part you control from within ZAI — use it to opt individual clients out of learning and retrieval.

Nothing is served until it's approved

Turning distillation on cannot, by itself, change anything triage or chat sees — every article it produces starts as a Draft, and only an approved article is ever retrieved. It's safe to enable capture and distillation ahead of building up a review habit.

Troubleshooting

Closures aren't being captured. Confirm the feature has been enabled for your deployment, that your PSA integration is connected, and that the client isn't opted out via the Knowledgebase toggle. If everything looks right and nothing is captured, contact ZAI support.

No draft articles are appearing. Articles are generated periodically and need enough captured closures on a theme to form a cluster (or one particularly valuable closure on its own). Give it time after enabling, and confirm closures are being captured in the first place.

A global article keeps getting scoped to one client. That's the redaction check doing its job — it found client-identifying language in the sanitised version the model produced. Edit the wording during review if you want it to be shareable.