What to automate, and what to leave to a person

When a business asks to "automate this", they almost always mean work that repeats. But repetition on its own is not enough to decide. Some work comes round every week and needs judgement every time, and automating that just produces bad decisions faster.

The line we work to: automation suits work that runs on a schedule and has a defined answer. If both are true, a person doing it by hand is waste. If either is false, automating it will cost more than it saves.

What it looks like when it fits

The system we built for Mishmar runs five scheduled jobs that nobody has to remember. Daily points granting, a daily sync against the spreadsheet, a daily collision report, hourly cleanup of swap requests, and a daily cleaning-duty rotation.

Each one has the same two properties. It runs at a fixed time, and its answer follows from the data without argument. Who earned points today is a calculation, not a decision.

It is worth noticing what was deliberately left manual. The scheduler produces a proposed roster, but a shift swap between two people goes through approval. That is where human judgement is not an inefficiency, it is the job.

Meet people where they already are

The most useful part of Mishmar is also the least impressive on paper: a bidirectional Google Sheets sync.

People in that organisation had worked in a spreadsheet for years. We could have announced that there was a system now and the spreadsheet was over, and that would have failed. Instead the spreadsheet stayed where it was, and the system syncs to it and takes changes back from it. There is Excel import and export through exceljs as well, with Hebrew preserved, which is exactly where it tends to break.

The system holds the truth. The spreadsheet stays as an interface for whoever prefers it. That is not a technical compromise, it is the reason the system got adopted at all.

Scheduled work that fails quietly

This is the failure that shows up in every system with scheduled jobs, and it is entirely predictable. A job that runs at three in the morning and stops running does not tell anybody. Two weeks later somebody asks why the report looks stale.

On Mishmar the jobs are spread across two schedulers, Vercel cron and GitHub Actions. That looks redundant until one of them changes behaviour or goes down, at which point it is not. The more important thing, though, is simply having one place that says when each job last ran and what it did.

Reporting here does not mean a dashboard. It means a row in a table with the job name, when it finished, and how many records it touched. Whoever maintains the system should be able to see in ten seconds that something stopped running, and without that they will hear about it from a customer instead.

Where to start

Take the repeating task that the person doing it hates most, and test it on two things: does it run at a fixed time, and is its answer defined. If yes, that is the first thing to automate and probably the fastest to pay for itself. If no, what you likely need is not automation but a system that makes that work easier for a human to do.

The process underneath an automation is the precondition for it. We wrote about that in a spreadsheet holds a list, a system holds a process.

Turn the repeating work in your business into a process that runs itself