Busy-season triage: how to order the work when it all arrives at once

Sort by readiness, not by arrival order. Three buckets — ready, blocked on the client, blocked on us — re-sorted weekly, and inside “ready” you work the earliest statutory deadline first. If your revenue authority already tiers its deadlines, copy the tiering rather than inventing one: it has done the prioritising for you, and it puts your least reliable clients at the front.

That last part is the one most practices get backwards, and it is the argument of this article. Everything below runs with no software you do not already have.

What does triage actually mean in a practice?

Sorting by state rather than by sequence. The word comes from medicine, where the sort has three properties worth stealing: it happens before treatment rather than during it, it ignores who arrived first, and it is redone as states change. A practice that sorts once in September and then works the list is not triaging, it is queueing.

The thing being sorted is the job, not the client. This matters more than it sounds. A client with a company return ready to start and a trust return waiting on a bank statement sits in two buckets at once, and any system that sorts whole clients has to pick one of those two truths and lose the other. Sorting jobs keeps both.

When is your busy season, actually?

That depends on which deadline binds each client, and in two of the three markets XTK sells into the answer is not one date but five. Here is the individual and trust calendar a practice with UK, Australian and New Zealand clients is actually working against, in chronological order.

Read down the “who it binds” column and the shape of the problem appears. The Australian agent program sorts a practice's clients into five tiers across seven months. New Zealand runs two dates. The United Kingdom has one, for everybody: 31 January, 11:59pm.

Why does one deadline for everybody produce a crush?

Because a shared deadline synchronises every client in the country, and the numbers are stark once someone counts them. For the 2024 to 2025 tax year, HMRC reported that 11.48 million people filed by 31 January — and that 475,722 of them waited until the final day. An estimated one million missed it entirely.

One figure in that release deserves more attention than the headline. The busiest hour of deadline day was not the last one: 32,982 returns were filed between 17:00 and 17:59, against 27,456 in the final hour. The peak lands inside office hours, which means most of deadline day is not panicking taxpayers at kitchen tables. It is practices clearing a queue, at the one moment in the year when clearing a queue is most expensive.

A synchronised deadline does not create more work. It compresses the same work into the window where every review is rushed, every query has no time to come back, and every staff absence is unrecoverable. The work was always there; the calendar decided when you would do it.

How does a tiered calendar prevent it?

By deciding in advance that different clients are due at different times, so no practice ever has its whole book due at once. Australia's agent program is the clearest published example, and it is worth reading as scheduling rather than as compliance. The tiers are in the table above: five dates from 31 October 2026 to 15 May 2027, sorted by trust size, by tax liability — clients whose latest return produced a bill of $20,000 or more come earlier — and by one other thing.

Look at what the first tier is made of. It is not the biggest clients, the oldest clients, or the most profitable ones. Tier one is individuals and trusts with a prior-year return still outstanding at 30 June. Tier one is the clients who were late last year.

Why do the late clients go first?

Because being late is not a fact about a client's motivation, it is a fact about how long their work takes to finish in calendar days rather than desk hours. A client with two returns outstanding cannot be started and completed in one sitting no matter how much capacity you point at them. Their records need reconstructing, their queries need answering by someone who has forgotten the year in question, and every round trip costs a week.

Elapsed time is the only resource a busy season cannot manufacture. You can buy desk hours in December — contractors, overtime, a temp on data entry. You cannot buy back the three weeks a client will take to find a 2024 bank statement. So the work that consumes elapsed time has to start when elapsed time is cheap, which is now.

That is why the instinct most practices have — leave the difficult, disorganised, chronically late clients until last, because chasing them is unpleasant — is precisely wrong. It puts the elapsed-time-heavy work into the part of the year with none left. Both revenue authorities that stagger deadlines reached the opposite conclusion independently: Australia moves the previously-late client to the earliest tier, and New Zealand withholds the extension of time from a newly linked client with more than one return outstanding. Neither is punishing anyone; both are scheduling. Adopt the tiering you are already subject to and you get a work order that is defensible to a partner and one no client can argue with, because it is the authority's own.

