The Job You Can't Start: Untangling What Blocks the Work
Most stalled jobs aren't behind because staff are slow — they're waiting on something. Here's how to make blockers visible and stop losing days to them.
Ask any practice owner where their jobs get stuck and you'll hear the same word: waiting. Waiting on a bank statement. Waiting on a signature. Waiting on a director to confirm which entity paid the invoice. Waiting on the partner to review a draft. The work isn't slow — it's blocked. And a blocked job that nobody can see looks identical to a job that's simply not started yet.
That's the quiet cost most account practice management software never addresses. Time tracking tells you how many hours went in. A due-date list tells you when something's owed. Neither tells you the thing that actually matters day to day: why isn't this moving right now, and whose problem is it?
The difference between 'not started' and 'can't start'
A job board with columns like To Do, In Progress and Done hides a whole category of reality. Two jobs sitting in To Do can mean completely different things:
- One is ready — everything's in, it just hasn't been picked up.
- The other is missing the one thing it needs to begin, and won't move no matter how much capacity you free up.
When those two look the same on the board, planning breaks down. You allocate a job to someone on Monday, they open it, discover it's waiting on a client document, close it again, and pick up the next one. That's a real cost — the context you loaded, the five minutes to figure out it can't proceed, the note you may or may not leave for next time. Multiply it across a compliance season and you've lost days to jobs that were never workable in the first place.
Name the blocker, not just the status
The fix isn't a busier board. It's making the reason a job is stalled a first-class piece of information, sitting on the job itself. Good client accounting software should let you record, at a glance, what a job is waiting on and who owns clearing it. Broadly, blockers fall into three buckets:
Waiting on the client
Missing documents, an unsigned engagement letter, an unanswered query, an unpaid deposit. The critical detail here is ownership. A job marked "waiting on client" that was never actually assigned to anyone to chase will sit forever — the client doesn't know you're waiting, and no one internally is watching it. The blocker needs a person attached: whose job is it to follow up, and when?
Waiting on someone internal
A draft sitting in a review queue. A second signature. A partner sign-off before lodgment. These are the ones that sting most because they're entirely within your control. When a job is blocked on internal review, the person who did the work should be able to see it's now the reviewer's move — not keep it open in their head as "mine, but stuck."
Waiting on time or a dependency
Sometimes a job genuinely can't proceed until a date passes, another job finishes, or data syncs through from Xero. These aren't problems to solve — they're facts to schedule around. The point is to get them off your "why is this late" list so your attention goes where it counts.
Why this belongs in one system, not scattered across tools
Here's where a lot of firms lose the thread. The job lives on a board. The document request went out by email. The engagement letter is in a signing tool. The review note is in a chat message. The client's file is in your accounting client management software. So when someone asks "why hasn't the Henderson return moved?", answering it means reading six places and reconstructing a story.
When the work, the client record, the document requests, the letters and the review sit in one place, the blocker answers itself. Open the job and you can see: engagement letter signed, two of three documents received, draft complete, sitting with the reviewer since Tuesday. No archaeology. This is the practical case for consolidating client accounting into a single system rather than stitching together a tax return tool, a signing app, a portal and a spreadsheet — the blocker becomes visible precisely because everything that could cause it lives together.
In Finye, jobs live on boards alongside the client record, so a work item can carry its own outstanding requests, its signing status and its review state. When a job is waiting on the client, the portal request that's chasing it is attached to the same job — so "waiting on client" isn't a dead end, it's a request with an owner and a follow-up. When it's waiting on review, the handover between preparer and reviewer is explicit, not implied.
Make blocked jobs the first thing you look at
Once blockers are named, you can run your day around them instead of stumbling into them. A few habits worth building:
- Start with the blocked list, not the to-do list. Every stalled job is either something you can clear now (nudge the reviewer, resend the request) or something to consciously leave alone. Deciding that on purpose beats rediscovering it job by job.
- Give every client-side blocker an owner and a next action. "Waiting on the client" with nobody assigned is how a job disappears for three weeks. Someone owns the chase, or it isn't really being chased.
- Watch how long jobs sit blocked, not just how long they take. A return that took four hours over six weeks was mostly waiting. That waiting is where your turnaround time — and often your write-offs — actually come from.
- Clear internal blockers first. The review sitting in someone's queue is the one you can fix today without touching the client. It's usually the fastest win on the board.
The payoff: capacity you already have
Firms reach for more staff or new tax return software when the real problem is that half their jobs are stalled and invisible. Surface the blockers and a chunk of your "backlog" turns out to be workable right now, or waiting on things you can chase in an afternoon. You don't get faster by working harder on the jobs that can move — you get faster by seeing, and clearing, the ones that can't.
The job you can't start isn't a mystery. It's waiting on something specific, and that something has an owner. Make both visible, and the queue starts moving on its own.