Automation Capacity Planning: Find the Real Limit

Capacity planning starts at the finished result

Automation capacity planning means matching incoming work to the rate of usable, completed results. Count what passes the required checks and reaches its destination. Then identify the stage that limits that rate, including human review and exception handling. A faster first step cannot clear a slower final step. This is business education, not financial advice. Financial decisions belong with a licensed financial adviser.

A scheduled run proves that a trigger exists. A running process proves that something started. Neither proves that a customer received the result. The capacity question is whether the whole operation can keep its promise under the actual mix of work.

That distinction matters before adding another tool, another worker or another daily batch. Each can increase activity while the queue of unfinished work grows.

What does finished mean in this workflow?

Choose one unit that survives the whole process. For a document service, it might be a customer request with an accepted document delivered to the correct account. A draft file is an intermediate result. An approval without delivery is another intermediate result.

The Kanban Guide distinguishes completed items per time period from work that has started but remains unfinished. It also separates the age of unfinished work from the time completed work took. Those measures depend on defining the start and finish points.

Apply that distinction before reading an automation report. Our proposed operating record follows a request through these states:

Keep correction attached to the original request. If the same document takes several attempts, the operation has completed one customer result when it finally delivers. The attempts belong in a separate count because they consumed capacity.

For a broader measurement setup, see business metrics from day one. Here the decision is narrower: which part of an automated workflow needs capacity next?

What happens when arrivals exceed completions?

Consider a hypothetical document operation. These figures are invented model inputs for arithmetic, not a client example, benchmark or forecast.

It starts with 360 unfinished requests. Each operating day brings 180 new requests. Preparation can produce 240 drafts a day. Review can inspect 150 requests a day. The complete workflow actually delivers 120 accepted results a day after corrections and delivery handling.

The final observed rate is the number that matters for this model. It is not a claim that every inspected request has the same failure probability.

Assume comparable requests and constant realized rates. Nothing is withdrawn or reopened. Over five operating days:

• New requests total 180 × 5 = 900.
• Completed results total 120 × 5 = 600.
• Closing unfinished work is 360 + 900 − 600 = 660 requests.

Now double draft preparation to 480 a day. If final delivery stays at 120, the same 660 requests remain unfinished. More drafts might reach review sooner. It does not change this queue calculation.

The response should follow the limiting stage. If review is waiting for clear source material, more reviewers alone may not help. If accepted work waits for delivery, faster drafting is aimed at the wrong problem. Trace the requests that failed to finish and name the dependency.

How much extra capacity clears the backlog?

Keeping up and catching up are different requirements.

Use the same hypothetical starting backlog of 360 requests and 180 new requests per operating day. Compare three assumed, sustained final completion rates:

The higher rates assume changes that let the entire workflow, including review, sustain that output. They cannot be achieved while the earlier review limit stays unchanged.

The recovery calculation uses spare capacity. At 200 completions a day, 180 serve continuing arrivals and 20 reduce the old queue. Therefore 360 ÷ 20 = 18 operating days. At 240, the spare capacity is 60 and 360 ÷ 60 = 6.

These are conditional arithmetic results. They are not customer delivery promises. Priority order, missing inputs, changing request complexity and interruptions can change the result. Individual requests can wait longer than an aggregate calculation suggests.

If completed output merely equals arrivals, the model has no spare capacity to remove the existing backlog. Calling that rate sustainable describes new demand only. It does not solve the inherited delay.

Are the work units actually comparable?

A short template request and a disputed source document should not automatically carry the same planning weight. Counting them together can hide a change in the work mix.

Google's Handling Overload chapter explains a related problem in software services: different queries can consume very different resources, and the relationship between request counts and resource use can change. It cautions against relying on request counts alone to model capacity.

Our business application is to compare similar request types before treating yesterday's output as tomorrow's capacity. Separate straightforward work from items requiring investigation. Keep the total item count, then add the time and resources each class actually used.

Record why difficult items are difficult. Missing information calls for a better intake step. Repeated review failures call for a defect correction. A dependency that answers only on certain days creates a calendar constraint. These are different interventions.

Do not relabel difficult requests as exceptions and remove them from the commitment record. They remain work owed until an authorised disposition changes that obligation.

Can the activity counter count one item twice?

Read the definition before trusting a platform metric. A successful technical operation may describe a message transfer, not a finished customer outcome.

Amazon SQS documentation gives a concrete example. Its received-message count can include repeated receipt of the same message. Its deleted-message count can include repeated successful deletion operations. Neither is an exact count of unique completed business results.

That is a specific warning about those SQS metrics. For any other tool, inspect its own definitions rather than assuming identical behaviour.

Our recommended business control is a unique request record with a separately confirmed delivery event. Keep retries and corrections visible beside it. Compare the counter with actual request histories, including a failed attempt and a successful retry. If the two disagree, fix the definition before using the number to promise capacity.

What capacity is available on the actual calendar?

Configured workers and available workers are different inputs. A process can exist but be paused. A reviewer can be assigned but unavailable. A downstream service can be accessible while the particular permission needed for a request is missing.

Build the capacity record from observed operation. Include the periods when work does not move. Do not multiply a brief peak rate by the entire day unless the process actually sustains that rate across the day.

List the coverage gaps explicitly: review hours, absence cover, input availability, maintenance and dependencies. Identify who sees a stopped process and who resumes the next batch. A schedule without an accountable response leaves the capacity assumption unfinished.

This is also why a tool purchase does not prove the desired capacity increase. The relevant test is a completed result through the entire path. Our research and execution work connects the proposed change to the operation that must carry it.

What should change before the next batch?

Start with a specific hypothesis about the limiting stage. For example, the proposed change might remove a repeated intake defect that forces reviewers to request the same missing information. State what evidence would show that the defect is actually the constraint.

Then compare like-for-like work before and after the change. Keep the completion boundary and acceptance checks fixed. Record incoming requests, final deliveries, returned work and the oldest outstanding commitments. Include interruptions rather than deleting them from the observation period.

If completed output increases while acceptance stays intact, that supports the change for the observed work. It does not prove unlimited scale. If preparation rises while finished output stays flat, inspect where the extra work accumulated. Do not call that a capacity win.

Choose the next action from that evidence. Improve the missing input, resolve the dependency, add qualified capacity at the limiting stage or revise commitments through the appropriate process. Keep legal and contractual decisions with counsel. Spending and financial decisions need the relevant licensed financial adviser. This analysis is not financial advice.

The discipline is simple: measure the finished result, account for continuing demand and leave room to recover. It is the same evidence-first approach described in how we work.

Sources

• The Kanban Guide, May 2025: defined workflow boundaries and distinct flow measures.
• Google SRE: Handling Overload: why request counts alone can misrepresent resource demand.
• Amazon SQS: Available CloudWatch metrics: repeated-message counting limitations.