AI Investment and Readiness for Leaders

Learn in your browser · Chapter 01 of 08

Every AI investment decision that goes well starts in the same place: a clearly written problem, not a tool. Every failure examined in this workbook started somewhere else.

Before you look at a single AI product, write three things down: the business problem in one sentence, the people affected by it, and the outcome you actually want if the problem is solved. This sounds obvious. In practice most AI decisions run the other way: someone sees a demonstration, a competitor's announcement or a vendor's pitch, and the tool comes first. The problem gets written afterwards, shaped to fit the tool already chosen.

A tool chosen before the problem is defined tends to solve the vendor's problem, selling the tool, rather than yours. It also makes every later step in this workbook harder: you cannot honestly compare alternatives against nothing, build a business case for an undefined benefit, or set a pilot's success measure if nobody wrote down what success means.

Reporting afterwards pointed to a cause this workbook returns to in later chapters: the target kept moving, the people who would actually use the system were not central to defining what it needed to do, and fitting the messy, real records already in use was treated as a detail to solve later rather than part of the problem itself.

1. Name the business problem in one sentence, without naming any tool or technology.
2. List who is affected, customers, staff or both, and how.
3. State the outcome you want, in terms you could measure within six months.
4. Ask a colleague who was not involved to read your sentence back in their own words. If their version does not match what you meant, rewrite it before moving on.

Harlow Fenwick Group is an invented, family-run manufacturer of specialist industrial fasteners, used as a running example throughout this workbook; all its names, numbers and dates are invented for illustration. Its twelve-person technical sales team answers customer questions about non-standard parts and prepares quotes. The board's first instinct was 'we need an AI chatbot for the website'. Working through this chapter's steps instead produced: problem, a technical query waits an average of two working days for a reply, during which some customers buy from a faster competitor; affected, the technical sales team, who carry a growing backlog, and prospective customers, who leave; outcome, a technical query gets a first, accurate reply within four working hours, without increasing the team's headcount.

Learn in your browser · Chapter 02 of 08

AI is one option among at least four. Compare it against the others honestly, using the same criteria, before you commit to it.

Once you have a real problem statement, you have at least four live options, not one: change the process, such as retraining staff or redesigning a workflow; buy or build conventional, non-AI software, such as a template, a form or a rules-based system; do nothing differently and accept the current cost; or introduce an AI system. Score all four the same way, rather than treating AI as the default and the others as things to mention in passing.

Scroll sideways to see every column.

The lesson is not that AI ordering can never work. It is that the comparison in this chapter needs to be run honestly, task by task: a well-trained human, or a simpler rules-based ordering flow, was still beating the AI system on the specific task of taking a fast-food order accurately, at the point the trial was pulled.

1. For each of the four options, estimate the cost to introduce it.
2. For each, estimate the time before you would see a result.
3. For each, ask how reversible it is if you are wrong.
4. For each, ask what it does to the people currently doing the work, more interesting, more repetitive, fewer of them.
5. Score every option against the same four questions. Do not skip 'doing nothing' or 'process change' just because they feel less exciting to present.

Harlow Fenwick scored its four options against its own problem statement. Process change (a simple triage step, urgent parts questions flagged first) scored well on cost and reversibility but only partly solved the delay for routine questions. Conventional software (an email template library) was cheap but could not handle the genuinely varied, technical questions that made up most of the backlog. Doing nothing kept losing an estimated share of quotes to faster competitors, by the team's own account. An AI drafting assistant, reviewed by the existing team before anything was sent, scored well on speed to a result and was judged reversible, since nothing would go to a customer unread. The board decided to trial the AI option alongside the triage change, not instead of it.

Learn in your browser · Chapter 03 of 08

A business case is not one optimistic number. It is four explicit, named assumptions: value, total cost, uncertainty and opportunity cost.

Value is what the initiative is worth if it works, stated over a period, with the assumption behind the figure named rather than left implicit. Total cost is the build or subscription cost plus the cost to run it, and, the part most often left out, the time of the people who will use, review or maintain it. Uncertainty is a range, not a single number, with a note on what would have to be true for the low end and the high end. Opportunity cost is what that same money, time and attention could otherwise have achieved, the next-best use of it, not a vague sense that the budget was available.

