Most outsourcing teams don't actually track bugs
A client drops "login is broken again" in a chat thread. QA tags a dev in the group chat. The dev fixes it and replies "done." Three days later the client says it's still broken, and nobody can find the original report — because there never was one.
That's not a tooling problem. It's a single-inbox problem. Bugs need one place to land, and it has to catch four sources: clients, QA, developers themselves, and production alerts. Miss one and you'll be doing catch-up on a Friday night.
Six fields, no more
Severity (P0–P3), affected module, source channel, client-visible yes/no, steps to reproduce, expected result. That's it. Every extra field costs you a chunk of the people who bother filling it in.
Anything without clear repro steps goes straight back to the reporter. Hold that line for two weeks and the quality of reports changes visibly.
The priority matrix: client-visible is its own axis
This is where outsourcing differs from a product team. Something the team shrugs at is what the client wants to sign off next week.
| Severity | Client-visible | Not client-visible |
|---|---|---|
| P0 blocker | Fix today, drop everything else | Fix within the sprint |
| P1 major | Proposal and ETA within 24h | Put in current sprint |
| P2 normal | Current or next sprint | Backlog, pull by capacity |
| P3 minor | Batch it | Close after 90 days of silence |
The hard part is closing P3s. A backlog with 200 three-year-old bugs takes half an hour to read and tells you nothing.
Plan sprints at 70%
Getting interrupted isn't an exception in outsourcing, it's the default. Fill a two-week sprint to 100% and one urgent client request collapses the whole plan. Do that twice and the team quietly decides plans are fiction. Hard to undo.
Plan 70%. Keep one or two slack slots for interrupts, production issues, and integration delays. Estimate in person-days, not in "we can probably finish it."
Rank bugs and features in one backlog
If features run through one process and bugs through another, you can't tell whether a sprint is deliverable. Put them in one list, rank by value and risk together, then check whether the total still fits the capacity.
Let clients file their own tickets
A PM spending two hours a day screenshotting, relaying, and explaining status is pure overhead. Give the client a portal: they file, they check status, they see the acceptance list. Their tickets land in the same backlog and the PM only decides priority.
That's what the client portal in Stepwise handles — clients see the tickets that concern them, not your internal arguments about sequencing.
Three numbers, once a week
- Opened vs closed. Two weeks in a row where opened beats closed means you're borrowing. Don't tell yourself next week will be better.
- Average time to fix. Split by severity. Blended numbers are useless; P0s and P3s move for completely different reasons.
- Reopen rate. Percentage of fixes that bounce back. Above 10% and the problem usually isn't headcount — it's that nobody wrote down what "done" means.
Traps we keep walking into
- Letting developers close their own tickets. Give close rights to QA or the reporter.
- Mixing staging and production in the same report. Every ticket needs an environment field, or repro becomes guesswork.
- Verbal client requests that never get filed, which two weeks later become "you promised this." If it was said out loud, the PM files a record within ten minutes — a title is enough to start.
- Standups that turn into status reading. Standup is for blockers. Status lives on the board.
Tools don't fix management. But they can make the single-inbox habit cheap enough to keep. In Stepwise the bug pool, sprint board, and client portal share the same data, so nothing gets re-exported — worth a look if that's the part you're stuck on.
