The scene I keep hearing about

A founder called me last week. His client had sent a dozen voice messages into a WeChat group. He replied "got it, I'll have the team look at all of them." Two weeks later the client asked for a status update, and nobody could say which items were fixed and which weren't.

That's not a discipline problem. It's a process problem. When bugs arrive without a shape, nobody can describe them on the way out.

One intake, or it doesn't count

Outsourcing teams get work through WeChat, phone calls, screenshots, and hallway conversations. A developer fixes something on the spot and writes nothing down. Three days later the client says "that one still isn't fixed" and you're scrolling through chat history.

The rule is simple: every issue enters through one place. Whoever talks to the client converts it into a record the same day — which client, what happened, the screenshot, who logged it. Developers shouldn't reply "ok looking" in the group chat. That sentence never happened.

Better still, let the client log it themselves. A client portal where they submit issues, see status, and read the resolution history. It sounds like extra work for you; in practice it removes half the "is this done yet" calls. That's what the Stepwise client portal is for — the client sees a clean progress view, you see the tickets and hours behind it.

Drop P0 to P3

P0 through P3 works when you have a dedicated QA team to argue about it. With ten people, who assigns the level, and who respects it?

Ask three questions instead:

  • Does it block the release?
  • How many users, and is it the client who's currently yelling?
  • Is there a workaround?

The answers set the level by themselves.

Situation What to do
Blocks release, hits everyone, no workaround Fix today, treat as an interrupt
Hits some clients, workaround exists Put it in the current sprint
Cosmetic, doesn't block use Next sprint, or per contract priority
Actually a change request Back to the backlog; quote and schedule it

That last row matters. A good chunk of what clients call "bugs" are change requests. Handle them silently inside a sprint and you'll finish the sprint having lost money.

Plan sprints at 70%

Outsourcing teams always get interrupts: a copy change, a new deal the boss signed, production going down.

Plan at 100% and any interrupt pushes the date. Push the date twice and the client stops believing your schedule — and starts asking every morning.

Plan at 70%. Five people, ten days, 50 person-days: commit to 35 and write the other 15 into the plan as buffer. Deliver early and you look reliable. Get an interrupt and nothing collapses.

Before each sprint, half an hour:

  • Walk the bug list and the requirement list together, not just requirements
  • Estimate each item; if you can't estimate it, it isn't defined yet
  • Write the buffer into the plan, not into your head
  • Ask: what share of this sprint is bug work?

The bug ratio tells you something

When bug tickets pass roughly 40% of a sprint, it's usually not a scheduling problem — it's a quality problem. Don't rush into the next sprint. Look at why: vague requirements, thin test coverage, or a previous sprint that was rushed.

Outsourcing carries a hidden cost called rework. The client rejects the delivery, you fix it again, and that time rarely reaches the timesheet. You find out at settlement that the project didn't make money. Time tracking isn't for policing developers; it's for seeing which project is quietly losing money.

Keep the status list short

I've seen a team with eleven bug statuses: new, to confirm, confirmed, assigned, in progress, to test, testing, to accept, closed, reopened, on hold. Nobody updated any of them. Everything sat in "in progress."

Five or six is enough: Open → In progress → To verify → Closed, plus On hold. Every extra status is one more thing nobody maintains.

Closing a bug needs evidence

"Fixed" is the cheapest word in the project.

Closing a ticket should mean: which build, who verified it, when, and on which environment. For outsourcing this isn't bureaucracy — you have to deliver, get sign-off, and collect the final payment. A client portal showing the trail on every issue does more than you saying "it's all done" ten times.

Last thing

Tools don't fix process. But without a single pool, everything above is just talk.

In Stepwise, requirements, bugs, sprints, timesheets, and the client portal live in one place. The practical benefit: when you plan a sprint you can see how much of it is bugs, whether the hours add up, and what the client is actually looking at. Self-hosted deployment is available if the client wants it inside their own network.

Get the intake right first. The rest can wait.