The inbox full of technical requests nobody could prioritize
A shared inbox of technical requests, with no visibility and no priority order, was replaced by a tracked, triaged queue. The first urgent production fix jumped the line the same day it was submitted.
Who, what, and how long
- Industry
- Media & Publishing
- Duration
- Ongoing retainer
- Cooperation model
- Ongoing retainer, phased
- Services
- Request triageUrgent fixesTracked queue
- Integrations
- StripeSendGridSegmentSentry
- Technologies
- Ticketing platformTriage workflowPriority routingSLA trackingReporting dashboard
- Team
- 1 Project lead1 Product designer2 Frontend engineers1 Backend engineer1 QA engineer
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
What went wrong, and when
- 01
A single editor's request for a minor CMS tweak had, on one occasion, sat unanswered for three weeks while a genuine production bug went unnoticed in the same inbox for two days before anyone realized it needed urgent attention.
An inbox has no state. A request was either in someone's head or it wasn't, and which requests got worked came down to recency and how insistently they'd been phrased, neither of which correlates with anything useful. The production bug went unnoticed for two days because nothing about its arrival set it apart from a request to change a caption.
We replaced the inbox with a tracked intake and triage process: every request gets logged with a status and an owner, assessed for real impact, and worked in priority order. An urgent production issue is visibly triaged ahead of a cosmetic tweak, where before both waited in the same undifferentiated pile.
Phase by phase
Phase 1: Replace the inbox
Make the work visible
Replaced the shared inbox with a tracked queue where every request has a state and an owner.
- Queue setup
- Intake form
Phase 2: Triage
Impact and urgency
Built a triage step that assesses real impact and urgency at the point of intake.
- Triage rubric
- Severity definitions
Phase 3: Route
Production first
Set priority routing so production issues move ahead of minor requests automatically.
- Routing rules
- Priority matrix
Phase 4: Account
A record that closes
Kept a resolution record so every request's outcome stays accountable after the fact.
- Resolution log
- Reporting dashboard
Four weeks of resolved requests laid out week by week, each with how long it took to close, and how requests actually end (fixed, answered, declined or merged) with the share each outcome takes.
The numbers, before and after
Same day
Time to triage a new request
Weeks → zero
Average time a request stays untracked
Resolved same day, jumped 11-item backlog
First urgent fix under the new process
Time to triage is measured from a request arriving to being logged with a priority and an owner. Time untracked is the change from weeks to none, which is structural, not measured: every request now enters the queue on arrival. The first urgent fix is a single incident, reported as an illustration, not an average.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
The engagement
Every technical request, from a broken embed to an urgent publishing bug, went through a shared inbox with no triage, so nothing had a status and small jobs regularly sat for weeks.
A publisher whose technical requests (embeds, CMS tweaks, production bugs) all arrived in one shared inbox with no status, no owner and no order. The engagement was commissioned after a stretch in which a minor CMS request sat for three weeks and a genuine production bug sat for two days in the same pile, and nobody had decided either should.
On-Demand Technical Support
How it was handled
- 01
Replaced the shared inbox with a tracked, visible request queue
Every intake channel now lands in one tracked queue with a status and a named owner, so nothing is worked out of a personal inbox.
- 02
Built a triage step that assesses real impact and urgency on intake
The rubric was written with the editorial team, since impact on a publishing deadline is something only they can score.
- 03
Set priority routing so production issues jump ahead of minor tweaks
The queue is worked in priority order with jumps recorded as overrides, so a production issue sits visibly ahead instead of competing for attention.
- 04
Kept a resolution record so every request's outcome stays accountable
Every request keeps a resolution record, which is what makes SLA attainment per priority band reportable instead of anecdotal.
A visible queue
Every request logged with a status and an owner, and none left sitting in a shared inbox.
Requests arriving by email, chat and hallway conversation now land in one tracked queue with a status and a named owner, which changed the question from "who's dealing with this?" to "what state is it in?" Nothing is worked from a personal inbox, so a request doesn't disappear when the person holding it is on leave, and the backlog is a number instead of a feeling.
- One tracked queue for every intake channel
- Status and named owner on every request
- Nothing worked out of a personal inbox
One urgent request opened: who raised it and through which channel, its named owner, the impact assessment behind its score, what the requester can see, and the hour-by-hour history to a same-day resolution.
The intake form: five plain questions on user impact, revenue, workaround, publishing deadline and whether it's live, producing a score, a priority, a target, an owner and a place in the queue.
Triage on intake
Real impact and urgency assessed the moment a request arrives.
Triage happens on arrival, against a stated rubric of user impact, revenue exposure and whether a workaround exists. How a request is phrased no longer counts, and it used to be the strongest predictor of how fast something got fixed. Priority and target response are set at intake and visible to the requester, so the expectation is set up front instead of negotiated later.
- Triaged on arrival against impact, revenue and workaround
- Phrasing and volume no longer determine speed
- Priority and target response visible to the requester
Priority that holds
Work against its targets per priority band: the two overdue items, a tally of the reasons requests slip, and the one override recorded with the reason it was worked out of order.
A production issue sits visibly ahead of a cosmetic tweak, where before both waited equally.
Priority holds because the queue is worked in priority order and the exceptions are visible: a low-priority item jumped is recorded as an override with a reason. SLA attainment is reported per priority band, so the tail is inspectable, and a band that keeps missing becomes a resourcing conversation with evidence attached, not an argument about impressions.
- Queue worked in priority order; jumps recorded as overrides
- SLA attainment reported per priority band
- Missed bands become a resourcing case with evidence
Working inside their operation
A cross-functional team of 5 worked on an ongoing retainer, covering Request triage, Urgent fixes, Tracked queue. We ran a weekly demo and kept a shared board they could read at any time. Their team took over day-to-day running of the queue while we stayed on the retainer for triage and urgent fixes.
A phased retainer starting with intake and triage before any priority routing, because a queue nobody can see can't be prioritized. Requesters could see their own items from the first phase, and that changed their behavior before any process did: the chasing emails stopped once the status was answerable without one.
What changed in the runbook
- 01
An undifferentiated pile isn't a backlog. It's what you have when there's no triage.
The two-day bug and the three-week tweak were the same failure: with nothing distinguishing arrivals, order is set by recency and insistence.
- 02
Making the queue visible changed requester behavior before any process did.
Visibility changed the requesters first. The chasing emails stopped as soon as the status could be checked, before any prioritization existed.
- 03
Triage at intake costs a minute and saves a day spent working the wrong thing.
Assessing impact on arrival costs about a minute, against a day spent working the wrong thing. That's the trade the shared inbox had been silently making.
One request, four steps
How an urgent request gets ahead of eleven that arrived first
The first urgent request under the new process, from the message that raised it to its place on the board. Watch the queue beside it: unscored, it sits last; scored, it goes first. Switch tabs, or use the arrow keys once one is focused.
REQ-1041 · Thu 17 Sep 2026
It's in the queue the moment it arrives, so it can't be lost. But unscored, it sits where the old shared inbox put everything: at the bottom, newest, below eleven others, and nothing about it looks different from a request to change a caption.
- 1P2Image crops lost on syndicated stories
- 2P2Newsletter sign-up embed blank on Sport
- 3P2Scheduled posts publishing an hour late
- 4P3Related-articles module repeats stories
- 5P3Podcast player skips on older Android
- 6P3Show an Updated time on live pages
- 7P3Author pages missing byline photos
- 8P4Footer copyright year is hard-coded
- 9P4Rename the Opinion tag to Comment
- 10P4Puzzle page font off in print preview
- 11P4Raise the CMS caption limit to 280
- 12?Subscribers sent back to sign-in on every article
Times from REQ-1041’s history; the count-up and the move up the queue are illustrative animation, not timings.
From a message in any channel to a record that closes
An inbox has no state. Each stage adds a piece of state the inbox never had (a place, a score, an order, an owner, an outcome), so which request gets worked is a decision, no longer left to recency.
- 01 · IntakeEmail, chat, in personEvery channel lands in one tracked queue on arrival. Nothing is worked out of a personal inbox, so nothing is untracked.
- 02 · TriageRubric on arrivalScored for user impact, revenue exposure and whether a workaround exists, never on phrasing, the same day it arrives.
- 03 · RoutePriority work orderProduction issues go ahead of minor tweaks by rule. Working anything out of order is recorded as an override with a reason.
- 04 · RecordStatus, owner, resolutionEvery request carries a status and a named owner throughout, and closes with a resolution record of how it ended.
- 05 · ReportTargets per bandSLA attainment reported per priority band, so the tail is inspectable and a band that keeps missing becomes a resourcing case.
So the urgent one is never missed
Tracked intake, scored impact & a recorded order
Nothing arrives off the books
Email, chat and hallway requests all land in one tracked queue with a status and a named owner. A request doesn't disappear when the person holding it is on leave.
An outage can’t pass for a tweak
Impact is scored on arrival against a stated rubric of user impact, revenue exposure and workaround, so a live production fault stands out the day it comes in, not two days later.
Order is visible, and so are exceptions
The queue is worked in priority order. Anything worked out of order is recorded as an override with a reason, and every request closes with a resolution record.
Is an urgent bug sitting in the same inbox as a caption change? Scope your build in three minutes.
Scope your buildNearby engagements
Web PlatformsA writing desk where the manuscript never leaves the machine
A desktop notebook built on Electron, where documents live on disk, the editor is a real rich-text surface, and the AI assistant reads only what the writer hands it.
Book Publishing · 14 weeks
AI & AutomationLong text becomes narrated audio, and the job tells you the truth while it runs
A production tool that pulls text out of a source, narrates it, and reports honestly on a job that takes minutes, without pretending to be instant.
Media & Publishing · 12 weeks
Web PlatformsTwo billing models in one product, and neither one pretending the other doesn't exist
A content platform sold both by subscription and as a lifetime deal, where a redeemed code and a monthly plan resolve to the same entitlement, with no parallel systems.
Media & Publishing · 18 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