That finding is a business-case failure as much as a technical one: an initiative without an explicit value assumption, an honest total cost and a stated uncertainty range is very hard to measure against later, so it is easy for 'no measurable return' to go unnoticed until someone asks directly.

Scroll sideways to see every column.

Harlow Fenwick's business case, built on its own invented estimates: value, the sales team estimated roughly 15% of technical quote requests currently go to a faster-replying competitor, at an average order value of 2,400 pounds and around 40 relevant enquiries a month, putting at risk in the order of 14,400 pounds a month if unaddressed, a figure the team labelled as their own estimate, not a measured fact. Total cost, an implementation cost band plus a monthly running cost, plus roughly three hours a week of the technical team's time to review drafts. Uncertainty, the board recorded that the value estimate could be far lower if the 15% figure itself was wrong, since nobody had actually measured how many quotes were lost to speed alone versus price or stock. Opportunity cost, the same three hours a week was previously spent on proactive account calls to existing customers, a benefit the case had to weigh against the new one.

Learn in your browser · Chapter 04 of 08

Readiness is not one question. It is six: permissions, quality, privacy, security, accessibility and supplier dependence.

Permissions ask whether you actually have the right, under your own privacy notice and contracts, to use this data this way, not just physical access to it. Quality asks whether the data is complete, current and representative of who it will actually be used on. Privacy asks what personal data is involved and whether you are using no more of it than the task needs. Security asks who can reach the data and what protects it. Accessibility asks whether the people who need to review, audit or challenge an output can actually see how it was reached, not only the output itself. Supplier dependence asks what happens if the supplier changes its price, its terms, or closes, and whether you can get your own data back.

This was a quality and permissions failure before it was anything else: historical hiring data was treated as a neutral record of merit, when it was actually a record of who the company had hired in the past, in an industry it already knew was skewed. No amount of careful prompt design fixes a readiness problem sitting underneath the data itself.

1. Permissions: check your privacy notice and supplier contracts actually cover this specific use, not just data storage in general.
2. Quality: sample the data and ask whether it is complete, current and representative of the people it will be used on.
3. Privacy: list what personal data is involved, and whether less would do.
4. Security: name who can currently access the data, and how that access is controlled.
5. Accessibility: check whether a reviewer, not just an engineer, can see why the system produced a given output.
6. Supplier dependence: check the contract for what happens to your data if you leave, and how quickly you could leave if you needed to.

Harlow Fenwick ran the six-dimension check against its own customer query archive. Quality was mixed: a large share of technical queries were still handled entirely by phone and never written down, so the archive under-represented exactly the harder cases the AI assistant most needed to learn from. Permissions raised a genuine question: the company's current privacy notice did not clearly cover using historic customer correspondence this way, so legal advice was needed before proceeding, not after. Supplier dependence was flagged against one shortlisted vendor, a newly founded AI start-up with no track record in the parts industry and a contract silent on what happened to Harlow Fenwick's own data if the vendor closed.

Learn in your browser · Chapter 05 of 08

Name who decides to adopt, who reviews the output, what makes it stop, and one accountable owner. Do this before go-live, not after something goes wrong.

Four things need a name attached, not a committee: who may approve the system going live; who reviews its output, and how closely; what triggers an immediate pause rather than a note for the next meeting; and one accountable owner whose post, not just their goodwill, carries responsibility for the outcome. Oversight only counts if the reviewer has real authority, real time and real information, not a rubber stamp squeezed between other tasks.

No single named post had the authority, or was expected, to stop the algorithm once it was producing wrongful accusations at scale. Oversight existed on paper without existing in practice, and the people harmed had no visible route to a human who could actually intervene.

Scroll sideways to see every column.

Harlow Fenwick named its technical sales manager as the accountable owner, with the operations director holding budget sign-off. Draft replies are reviewed by the same team member who would previously have written them, with review time explicitly built into their working week rather than treated as extra. Three stop conditions were agreed before launch: any drafted reply containing a wrong price or lead time reaching a customer unread; the reviewer catching fewer than 90% of ten deliberately planted errors in a monthly test; or a single written complaint naming the assistant specifically.

Learn in your browser · Chapter 06 of 08

