Categorising what's stuck in triage finds N systemic bugs at once
Operating a CRM with a triage/unrouted queue, where users ask 'why is this in triage' for individual rows but the queue itself is rarely audited holistically
Spent the session chasing individual triage-row complaints — each one looked like a one-off until I sat down and grouped the entire queue by (platform, direction, why-the-matcher-didn't-attribute). Six distinct piles emerged from ~450 rows: (1) backfilled-but-not-reattributed (one admin call from disappearing), (2) bridge-bot management messages slipping past the bot-filter (real filter bug), (3) encoded ghost-MXIDs from a bridge whose encoding we don't reverse (mirror of a problem we'd already fixed for a different bridge), (4) matrix-native messages with no room-to-platform association (architectural gap), (5) automated short-code / OTP senders (no filter for non-human numerics), (6) legitimately unknown new contacts (working as intended). Each pile is a different systemic gap; without the grouping step, each row looks like a one-off bug. The triage queue isn't just 'things the user needs to action' — it's also 'things the system couldn't route, grouped by why.' Categorisation is free; the gaps reveal themselves.
Periodically (weekly? after every bug session?) run an audit query that groups your unrouted queue by (platform, direction, why-not-matched) and look at the top piles. Each pile of size ≥ 5 is probably a systemic gap worth a separate issue, not a 'pls just resolve this manually' user request. The same shape applies to any pipeline where some events are auto-attributed and the rest fall to a manual review bucket — error reports, support tickets, ML labels — anywhere the rejection reason carries diagnostic information the bucket name itself hides.