Turn repeat support tickets into draft help articles

Every Friday at 3pm, find the gaps in our knowledge base by looking at what our service desk keeps answering by hand.

Start by using the Jira Service Management List Customer Requests action to pull every customer request that was resolved in the last 30 days, capturing the request summary, description, request type, and resolution date. For the requests that end up in a shortlisted theme, also use Get Request Comments to read how the agent actually walked the customer through the fix. The real resolution steps usually live in the comment thread rather than in the summary field.

Do not treat each ticket separately. Cluster the resolved requests into recurring themes based on the underlying problem the customer had, so that "cannot log in to VPN", "VPN password expired", and "VPN access denied after laptop refresh" all roll up into a single theme. For each theme, keep the contributing ticket keys, the count, and how long those requests took to resolve.

For every theme, use the Search Service Desk Articles action to check whether the knowledge base already covers it. Search using the words customers actually used in their requests, not internal jargon, and try more than one phrasing before concluding nothing exists. A theme counts as covered only if an existing article genuinely answers it. A loosely related article does not count as coverage.

Then pick the single top theme that has at least five similar resolved requests and no existing article, ranking by ticket volume. If two themes tie on volume, prefer the one whose tickets took longer to resolve, since that is where the manual effort is going.

For that one theme, use the Confluence Create Page action to write a draft help article. Build the actual steps out of how those tickets were genuinely resolved, following the real fix sequence found in the request comments and resolutions rather than inventing generic advice. If the tickets show more than one valid resolution path, cover each one and say when each applies. Structure the page as a short description of the symptom, who it affects, numbered resolution steps, and a note on when to escalate to a human agent. Close with a list of the source ticket keys so a reviewer can trace every step back to a real request. The page must be created as a draft so a human reviews and publishes it. Never auto-publish it.

Finally, use the Slack Send a Message action to tell the support lead what was drafted. Include a link to the draft Confluence page, the theme name, how many resolved requests it came from along with their ticket keys, and a one line explanation of why that theme was picked over the runners up. Also list the next two or three themes that nearly qualified, with their counts, so the lead knows what is likely coming next week.

If no theme clears the bar of at least five resolved requests with no existing article, do not create a Confluence page at all. Just send a short Slack message saying the knowledge base kept up this week, and list the closest themes with their counts.