A pilot only earns its name if it is bounded: a stated success measure, a stated failure measure, a review date, and gates decided before you start, not after you like the result.

A bounded pilot has five parts, all fixed before it begins: the scope, deliberately narrow; a success measure, specific enough that two people would agree whether it was met; a failure measure, equally specific, not just the absence of the success measure; a review date, fixed on the calendar, not 'when it feels ready'; and three gates decided in advance, proceed to wider use, hold and gather more evidence, or stop.

Zillow's own algorithm had performed acceptably in calmer markets; the business scaled it into far more volatile conditions without a gate that forced a genuine pause to re-test the model's accuracy first. A stated failure measure and a hold gate, triggered automatically once forecasting error crossed a set threshold, is exactly the kind of control this chapter asks you to write down before your own pilot begins, not after.

Scroll sideways to see every column.

Learn in your browser · Chapter 07 of 08

Two questions, both best answered before you need them: what evidence is actually enough to scale beyond a pilot, and how would you roll the system back if it went wrong.

'It felt fine' is not evidence. Scaling evidence should directly answer the pilot's own success and failure measures from chapter five, over a large enough sample that a good month was not luck, and should include at least one deliberately hard test, not only routine cases. Rollback is the mirror image, planned before go-live: a working kill switch that returns you to the previous process without depending on the vendor's help, clarity on what happens to your own data if you leave, and contract terms that let you actually leave within a reasonable notice period.

Forty-five minutes is not long. The lesson generalises well beyond trading floors: any system that acts quickly and at scale needs a rollback mechanism that works at least as fast as the system can cause harm, tested before go-live, not designed after the first real incident makes the need obvious.

Scroll sideways to see every column.

Harlow Fenwick's evidence review, at the chapter five review date: 84% of drafted replies sent with no factual edit needed, against an 80% target; first reply time averaging three hours forty minutes; the monthly planted-error test caught 9 of 10 seeded mistakes, meeting the 90% threshold. The board proceeded to a wider rollout, but only after confirming, in writing with the vendor, that Harlow Fenwick's own query and reply data could be exported in full at any time, and that reverting to manual drafting needed no more than switching a setting off.

Learn in your browser · Chapter 08 of 08

Bring every earlier chapter together into two short documents: a one-page decision brief for people who were not in the room, and a scorecard that keeps forecasts and measured outcomes visibly separate.

A decision brief is not a summary of everything you did. It is a one-page document that lets someone who was not involved make, or understand, the actual decision: the problem, the option chosen and why, the headline business case numbers with their stated uncertainty, the key readiness findings, the decision rights and stop conditions, and the pilot result against its original success and failure measures. A pilot scorecard sits alongside it, and does one specific job: for every measure that mattered, it shows the number that was forecast and the number that was actually measured, in adjoining columns, never blended into a single retrospective story.

Every failure examined in this workbook, a project built before the problem was defined, a tool chosen without a fair comparison, a case built on one unstated number, data trusted without being checked, a system nobody had the standing to stop, a pilot scaled past the evidence, software deployed with no way back, shares one trait: the discipline in this final chapter was missing. A one-page brief and an honest scorecard are not paperwork. They are the difference between a project that gets a real decision and one that drifts, unmeasured, until it is cancelled by default.

Scroll sideways to see every column.

Harlow Fenwick's finished brief fit on one page: the problem and outcome from chapter one; the four-way comparison's result from chapter two; a value estimate of roughly 14,400 pounds a month at risk against a stated total cost and the named uncertainty in that figure; the two open readiness questions from chapter three, owned by the operations director; the decision rights and three stop conditions from chapter four; and the pilot result from chapter six, 84% against an 80% target, shown on the scorecard next to that same 80% forecast, not folded into a single success story. The board's recommendation, reading the brief alone, was proceed, with the two open readiness questions closed within 60 days.

If your organisation has decided to proceed and needs this built properly, tailored to how your technical sales, claims, operations or support workflow actually works rather than adapted from a generic template, Mickai builds bespoke AI workflows and code enhancements for businesses, running on Mickai's own sovereign operating system with zero data egress: your data and code never leave your own environment while the pilot itself is built and run. See what that looks like at mickai.co.uk/bespoke.