When to Turn a Manual Process Into Software (and When Not To)

Most advice on this question starts with the xkcd test. You’ve probably seen the chart: how many minutes a day you spend on a task, cross-referenced against how much time you’d save automating it, over five years. It’s a genuinely useful gut check for an individual deciding whether to write a script. It is the wrong starting question for a RevOps team at $3-15M ARR deciding whether to build software around a manual process.

The comic has taken its share of criticism inside engineering circles too. A piece called “Xkcd’s ’Is It Worth the Time?’ Considered Harmful,” discussed on Hacker News in 2025, argues the chart undercounts automation’s value because it ignores compounding skills and culture effects. That’s a fair critique for engineers automating their own workflows. But it still shares the comic’s core assumption: that time saved, or time lost, is the variable that decides the automation call. At the team level, it usually isn’t. The two costs that actually kill automation projects here are the cost of automating something that wasn’t ready to be automated, and the maintenance burden of a system built around a process that was still changing shape when you locked it in.

EY’s 2019 report “Get ready for robots” found that 30 to 50 percent of initial RPA implementations fail on the first attempt. That’s not a niche failure rate, it’s closer to a coin flip. EY’s report attributes the pattern largely to planning failures: targeting the wrong processes, weak business cases, insufficient testing, rather than weak RPA tooling itself. Read plainly, that’s a planning problem more than a technology problem. Automation projects fail at the planning stage, not the build stage, more often than most teams expect.

The question isn’t “how much time,” it’s “how settled is this”

Simon Wardley’s Pioneers/Settlers/Town Planners model, part of Wardley Mapping, gives a cleaner lens for this than a time-savings chart ever will. Wardley classifies work by evolutionary stage. Pioneers are exploring something genuinely novel, where nobody yet knows the right shape of the solution. Settlers take something that’s proven to work but isn’t standardized yet, and they productize it. Town Planners industrialize fully commoditized processes that everyone already understands and expects to run the same way everywhere.

Automation belongs at the Settler stage, not before. That’s the non-obvious part: it’s tempting to read “wait until it’s stable” as the whole lesson, but the sharper failure mode is teams that mistake Pioneer-stage work for Settler-stage work because it feels repeatable after a few cycles. If your lead-routing process, your quarterly QBR data pull, or your churn-risk flagging workflow is still in Pioneer territory, meaning the people running it are still discovering what “correct” even looks like, building software around it doesn’t speed up that discovery. It fossilizes whatever half-formed version of the process existed the week you shipped the build. Every subsequent discovery about how the process should actually work then becomes a change request against a system, instead of a conversation with the person doing the work. The system becomes the thing you have to convince, not the person.

The practical test for which stage you’re in isn’t “has this been done before.” It’s whether three or four different people who ran the process independently would describe its steps the same way, without checking with each other first. If they’d each describe a different version, you’re still at Pioneer stage no matter how many cycles have run.

What this looked like for one client

A Series B marketing software company came to Chalk Theory wanting to automate its lead-to-opportunity handoff: the point where SDR-qualified leads got routed to an AE and a deal record got created in the CRM. Time-savings math said build it. Three ops hours a week were going into manual routing and record cleanup, and the team had already scoped a rules engine to replace it.

Before building anything, we sat with the four SDRs doing the handoff and asked each of them, separately, to walk through their last five handoffs. All four described different qualification thresholds for what counted as “sales-ready,” and two of them were routing the same lead type to different AEs based on relationships they’d each built individually, not on a documented territory rule. The process wasn’t settled. It was four people’s personal judgment calls that happened to produce a plausible-looking CRM record at the end.

We spent roughly three weeks with the team standardizing the qualification criteria and territory logic first, no software, just documentation and a weekly review of edge cases. Once that ran unchanged for about six consecutive weeks across all four reps, we built the routing rules into the CRM. The system that shipped took about two weeks to build instead of the six originally scoped, because there was no back-and-forth discovering the “real” rules mid-build. Handoff time dropped from roughly four hours to about twenty minutes per lead, and the rework rate on misrouted leads, tracked by AE-reported “wrong fit” flags, went from around one in six leads to near zero over the following quarter.

What this looks like in practice

None of this argues against automating. It argues against automating on time-savings math alone. A process that’s genuinely settled, described the same way by three or four different people who each ran it independently, is exactly what belongs in software. A process still being negotiated person-by-person, no matter how many hours it appears to burn on a five-year xkcd chart, is not.

This is the diagnostic Chalk Theory runs before any build recommendation: not “how much time would this save,” but “would four different people describe this process the same way if we asked them separately.” When the answer is yes, that’s the kind of recurring, well-understood work Chalk Theory Labs turns into shipped tooling.