The three-bucket sort

Every open job goes in exactly one of three buckets, and the definitions have to be tight enough that two different people sorting the same job agree.

1. Ready. Everything needed to do the work is in your possession, and the next action is somebody in the practice doing the work. If you would have to ask anyone for anything before starting, it is not ready.
2. Blocked on the client. The next action belongs to the client, and you have asked for it specifically enough that they know what it is. A job where you have been meaning to ask is not blocked on the client. It is blocked on you.
3. Blocked on us. The next action belongs to the practice but is not the work itself — a review sitting with a partner, a query drafted but not sent, a job waiting on a colleague's file, an unanswered internal question, a job nobody has been assigned to.

The third bucket is the one practices refuse to create, and it is the one that shortens the season. Its contents are almost always invisible, because every item in it is somebody's intention rather than an event, and intentions do not appear in any system. It is also the only bucket a partner can clear in an afternoon without anyone outside the building doing anything.

Expect it to be embarrassing the first time. A practice that has never separated “waiting on the client” from “waiting on us” usually finds that a good share of what it called client delay was its own, sitting for weeks with nobody knowing whose it was.

How do you order the work inside “ready”?

Three keys, applied in this order, and the order is the whole point:

1. Deadline tier. The statutory date the client is actually bound by, not the date you associate with their type of work. In Australia this is handed to you; in the UK, where one date binds everyone, you build the tiers yourself and the next two keys do the work.
2. Elapsed-time risk. Within a tier, start the jobs most likely to need a round trip to somebody outside the practice — first-year clients, clients who were late last year, anything with a missing record, anything needing a third party such as a bank, a lawyer or an auditor.
3. Size, last. A job's hours matter for resourcing the week; they should not decide which week it falls in.

Alphabetical and arrival order need no argument. Smallest-first is more tempting, because it clears rows and feels like progress, and it fails because the rows it clears are the ones that would still have been clearable in January. The one honest exception: if a job genuinely takes five minutes and it is in front of you, finishing it costs less than scheduling it. Keep that narrow — the moment it becomes a category rather than a moment, you are doing smallest-first with a better name.

Is it always better to lodge early?

No, and this is where generic busy-season advice quietly harms a client. In Australia, the payment date for a return due 15 May is staggered by when the return is lodged and processed. Lodge up to and including 12 February 2027 and the payment is due 21 March 2027. Lodge between 13 February and 12 March and it is due 21 April 2027. Lodge from 13 March and it is due 5 June 2027.

So for a client with a bill to pay and a tight cash position, doing their return in early February rather than late March moves their payment date forward by roughly ten weeks. The work was done better and earlier, and the client is worse off — and nothing in the practice's own throughput metrics would ever show it.

The rule that survives is narrower than “lodge early” and more useful: get the work ready early, then sequence lodgment for the client's circumstances rather than the firm's queue. A refund position goes as soon as it is right. A payment position with a cash-flow problem is finished early and lodged deliberately. Either way, tell the client which you did, because the thing that reliably damages the relationship is a payment date they did not see coming.

What do you do with the blocked-on-client bucket?

Work it as a batch, not as a set of individual clients. The bucket exists so that chasing becomes one task done well on a Tuesday rather than forty interruptions across six weeks, and so that a job nobody can progress stops occupying anybody's attention until it can. The mechanics of the asking — what to itemise, where the files should land, how to make the outstanding items visible to the client rather than only to you — are a subject in their own right, and this blog has a five-step system for it.

One deadline belongs in this section rather than that one, because it is about sequencing rather than chasing. In Australia, a client engaging you for the first time, or moving from another agent, should contact you before 31 October to be part of your lodgment program. That makes September and October an onboarding deadline as well as a filing one: a prospect who signs in November has already lost the extended dates for that year.

Where does Practice Manager already do this?

More than most practices use it for. The three buckets do not need a new tool, a spreadsheet or a project board — they need three job states and three saved filters in software you are already paying for.

