What's Actually Worth Automating

Someone on your team loses most of Thursday afternoon to a report. The numbers live in three places: the accounting software, a spreadsheet somebody maintains, and whatever the operations tool exports. They pull from each, reconcile the differences by eye, format it, and send it Friday morning. They have mentioned more than once that there should be a better way.

They're right. But the better way is probably not the thing they asked for.

Requests like this almost always arrive shaped as a tool. Build us something that does the report. A tool is the unit people know how to ask for, the way you ask for a car rather than for a change in how you get to work. And a tool is the most expensive answer available, which makes it a poor place to start.

The thing that gets escalated is never the small thing

It's worth noticing which friction people actually complain about, because it isn't the friction that happens most often.

Nobody escalates twenty seconds. Copying a client name from one system into another, four times a day, never comes up in a meeting about process. Across a team of six over a year that's still only about thirty-five hours, and it arrives twenty seconds at a time, which means it never comes back as anything usable. Nobody works fewer hours. No hire is avoided. It dissolves into the day.

The Thursday afternoon is different, and not only because it's bigger. It's a block. It has a name, it has a dread attached to it, and it displaces other work. The person doing it can tell you what it costs them because they can point at the hole it leaves in their week.

And the real cost is larger than the clock. Three hours of reconciliation is three hours plus every reorientation on either side of it: closing what you were doing, loading the report context, and finding your way back afterwards. Interrupted work is worse than slow work. That's why the weekly thing gets raised and the daily thing doesn't, even though the daily thing happens sixty times more often.

Concentrated time is also the only kind you can spend. Two days a month lost to a reconciliation is a quarter of someone's year you could redeploy, or a role you don't have to backfill. That is a number a build can be measured against. Diffuse seconds aren't.

Most of it isn't a tool

Once you know which block of time you're attacking, the question becomes how little you can spend to remove it. In practice the answers run in rough order of cost.

Sometimes the answer is nothing: the report exists because someone asked for it two years ago and nobody has checked whether it's still read. This happens more than people expect, and it's worth ten minutes of asking before anything else.

Sometimes the spreadsheet just needs fixing. A well-maintained spreadsheet is often more effective than a custom tool that takes months to build and needs supporting afterwards. There's no shame in a spreadsheet that works.

Sometimes two systems need to talk to each other, once, and the reconciliation disappears because the numbers stop disagreeing. This is the most common real answer and the one people are least likely to ask for, because it isn't visible as a thing you own.

Sometimes a step needs to run on a schedule rather than when somebody remembers. The export that happens Thursday because a person does it can usually happen Thursday because a machine does it.

And sometimes it really is a tool. But that should be the conclusion you arrive at after the cheaper answers have failed, not the request you start from.

When a spreadsheet stops being enough

Spreadsheets are flexible, people already know how to use them, and they can be changed without a developer. They stop being the right answer under fairly specific conditions:

• Multiple people need to update it simultaneously and conflicts become frequent
• The data in it needs to be reliably connected to other systems
• It's grown to the point where its structure is fragile and only one person understands it
• Business decisions depend on its accuracy, but there are no safeguards against errors
• The same information is being manually mirrored across several spreadsheets

That last one is the Thursday report in disguise. If the same numbers exist in three places and someone reconciles them by hand, the problem isn't the spreadsheet. It's that nothing connects.

Signs the answer really is custom software

Some patterns do justify building something purpose-built:

• A manual process consumes enough concentrated time that it changes a staffing decision
• Errors in a process have meaningful financial, reputational, or operational consequences
• Information that should be connected lives in separate systems, and someone is acting as the bridge
• A workflow has grown complex enough that new team members can't learn it without extensive guidance
• The team has already tried spreadsheets and off-the-shelf tools, and the gap between what's available and what's needed is clear and specific

The key phrase is "clear and specific." Vague dissatisfaction with current tools is not a strong signal. A precise description of where time is lost, where errors occur, or where information falls through the cracks is.

Getting to specific means watching, not asking

Most automation is designed around how work is supposed to happen. Someone documents the ideal process, identifies the pain points in that ideal process, and automates those. The problem is that the ideal process and the actual process are rarely the same thing.

Teams develop workarounds, informal handoffs, and shortcuts that make sense in context but never appear in any process document. Automate the documented version and you get something that feels foreign, built for a different team doing different work.

Interviews have a well-known limitation here: people describe the process they think they follow, which is often different from the process they actually follow. They omit steps they've internalized. They understate workarounds they've normalized.

So sit with the Thursday afternoon and watch it happen once. You will usually find that the three hours aren't three hours of one thing. They're forty minutes of genuinely fiddly reconciliation and two hours of exporting, reformatting, and waiting, and only one of those needs a person.

If you've read Making Invisible Workflows Visible, this idea will be familiar. The same principle applies: understanding how work actually flows has to come before deciding what to change.

The question to bring, instead of a tool

The useful thing to arrive with isn't a specification. It's a block of time you can name, and a description of what happens inside it.

If someone on your team loses a predictable chunk of every week to moving information between systems, tell us what that afternoon looks like. We'll tell you which part of it is worth automating, and often the answer is smaller and cheaper than the thing you were about to ask for.