It's 5pm Friday. A client drops a screenshot in the group chat: "this button does nothing." The PM forwards it to a developer, who asks: which account? which version? which browser? The client says "that one." Three rounds later it's dark outside. Monday morning you find out it was the client's own browser cache.
Three of those a week and your sprint is gone.
Anyone running outsourced delivery knows the bug itself isn't the scary part. It's that the bug has no shape — nobody knows who filed it, how bad it is, whose hours it eats, or whether it fits this week. Here's what we do after enough of these.
One queue, no exceptions
Chat messages, phone calls, emails, and the client's CEO saying "while you're in there, just tweak this" — none of that counts as a ticket.
The rule: everything goes into one queue. Clients file through the client portal. QA files from test cases. Internal folks use the same form. When someone says "small issue" in chat, the answer is always one line: file a ticket, here's the link.
Clients push back for two weeks. Then they get used to it, because after filing they can see the status: triage, in progress, ready for verification, closed. That alone kills twenty "is it fixed yet?" messages a day.
Make the form strict
Missing field, ticket bounced back. Sounds unfriendly. It's far cheaper than a developer guessing.
Required: severity, environment (client, version, device), reproduction steps, screenshot or screen recording, expected vs actual.
Let the reporter pick severity, but the tech lead overrides. To a client everything is "urgent." Don't hand over that judgment.
| Level | When it applies | Response | Scheduling |
|---|---|---|---|
| P0 Blocker | Core flow broken, bad data, production down | Within 2 hours | Same day, hotfix if needed |
| P1 Major | Core feature broken but there's a workaround | Same day | Current sprint |
| P2 Normal | Non-core issues, rough edges | 2 working days | Next sprint pool |
| P3 Suggestion | Polish, copy, styling | Batched | Backlog, cleared quarterly |
Send that table to the client. It saves a hundred explanations.
Plan sprints with room to be interrupted
Outsourced work always gets interrupted. Plan to 100% capacity and the first hotfix sinks the whole thing.
We run two-week sprints, estimate in person-days, and commit only 70–80%. The rest is explicitly held back for interruptions and production issues — and we tell the client that this buffer is not a spare slot to fill with extra scope.
Before planning, count the open bugs from last sprint and put the number on the table. Over 15 and you don't take new features this round. Pay the debt first.
Separate bugs from change requests
This is where outsourcing companies bleed money.
The same "problem" is one of three things: our code is wrong, the client never specified it, or the client changed their mind. First one we fix free. The other two go through a change order with re-estimated hours and cost.
So add a required field to every bug: responsibility (our defect / missed requirement / change request / environment). Filled in at close.
Pull the data at month end. One module showing 70% "our defect" means it needs a rewrite or was rushed. One client generating change orders every week means you under-quoted.
The week before release
- Freeze features seven days out, bugs only
- Track open vs closed daily; if the curve isn't converging, something systemic is wrong
- Publish a known-issues list with every remaining P2/P3 and get the client to sign off on what ships unfixed
- Put scope, known issues, and acceptance criteria in the sign-off document
Skip this and the acceptance meeting becomes a debate club.
Ten minutes a week, two numbers
One: bug-fix hours as a share of sprint hours. Over 30% means quality is eating your capacity — stop adding scope.
Two: average time to close P0/P1. When it climbs, client satisfaction has already started falling.
Keep the meeting to ten minutes. Put both charts on screen. Whoever owns the number owns the fix.
On tools: you can run all of this on spreadsheets and chat groups — you'll just spend half an hour a day reconciling. Stepwise keeps requirements, bugs, sprints and hours on one line: clients file in the portal and it lands in the right queue, they see status changes themselves, and time tracking rolls straight into a billing sheet at month end. The time you save is enough to keep an eye on two more projects.
