It’s 10:00 AM. Your team is in flow. Then the phone rings, or an all-caps email hits the inbox. A client wants something fixed. Now.
The old instinct is to jump. To show “good service,” you interrupt a developer, a tester, break their focus, and rush the fix.
We used to do that. And we realized it was destroying our profitability and our brand. Every time we “jumped,” we lost not just the time to fix the issue, but the hours of recovery time the team needed to get back into deep work.
So, we implemented The Protocol of the Fair Queue.
Step 1: The Triage (Burning vs. The Queue)
First, we assess the request objectively. We don’t ask “Is the client angry?” We ask: “Is the building on fire?”
- Is this a “Burning” Issue? (e.g., The server is down, the client cannot invoice their client, work has totally stopped).
- Is this a “Queue” Issue? (Everything else. This includes serious bugs, bugs with workarounds, design tweaks, and “nice to haves”).
If it’s Burning, we treat it immediately. If it’s Not Burning, it goes into our FIFO Queue (First-In, First-Out).
Note: The Queue isn’t a junk drawer. We organize it by gravity. “Serious Bugs” are processed before “Minor Inconveniences.” But crucially, we do not stop current work to start them. They wait for their turn.
Step 2: The Pushback (The Judo Move)
Here is the hardest part: telling an angry client they are in a queue.
When a client demands we drop everything, we don’t apologize for being busy. We explain that our process protects them, and we give them a hard deadline for safety.
Here is the exact script we use:
Client: “I need this fixed right now! I don’t care about your schedule!”
Us: “I understand this is frustrating. However, we work on a strict First-In-First-Out (FIFO) model to ensure quality.”
“If I make my programmers jump from issue to issue every time a phone rings, nothing gets solved properly. It creates more bugs, not fewer.”
Client: “But I’m paying you!”
Us: “Exactly. And we want to give you our full attention when we work on your code. Ask yourself: How would you feel if we were halfway through solving your critical issue, and we suddenly stopped—leaving you broken—just because someone else called?“
“We refuse to do that to other clients, and we promise never to do that to you.”
Client: “So when will it be done?”
Us: “We will have this solved by [Day/Time]. You can count on that deadline.”
The “Nice Surprise” Strategy: Notice that we never tell the client: “We usually finish sooner.” If you say that, they will expect it, and meeting the actual deadline will feel like a failure. Instead, we give a safe deadline that allows for the queue. When we inevitably deliver the fix early, it comes as a delightful surprise. This turns a tense situation into a win.
How We Keep The Promise
You might be wondering: “How can you be so sure you’ll hit that deadline?”
It comes down to visibility. You cannot manage a queue—or keep a promise—if you don’t know exactly where your team’s time is going. The reason our FIFO system works is that we have “Zero Leaks” in our billable hours tracking.
If you want to see the exact method we use to maintain that clarity (and stop the profit leaks that cause chaos in the first place), read this next:
I Thought My Team Was Bad at Tracking Time. I Was Wrong.
A founder’s story of invisible work, broken systems, and the simple method that finally stopped profit leaks and brought clarity to billable hours.
