## 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
```text
(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