Most AI strategies fail because they start with technology. That was the claim in the last piece — and I still believe it.
What I understated was how the failure shows up day to day.
It doesn’t usually look like a model that can’t write a sentence. It looks like a pilot bolted onto a process nobody can explain without three side conversations and a spreadsheet that lives on someone’s laptop. The demo works. Production doesn’t. Leadership asks for another strategy. The operators keep doing the work the hard way.
Stop building AI strategies. Start fixing broken workflows.
That isn’t a slogan against ambition. It’s the operator’s filter for whether an AI project has a chance. If you can’t whiteboard the process — who does what, when, and why — you can’t automate it with agents. You can only decorate it.
Strategy theater vs. the work that actually moves
Here’s what I’ve seen in rooms where “AI strategy” is on the agenda.
Someone presents a slide titled Use Case Portfolio. Fifty ideas. Three “quick wins.” A governance committee. A vendor shortlist. Budget language that sounds serious. Nobody has drawn the approval path that already takes four people and dies when one of them is on PTO.
The strategy feels productive because it produces documents. The workflow stays broken because documents don’t move tickets.
I’m not against plans. Plans are useful when they point at a specific process you can touch. What fails is strategy theater — the performance of readiness that never intersects the handoff, the exception queue, or the shadow system holding the real truth.
The last piece said: start with the workflow, not the model. This piece is the how. Map first. Model second. Agent third — and only after the map survives contact with the people who do the job.
One more distinction matters. A strategy can be correct at altitude and still useless on the floor. “We will use AI to reduce cycle time in finance operations” can be true and still leave every invoice stuck in the same fog. Operators don’t need another altitude statement. They need a drawing of the path work actually takes — and permission to fix the path before anyone brands it an AI program.
What “whiteboard the workflow” actually means
When I say whiteboard, I don’t mean the org-chart version.
The org-chart version is clean. Boxes. Swim lanes. “Request → Approve → Execute → Close.” It looks like something you could feed an agent on day one.
The real version has footnotes.
Someone forwards the request to a person who isn’t on the chart because that person “just knows how we do exceptions.” Someone else keeps a personal spreadsheet of open items because the ticket system loses status. A third person re-keys the same data into two systems because the integration was “next quarter” for years. The official SOP says three steps. The tribal version has seven — and only two people can teach it without notes.
Whiteboard the workflow means drawing the version people actually run, including:
- Who waits on whom, and what they wait for
- Where work parks when someone is out
- Which tools are official vs. which ones are load-bearing by accident
- What counts as an exception, and who invents the rule on the fly
- What “done” means to ops vs. what “done” means to finance or compliance
If that drawing makes people argue, good. Argument is signal. Silence usually means you’re still looking at the org-chart version.
If the team can’t agree on the map in a room with a marker and a blank surface, an agent won’t resolve the disagreement for you. It will encode whoever shouted loudest in the requirements meeting.
A concrete scene: approval hell with a polite UI
Picture a mid-market ops team. Vendor invoice over a threshold needs approval. On paper: requestor submits, manager approves, finance posts, AP pays.
In practice:
The requestor pastes a PDF into email because the portal rejects their file type. The manager is in meetings, so they Slack a “looks fine” that never hits the system of record. Finance won’t post without a cost center that only lives in a shared drive folder named after last year’s reorg. AP has a shadow tracker because the ERP status field lies. When the usual manager is out, the backup doesn’t have access — so the requestor finds a VP who will reply-all to unblock it, and nobody updates the ticket.
Cycle time is measured in days. Blame is measured in threads. Everyone agrees “AI could help with approvals.”
So the company buys an “AI assistant for finance workflows.” It summarizes the email thread beautifully. It does not know the cost-center folder exists. It cannot see the Slack nudge. It cannot grant the backup manager access. It drafts a polite status update while the invoice still sits.
That’s not a model failure. That’s automating fog.
Notice what the assistant could do well: summarize, draft, remind. Notice what the broken workflow needed: access rights, a single system of record, a named backup path, and a cost-center rule that doesn’t live in a folder. Those are operator fixes. Buy the assistant after those exist and it compounds. Buy it before and it narrates the mess in nicer language.
The whiteboard session for this team wouldn’t start with vendors. It would start with: show me the last ten invoices that took more than three days. Walk me through each one. Mark every handoff, every exception, every tool that isn’t supposed to be in the path. Then decide what to fix with process, what to fix with access, and only then what an agent should own.
I’ve watched versions of this scene across industries — fulfillment exceptions, property-ops work orders, fleet maintenance approvals, customer escalations. The tools change. The fog doesn’t. Somewhere in each of them is a person who became the integration layer because the systems never did.
That person is not an AI use case until you map what they actually do when things go sideways.
How to map this week (without a transformation program)
You don’t need a six-month BPM initiative. You need operator honesty and a few hours.
1. Pick one painful workflow you already understand poorly. Not the sexiest AI idea. The one people complain about in standup. Approvals, exception handling, customer escalations, inventory adjustments, onboarding handoffs — anything with waiting and rework.
2. Pull five to ten recent instances. Real tickets, real emails, real dates. Abstract process maps lie. Instance walkthroughs don’t.
3. Put the people who touch it in a room (or a call) with a blank board. Not their managers only. The people who re-key, chase, and invent workarounds. Ask them to draw the last messy case, not the ideal case.
4. Label every arrow. What moves? A file? A decision? A status change? A verbal “you’re good”? If the arrow is vibes, write “vibes” on the board. That honesty is the map.
5. Mark the shadow systems. Spreadsheets, inboxes, chat threads, personal notes. Circle anything that would break if one person left. Those circles are where “AI strategy” usually pretends the official system is the real one.
6. Name the exception paths out loud. Happy path is maybe 60% of the pain. Exceptions are where cycle time and risk hide. If you can’t name them, you can’t automate them safely.
7. Stop when the board is ugly and agreed. Ugly + agreed beats pretty + fictional. Photograph it. That’s your artifact. Not a 40-page BRD.
Concession where it’s earned: some regulated processes need formal documentation after this. Fine. Start with the ugly map anyway. Formal docs written before the whiteboard session tend to document hope.
Which workflows to pick first
Not every broken process is a good first candidate for agent work.
Prioritize the intersection of three things:
Pain. People already feel it. Time, errors, rework, customer delay. If nobody is frustrated, you won’t get energy to finish the map — let alone the fix.
Understood enough to map. You don’t need perfect knowledge. You need enough instances and enough operators in the room that the whiteboard converges. If the process is pure mystery owned by a vendor black box, start by getting visibility, not by buying an agent.
Owned. Someone can change it. A workflow orphaned across three departments with no accountable owner will eat an AI pilot alive. Fix ownership first, or pick a different workflow.
Avoid the traps that look strategic and ship nothing:
- “AI for everything in the value chain” (too wide)
- The CEO’s pet demo that doesn’t touch daily ops (too shallow)
- The process everyone hates but nobody has authority to change (orphaned)
- The process that only exists in a vendor’s UI with no export and no API (visibility first)
The best first workflow is boring, owned, painful, and drawable. Boring is a feature. Boring means you can measure before/after without inventing a new OKR religion.
If two workflows tie on pain, pick the one with fewer systems and a clearer owner. Early wins teach the organization that mapping is how you earn the right to automate. Early losses — usually from orphaned, cross-org chaos — teach the wrong lesson: “AI doesn’t work here.” AI wasn’t the failure mode. Selection was.
What happens after the map
Once you have a map that survives the room, three moves become obvious — and they are not all “add AI.”
Simplify. Kill steps that exist only because a tool failed. Merge handoffs that create waiting. Give the backup person access before you teach an agent to escalate.
Stabilize. Make the official system match reality, or admit the spreadsheet is the system and treat it like one. Agents hate lying data. So do humans, they just cope louder.
Then agent-ify the parts that are rules-plus-judgment on a clean path. Routing. Drafting. Gathering context. Watching queues. Flagging exceptions for a human who still owns the call. That’s where agentic AI earns its keep — on a workflow you’ve already made coherent.
Order matters. Teams that skip straighten-and-stabilize and jump to agents don’t look bold. They look busy. They ship a bot that escalates into the same broken inbox, then conclude the technology wasn’t ready. The technology was ready for a different problem than the one they actually had.
In the next post in this series, I’ll go deeper on that third move: how to turn a whiteboarded workflow into an agent surface — what to automate, what to leave human, and how to avoid building a bot that just accelerates a broken handoff.
For now, the operator rule stays simple.
Map the process before you automate. If you can’t whiteboard it, you can’t agent-ify it.
The question worth sitting with
Strategy decks will keep arriving. Vendors will keep demoing. Models will keep getting better.
None of that rescues a process that only exists as tribal knowledge and a folder named after last year’s reorg.
So before the next pilot gets a name, try this: put the people who run the painful workflow in front of a blank board and ask them to draw the last ugly case end to end. Watch where they hesitate. Watch what they refuse to put in a box. Watch which spreadsheet they mention under their breath.
What shows up on that board — and what people fight about while drawing it — is the real starting line for AI in your operation. Where does your whiteboard go quiet first?