Every technical leader I talk to has the same list in their head. A dozen tasks that feel like obvious AI candidates: drafting client reports, triaging support tickets, summarizing literature, writing code review comments, generating first-pass proposals. The list is long enough that picking feels impossible, so nothing gets picked. Three more months pass. The licenses renew.
I’ve watched this stall out the same way at enough science and engineering firms to stop believing it’s an ideas problem. It’s a ranking problem. The list isn’t short on candidates. It’s short on a method for telling which one to ship first and which one will quietly wreck the initiative if you touch it before you’re ready.
The two questions that actually matter
Forget “how impressive would this be.” Ask two things about each candidate task instead.
How often does it happen? A task you do once a quarter isn’t worth building a pipeline around, no matter how painful it is. The setup cost never gets paid back. A task you do every week is where automation compounds. You’re not saving someone twenty minutes once. You’re saving it fifty times a year.
Can you check the output cheaply? This is the one people skip, and it’s the one that decides whether the project survives contact with reality. Some AI output is easy to verify: does this number match the source document, did this code pass the test suite, is this summary missing a section that’s in the original. Some output is nearly impossible to verify without redoing the work: did this model make the right strategic call, did it correctly judge which client concern matters most, is this legal interpretation actually sound. If checking the answer takes as long as doing the task yourself, you haven’t automated anything. You’ve added a review step to a task that used to just get done.
Frequency tells you if a workflow is worth building. Verifiability tells you if you can build it safely. You need both.
The 2x2
Plot every candidate task on two axes: how often it happens, and how easily you can verify the output.
High frequency, high verifiability: ship first. This is the quadrant that pays off fast and fails safely. Example: a firm that receives structured lab reports every week and needs the key values pulled into a tracking spreadsheet. The model extracts numbers, a script checks them against expected ranges and flags anything odd, a human glances at the flagged rows. If the model gets a value wrong, the range check catches it before it goes anywhere. Low blast radius, fast feedback loop, immediate weekly payoff.
High frequency, low verifiability: build carefully, with a hard human gate. Example: drafting first-pass client status emails from project notes. It happens constantly, so the upside is real, but “does this email say the right thing to this client” isn’t something a script can check. This is fine to build, but only with a mandatory human read-through before anything sends, and clear ownership of who’s accountable when the tone or substance is off.
Low frequency, high verifiability: fine to automate eventually, not urgent. Example: generating a standard compliance checklist for a new project kickoff. Easy to check against a template, but it happens four times a year. Building a pipeline here is a nice-to-have, not a priority. Do it once you’ve proven the model on something that happens weekly.
Low frequency, low verifiability: leave it alone. Example: drafting the strategic recommendation section of a major proposal, the part where you’re arguing for a specific technical approach over three alternatives based on judgment calls nobody’s written down. It’s rare, the stakes are high if it’s wrong, and there’s no cheap way to check whether the reasoning holds. This is exactly the task that looks most impressive to automate and does the most damage when it’s shipped too early. I’ve seen firms burn their first AI initiative here, because the one time it mattered most, nobody could tell the output was wrong until a client did.
The pattern underneath
Notice what’s not on the list of criteria: how sophisticated the model is, how good the demo looked, how much the vendor’s case study impressed you. None of that predicts whether a workflow survives its first month in production. What predicts it is whether a wrong answer gets caught before it costs you something, and whether you’re catching it often enough for the automation to be worth building at all.
Start where AI is checkable and the downside is bounded. Not where it looks the most impressive.
This is what a diligence sprint produces
This ranking exercise, done properly, is the actual output of the AI Workflow Diligence Sprint I run for clients. Ten business days, one engagement: I sit with your team, map the real candidate workflows against frequency and verifiability, rank them by risk against value, and hand you a scoped, ship-ready pilot for the one that should go first, along with a clear list of what to leave alone for now.
If your team has the licenses, has the list of a dozen ideas, and can’t get past the ranking problem, that’s exactly the gap this closes. Book a scoping call and I’ll help you figure out which task on your list is actually the right one to ship first.