How to tell if a workflow is actually worth automating

Say a 12-person landscaping company calls us in because their owner is done writing quotes by hand at 9pm. That's the workflow he wants fixed. It's also, almost every time, not the one we'd build first.

Here's why. Quoting happens maybe fifteen times a week and it hurts because it happens at the end of a long day, not because it happens often. Meanwhile the crew dispatcher is manually texting four different guys every morning to figure out who's free, who's already on a job, and who's driving forty minutes out of their way for no reason. That happens five days a week, twice a day, and nobody's complained about it because it's just always been the job. Pain gets you to pick up the phone. It doesn't tell you what to fix first.

Frequency does more work than pain does

Say a once-a-month report eats three hours. That feels brutal in the moment, worse than almost anything else on the list. Now say a five-minute task gets done forty times a week: over a month it costs more time than that report costs in a year, and almost nobody does that math before they call us. We do it on every Listen call, out loud, on a shared screen, because owners are usually surprised by the answer.

This isn't a reason to ignore pain entirely. If something is genuinely miserable, that's real information too. It's just not the same information as "this workflow costs the most hours," and treating them as interchangeable is how businesses end up automating the wrong thing first and wondering why the ROI feels smaller than expected.

Who's actually doing this task right now

We ask who does a task right now, specifically, by name. "Whoever's free" comes up constantly, and when it does, that answer is the actual finding, worth writing down and staring at for a second. A task with no fixed owner usually has a routing problem sitting underneath the manual-work problem, and automating the manual work without touching the routing just moves the mess somewhere else faster.

Say a client tells us intake is "basically automated already" because there's a form. A few questions in, it usually turns out a handful of people check that form depending on who happens to notice the notification, and most of them stopped checking regularly months ago. The form worked fine, and nobody owned checking it.

Some decisions aren't decisions

This is the part people get wrong most often, including us early on. A step can look like judgment and not be judgment at all. Qualifying a lead against three fixed criteria is a lookup dressed up as a decision. Pricing off a rate card is the same thing wearing a different hat, even though the person doing it will swear it takes years of feel, because they've internalized the rule so completely it now feels like intuition instead of arithmetic.

If you can write the rule down in one sentence, it's automatable, full stop. If you try to write it down and it takes a paragraph with three "well, it depends" clauses, that's a real signal, and it usually means a person needs to stay in the loop on that specific step, not that the whole workflow is off the table. We've walked away from building the wrong half of a workflow because of exactly this distinction, and it's saved clients money more than once.

What a wrong answer actually costs

The last piece is the one owners skip because it's uncomfortable to think about. A draft email that gets reviewed before sending is a cheap mistake to catch. A quote that goes straight to a client with the wrong number on it is not. The more expensive a wrong answer is, the more you build a check into the workflow before anything ships automatically.

Back to the landscaping company. We ended up building the dispatch routing first, not the quoting tool the owner walked in asking for. It scored higher on frequency, the ownership gap was real and costly, the decision inside it was a genuine rule (closest available crew, correct certification, done), and a wrong answer just meant a slightly annoying drive, not a lost customer. The quoting tool got built four months later, and by then the owner had stopped dreading his evenings for a different reason entirely.

That's the shape of the test: how often does it happen, who actually owns it today, is the decision inside it really a rule, and what does it cost if it's wrong once. None of that requires a tool to answer. It just requires sitting with the workflow long enough to see it clearly, which is most of what happens on a Listen call before we ever open a laptop.

If you've got four or five candidates on your list and you're not sure which one deserves to go first, that's exactly what the Listen call sorts out, against your actual workflows instead of a hypothetical one.