What a repetitive task really costs: the hours and francs math

How much does a repetitive task cost an SME?

Short answer: the yearly cost of a repetitive task is the time spent per occurrence, multiplied by the number of occurrences per year, multiplied by the fully loaded hourly cost of the person doing it, plus the cost of the errors it produces. The fully loaded hourly cost usually runs 40 to 60 % above the gross hourly wage, which is why most gut-feel estimates come out too low.

A manager who says “this takes us about a quarter of an hour a day” almost always underestimates the real cost. Payroll charges, rework, errors and interruptions get left out. This article walks through the calculation step by step, in hours and Swiss francs, with a full worked example, a threshold table, and the cases where the maths says not to automate. If you are still deciding which task to pick first, read our guide to choosing a first process before this one. Here, we put numbers on it.

Step 1: compute the fully loaded hourly cost

The fully loaded hourly cost is what one productive hour of work costs the company, not what appears on the payslip. The formula: (annual gross salary + employer charges + workstation costs) divided by the number of genuinely productive hours in the year.

Swiss employer charges have a known part and a part that depends on you. The known part, for 2026: 5.3 % for AHV/AVS, IV/AI and EO/APG, and 1.1 % for unemployment insurance up to a salary of CHF 148,200, so 6.4 % borne by the employer (federal social insurance overview, Swissmem). The variable part: occupational pension (LPP/BVG), accident insurance, family allowances, sickness daily-allowance cover. It depends on your fund and your industry. Use the rates on your own statements.

Here is the example we use throughout. Every value other than the AHV and unemployment charges is an assumption, to be replaced with your own.

In this example one hour costs CHF 56, while the gross salary divided by hours worked (78,000 ÷ 2,080 hours, a 40-hour week) gives CHF 37.50. The gap is close to 50 %. Calculating on gross salary understates every task by half.

Step 2: measure the time, do not guess it

Time per occurrence is the most mis-estimated figure. To measure it, time fifteen to twenty real occurrences over two weeks and take the average. Count the full duration, from the moment the task starts to the moment it is finished and checked, not just the keying time.

Three traps come back again and again. First, counting only “active” time and forgetting the search for information, the wait for a reply, the proofreading. Second, ignoring the interruption cost: a five-minute task that breaks a deep-work task costs more than five minutes. Third, forgetting seasonal peaks such as year-end close or VAT returns, which concentrate the work in a few weeks.

The example used here is chasing unpaid invoices, as described on our article on payment reminders. An assistant spends 25 minutes a day on it: reading the list, writing or adapting messages, logging replies. Over 220 working days that is 5,500 minutes, about 92 hours a year.

Step 3: compute the cost in francs, errors included

The cost of the time is simple: 92 hours × CHF 56 = about CHF 5,150 a year. The cost of errors is computed separately with this formula: number of occurrences × error rate × average cost of an error.

Assumptions for the example: 8 reminders handled a day, so 1,760 a year. A 2 % error rate (wrong amount, wrong recipient, a missed reminder) gives about 35 errors. Each takes 20 minutes to fix, nearly 12 hours and CHF 650. One error in ten also has an external consequence (an annoyed customer, a reminder sent by mistake), estimated at CHF 150: about 3.5 cases, so CHF 525.

So a task that takes a quarter of an hour a day costs about CHF 6,300 a year. No single line is spectacular. The sum is.

Step 4: remove what automation will not eliminate

Automation does not remove 100 % of the cost. Industry guides usually assume 60 to 80 % of the time is recovered, because some review, exceptions and supervision always remain. Those are vendor rules of thumb, not guarantees. Take 70 % for the example: the gross gain is 6,300 × 0.7, about CHF 4,400 a year.

Then deduct the recurring costs of the automation itself: subscriptions, hosting, maintenance. Market sources put maintenance at 10 to 20 % of build cost per year, on top of subscriptions. In the example we assume an initial investment of CHF 4,000, CHF 600 a year of maintenance and CHF 40 a month in subscriptions, which is CHF 480. These are calculation assumptions, not a price list.

1. Gross annual gain: CHF 4,400.
2. Recurring costs: 600 + 480 = CHF 1,080.
3. Net annual gain: CHF 3,320.
4. Payback: 4,000 ÷ 3,320 = 1.2 years, about 14 months.

Fourteen months: neither obvious nor bad. A payback under 12 months is comfortable, beyond 24 months you should ask questions. Those are the usual benchmarks in the field; adapt them to your own horizon.

The hours threshold: when is a task worth it?

The useful question is not “does this task cost a lot?” but “how many hours a year does it take for automation to pay for itself?”. With the same assumptions (CHF 56 an hour, 70 % gain, CHF 4,000 investment, CHF 1,080 of recurring costs), and leaving errors out, here are three tasks of different sizes.

Reading it: payback is not linear. Below roughly thirty hours a year, the gain does not even cover the recurring costs. Up to 50 hours, payback exceeds four years. Between 50 and 100 hours the case is borderline and depends on how you count errors. Above 150 hours it becomes comfortable. Note the effect of errors too: on the 92-hour task, including them brings payback from 19 to 14 months. A task that produces many costly errors pays off sooner than a clean but long one.

When this calculation says not to automate

An honest calculation sometimes returns a negative answer. These are the cases where you are better off installing nothing.

• The task is rare or short. Under 50 hours a year, with an investment of a few thousand francs, payback often exceeds five years. A clear instruction and a message template are enough.
• The process is not stable. If the rules change every quarter, maintenance eats the gain. Stabilise the process first.
• The gain is scattered time. Five minutes saved a day across ten people does not become a position saved. The gain is real only if the time is redirected to something that earns money, or if the workload avoids a hire.
• The data is not accessible. If the information lives on paper or in one person’s head, the real cost of the project is tidying it up, not automating it.

In those cases the right investment is often to simplify the task, or drop it. A task that no longer has a reason to exist does not deserve to be automated.

The costs the calculation still forgets

Three items almost always escape the first pass, and they cut both ways.

• Start-up time on the team side. Validating rules, testing, correcting: count a few hours from the person who knows the task. That time is an entry cost.
• The adoption curve. Gains do not arrive on day one. Allow two to three months before measuring a steady state.
• Single-person dependency. When a task rests on one person, an absence blocks it. That risk has no line in the table, but it weighs on the decision.

For customers’ personal data, add one check: whatever is sent to an AI service must comply with Swiss data protection law. We cover this in our article on the Swiss FADP and language models.

Running the numbers for your own SME: the method in five lines

1. Compute your fully loaded hourly cost from your actual statements, not from gross salary.
2. Time the task over fifteen real occurrences.
3. Multiply by the yearly number of occurrences, then add errors.
4. Remove 20 to 40 % that automation will not eliminate, then the recurring costs.
5. Divide the investment by the net annual gain: under 12 months, go; over 24 months, reconsider.

If you have several candidate tasks, run this for each and rank them by payback. The first one to start with is the one with the shortest payback and the clearest rules, as explained in our method: a foundation, then modules.