It usually arrives as a link. Someone forwards a tool, or a demo, with a short note asking whether the business should be using it.
The demo is good. They nearly always are now. And the question comes from a decent instinct, from someone trying to move before a competitor does.
It still has the order wrong. A product is what a firm chooses once it understands the work the product serves. Chosen before that, it does not fit the business. The business bends to fit it.
The failure showing up isn’t a missing tool
Sit inside a founder-led business for a week and the same shape turns up under different names. A customer asks for a quote, and three people could answer, and all three would answer differently, because how to price that job lives in one person’s head, and nobody has ever written it down. A complaint arrives and goes to whoever caught the last one. A report gets rebuilt every Monday by someone who does not know it already exists in a folder.
Those failures come from work nobody has ever drawn.
The big consultancies have started saying the same thing in more formal language: enterprise AI stalls when nobody has mapped the organisation’s own structure, the areas of work it runs and the sequences inside them.
A business is that structure whether or not anyone has drawn it. There are functions, the standing areas: finance, support, delivery. Inside each are workflows, the actual sequences of steps. Inside those are tasks, the smallest units, where the work happens.
Most businesses have never written any of it down. That absence is the real reason the conversation keeps landing on which product to buy. The product question is answerable in an afternoon. The other one needs a whiteboard and someone willing to be wrong in front of colleagues, and nobody schedules that.
Where the mapping has to happen
A function is too big to act on. “Should support use AI?” has no answer, because support is a dozen sequences with a dozen different answers, and treating them as one is what produces the platform purchase that half the team quietly stops opening.
A workflow is where a product lands, and where buying first does the most damage. The tool arrives with opinions about how the steps should go. Those opinions win, because the vendor already built them into the product, and the vendor’s default rearranges a sequence that existed for good local reasons.
The task is where a product does useful work. A model does not automate support. It drafts one reply. It reads one form and pulls four fields out of it. It marks the third message in a thread as the one that needs a person.
That happens to be the level the labour research works at too. The study most exposure estimates trace back to measures exposure task by task rather than job by job, and finds the strongest exposure in non-routine, well-paid work most people assumed was safe. A buyer decides at the same level a researcher measures: the task.
Why the word “governed” is not decoration
Once a firm hands a task to something that acts on its own rather than waiting to be told, the mapping question turns into a plainer one: who can see what it did, and who can stop it.
That is the difference between a capability and something running unattended in the corner. Industry analysts expect roughly half of ERP vendors to ship oversight capability during 2026: audit trails, policy checks, a visible stop switch. The industry is arriving, in its own vocabulary, at what a founder learns the hard way the first time something goes out wrong and nobody can say who approved it.
Skipping it has a number attached now. Big consulting expects organisations to cancel more than four in ten agentic AI projects by the end of 2027, and names three reasons: cost, unclear business value, and inadequate risk controls. The reports do not name the missing map as the cause. From inside a founder-led business, it is the same failure counted differently: a firm automated a task before anyone drew the workflow around it, and the bill arrived as a cancelled project instead of a quiet disappointment.
What comes before choosing an AI product?
A firm starts with the function, finds the workflow inside it, and gets down to the task. For that one task, it decides whether the work wants a machine or a person, and it names who is accountable for the call and for looking at it again when the tools move.
It is less impressive than it sounds. What comes out the other side is usually narrower than whoever asked first had in mind: one sequence made to work properly, rather than a platform bought to cover all of them at once.
Job titles and products change more often than the tasks inside a workflow. A support reply still needs drafting, whether a person writes it today or a model writes it next year. The firm still has to place that task inside a sequence someone has drawn, and name the person who checks it.
The question that matters
So, before the next link arrives with a note attached: which workflow is the tool going to run inside, and has anyone drawn that workflow, or will the product draw it instead?
If someone has drawn it, the purchase is a small decision and probably a good one. If nobody has, the product is a bet on a shape nobody has examined. It will reshape the business either way. The only open question is whether the firm chooses that shape or inherits it.