Skip to main content
Start a conversation
Menu

Planning tool

Automation capacity calculator

Put in the people, the minutes and the costs you believe. The calculator shows the arithmetic. It does not tell you that the money will appear in the bank.

Calculate from your assumptions

The numbers already in the boxes are an illustrative example: 10 people, 20 tasks, 15 minutes becoming 10, 46 weeks, £30 an hour, £10,000 upfront and £2,000 a year to run. They are not a TechGeek result. Change them before you treat the answer as yours.

When to use this

Use this when a team wants to see whether a repeated task is even large enough to justify a conversation about automation. Use it before a proposal, not instead of one.

  1. 01

    Name one repeated task

    Choose a task a named group of people already does, such as checking an intake form or copying a status into another system. A department-wide transformation is too vague for this sum.

  2. 02

    Time the task as it is

    Use a recent sample of how long the task takes today, including the waiting and checking that belong to it. A hoped-for future time is not the 'before' figure.

  3. 03

    Be honest about the after time

    If the new process adds review, exception handling or rework, the minutes after can be higher than the minutes before. The calculator keeps that negative result.

  4. 04

    Separate capacity from cash

    An hour released is an hour that might be used for other work. It becomes cash only if headcount, overtime or a supplier invoice actually changes. Say which of those is in scope.

  5. 05

    Include the cost of running it

    Put the annual cost of licences, support and the time spent looking after the change into the running-cost box. Leave it at zero only when you have checked that there is nothing to pay.

  6. 06

    Treat the answer as a question

    A positive figure is a reason to look harder at adoption, risk and the workflow. It is not a savings guarantee and it is not a quote from TechGeek.

Applied guidance

Use the tool as a decision record, not a box-ticking exercise.

01

Start from a task you can watch

The useful input is a task someone can point at. A coordinator opening a queue, reading three fields, and typing a decision into another screen is a task. 'Become more efficient' is not. Write who does it, what triggers it, and what finished looks like. If several roles touch the work, either pick the role that repeats the same action or add their time into the minutes rather than inventing a second calculator. The point of one task is that a sponsor can later check whether the assumption was fair. A blended departmental average hides the work that will not actually change.

02

Count the weeks people really work

A year of fifty-two weeks overstates a team that stops for leave, month-end freezes or seasonal quiet. The worked example uses forty-six weeks because that is a visible assumption, not because every organisation has the same calendar. Put in the number of weeks the task actually happens. If the task is monthly, do not pretend it is weekly: either convert it to an equivalent weekly figure and say so, or lower the tasks-per-week number until the annual total matches the real calendar. The calculator will not correct a calendar you have invented.

03

Price an hour without pretending it is a saving

Hourly cost should be a figure the organisation is willing to defend: a loaded employment cost, a contractor rate, or the overtime rate that would otherwise be paid. It should not be a benchmark copied from a vendor slide. Multiplying hours by that rate produces a capacity value. Capacity value answers 'what is this time worth at the rate we typed?' It does not answer 'whose salary will we stop paying?' If the same people will still be employed and will use the time on other work, say that. The net figure then becomes a way to compare the running cost with the time released, which is still useful and still not cash.

04

Let the after-time be worse

Some changes add a check that did not exist. A person may spend five extra minutes reviewing an automated suggestion. The formula keeps the sign of the difference, so the annual hours can be negative and the capacity value can be negative. That is a successful use of the calculator. It tells the team that, on these assumptions, the proposal consumes time. Payback is then shown as no positive payback, rather than a divide-by-zero or a flattering infinity. If you are comparing two options, run the sum twice and keep both assumption lists. Do not average them into a single optimistic case.

05

Read ROI only when there is an upfront cost

The first-year illustrative return divides the net capacity value, after running cost and after the upfront investment, by that upfront investment. If the upfront box is zero, there is nothing to divide by, so the result says not applicable. That is deliberate. A change with no upfront spend can still be worth discussing, but it does not have a return on an investment that was never made. If the net capacity value is zero or negative, payback also stays unavailable: there is no positive monthly surplus from which the upfront spend would be recovered. Show those labels to a finance colleague rather than replacing them with a zero that looks like instant payback.

06

Put the result back into a delivery question

A calculator cannot see whether the source system will allow the change, whether the people will adopt it, or whether an exception path will eat the minutes you hoped to remove. After you download the record, the useful next step is a short workflow test: one user, the real trigger, the exception, and the owner who would accept the change. TechGeek can look at that with you as an ordinary delivery conversation. The downloaded file is your assumptions and the arithmetic. It is not a forecast, a case study or a commitment that a project will pay for itself. If the numbers are large only because the hourly rate or the volume was guessed, correct the guess before anyone repeats the figure in a board paper.

Working prompts to adapt

Task

[Role] repeats [task] about [n] times a week. It takes about [a] minutes. We think a changed process would take [b] minutes, including review.

Money assumption

We are pricing an hour at [c], which represents [salary, contractor rate or overtime]. Upfront cost is [u]. Running cost is [o] a year.

What the number is for

We will use the result to decide whether to [investigate / pilot / stop]. We will not present it as cash saved unless [named change in spend] is agreed.

Primary guidance