Skip to content
Chokmah

Adoption

How to choose the first workflow to automate (and three you should not)

The first workflow decides whether the whole programme survives. A four-axis scoring grid, the case for back-office over customer-facing, and the three types to leave alone.

Abstract slug-seeded geometric mark in the brand gradient standing in for the agentic-engineering byline avatar
Vikram ShettyEditorial: agentic engineering · 30 July 2026 · 7 min readComposite editorial persona. Articles are written and reviewed by the Chokmah practice team.
Glass dashboard cards illustrating the blog cover on a light background

Choose a workflow that is high-frequency, high-friction, rule-dense, and already instrumented, so you can prove a delta. MIT's NANDA research found more than half of GenAI budgets go to sales and marketing despite better returns in back-office automation. Start where the work is boring and measurable.

  • MIT NANDA, 2025: over 50% of GenAI budget went to sales and marketing despite better back-office returns.
  • A good first workflow scores high on frequency, friction, rule-density, and existing instrumentation.
  • Back-office beats customer-facing for a first project because failures are cheaper and more visible.
  • Leave alone workflows where errors are invisible, rules change faster than you can test, or judgement is tacit.
  • Only about 5% of custom enterprise AI tools reach production; the first pick is most of that odds.
Choose a workflow that is high-frequency, high-friction, rule-dense, and already instrumented, so you can prove a delta. MIT's NANDA research found more than half of GenAI budgets go to visible sales and marketing functions despite better returns in back-office automation. Start where the work is boring, measurable, and nobody is watching.

Key takeaways

  • MIT NANDA, 2025: over 50% of GenAI budget went to sales and marketing despite better back-office returns.
  • A good first candidate scores high on frequency, friction, rule-density and existing instrumentation.
  • Only about 5% of custom enterprise AI tools reach production: the first pick carries most of that risk.
  • Three workflow types should be refused outright, and naming them is part of the job.

What makes a workflow a good first candidate?

The first workflow is not a technology decision. It is a risk decision. You are choosing where to spend your one shot at a credible result before anyone believes you, and the temptation is always to pick the workflow that matters most. Resist it. Pick the one where you can prove a change.

Four properties matter, and all four have to be present:

  • High-frequency. The workflow runs many times a week, so a small per-instance improvement compounds into a number the sponsor can see, and so you accumulate enough instances to measure inside a quarter.
  • High-friction. People spend real effort on mechanical steps: rekeying, reconciling, reformatting, chasing. Friction is the fuel; a smooth workflow has nothing to give back.
  • Rule-dense. The decisions follow rules that can be stated, even if they are currently in someone's head. Rule-density is what makes the work automatable at all.
  • Already instrumented. Timestamps, counts and outcomes already exist in a system. If the workflow is invisible to measurement today, your first task is measurement, not automation.

MIT's NANDA study found that organisations systematically pointed spend at the wrong end of this: more than half of GenAI budget went to sales and marketing functions, despite the study observing better returns in back-office automation (MIT NANDA, July 2025). The visible functions attracted the money. The measurable ones would have earned it.

The four-axis scoring grid

Score each candidate workflow 1–5 on the four axes and multiply nothing: read them together. A workflow that scores 5 on frequency and 1 on instrumentation is not a 3; it is a workflow you cannot yet prove anything about.

| Axis | Score 1 | Score 5 |
|---|---|---|
| Frequency | A few times a month | Dozens of times a day |
| Friction | Smooth, low manual effort | Heavy rekeying, reconciling, chasing |
| Rule-density | Judgement-heavy, few statable rules | Mostly statable rules with clear exceptions |
| Instrumentation | No timestamps, no counts | Cycle time and outcomes already logged |

The workflow you want scores 4 or 5 on all four. That workflow is almost never the one the leadership team names first, because the ones they name are strategic, visible and contested, which is to say expensive to get wrong and hard to measure. The scoring grid exists to override the instinct toward importance. This is the same grid we run inside an adoption diagnostic; the difference is only that we shadow the workflow to score the axes honestly rather than scoring them from a meeting room.

Why back-office beats customer-facing for a first project

A back-office workflow has three properties a customer-facing one does not: its failures are cheap, its failures are visible internally, and it can be rolled back without anyone outside the building noticing.

Cheap failure matters because your first automation will fail in ways you did not predict. That is not pessimism; it is the base rate. Only about 5% of custom enterprise AI tools reach production according to MIT's data (AIGL analysis, 2025). You want the 95% of near-misses to happen where the cost of a wrong output is a corrected invoice, not a damaged customer relationship.

Visible failure matters because a back-office error surfaces in a queue you control: a reconciliation that does not balance, a ticket that bounces. You see it, you fix it, you learn. A customer-facing error surfaces in someone else's inbox, on someone else's timeline, and you learn about it late.

