Run a weekly capacity review without guesswork

Count demand before discussing hours

Start the weekly review with the work that arrived, not the hours the team logged. Count requests by channel, client, and type, then separate new work from follow-ups. A week with high logged hours may still have low output if most time went to waiting or rework. Put the demand count beside the capacity number before anyone offers an opinion.

Use a consistent counting rule so week-over-week comparisons mean something. Count one request per distinct outcome, not one per message in a thread. Record the source of the count, such as the inbox export or the task board. If the source changes, note the break rather than pretending the trend is continuous.

Show the arrival pattern by day and hour, not only the weekly total. A team can be fully staffed on paper and still fail every Monday morning because the work arrives in a two-hour window. The pattern tells you where to place the buffer. A total without a shape hides the operational problem.

Keep the counting rule beside the report so a new reviewer can reproduce the number. If a request is split across two channels, count it once at the point of origin and note the second channel. A rule that changes with the reviewer turns the trend into a story. The count should be boring enough to trust.

Separate recurring work from one-off requests

Recurring work has a predictable cadence and a known owner, while one-off work arrives without a schedule. Split the two because they consume capacity differently and need different planning. Recurring work can be leveled across the week, while one-off work needs a buffer or a queue. A review that blends them hides the real reason a Thursday collapses.

Tag the one-off requests that recur often enough to become a standard task. A client who asks for the same report every month is creating recurring work without a recurring slot. Move that work into the schedule or price it as a project. The tag turns a surprise into a planning decision.

Measure queue age instead of activity

Activity counts such as messages sent or tasks touched can rise while the queue gets worse. Measure the age of the oldest open item and the number of items past their target. Add the time a request waits for a decision, because waiting is often the largest hidden cost. These measures show whether capacity is reaching the work that matters.

Review the age distribution rather than only the average, since one old item can disappear inside a healthy mean. List the five oldest items and their blockers at every weekly review. Assign an owner and a next action to each. A queue that is reviewed by age is harder to neglect than a queue reviewed by volume.

Separate queue age from task age. A request can sit in a triage queue for two days and then be completed in an hour, while another task can age slowly inside a single owner's list. Both waits matter, but they need different fixes. Report them separately so the review does not blame the wrong stage.

Identify the real constraint in the lane

The constraint is the step that limits the whole lane, not the person who looks busiest. It might be a single approver, a missing report, a slow client response, or a tool that requires manual entry. Trace a sample of requests from arrival to completion and mark where each one waited longest. The pattern usually points to one or two constraints.

Test the constraint before adding hours. If every request waits for the same reviewer, a new assistant will simply create more work for that reviewer. Fix the approval path, delegate a narrow decision, or batch the reviews. Add capacity only when the constraint is genuinely assistant time.

Name the constraint in one sentence and test it with a small change before committing to a hire or a schedule change. If the change does not move the queue, the constraint was misidentified. Record the test and the result in the next review. A constraint that survives a test is a much stronger basis for spending money.

Decide what to stop, shift, or add

Every capacity review should end with a short decision list: what to stop, what to shift, and what to add. Stopping might mean retiring a low-value report or declining a request that is outside scope. Shifting might mean moving a task to a different day or a different assistant. Adding should name the hours, the owner, and the start date.

Put a cost or consequence beside each option so the decision is not purely emotional. A report that takes four hours but nobody reads is a candidate for retirement. A task that blocks a client deliverable may justify extra coverage. Record the decision and the expected effect so the next review can check it.

Record the capacity decision for next week

Close the review with one page that shows demand, capacity, the constraint, and the decisions. Send it to the people who can change the schedule or the scope. Keep the page short enough to read in five minutes. A decision that lives only in a meeting will be relitigated by Thursday.

At the next review, check whether the decision changed the measure it was meant to change. If it did not, record why before choosing another action. Capacity planning improves through these small, dated tests. The goal is not a perfect forecast but a team that notices drift early.