Stop buying AI tools before you map the work.

Every month, somewhere in Sydney, a leadership team signs for an AI platform licence before anyone has written down what the platform is supposed to change. Six months later the licence renews, adoption sits under 10%, and the conclusion drawn is "AI isn't ready."

The model was never the problem. The sequence was.

The buying reflex

AI procurement usually starts with a demo. Demos are built to show off a model, so the conversation anchors on capability (what the tool could do) rather than on your operation (what must change). Capability is abundant. Fit is scarce.

The money involved is not small. A mid-tier AI platform for a 30-person business runs $40 to $90 a seat each month. Call it $20,000 to $35,000 a year once onboarding and the inevitable consulting top-up land. Against that, the diagnostic work that would have told you whether the tool fits costs a half-day of three people's time.

When the tool arrives, it lands on a workflow nobody has described precisely. Staff are asked to "use AI" in the gaps of their day. There is no baseline, so nobody can say whether anything improved. The renewal decision gets made on anecdotes.

There is a tell for this pattern. The licence was bought to answer a board question ("are we doing something about AI?") rather than an operations question ("which ten hours a week are we buying back, and from whom?"). Tools bought to answer board questions get measured by board metrics, which is to say: not at all.

What mapping the work means

Pick one workflow that hurts: quoting, intake, reporting, scheduling. Then write down, with the people who do it:

1. Each step, in order, including the informal ones that live in someone's head.
2. Who touches it, and where it waits between people.
3. What enters and exits each step: emails, spreadsheets, phone calls, PDFs.
4. Where the hours go, measured roughly but honestly.

The map fits on one page. The first time you draw it, two or three steps will surprise the owner of the process. Those surprises are usually where the value is.

A worked example: quoting at a trade business

Here is the shape of it at a signage manufacturer we work with. The workflow that hurt was quoting. Before mapping, the owner described it in one sentence: "the estimator reads the drawings and prices the job." The map said otherwise:

• An enquiry lands by email or phone and waits, on average, a day and a half before anyone logs it. Nobody owned the inbox.
• The estimator re-types customer details that already exist in the CRM.
• Measurements come off PDF drawings by hand, into a spreadsheet with one tab per product type.
• Half the pricing rules live in that spreadsheet. The other half live in the estimator's head.
• Won quotes are re-keyed, line by line, into the job-management system.

Rough but honest numbers: about 3.5 hours per quote, around 12 quotes a week. Call it 40 hours: a full role spent producing documents rather than winning work. None of that was visible in the one-sentence version of the process.

The surprises follow a pattern, too. Across the maps we draw, they are almost always one of three things: work sitting in a queue nobody owns, the same data entered twice in two systems, or a decision rule that exists only in one person's head. None of those shows up in a vendor demo. All of them show up on a one-page map.

The tool decision makes itself

With the work mapped, the question stops being "which AI platform?" and becomes "which step do we change first?" Often the answer needs no new licence at all: a model you already have access to, wrapped around one step, with its output checked by the person who used to do that step manually.

"Wrapped around one step" is smaller than people expect. At the signage business it was a single skill that reads the measurement table out of a PDF drawing and drops the line items into the estimating spreadsheet. The estimator checks every line before pricing: the model proposes, the human approves. No platform, no new login, nothing changes for the customer. Per-quote time came down from about 3.5 hours to a little over two, and because checking is faster than transcribing, errors fell rather than rose.

Run that for a month against the baseline you measured. If the hours come back, scale it to the next step. If they don't, you have spent weeks, not a year, learning that.

The baseline is what makes the result defensible. "Quotes took 3.5 hours and now take just over two" survives a board meeting. "The team feels faster" does not. It is also what stops scope creep: every proposed second step has to clear the same bar the first one did.

Where to start this week

Choose the workflow whose owner complains the loudest. Book a half-day with them. Draw the map, measure the baseline, and only then open the conversation about tools.

A few rules keep the half-day honest:

• Map what actually happens, not what the procedure document says happens.
• Time the waits as well as the work: waiting is usually the bigger number.
• Write down every re-key and every export-import. Each one is a candidate.
• Keep tool names out of the room. The map first, the shopping list later.

If you want a second pair of eyes on the map, that is exactly what our discovery call is for.

FAQ

How long does mapping a workflow actually take?

We already bought a tool. Is it wasted?

Who should own the work map?

tags: adoption ● tooling ● process