Where do the hours go in operations? A one-week time audit

Ask an operations manager where the time goes and they'll give you an honest guess that's wrong. Not because they don't know the work, but because the work that feels heavy is the awkward, occasional kind, and the work that fills the week is the small stuff nobody notices: the status update typed into two systems, the invoice checked by eye, the question answered for the third time today. Ten minutes here, ten there, across five people, every day.

A one-week time audit replaces the guess with a count. It takes very little effort, it costs nothing, and it gives you the list you need before deciding what to automate first.

Before you start

Three things to settle, in a short meeting with everyone who'll take part.

• Say what it's for. This is about finding work a system could do so the team has more time for the work only they can do. It's about the tasks, never about the people. If people think they're being measured, they'll record what they think they should be doing, and the audit is useless.
• Agree the task list. Ten to fifteen names for the kinds of work the team does, in the team's own words: order entry, invoice matching, supplier chasing, status updates, reports, customer queries, meetings. Add a line for interruptions and one for other. Don't try to be exhaustive; a short list people use beats a long one they don't.
• Pick an ordinary week. Not month end, not a holiday week, not the week a new system goes live. You want the week that looks like most weeks.

Running the week

Each person keeps a simple sheet: the day down the side, half-hour blocks across, and in each block the name of the task from the list. It takes under a minute at the end of each hour and nobody should spend longer than that on it. If a block was split between things, put the bigger one. If the block was interruptions, write that; the interruptions line tells you more than anything else on the sheet.

Ask people to add one note beside any task that annoyed them that day, in a few words, without worrying about spelling or tone. Those notes are where you find the specifics: the invoice that arrived with the wrong purchase order number, the report that needed a formula fixed again, the question that could have been answered by a screen the customer can see.

Reading the results

At the end of the week, add up the blocks by task, per person and for the team. Then look for four patterns.

Small, daily, and shared

A task that takes half an hour a day for four people is ten hours a week, every week. It rarely feels like much to any one of them, which is why it never came up before. These tasks tend to be the best first candidates: they happen often enough to have a clear pattern, they're already half documented in people's habits, and taking them off the week is felt immediately.

The same information handled twice

Look for pairs: order entry and order acknowledgement, invoice checking and invoice posting, a status update in the project tool and the same update in an email. Whenever the same fact is touched in two places by two people, there's a handoff that could be a connection instead. Re-keying between systems usually shows up here.

Questions and interruptions

If the interruptions line is one of the largest, read the notes to see what the interruptions were. Very often they're questions whose answer exists in a system the asker can't see or doesn't know to look in. Where's this order? Has that invoice been paid? Is the supplier confirmed? Each is a minute, and the minute costs the person who was in the middle of something else.

The occasional heavy task

The month-end report, the quarterly compliance return, the annual supplier review. These feel heavy, and they are, but they happen rarely, there are few examples to learn from, and a system built for one of them is a system used twelve times a year. Note them, and put them behind the daily work in the queue.

What a week typically looks like

Take an operations team of five as an illustration. Added up, their week might show order entry and acknowledgements as the largest single line, spread across three people who each thought it was a minor part of their job. Next, invoice checking and chasing, mostly one person. Then interruptions, with the notes showing most of them were status questions from sales and from customers. Then the weekly report, a morning for one person. Then a long tail of smaller tasks, and the occasional heavy one that everyone remembered but that took fewer hours than the order entry.

Nothing in that picture is surprising once it's counted, and every team's version will differ in the detail. The surprise is the ranking. The team would have named the heavy task first; the sheets put it fifth. That reordering is the whole value of the exercise, and it's why the audit comes before any conversation about systems.

Mistakes that spoil the audit

• Too many task names. People stop choosing and start writing other. Fifteen is plenty.
• Recording at the end of the day instead of the hour. Memory rounds everything to the big tasks and loses the ten-minute ones, which are the ones you're looking for.
• A manager filling it in for the team. It's the team's week, and the notes are the part a manager can't write.
• Treating the result as a performance review. The first time anyone is questioned about a block, the next audit is fiction.

What to do with the list

You'll end the week with a ranked list of where the hours go and notes on why. Share it with the team first; they'll correct it and they'll have opinions about which task they'd most like to lose. Then take the top three and ask the four questions from the first post: how often it happens, how much judgement it needs, where its information comes from, and how you'd know it had worked.

Keep the completed audit sheets. They're the baseline, and they're the honest answer to the question every automation project gets asked later, which is whether it made any difference. When the first system goes live, run the same week again three months later, and the difference in hours is your result, counted the same way by the same people.

What to measure

• Hours per week by task, for the team, from the audit itself.
• Hours of manual work removed each week, from a repeat audit after the first system is running.
• Interruptions per person per day, before and after, where the system answers questions the team used to answer.

These are the first measures on our Operational Efficiency page. If you run the audit and want a second opinion on the top three, bring the sheets to the first call. It's the most useful thing you can bring.