Most AI projects inside a large company are rarely examined by anyone whose job is to test a financial argument. A pilot costing a few hundred thousand sits below the threshold at which finance builds its own model, so it gets approved on a slide inside a functional budget, by a steering group that would like it to work. The slide usually carries one metric, a percentage of time saved on a step, and the number is usually true. What it rarely says is which time it measured, how the pilot conditions differed from the ones the tool will live in, or who is going to turn the saved hours into money.
Take the RFP process at a company selling industrial software, which answers around 300 requests for proposal a year, each running to a few hundred questions. An RFP arrives and waits for the Monday bid review. Once the company decides to bid, a bid manager splits the questions between the people who can answer them: product for functional requirements, professional services for the implementation plan and staffing, IT security for the security questionnaire, legal for the contract exceptions, and the deal desk for pricing. The bid team drafts everything that can be drafted from past responses, the heaviest single piece of work in the process at around twenty-four hours per RFP. Product managers get to their questions in about six working days, professional services in five, and roughly a third of what comes back goes round a second time because the question reached the wrong person or the answer did not address what was asked. Pricing waits for the weekly deal desk. From arrival to submission the response takes about seventeen working days, and across five departments somewhere around forty hours of that is work.
The AI project proposed for this process is almost always the drafting, because that is where the labour is. A model drafts answers from the content library and past submissions, and the bid team's part comes down from twenty-four hours to something like six hours of reviewing and correcting. On the pilot dashboard this becomes "first draft in a day instead of a week", and by the time it reaches the steering committee it has become faster RFP responses. The response goes in on the same day it always did, the evening before the buyer's deadline. The draft now sits complete while product works through its queue, professional services scopes the implementation, and pricing waits for Thursday.
Every step in a process has two clocks running on it. One measures the work, the hours somebody spends on the document. The other runs from the moment the work arrives to the moment it leaves, and most of what it records is waiting, much of it at the handoffs between teams, where no one team owns it and nobody's timesheet shows it. AI shortens the first clock. Whether it shortens the second depends on things the model has no part in. The drafting project may well be worth doing, but the case for it is a labour case, and it was presented as a speed case. That confusion is the most common one in AI business cases, and it is only the first of several that a team weighing an investment can avoid by deciding what to measure before the pilot starts.
The first thing to measure is the process as it runs today, in elapsed time, from the timestamps in whatever system holds the work: the CRM, the proposal tool, the ticket queue that requests to product go into. Interviews are the wrong source for this. People asked how long a task takes answer with the work, and they do not count the days a request sat before they picked it up, because from where they sit it was not yet waiting for them. Split each step into work time and waiting time, and place the waiting at the handoff where it occurs, so the map shows which boundary between teams is holding the response.
The second is labour, ranked. For each step, multiply volume by work time by loaded cost, and sort. That ranking is where a labour case can come from, and it frequently points at a different step from the one a vendor has chosen to demonstrate. Work time is harder to get from systems than elapsed time, since a document can be open on a screen for an hour while its owner is in a customer call. A fortnight of work sampling, in which people log what they are doing at a few random moments each day, is cheap and considerably more accurate than asking them to estimate. In an RFP process it is worth including the product managers and solution architects, whose hours on bids are real and rarely appear in anyone's cost of sale.
The third is quality, measured in the same period as the baseline: how many drafted answers the subject matter experts change, how many commitments legal or professional services have to walk back, and the shortlist and win rates. In RFPs quality has an unusually long tail. An answer that overstates a capability or promises an implementation timeline nobody checked reads well on submission day and turns into a contract dispute or an unprofitable statement of work a year later. A pilot that takes hours out of drafting while pushing correction effort onto product and legal has moved the labour rather than removed it, and without a quality baseline nobody can tell.
The fourth is the constraint. If the company declines RFPs because the bid team does not have the hours, faster drafting releases that constraint and shows up as more bids. If the constraint is product managers who can give bids only a few hours a week, the drafts are ready sooner and wait longer. Goldratt made this argument about factory floors forty years ago, and the timestamps settle it for a bid process in a day or two.
The same map sometimes turns up a project the usual template never finds. A third of the questions sent to other departments go round twice, and each second round costs about four working days. A model that routes each question to the person who owns it, with the last approved answer and a note of what has changed in the product since, lets the expert confirm or amend instead of writing from scratch. It saves the bid team almost no labour. It takes days out of the waiting and hours out of product's time, and because the buyer's deadline does not move, those days turn into a response that gets a proper review before it goes out, or into a bid the company would otherwise have declined. Scored on bid team hours saved, it loses to the drafting project and does not get funded. Whether it belongs in a financial case depends on whether the gain can be tied to a line someone can name, and here the CRM will usually say how many RFPs were declined for lack of capacity last year and what they were worth.
Then comes the pilot, and the harder part, which is knowing what its numbers mean. A pilot is run under conditions that differ from production in predictable ways, and a team that waits until the results are in to discuss those differences will find the discussion goes the way the sponsor wants. The adjustments should be written down before the pilot starts, in the way a trading desk agrees its marking policy before it knows where the positions will close.
Most of the adjustments are mark-downs. Pilot RFPs are usually more favourable than the production mix, because someone selected them, or because the ones that drafted badly were quietly left out; in this example, standard questionnaires for the core product draft well from a maintained library, and heavily customised industry RFPs for newer products do not. Pilot users are volunteers who want the thing to work and know the results are being watched. The vendor's engineer is often fixing problems in the background, and those hours appear nowhere in the pilot's cost. Pilot bids frequently get quicker attention from product managers who know a pilot is running, which takes the queue out of the process until the tool rolls out to bids competing for their normal attention. And the review time on the dashboard may leave out the corrections made later by someone else, by product when a capability was overstated or by legal when an answer committed to something the contract could not carry.
Some adjustments go the other way. The first weeks of a pilot are slow because people check everything twice and the content library is still being cleaned up. Review time usually falls as the bid team learns where the drafts are reliable, and that decline is a legitimate mark-up if, and only if, the rate at which experts and legal correct answers held while it fell. If review time fell and corrections rose, reviewers have stopped reviewing, and the gain is a risk that has not been priced yet.
Worked through, it might look like this. The pilot ran on twenty RFPs and reported bid team time down from twenty-four hours to six, a saving of eighteen hours per response. Weighting the result to the production mix of RFPs takes off two and a half hours. Answers corrected later by product and legal take off another hour. Review time settling in the last month of the pilot, with the correction rate flat, adds back half an hour. The production estimate is fifteen hours saved per RFP, about 4,500 hours a year, which is a respectable result and a sixth less than the dashboard figure. Reporting both numbers, with the adjustments between them, is what lets a steering committee trust the second one.
The line in the case most in need of that treatment is headcount. 4,500 hours is close to three full-time bid managers, and a slide will say so. But the hours do not arrive as three people. They arrive as fifteen hours per RFP, spread across a bid team of twelve, which comes to about a day a week each. No role disappears. The hours get absorbed, into more polished responses, into the security questionnaires that were always late, into the sales support work bid managers were always behind on, and a year later the team is the same size and the savings line has quietly turned into capacity. Nothing about that is anyone's failure. Released time is simply not a cost reduction until somebody decides what happens to it.
There are three ways the decision gets made, and a business case should say which one it is relying on. The team can shrink, which requires a named owner, a number and a date, and usually a redesign that consolidates the released time into whole roles rather than fractions of many. The team can stop hiring as RFP volume grows, which means bid manager hires that do not happen, a real saving that shows up as avoided cost rather than reduced cost. Or the hours can be redeployed to something with its own value, which in a bid team usually means bidding on the RFPs it currently declines, and in that case the case should measure bids submitted and won, and stop calling the result a saving. If none of the three is written down with someone taking accountability for it, the honest entry on the cost line is zero, and the hours belong under capacity.
The same discipline applies to the costs that arrive with the tool: licences and inference, the review time that never goes away, the person who keeps the content library current as the product and the standard contract change, and the engineering attention a system in production needs for as long as it runs. These are recurring, and a case that sets a one-off pilot cost against a recurring labour saving has compared two different kinds of number.
Finally, each gain should be assigned to exactly one line: labour cost where capacity is actually released, avoided hiring, additional bids and the revenue they win, or the cost of commitments walked back after signature. The double count to watch for presents fewer bid team hours as headcount savings and then presents the same hours again as the extra bids they made possible.
What a team gets from doing this before the pilot is a decision it can actually take at the end of it. The case should state in advance the adjusted figure below which the project stops, the figure above which it scales, and what happens in between. Agreed in advance, that is an ordinary governance step. Agreed afterwards, it becomes a negotiation with a sponsor who has spent three months on the project, and the pilot almost always continues.
I am not arguing against AI in sales, in fact I am all for it - and enthusiastically so. A company that frees a day a week across its bid team and uses it to bid on work it previously turned away has made a good investment. The difficulty is that the slide which approved it signed up for a different metric from the one the committee thought it was asking, and a few weeks of measurement before the pilot is what makes the difference visible while it can still change the decision.
That's the fifteenth pattern.