What the Workflow AI Readiness Sprint actually produces

What a short diagnostic should achieve

Businesses are frequently offered AI assessments that begin by asking which tools they use, how confident employees feel about AI and whether management has an adoption strategy. Those questions may have their place, but I am more interested in whether the business can identify a piece of work that needs improving and explain why it currently performs as it does. A manufacturer may already have Microsoft 365, an ERP system and a collection of spreadsheets, yet still struggle to understand where a customer order is delayed or why a quality investigation requires so much manual effort. The existence of the technology tells us relatively little about the work.

The Workflow AI Readiness Sprint is a proposed short diagnostic engagement built around that distinction. The name describes an intended service rather than a claim that a fixed, fully validated package is already in operation. Its purpose would be to investigate one meaningful workflow, identify the conditions affecting its performance and determine whether there is a credible opportunity for improvement. Sometimes AI may be part of the answer. In other cases, the most useful intervention may be a simpler change to information management, responsibility or the sequence in which activities are carried out.

Choosing a sensible boundary

The first task is to agree which workflow is worth examining and why. The scope needs to be specific enough to investigate properly. ‘Improve production’ is too broad for a short engagement, while ‘automate this spreadsheet’ may already assume the answer. A better starting point might be the preparation of quotations for repeat customers, the handling of a supplier non-conformance or the movement of a confirmed order into production planning. These examples have recognisable starting points, outputs and people who can describe the work.

The business would also need to identify what it wants to improve. That might be elapsed time, repeated data entry, rework, missing information, avoidable interruptions or difficulty locating evidence. It is tempting to treat every inconvenience as equally important, but a short diagnostic is most useful when it focuses on a problem that matters operationally. I am looking for a small number of recent cases and the opportunity to speak with people who carry out the activities, including those who receive the work after a handover.

This is not intended to become a lengthy exercise in documenting every procedure. The aim is to establish enough of the actual workflow to explain where difficulties arise and what evidence would be needed to justify a change. The formal process may provide a starting point, but the more revealing account often comes from tracing a real case through the business and asking what happened when the normal assumptions did not hold.

Understanding what people actually do

A useful output would be a concise description of the workflow as it operates in practice. That includes the trigger, the intended result, the main activities, the information used and the points where work passes between people or systems. Waiting, repeated entry, informal checks and exceptions deserve particular attention, because these are often the places where the apparent process differs from the real one. If a job sits in a queue for two days before somebody spends ten minutes completing it, making the ten-minute task faster may have little effect on overall performance.

I am also interested in why local workarounds have developed. A spreadsheet maintained by one employee might look like an obvious candidate for automation, but it may exist because the main system cannot provide a view the employee needs. A manual approval might seem unnecessary until we discover that it is the only point at which conflicting customer requirements are reconciled. The diagnostic should distinguish arrangements that create avoidable effort from those that compensate for genuine weaknesses elsewhere.

Where possible, the description should be supported by a modest amount of evidence. This might include examples of completed cases, approximate waiting times, repeated corrections or the number of handovers. It would be misleading to claim a precise baseline from a handful of conversations, but a small sample can still identify what is worth measuring more carefully. Any conclusions should be explicit about where the evidence is strong and where further observation would be required.

Examining information and decisions

A second output would concern the information on which the workflow depends. In many manufacturing SMEs, documents remain on network drives while employees use Microsoft 365 for email and everyday applications. Other information may sit in an ERP, CRM or quality system, with spreadsheets used to bridge gaps between them. Before proposing Copilot or another AI tool, we need to establish what information is accessible, which source is authoritative and whether employees can rely on the records they find.

This may identify practical improvements that have nothing to do with language models. A controlled document library in SharePoint might help employees find the current procedure. A structured list might replace an inconsistent spreadsheet. A simple integration might remove the need to copy the same information between systems. Equally, some information may properly remain in specialist systems, and the diagnostic should not assume that everything belongs in Microsoft 365 merely because Copilot can work with SharePoint content.

Alongside the information, the diagnostic needs to identify where employees exercise judgement. Which activities follow clear rules, and which require interpretation of technical, commercial or operational circumstances? Who has authority to make a consequential decision? What evidence do they need, and what happens when it is missing? This distinction is important because a workflow may contain routine administrative work that can be automated, evidence-gathering work that AI could assist with, and decisions that should remain under explicit human control.

A reasoned view of the opportunities

The diagnostic should produce a small set of candidate improvements, each connected to an observed problem. These might range from removing unnecessary activity or clarifying responsibility through to improving information access, introducing conventional automation or testing a carefully bounded AI-assisted task. They should not all be labelled AI opportunities. If a simpler intervention is likely to address the problem more reliably, that should be made clear.

For each candidate, the business needs to understand what would change, what information or system access would be required, what risks or dependencies exist and how success could be judged. A proposed AI assistant that searches historical quality records, for example, is only credible if those records are accessible and sufficiently reliable. A proposed automation that transfers order details between systems is only credible if the rules are stable and the exceptions can be handled. The point is to replace enthusiasm with a reasoned basis for deciding what is worth testing.

A long prioritised list based on speculative savings would give a misleading impression of certainty. A short engagement is unlikely to justify confident claims about annual financial returns without further measurement. It can, however, distinguish promising interventions from weak ones and recommend where a limited trial would provide useful evidence. That is a more honest and practical result than assigning precise benefits to ideas that have not yet been tested.

What the business would take away

The intended outputs would therefore be a clear account of the selected workflow, the main constraints and uncertainties, an assessment of the information and judgement involved, and a reasoned set of improvement options. The most useful final element would be a recommendation for the next small investigation or pilot, including what should be tested and how the result should be evaluated. The form of these outputs could be concise: a workflow view, a short evidence-led narrative and a practical decision about what to do next. Their value would come from the quality of the diagnosis rather than the volume of documentation.

It is equally important to explain what such a sprint would not provide. It would not constitute a complete redesign of the business, a comprehensive audit of every information system or a guarantee that an AI implementation will deliver a particular saving. Nor should it be presented as a substitute for detailed engineering, security or compliance work where those are required. Its purpose is to reduce uncertainty before the organisation commits to a larger intervention.

A good outcome might be the decision to proceed with a small AI trial. It might instead be the recognition that an information problem needs resolving first, or that a simple change to responsibilities would remove the delay that prompted the enquiry. All of these are useful results when supported by evidence. The business has learned something important about how its work operates and can make its next investment with a clearer understanding of the likely benefit.

That is the standard the proposed sprint needs to meet. It should leave the organisation better able to explain the problem, distinguish what is known from what is assumed and choose a proportionate next step. AI may be involved in that next step, but the diagnostic should never depend on finding a reason to use it.