Where the Week Goes

The most expensive line in a small store's accounts is not in the accounts.

Founder and staff time spent on operational admin generates no invoice, appears on no report, and is absorbed into the working day without ever being counted. It is treated as free because nothing bills for it. It is not free — it is the most constrained resource the business has, and at £250k–£1m it is almost always the binding constraint on growth rather than capital or demand.

This is the last guide in the series. The previous ten described specific operational failures. This one is about measuring what they cost you in hours, and — the part most content on this subject skips — deciding honestly whether it is worth doing anything about it.

Why the number stays hidden

Three reasons, and they compound.

It arrives in fragments. Nobody spends a day on inventory admin. They spend eleven minutes, then seven, then twenty. Fragments do not register as work; they register as the texture of the day.

It is done by the person least likely to record it. Founders do not fill in timesheets. The tasks are absorbed into evenings and Sunday mornings, which are not counted as working hours at all.

It feels like the job. Checking stock, chasing a supplier, processing a return — these are the business. Questioning whether you should be doing them personally feels like questioning whether you should be running the business.

The result is a cost the size of a part-time salary that has never been written down.

How do you measure where the week goes?

Not a time-tracking app. A note on your phone.

For ten working days, every time you do something operational, write the task and the minutes. That is the whole method. Two weeks is enough to catch weekly tasks and short enough that you will actually finish.

What counts. Anything from this series: checking stock levels, deciding reorders, raising or chasing purchase orders, receiving deliveries, processing returns, checking what is out of stock, adjusting advertising for unavailable products, building campaign product lists, reconciling stock between locations, answering "where is my order" enquiries, updating spreadsheets that exist to bridge two systems.

What does not count. Product development, buying decisions, supplier relationships, marketing strategy, customer conversations that build something. These are the work. The point of the exercise is to see how much of the week is not these.

Two things to record that people leave out:

• Context switching. A task that takes four minutes but pulls you out of something else costs more than four minutes. Note when it happened, not only how long it took.
• Exception handling. The delivery that arrived short. The return that needed a decision. These are irregular, they are the bulk of the real cost, and they are exactly what a fortnight's log captures and a mental estimate misses.

What does operational admin add up to?

An illustrative store, using its own measured figures. These are not benchmarks — your numbers will differ and yours are the ones that matter.

Across 48 working weeks that is 440 hours — about 11.7 working weeks, or roughly a quarter of a full-time role.

The line worth staring at is the ten-minute one. Ten minutes a day is 40 hours a year. A full working week, spent checking what is out of stock, in fragments too small to notice.

What rate should you value your own time at?

Most people multiply their hours by what they would pay someone else to do the work. That understates it, sometimes by a factor of three.

The correct figure is opportunity cost: the value of what you would have done instead. For a founder at £500k, the alternative use of those 440 hours is not idleness. It is product development, buying, supplier negotiation, partnerships, or the customer conversations that only the founder can have. Those activities have a return, and it is generally well above an administrative hourly rate.

The honest version of the calculation is uncomfortable and simple: if I had eleven additional weeks this year to spend on the highest-value thing I am not currently doing, what would that have been worth?

For staff hours, replacement cost is the right measure. For founder hours it is not, and using it will lead you to conclude that a problem is smaller than it is.

Eliminate, delegate, automate — in that order

Automation is the last of the three and most content on this subject presents it as the first. Work through them in sequence.

Eliminate. The cheapest automation is not doing the task. A surprising proportion of recurring operational work exists because of a decision nobody remembers making — a report nobody reads, a check that duplicates another check, a spreadsheet maintained to reconcile two systems that no longer disagree. For every task on your log, ask what would actually happen if you stopped. Sometimes the answer is nothing.

Delegate. Some tasks need a person but not you. Receiving is the clearest example: it is 72 hours a year in the illustration above, it is genuinely manual, and it does not require the founder. This is a hiring or restructuring decision, not a software one.

Automate. What remains: high-frequency, rule-based, unambiguous, and consequential when done late. That is a much smaller set than it appears at the start of the exercise, and it should be.

Guide 02 covers what an app will handle. The Flow recipes companion covers what Shopify will do for free. Both are worth exhausting before anything is built.

When should you not automate?

The section that most writing on this topic omits, and the one that will save you the most money.

