how to run a weekly ticket review that improves things

TL;DR

Spend 30 minutes weekly on: the worst ticket of the week (what went wrong), the numbers (volume, SLA, reopen rate), and one improvement to implement. End every meeting with a named owner and a deadline for the improvement. Reviews without actions are just storytelling.

The error

(Process task; no error.)

Steps

1. Pick the worst ticket of the week (longest, messiest, or most escalated). Expected: selected. Dissect it: where did time go, what would have fixed it faster.
2. Review the week's numbers: volume by category, SLA attainment, reopen rate, CSAT if available. Expected: reviewed. Look for changes, not absolutes.
3. Identify one improvement: a KB article to write, a rule to fix, a process tweak. Expected: one item chosen. One per week compounds; five per week evaporates.
4. Assign an owner and a deadline (next week). Expected: assigned. Improvements without owners do not happen.
5. Start next week's review by checking last week's improvement. Expected: followed up. The loop is the entire value.

When to use

• Weekly continuous improvement
• New helpdesk leads establishing rhythm

When not to use

• Monthly business reviews (different audience)
• Blameless incident postmortems (separate, deeper)

Compatibility

• Any ITSM with reporting; the format is universal

Variants

Small teams

15 minutes works; keep the same three agenda items.

Distributed teams

Async written review in a doc; same structure.

Why it happens

Helpdesks improve through small compounded fixes, not big projects. The weekly review is the mechanism that converts observations into those fixes.

Edge cases

• Keep it blameless; the goal is system improvement, not calling out agents.
• If the same improvement repeats for weeks, the problem is ownership, not ideas.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_X4LQzfbQFU0ZF3Em42rmRA