How we decide whether a workflow is actually worth solving with AI

Every client conversation about AI starts the same way now: someone in the room has seen a demo, and they want to know how fast we can build something like it for their business. That's a reasonable question, and also the wrong first question. Before we talk about models, we spend a working session figuring out whether the workflow in front of us actually needs one, because a meaningful share of the requests that arrive framed as an AI project turn out to be solved faster and more reliably with a rule, a form, or a better dashboard.

We run every candidate workflow through the same three questions before scoping any actual build. First: is the input genuinely unstructured, free text, images, a mix of formats, or is it actually structured data that someone has just been reading by hand out of habit? A lot of tasks that look like they need language understanding are really a data entry problem wearing a costume. Second: does the task require judgment that shifts case by case, or is there a small set of rules that would cover the overwhelming majority of instances? Third: what does a wrong answer cost, and how often is a wrong answer tolerable? A workflow where a mistake is cheap and easily caught is a very different build than one where a mistake reaches a customer or a regulator before anyone notices.

Only after we have real answers to those three do we start talking about which kind of system fits: a straightforward script, a rules engine, a traditional machine learning model, or something that actually needs a large language model's ability to handle open-ended text. Skipping straight to the last option because it's the most talked-about one is how a client ends up paying for a complex system that a much cheaper tool would have handled just as well.

We turned down an AI-framed project for a subscription box company earlier this year, and pointed them toward eight if-then rules and a shared spreadsheet instead. Their actual problem was flagging orders likely to churn based on delivery delays, support tickets, and pause history. Everything they described was structured data they already had in three systems, no free text involved, no judgment call that varied meaningfully case to case. A model would have added latency, cost, and a new source of unpredictable output to a problem that a weekly export and eight rules solved completely, at zero marginal cost per prediction and full transparency into why any given customer got flagged.

That project cost them a fraction of what an AI build would have, shipped in a week instead of two months, and gave their retention team a system they could audit and adjust themselves without calling anyone. We'd rather lose the more expensive engagement and keep the relationship than build something impressive that solves a smaller problem than the simpler option would have.

The workflows that are actually worth solving with a model share a specific shape: the input is messy or highly variable, no fixed rule set would realistically cover the range of cases, and there's enough historical volume to build a real evaluation set rather than guessing at quality from a handful of examples. Support ticket triage across a wide range of customer language, contract review against a flexible playbook, and content moderation at a scale no manual team could sustain are all workflows we've built for exactly this reason: the variability is the whole problem, and no simpler tool handles variability well.

Volume matters too, not because a model needs enormous amounts of data to work, but because a workflow that only happens ten times a month rarely justifies the ongoing cost of monitoring and maintaining a production AI system. We're candid with clients about this trade-off before scoping anything: below a certain frequency, the operational overhead of running a model responsibly outweighs the time it saves.

Most clients who come to us asking for an AI feature take the redirection well once we walk through the reasoning with their own data in front of them, rather than an abstract argument. We'll pull up the actual workflow, count how many cases a rule-based system would correctly handle, and show the gap that's actually left for a model to solve. Sometimes that gap is the whole workflow, and we build accordingly. Sometimes it's a small fraction of cases, and the right answer is a rules engine with a model handling only the genuine edge cases it escalates to.

The clients who push back hardest are usually the ones who've already told a board or an investor that an AI initiative is underway, and a rules-based recommendation feels like a step backward regardless of the actual engineering case for it. We still make the recommendation, because a system that's honestly described as smart automation and works reliably beats a system marketed as AI that breaks in ways nobody can explain six months in.

The case that comes up most often, and the one we spend the most time actually walking through with clients, is content generation: marketing copy, product descriptions, first-draft emails. It's borderline by our own three questions, since the input is unstructured, judgment matters moderately, and the cost of a wrong answer is usually low, since a bad first draft gets edited rather than published as is. That combination usually makes it a reasonable candidate, but the deciding factor ends up being volume and repetition rather than the three questions alone: a client publishing five product descriptions a month doesn't need a generation system, they need a good freelance writer, while a marketplace listing thousands of new products a quarter genuinely benefits from a model that can draft a serviceable first version for a human editor to tighten.

We ask a fourth, more practical question in these borderline cases: if this task disappeared entirely for a month, would anyone notice, or would the backlog just quietly grow? A task where the backlog grows unnoticed is rarely worth automating urgently, regardless of how well an AI system could theoretically handle it, because the actual business cost of the status quo is lower than the sales pitch for automating it implies. We'd rather have that blunt conversation upfront than build a system to solve a problem that, honestly, wasn't costing the client very much to begin with.