The Job That Sat in a Queue Nobody Owned
Work that isn't assigned to a person doesn't move. Here's how to close the ownership gaps that quietly stall jobs across your practice.
Every practice has them: jobs that are technically 'in progress' but haven't moved in a week. Nobody's stuck. Nobody's blocked. The job just sits there, because at some point it slipped out of one person's hands and never landed in another's. It's in a queue that nobody owns.
This is one of the quietest ways a practice loses time. It doesn't show up as a missed deadline until it's nearly too late, and it doesn't show up in anyone's individual workload because, on paper, it isn't assigned to anyone. The job is in limbo — and limbo doesn't send reminders.
How jobs end up ownerless
It rarely happens on purpose. A few common patterns create these gaps:
- The handoff that never completed. A preparer finishes their part and moves the job to a 'ready for review' stage, but doesn't assign it to a specific reviewer. It's now the whole team's problem, which means it's no one's.
- The 'waiting on client' trap. A job is parked because you're waiting for a document. But nobody owns the chase, so the job stays parked long after the client actually replied.
- The staff change. Someone goes on leave, and their jobs get moved to a generic bucket 'for someone to pick up' — and then everyone assumes someone else already picked them up.
- The new job with no owner. A recurring job rolls over for the new year, gets created automatically, and lands in a stage with no assignee attached.
In each case, the work is visible on a board somewhere. What's missing is a person's name against it — and without that, there's no one whose day gets worse if it doesn't move.
Why 'the whole team owns it' doesn't work
Shared responsibility sounds collaborative, but for individual jobs it's a failure mode. Accountability that's spread across everyone evaporates. If a BAS is 'the team's job to finish', each person can reasonably assume a colleague is handling it. The result is a job that everyone has seen and no one has touched.
Real workflow depends on a simple rule: at every moment, every active job belongs to exactly one person. That person may change as the job moves through preparation, review and lodgment — but there is never a moment where the answer to 'whose job is this right now?' is 'not sure.'
Ownership has to follow the work, not sit beside it
This is where spreadsheets and shared inboxes let firms down. A tracking spreadsheet might have an 'assigned to' column, but nothing forces it to stay accurate. Someone reassigns a job verbally, or by email, and the spreadsheet quietly goes stale. The email thread that actually carries the handoff isn't connected to the job at all.
The fix is to make ownership a property of the work itself. In good accounting practice management software, a job on a board carries its assignee with it. When it moves from 'preparation' to 'review', the reassignment is part of the move — not a separate step someone has to remember. And when a stage has no assignee, that should be a visible, flagged state, not something you only discover when a deadline arrives.
This is exactly the gap Finye's work items are built to close. Jobs live on boards, each with a named owner, and moving a job between stages prompts you to hand it to the next person. Recurring jobs — the BAS runs, the annual returns, the ASIC review dates — roll over with their assignees intact, so a new period's work never lands in a nameless pile. It's the difference between client accounting software that tracks work and software that actually keeps work moving.
The 'waiting on client' problem needs its own answer
The most common ownerless job is the one parked in 'waiting on client'. It looks like the client owns it — but they don't know that, and 'the client' isn't going to move the job for you when the document arrives.
The job is still yours. Someone in your firm owns the chase, owns noticing when the response comes in, and owns pushing the work forward again. Treating 'waiting on client' as a parking spot rather than an active state is how a return sits for three weeks when the client actually replied on day two.
Practically, this means:
- Every 'waiting' job keeps a named internal owner, not just a status.
- The request to the client is logged against the job, so anyone can see what's outstanding and when it was asked for.
- When the client responds — ideally through a portal that ties their reply back to the request — the job surfaces to its owner instead of sitting silently.
A client portal helps here because it closes the loop automatically. Instead of a document arriving in one person's inbox and a job stalling on a board somewhere else, the response lands against the work item and the owner sees it.
A weekly habit that catches the strays
Even with good systems, jobs will occasionally slip. Build one small ritual into your week: scan for work items that have no assignee, or that have sat in the same stage past a sensible threshold. Five minutes across the practice will surface the jobs quietly going nowhere — the return waiting on a single outstanding item, the review nobody claimed, the rolled-over job with no owner.
The point isn't to police people. It's to make invisible stalls visible while there's still time to act on them.
The bottom line
Missed deadlines usually aren't caused by anyone dropping a ball they were holding. They're caused by balls that were never in anyone's hands. The cure is boring and reliable: every active job has one owner, ownership travels with the work as it moves, and 'waiting on client' is an assigned state, not a black hole.
Get that right and most of your workflow problems stop being mysteries. When something isn't moving, you'll know exactly whose job it is to move it — and so will they.