When the task is rare. Something done monthly for twenty minutes is four hours a year. Almost nothing is worth building for four hours a year.

When the process is broken. Automating a bad process makes it produce bad outcomes faster and removes the human who was quietly correcting them. Fix the process first, then automate the fixed version. This is why Guide 05 on product data comes before everything else — automating on top of inconsistent SKUs produces confident, wrong results.

When the exceptions are the work. If eighty per cent of instances follow the rule and twenty per cent need judgement, automating the eighty leaves you handling only the hard cases with no routine work to keep you fluent in the process. Sometimes that is the right trade. Often it is not, and it is rarely considered.

When you have not measured it. Building against an estimate means building the wrong thing at the wrong size.

When the payback is long. The test: hours saved a year, multiplied by your honest rate, against build cost plus running cost. If the payback runs beyond roughly eighteen months, the case is weak — requirements will have changed by then. If it is under six months, the case is strong. In between, it depends on how much you dislike the task, which is a legitimate factor and worth naming rather than dressing up as arithmetic.

A caution on estimates. People consistently overestimate savings, because they price the task and forget the exception handling, the monitoring, and the periodic maintenance. Assume you will recover perhaps seventy per cent of the measured hours rather than all of them, and check whether the case still holds at that level.

Why this matters more as you grow

The reason this guide closes the series.

Operational hours scale with SKU count, order volume and channel count. Revenue scales with all three too — but the founder's available hours do not scale with anything. They are fixed at the same number they were at £200k.

So the proportion of the week consumed by operations rises steadily, invisibly, and the crossover arrives without announcing itself. There is no month where operations become a problem. There is a gradual transition from the founder does operations in the evening to operations are not being done properly and nobody has noticed.

That transition is what every guide in this series has been describing from a different angle. The variant that went out of stock while ads ran. The back-in-stock alert that went to everyone. The returned unit that sat for ten days. None of those are technology failures. They are all the same failure: a person who used to bridge the gap no longer has the hours to bridge it, and nothing else was ever built to.

The App Ceiling

This section appears in every one of The Operational Guides. It describes where the advice above stops working.

Everything above holds to roughly £1m–£1.5m in annual revenue. Past that point the constraint changes, and it changes in a way that adding further apps does not address.

Apps are built to be sold to many stores. That is what makes them affordable, and it is also what limits them: an app can only act on the data inside its own boundary. Your forecasting tool does not know what your ad platform is spending. Your ad platform does not know what is out of stock. Your back-in-stock tool does not know what your supplier lead times are. Each app is correct within its own scope and blind outside it.

Below roughly £1m, a person bridges those gaps. Someone looks at the stock report, notices a line is running low, and adjusts. The bridging is invisible because it is absorbed into the founder's day.

Above roughly £1m, three things happen at once. SKU count rises, so there is more to bridge. Order volume rises, so the consequence of missing something rises with it. And the founder's time is now spent on growth rather than operations, so the bridging stops happening reliably. Nothing breaks visibly. Revenue keeps climbing. What changes is that a percentage of it begins to leak in places nobody is looking — advertising spend running against unavailable variants, stock accumulating in the wrong location, returns sitting unprocessed for a week and a half while the item they contain is out of stock and being advertised.

That is not an app problem, and no app solves it, because the solution has to sit between systems rather than inside one. It requires something built for your specific stack, your specific SKU structure, and your specific supplier terms.

The time log is how you find out where you actually stand. A store spending four hours a week on operational admin has a habit. A store spending fifteen has a structural problem it has not named yet. The number tells you which, and it is the only reliable way to know — because the experience of both is identical from the inside.

Where this leaves you

Eleven guides, and the through-line is a single argument: the operational problems that limit a growing Shopify store are not caused by bad tools. They are caused by good tools that cannot see each other, bridged by a person whose hours do not grow with the business.

Almost everything in this series can be improved without buying anything. Fix the product data. Calculate reorder points properly. Bind the notify-me widget to variant availability. Add an inventory condition to your flows. Prioritise the returns queue by stock position. Turn on the free Flow workflows. None of that costs money and all of it works.

Do those things first. If you do them and the hours still do not fit in the week, you have learned something specific and expensive about your business, and you will have the measurements to act on it.

Start with the log. Two weeks, a note on your phone. It is the cheapest diagnostic available and the only one that tells you which of the previous ten guides actually applies to you.