Friday, 4:30pm. The client drops 'login seems broken' into the group chat, followed by two question marks. The PM forwards it to a developer. The developer asks which account. No reply. By Monday morning it has become 'your system isn't stable.'
If you run an outsourcing team, you've lived this. It's not a motivation problem. The process fails at step one: bugs live in chat history, sprint goals get overwritten by whatever feels urgent that afternoon, and hours get filled in from memory at month end. Here's what we kept after a few years of getting it wrong.
1. One intake. Just one.
The moment there's a second door — WeChat, a phone call, the client's CEO messaging a developer directly — things fall through it.
- Client side: they file through the client portal and can see what they submitted and where it stands. That's the two hours a week your PM used to spend writing status emails.
- Internal side: QA, implementation, and developers file into the same pool. No fixing things in DMs. A bug fixed in a DM comes back next month.
- Verbal requests: the PM logs them the same day, with the requester's name attached.
One pool isn't just about not losing tickets. It turns 'how many did the client raise this month, how many did we close' into a number you can actually report.
2. Severity has to map to an action
The usual failure is that 'urgent' gets used for everything, so nothing is urgent. Pin the definitions down and tie each one to a behaviour:
| Level | Test | Action |
|---|---|---|
| P0 | Production down, client can't get paid, data corrupted | Drop everything, someone handles it today |
| P1 | Main flow works but breaks visibly, client hits it daily | Fixed inside the current sprint |
| P2 | One feature misbehaves, there's a workaround | Goes to backlog, scheduled weekly |
| P3 | UI, copy, polish | Batched and done together |
What matters isn't the table. It's that someone can overrule the client. Give the PM the authority to downgrade a 'very urgent' request that doesn't meet P0, and to explain why in writing. Without that, your sprint plan is decoration.
3. Never plan a sprint at 100%
Outsourcing work gets interrupted. Plan at full capacity and you'll be off track by Wednesday of week one.
On a two-week sprint, commit to 7–8 days of work. Leave the rest for inserts, P0s, and client alignment. Two other things that pay off:
- Write the sprint goal as one sentence, not a list. Lists get edited. Sentences don't.
- Log every mid-sprint insert, even the ones from your own boss. At month end that number tells you where the team actually bled.
4. If nobody can reproduce it, it's a meeting
Most rework isn't a hard technical problem. It's an underspecified ticket. Make these required fields:
- Steps to reproduce, walkable by a stranger
- Expected result vs actual result
- Environment, account, version
- Screenshot or screen recording
A developer who doesn't need to ask a follow-up question is a developer who's shipping. Portal forms can be configured per project with required fields — that beats chasing people for details later.
5. Hours and retros: if you can't see it, you can't price it
Don't track to the minute. Daily entries are enough. The point is twofold: know your project margin, and calibrate estimates.
Once a month, pull three or five tickets where the estimate was badly off. That's worth more than ten meetings.
Keep the retro to half an hour and look at three numbers: insert ratio, rework rate, P0 count. When all three trend down, the process is working. Watch only one and you'll fool yourself.
Where this lands
Tools aren't the hard part. Sticking to 'everything goes into the same pool' is. Stepwise puts requirements, bugs, sprints, hours, and a client portal in one system, with on-premise deployment if you need it — useful when the delivery process has to be visible to the client. If you're still running projects out of a group chat, start with the intake and leave the rest for later.
