Auto-Document Resolved Issues as Runbooks

The fix everyone agrees on is a runbook: a short, structured doc that says here's the problem, here's the root cause, here's the fix. The reason it rarely gets written is just as universal — writing the runbook takes longer than resolving the ticket did, and the moment the ticket is solved, the incentive to document evaporates.

This post is about closing that gap automatically. With Macha, a resolved ticket becomes a Confluence runbook on its own: an agent reads the full solved conversation, checks whether a runbook already exists, and — if not — writes a structured page to your documentation space. No screen recording, no "remember to write it up later," no human in the loop. This is one of Macha's knowledge-management use cases, and it runs on connectors most support teams already have: Zendesk and Confluence.

What "auto-document as runbooks" actually means

Macha is not a wiki and not a helpdesk — it's an AI agent layer that sits on top of the tools you already run and takes real actions in them. For this workflow, the agent does four things every time a ticket is solved:

1. Reads the resolved ticket — the full comment thread, tags, and custom fields, not just the subject line.
2. Extracts the runbook — distils the conversation into Problem, Root cause, Solution, and Prevention.
3. Checks for duplicates — searches your Confluence space so you don't end up with five pages on the same SSO bug.
4. Writes the page — creates a structured runbook in your chosen space, with confirmation before any write.

Here's the worked shape of it, taken straight from the use-case definition:

And the agent's own summary of that run, posted back so the team can see what it did:

Runbook: SSO Login Failing for New Users - Problem: New users get "Invalid SAML response" when attempting SSO login - Root cause: IdP attribute mapping is missing the department field required by our SAML config - Solution: Add the department attribute mapping in the IdP admin panel, then have the user retry - Prevention: Added department to the SSO setup checklist

That's the difference between a tool that can document and a system that does — turning a one-off fix into searchable institutional memory without anyone deciding to.

How you build it in Macha

The whole thing is one agent with a trigger and two connectors. You don't write code.

1. Connect Zendesk and Confluence

Both are live connectors. Zendesk gives the agent read access to tickets — full conversation history, tags, brand, requester info, and custom fields with labels resolved. Confluence gives it search and page-creation tools. Critically, every Confluence write requires confirmation by design — the connector will not silently create or overwrite a page, which matters a lot when you're letting an agent author into your team's wiki.

2. Set the trigger to fire on resolution

The point of this workflow is that no one has to remember it. So instead of running the agent by hand, you attach a Zendesk trigger. The relevant event is Ticket Closed, which fires when a ticket is marked solved or closed — exactly the moment the knowledge is freshest and the conversation is complete.

You'll want to narrow it. Firing on every closed ticket is noise — most tickets ("where's my order?") don't deserve a runbook. Scope it with a condition so the agent only runs on tickets worth documenting: a specific tag (needs-runbook, applied by the resolving agent), a group (Tier 2 / Engineering Escalations), or a ticket type. A good rule of thumb, borrowed from Supportbench's runbook-library guidance: start with your top ticket categories by volume, where a single runbook pays for itself the fastest.

3. Give the agent its tools and instructions

The agent needs three actions: Zendesk Get Ticket, Confluence Search Pages, and Confluence Create Page. You pick those in the tool picker, then write the instructions in plain language.

The instructions are where the runbook quality lives. A good prompt tells the agent the template (so every runbook looks the same), the dedup rule (search before you write; if a close match exists, update it or skip rather than duplicate), and the destination space. Something like:

When a ticket is solved, read the full conversation. Summarise it as a runbook with these exact sections: Problem, Root cause, Solution, Prevention. Before creating anything, search the "Support Runbooks" space for an existing page on the same issue. If a close match exists, do not create a duplicate. Otherwise, create a new page titled "Runbook: [issue]" in the Support Runbooks space.

That standardized template is doing real work. As the Supportbench team puts it, "a runbook is only as good as its structure — without a consistent template, runbooks become scattered notes" no one trusts during the next incident. Telling the agent the headers up front is how you get a library instead of a junk drawer.

How this differs from the other "auto-runbook" tools

This is a busy category, and the tools in it solve the problem from very different angles. It's worth being honest about where Macha fits.