A job in Xero Practice Manager carries a job number, an owning client, a start date and a due date, a priority, an assigned manager, partner and staff, an estimated time against the time actually recorded, a percentage complete, and a job state that your practice defines itself. The Job Manager filters on those fields and lets you save the filters you use repeatedly.

Which gives you a working implementation in an afternoon:

• Add three job states — Ready, Waiting on client, Waiting on us — alongside whatever states you already run, and make one of them the default for new jobs so nothing lands unsorted.
• Set the due date on every job to the client's actual statutory deadline rather than an internal target, so that sorting by due date sorts by tier.
• Save one filter per bucket, and a fourth for the only view that matters on a Monday: state is Ready, ordered by due date.
• Put the practice's estimated time against the ready bucket for the coming fortnight. If it exceeds the hours you have, the sort has just told you something no amount of working harder will change.

Two habits make the difference between a system and three unused dropdowns. Changing state has to be part of doing the work rather than an administrative step afterwards — the person who sends a query sets the state to Waiting on client in the same minute. And somebody has to own the Waiting on us filter, by name, with a standing slot in the week to empty it.

Where does XTK help, and where does it stop?

XTK's honest contribution to triage is narrow, and it is worth being exact about, because triage is a cross-client problem and XTK is not a cross-client tool. What it does help with is the evidence a sort depends on. A document request turns “have we got everything for this job?” into something answerable at a glance, because each requested item is badged Provided or Outstanding as files arrive in the client's folder. That is the difference between a job you have classified as blocked and a job you assume is blocked.

The notification tray is practice-wide too: XTK records one row per event for the whole practice, so you learn that a client has uploaded or signed without opening every client's tabs.

Now the limits, because they bear on this article specifically. The tray is a feed, not a work queue — XTK's own guide calls it a launcher rather than a workspace. It shows the twenty most recent events, pages back through ninety days, then deletes them, and the unread badge stops counting at “9+”. More to the point, a feed reports arrivals. Triage needs absences. Outstanding-versus-provided state lives inside one client's Documents tab, and nothing in XTK aggregates what is still missing across every client.

Nor is there a scheduler anywhere in the product: no automatic reminders, no chasing on a cadence, no capacity planning, no workload dashboard. Following up is a manual action, and on a document request it rotates the link, so the previously emailed one stops working. The cross-client view lives in the Job Manager, which is where it belongs, and the sorting is done by a person.

A pre-season checklist

Six weeks before your ramp — early September for an Australian practice, mid-November for a UK one — in this order:

1. Pull every client's actual statutory deadline from the authority's own tiering, not from memory or last year's spreadsheet.
2. Find the clients in the earliest tier. In Australia that means anyone with a prior-year return outstanding at 30 June; in the UK and New Zealand, build the tier yourself from who was late last year.
3. Create the three job states and set every open job's due date to the client's real deadline.
4. Sort every open job into a bucket once, by hand. This is a two-hour job for a small practice and it is the only step with no shortcut.
5. Count the Waiting on us bucket and clear it before the season starts. This is the cheapest week of the year in which to do it.
6. Send the earliest-tier document requests now, itemised, with a single destination for the files.
7. Compare the estimated hours in the ready bucket against the hours you actually have, and take whatever decision that arithmetic forces while there is still time to take it.

What to measure across one season

Two numbers, and they answer different questions. First, what share of jobs entered the Waiting on us bucket at all. Second, the median number of days a job spent there once it did.

The first is a design number: it tells you how often the practice itself is the constraint, and it is reduced by changing how work is handed over, reviewed and assigned. The second is an execution number: it tells you how long the practice takes to notice, and it is reduced by somebody owning the filter. A practice that measures only total turnaround time cannot tell those two failures apart, and will spend a year fixing the wrong one.

Neither number needs new software. Both need the buckets to exist, which is the whole of the argument: the sort is free, the states are already in Practice Manager, and the only thing a flat-priced layer over your own storage changes is how quickly you can tell which bucket a job belongs in.