When to Automate a Workflow vs. Hire for It

Almost every founder we talk to has already decided the answer before asking the question — usually "automate," because headcount feels like the more expensive line item. It isn't always. Here's how we actually think about it with clients.

The real question isn't cost, it's volatility

A process that's stable — the inputs, the edge cases, and the "correct" outcome barely change month to month — is a good automation candidate regardless of volume. A process that's still being figured out, where the rules themselves are the thing in flux, usually needs a person making judgment calls until it stabilizes. Automating a moving target just means re-automating it every six weeks.

Three signs a process is ready to automate

• You can write the decision logic down in a page or less, and it hasn't changed in the last two quarters
• Someone is doing the same categorization or data-entry task more than a few times a day
• The cost of an occasional wrong automated decision is lower than the cost of a human doing it manually every time

Three signs it isn't yet

If the team doing the work can't yet explain why they made a particular call — only that it "felt right" given the context — there's tacit knowledge in there that hasn't been made explicit. Automating too early usually means encoding last month's judgment calls as this month's hard rules, which is worse than not automating at all.

A simple way to decide

We ask clients to track one thing for two weeks: every time someone made a non-obvious call on the process in question, write down what made it non-obvious. If that log is short and repetitive, automate it. If it's long and varied, hire for it — and come back to automation once the role has run long enough to know what "normal" actually looks like.

The expensive mistake isn't automating too late. It's automating a process you don't understand yet.