• Screen-recording tools (e.g. Glitter AI) capture the fix as you perform it — the technician hits record, the tool watches every click, and it generates an annotated, screenshot-rich runbook in about five minutes, then publishes to Confluence, Notion, or IT Glue. That's excellent for click-by-click procedures, and it genuinely turns a 45-minute write-up into a 5-minute one. But it still requires a human to remember to record, and it documents the clicks, not the reasoning in the ticket thread. Macha needs neither a recording nor a human — it reads the conversation that already happened.
• Helpdesk-native AI (e.g. Supportbench's KB-from-case-history) drafts an article when a resolved case reveals a gap. Closest in spirit to this workflow, but locked to that one helpdesk.
• Incident/SRE platforms (incident.io, Cutover, HCL BigFix Runbook AI) build and execute operational runbooks from incident data. Powerful for on-call engineering, overkill for a support team that just wants its resolved tickets written down.

Macha's niche is specific: autonomous, conversation-driven documentation that writes into the wiki you already use, triggered by your existing helpdesk, with the dedup check built into the same agent. It's not trying to replace Confluence or Zendesk — it's the layer that finally makes the runbook get written.

Watch-outs and when not to use it

Automation that authors into your knowledge base deserves a few guardrails. Be honest about these before you switch it on for the whole queue:

• Don't fire on every closed ticket. Most resolved tickets are routine and don't warrant a doc. Without a tag or group filter you'll flood Confluence and bury the runbooks that matter. Start narrow.
• Garbage in, garbage out. The agent can only document what's in the ticket. If the real fix happened in a side-channel Slack thread and the ticket just says "fixed, closing," the runbook will be thin. This works best where agents actually write their resolution into the ticket.
• Keep the confirmation step honest. Confluence writes require confirmation for a reason. For a fully hands-off flow you can auto-confirm, but for the first few weeks, keep a human approving page creation so you can tune the template and catch hallucinated specifics.
• Dedup is a prompt, not a guarantee. Search-before-write dramatically cuts duplicates, but near-misses (different wording for the same bug) can still slip through. Plan a light periodic cleanup, and consider having the agent update an existing page rather than always creating new ones.
• Sensitive data. Resolved tickets contain customer PII. Scope the runbook template so the agent documents the issue and fix, not the customer's personal details — and review your space permissions.

If your team already maintains disciplined, high-quality runbooks by hand, or your "tickets" are mostly low-complexity FAQs, this will add more noise than value. It earns its keep on complex, recurring, technical issues — the ones that cost a senior hour every time they recur.

The compounding payoff

The reason this is worth wiring up isn't any single runbook — it's the loop. Every solved escalation quietly thickens your documentation. New hires onboard against real, recent fixes instead of stale wiki pages. And because Confluence is searchable, the next agent (human or AI) finds the runbook before re-solving the same problem. Over a few months, the issues that used to eat a senior hour each become a thirty-second lookup.

That's the whole pitch for Macha as an agent layer: it doesn't just answer the ticket in front of it — it makes the work it does accumulate. Pair this with Macha's live agents that resolve and triage incoming tickets, and you get a support operation that both handles today's volume and gets measurably smarter about tomorrow's.

FAQ

Does this require recording my screen like some runbook tools? No. Macha reads the resolved ticket's text conversation — the comments, tags, and fields — and writes the runbook from that. There's nothing to record and no plugin to install on agents' machines.

Where do the runbooks get written? To Confluence, in whatever space you specify (e.g. "Support Runbooks"). The agent uses the Confluence Create Page action, and every write is confirmation-gated by default.

How does it avoid creating duplicate pages? Before writing, the agent runs a Confluence Search Pages query for the same issue. You instruct it to skip or update when a close match exists rather than create a new page. It's not perfect, but it removes the bulk of duplicates.

Can I limit it to only certain tickets? Yes — that's recommended. Scope the Zendesk Ticket Closed trigger with a condition like a tag (needs-runbook), a specific group, or a ticket type, so only issues worth documenting trigger the agent.

What does it cost to run? Macha is credit-based — credits are consumed per AI action, from 0.5 to 9 by model (the default GPT-5.4 Mini is 1). A single runbook job is just a few actions (read the ticket, search, write the page), so cost scales with how many tickets you document, not a per-seat fee. See the pricing page for plans and credit allowances.

Does Macha replace Confluence or Zendesk? No. Macha is the AI agent layer on top of the helpdesk and wiki you already use. It reads from Zendesk and writes to Confluence — it doesn't replace either.

Get started

If your team keeps re-solving the same hard tickets, this is the highest-leverage agent you can build. Start a 7-day free trial, no credit card required, connect Zendesk and Confluence, scope a Ticket Closed trigger to your escalation queue, and let your resolved issues document themselves. The full setup is in the Macha docs.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.