Rollback matters because a first project should be reversible by design. Back-office automation usually can be switched off and the manual process resumed the same afternoon. Customer-facing automation, once customers have adapted to it, cannot.

None of this says never automate customer-facing work. It says not first. The first project is where you build the muscle (the baseline, the evaluation harness, the ownership model), and you build it somewhere failure is survivable.

Three workflow types to leave alone

A vendor that cannot tell you what not to automate is selling you the thing that fails 95% of the time. Three types belong on the refusal list, and we say so in full in the workflows you should not automate.

Invisible-error workflows. If a wrong output is expensive and does not announce itself (a mispriced contract clause, a misclassified transaction that only surfaces at audit) automation removes the human who would have caught it and adds nothing that will. The error rate does not go to zero; it goes underground.

Fast-changing-rule workflows. If the rules change faster than you can re-test the system against them, your evaluation harness is always out of date, and an out-of-date harness is worse than none because it certifies confidence you do not have. Regulatory-edge workflows and pricing workflows in volatile markets often fail this test.

Tacit-judgement workflows. If the process is undocumented judgement living in a few experienced heads, the honest first step is to document it, and documenting it well often removes most of the pain without any automation at all. Automating tacit judgement you have not made explicit is automating a guess.

How to instrument before you automate

Instrument for two weeks before a tool touches the workflow. You are capturing three numbers (cycle time per instance, rework rate, escalation rate) from systems that already hold them, not from self-report.

Self-report is the trap. People estimate their own productivity badly and in a consistent direction. METR's randomised controlled trial found experienced developers were measured as 19% slower using early-2025 AI tools on real tasks in mature codebases, while estimating afterwards that the tools had made them about 20% faster (METR, July 2025). METR has since noted the result is historical and does not necessarily reflect current tools (METR, February 2026); the tooling improved, the self-report gap is a property of people, and it is why you measure the workflow rather than ask about it. The full distinction between counting activity and counting change is workflow absorption.

What a two-week diagnostic produces

Done properly, workflow selection is not a workshop output. It is the product of shadowing real work, and it produces a decision, not a strategy deck: this workflow first, these two later, these three not at all, and the reasoning for each.

What this means for a GCC transformation owner

You will be pushed toward the visible workflow: the one the business unit head is excited about, the one that demos well. Choosing it is how programmes join the 40%-plus of agentic projects Gartner expects to be cancelled by the end of 2027, on the named cause of unclear business value (Gartner, 25 June 2025).

The defensible move is smaller and less exciting: pick the boring, frequent, measurable back-office workflow, baseline it, ship it, and put a proven delta in front of the CFO before you go near the workflow everyone actually cares about. The first result buys you the right to attempt the second.

Sources

  1. MIT NANDA, The GenAI Divide: State of AI in Business 2025, July 2025. https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
  2. AIGL, State of AI in Business 2025: figure breakdown, 2025. https://www.aigl.blog/state-of-ai-in-business-2025/
  3. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 July 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
  4. METR, We are Changing our Developer Productivity Experiment Design, 24 February 2026. https://metr.org/blog/2026-02-24-uplift-update/
  5. Gartner, Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, 25 June 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

Related reading: which workflows you should not automate · what workflow absorption means · scope a workflow sprint

Frequently asked questions

A high-friction workflow is one where people spend disproportionate effort on mechanical steps: rekeying data between systems, reconciling formats, chasing approvals, correcting predictable errors. Friction is not the same as importance. A workflow can be strategically trivial and still be an excellent first automation target precisely because the friction is dense, repetitive and measurable.

Usually no. Customer-facing failures are expensive, visible to people outside your control, and hard to roll back. MIT found more than half of GenAI budget went to sales and marketing despite better returns in the back office. A first project should fail cheaply if it fails, and back-office workflows meet that condition.

One. A single instrumented workflow with a named owner and a pre-baseline produces a defensible result. Three parallel pilots produce three half-measured efforts and no clear attribution when the quarter ends. Sequence them. The first workflow also teaches you your own delivery capacity, which you cannot estimate before you have shipped once.

Measure cycle time per instance, rework rate, and escalation rate for two weeks before any tool touches the process. Capture the numbers from systems that already exist rather than asking people to self-report. The pre-baseline is what lets you distinguish a real improvement from a remembered one later, and remembered improvements are reliably generous.

Then documenting it is the first deliverable, and it is valuable on its own. An undocumented workflow cannot be automated safely because you cannot see the exceptions, and exceptions are where automation breaks. If the process exists only as tacit knowledge in a few heads, that is a signal to shadow and map it first, not to automate it fast.

Ready to install the workflow?

Book a free AI Reality Check and build one real thing from your own work, live.