"It only takes five minutes" sounds like a perfectly reasonable reason to leave a process alone. I've spent enough time building and changing workflows to know that five minutes rarely tells you much on its own. What matters is how often those five minutes happen.

A small piece of repetitive administration can look insignificant when you watch someone do it once. Repeat it several times a day, across weeks and months, and it can

become a very different commercial problem. Five minutes isn't really the number that matters.

Take something as ordinary as moving a new enquiry from one system into another. Perhaps the enquiry arrives through one platform, but an employee then needs to copy the customer's details manually into a CRM or another internal system. Let's assume that takes five minutes.

If it happens once a week, it's probably not high on the list of problems worth solving. If it happens 20 times every working day, the calculation changes:

20 enquiries × 5 minutes = 100 minutes a day.

Across a five-day week, that's more than eight hours. Over 48 working weeks, that's roughly 400 hours of staff time. The task hasn't changed. The volume has. That's why looking at the time taken to perform an individual task without understanding its frequency can be misleading.

You're paying people to move information you already have

There's another reason I pay attention to this type of work. In our example, those 400 hours aren't being spent creating new information; the business already possesses the customer's details. Someone is simply moving that information from one place to another because the systems or workflow require them to.

That's a very different use of an employee's time from speaking to a customer, solving a problem, producing work, or doing something else that genuinely requires their knowledge and experience. It's also why I often talk about employees becoming the connection between systems. If information exists in one part of the business but somebody repeatedly has to re-enter it elsewhere, I'd want to understand why.

The true cost can be greater than the time spent.

The 400 hours in our example only measures the obvious part of the problem. Manual data entry can also introduce errors: a name, telephone number or email address might be entered incorrectly, information could be missed altogether, and someone then has to identify the mistake and correct it.

Interruptions also add cost. If an employee has to stop another task every time an enquiry arrives, the cost isn't limited to the five minutes they spend entering the information. If another part of the workflow can't begin until that manual step is complete, customers or colleagues may be waiting too. That is why I prefer to look at the wider workflow rather than measure one task in isolation.

Small inefficiencies can become expensive as a business grows.

A process can work perfectly adequately at one level of activity and become inefficient at another. Imagine our example business originally received five relevant enquiries a day. At five minutes each, manually moving the information might consume around 25 minutes; nobody is likely to see that as a major operational problem.

If growth takes that business to 20 enquiries a day, the same process now consumes 100 minutes. At 40 enquiries, it would consume more than three hours every working day. Nothing has technically broken; the process still works exactly as it did before, but the economics have changed. This is one reason growth can expose operational weaknesses that have existed for years.

Turn the time into a commercial number.

Once you know how much staff time a process consumes, you can start asking whether it's worth changing. Suppose the repetitive task accounts for about 400 hours a year;; the next step is to understand whose time those hours represent and what that capacity costs the business.

That doesn't automatically mean the process should be automated. The cost and complexity of improving it still matter: if releasing a meaningful proportion of those 400 hours requires a relatively straightforward integration between two existing systems, the commercial case could be compelling, but if solving the same problem requires an expensive, disruptive project, it might sit further down the priority list. Quantifying the problem makes that comparison possible.

This is about capacity, not just cost

Think of those 400 hours as capacity. If a business is growing, freeing up time from repetitive administration could let the existing team handle more enquiries, serve more customers, or focus on work that genuinely requires them.

That's particularly important when a business assumes increasing workload automatically means increasing headcount. Sometimes another employee is needed, but before hiring someone to absorb more administrative work, I'd want to understand how much of the existing team's capacity is consumed by repetitive processes that could be improved.

Look for the multiplier.

This is one of the things I'd want to establish during an operational audit. When somebody tells me a task "only takes five minutes," I'm less interested in the five minutes than I am in the multiplier behind it: how many times does it happen, how many employees do it, does the same information get handled again somewhere else, what happens as transaction volumes increase, and what else could those people do with the capacity if the task disappeared?

A five-minute task may genuinely be too insignificant to worry about. But you can't know that from the five minutes alone. Look at the frequency, the total time, and the wider workflow it sits inside before deciding it doesn't matter.