Measure first-contact resolution for the desk (or a board, team, or tech) over a
period, using ONE explicit definition printed in the output: a ticket counts as FCR
when it was resolved directly by its first assignee with no intermediate handoffs — no
reassignment, no board bounce, no escalation. FCR debates are almost always definition
debates; this skill ends them by shipping the definition with the number.
1. Confirm the period (default: last full month) and scope — the whole desk, a single
board, a team, or one tech (look up the tech by name if needed).
2. State the definition up front and get agreement if the requester implies a different
one (some desks count "resolved within one business day" as FCR — a different
metric; offer to run both, labeled separately).
3. Run split searches per board: tickets resolved in the period, then identify the
non-FCR set — tickets showing reassignment, board moves, or escalation between first
assignment and resolution. Use the strongest signals the data exposes; where
handoffs are only partially visible, say which signal you used and what it can miss.
4. Compute FCR = (resolved with no handoffs) / (all resolved), overall and broken down
by board and category where volume permits. Exclude auto-closed/no-touch tickets
from both numerator and denominator — automation resolutions are a different (good)
story and inflate FCR if mixed in.
5. ANTI-PATTERN CHECK — a suspiciously high FCR can mean techs avoid escalating when
they should; scan the non-FCR set's reopen rate vs the FCR set's. If FCR tickets
reopen more, flag it: speed is being bought with quality.
6. Output: the definition verbatim (always — a bare percentage is not a deliverable),
the headline rate with prior-period comparison if available, the breakdown table,
the top three handoff patterns (which category bounces, and to whom, as patterns not
blame), and a methodology note (period, scope, handoff-detection signals,
exclusions, searches, caps). Per-tech FCR is role-sensitive: escalation-tier
engineers structurally cannot have high FCR because they receive the handoffs —
benchmark role-aware and never rank techs on this number alone. AGGREGATE, not
enumerate. Never present capped searches as exact totals. If handoff history is not
reliably visible, downgrade honestly: report a bounded estimate ("between X% and Y%
depending on treatment of Z") instead of a false-precision single number.
Magic Library