AI readiness is mostly an operations problem

Almost every AI readiness workshop opens with a data audit. How clean is the CRM. How many source systems. What is the state of the warehouse. All good questions, and all wrong as the first question.

The reason is that data problems are solvable with money and time. Operations problems are only solvable with authority, and authority is the scarcest resource in most mid-market businesses. A client with a perfect warehouse and no process owner will never ship a workflow. A client with a messy warehouse and a decisive COO will ship four workflows in a quarter.

This is the pattern we have seen across dozens of engagements, and it is why our own intake calls now start with the operations questions, not the data ones.

Every workflow you want to automate needs a named owner who can approve changes without a committee. If three departments have to agree on how a lead is qualified, no AI system will ever ship, because the underlying disagreement will surface the moment the agent makes a decision. What was previously a slow, invisible political negotiation becomes a fast, visible technical blocker.

Fix the ownership question before you write a single prompt. It sounds like a governance concern and it is really a delivery concern. A workflow with an owner ships. A workflow without one becomes a proof of concept that never leaves staging, no matter how well it performs on the evals.

The owner does not need a technical background. They need three things: authority to change the process without escalation, willingness to defend that change in front of peers, and enough time in their week to sit with the build team through discovery. If any of those three are missing, pick a different workflow. It is cheaper than trying to force one through.

The best process owners we have worked with treat the automation as their project, not the AI team's project. They write the intake brief, they present the results, they take the questions when something breaks. That ownership is what separates a workflow that survives its first bad week from one that gets quietly shelved.

AI systems cannot infer what your operators know implicitly. If the current process depends on Sarah remembering to copy accounting on a particular kind of invoice, no model will guess that rule from context. The rule needs to become explicit before it can become code.

The good news is that you do not need a perfect process document. You need a two-page map of every input, every decision, every handoff, and every failure mode. Two pages, one workflow, one afternoon with the operator who actually does the work. If it takes longer than an afternoon, you are documenting too many workflows at once, not too few details.

This is the first artefact we produce with every client and it is often the thing that unlocks the automation, before any code is written. Half of the time, the client discovers that two departments were doing the same handoff in different ways, and the fix is a policy change rather than an AI system. That counts as a win, even if it does not generate an invoice for us.

The map is also the specification for the eval harness. Every decision point in the map becomes a test case. Every failure mode becomes a red-team script. Skipping the map means writing the evals from scratch later, which always takes longer than doing them alongside the process work.

The operators who used to do the work manually need to be told what changes and what stays the same. Skipping the adoption conversation is why so many pilots never reach production. The technology works, the numbers look good, and the operators keep doing the task by hand because nobody gave them permission or training to stop.

Budget one week of change management per shipped workflow, and treat it as non-negotiable. That week includes a live training session, a written companion sheet, a feedback channel where the operators can flag surprising outputs, and a review meeting at the end of week two to catch anything the training missed.

Give the operators the language they need to explain the system to peers. If they cannot describe it in one sentence, adoption will stall, because they will hedge every time a colleague asks whether they should use it. A good one-sentence description names what the system does, who it does it for, and one thing it explicitly does not do. That third part matters most, because it defines the boundary of safe use.

The other adoption trick we push hard: never launch on a Friday. Every voice, chat, or workflow deployment we have seen fail catastrophically had a Friday launch date, because the operators discovered the problems over the weekend when nobody could respond. Tuesday launches, morning UK time, have a materially better track record.

A COO or head of operations in the room, not just a CTO. Technology leaders are essential downstream, but the strategic call about which workflow to automate is an operations decision, and it needs an operations voice in the discovery.

A specific workflow that is expensive when it breaks, with an owner willing to defend the change. Vague ambitions like use AI across the business are a red flag; specific, painful, well-owned workflows are green flags.

A willingness to start with one build, not a platform vision. Clients who insist on scoping an entire AI transformation before shipping their first workflow almost always stall out. Clients who ship one workflow first and let the platform accrete around it almost always compound.

A budget that includes ongoing costs, not just build costs. If the intake conversation has no line for maintenance, monitoring, and change management, the launched system will die of neglect. See our note on calculating automation ROI without fantasy math for the specific numbers we recommend.

If those four are present, the technical readiness questions almost always take care of themselves. If any of them are missing, no amount of data readiness will save the project, and the right answer is to spend a quarter fixing the operations before spending a dollar on the system.

Fifteen minutes on the business. Where is the pressure this quarter, and which workflow, if it ran twice as fast or twice as well, would move the needle on that pressure.

Twenty minutes on the workflow itself. Walk through a live example, screen shared, with the operator who does it. Note every tool switch, every decision, every place where they say usually or it depends.

Fifteen minutes on the data. Not a warehouse audit, just a check on whether the systems that hold the data are accessible, current, and correct. Two out of three is usually enough to start.

Twenty minutes on ownership. Who signs off on process changes today, who will sign off on the automated version, and what happens when the two disagree.

Twenty minutes on the plan. Scope the smallest possible first build that could ship in six to ten weeks, name the eval criteria, and put a preliminary payback range on the wall.

If we cannot finish that agenda in ninety minutes, the workflow is not scoped tightly enough for a first build, and the honest recommendation is to narrow the scope before we quote anything.