Explaining AI to the Board: Bring Three Numbers, Not a Capability Briefing

What is the board actually asking for?

A board does not need to understand AI. It needs to know what is still manual, what that manual work costs every month, and what changes the first time one workflow runs in production. Questions that sound like a request for education, such as "what is an agent" or "are we behind", are nearly always requests for one of those three numbers, asked by someone who has not yet worked out that this is what they are asking.

The pattern I see is consistent: the sponsor prepares a briefing, it is well received, and nothing is decided. Six weeks later the same conversation happens with better vocabulary.

Boards do not need a capability briefing on AI; they need three numbers, and any executive update that cannot state all three is asking the board to approve a feeling.

That is a harder standard than it sounds, because the third number is genuinely uncertain at the point when the board wants it. The rest of this is about producing the first two honestly and stating the third in a form that survives contact with a CFO.

Why does a capability briefing make the conversation worse?

A briefing transfers vocabulary. It does not transfer accountability. When a board is taught what a model can do, it gains the ability to ask follow-up questions but not the ability to check any answer, so the meeting becomes a debate about technology that nobody in the room can referee. There are only two outcomes. Either the board defers, because it now knows enough to see risk and not enough to size it, or the most confident voice in the room sets the budget.

There is a second cost that shows up later. A briefing has no baseline, so it cannot fail. That sounds like safety, and it is the reason briefings get repeated for three quarters while a pilot quietly stops being used. When you have no numbers, you also have no way to notice that the thing you funded has stopped doing anything.

What are the three numbers?

The columns matter as much as the rows. The board is not judging your technical choices; it is testing whether each number has a provenance it can audit. A figure with a named source survives a challenge. A figure with an adjective attached does not.

How do you measure what is still manual?

Build a register, not a narrative. One row per process, and only processes where someone personally moves a case from one state to another: order entry, invoice matching, contract intake, ticket triage, compliance review, report assembly. For each row record monthly volume, touch time per case, exception rate, and the named owner. Touch time is the number people guess worst, so measure a sample of at least twenty cases with a stopwatch or a timestamp log rather than asking for an estimate.

Here is the arithmetic, using a worked illustration rather than a published statistic. An accounts payable queue handles 2,400 invoices a month at roughly six minutes of human touch each, which is 240 hours of work. At a fully loaded internal rate of about 120 CNY per hour, taken from that company's own payroll and overhead, the queue costs roughly 28,800 CNY a month before any exceptions are counted. If a quarter of the invoices need rework averaging fifteen minutes, add about 150 hours, and the number moves by more than half. Substitute your own volume, loaded rate, and rework share; the mechanism travels, not my figures.

Two caveats. Self-reported touch time runs low, because people compress the searching, re-keying, and waiting into "a couple of minutes". And a register built in a meeting is a list of opinions, so label every unmeasured row as an estimate and date it for measurement.

How do you state the monthly cost without guessing?

State a floor and a mechanism, not a licence price. The recurring cost of an AI-assisted workflow has three parts, and boards reject proposals when only the first is present.

The variable part is cost per run multiplied by monthly volume. With per-token pricing this is knowable before launch: run your twenty hardest test cases, measure the tokens consumed, and multiply. The second part is exception handling, priced separately, because exceptions are human minutes and they are usually where the money actually goes. The third part is the fixed platform and engineering cost, which does not scale with volume and therefore should never be used to justify or reject a case at high volume.

Then show the same three-part cost at five times the current volume. If the per-run cost stays flat and exception handling stays proportionate, the case is robust. If not, you have found the real constraint before a board member finds it for you. The mechanics of turning those figures into a benefit line that a finance reviewer will accept are set out in a per-token cost model that survives a finance review.

What will the first production workflow actually change?

Answer in the same units as the register, so the before and after can be compared without translation. Cases handled without human touch. Exception rate, stated per hundred cases. Cycle time from arrival to resolution. Cost per case, split into run cost and human minutes.

What it will not change in the first quarter is headcount, and saying that out loud is what separates an update from a pitch. The honest first-quarter claim is that a stated share of volume no longer needs touch, that the exception rate is measured rather than hoped for, and that the human minutes per case have fallen by an amount you can defend with timestamps. Any board that has been through a failed pilot will respect that sentence more than a projected saving, because it is the kind of sentence that can be checked next quarter.

Two limits worth naming at the same meeting. A pilot proves that a workflow can work on one queue with one owner; it does not prove it generalises to a second queue with different exception types, and that second deployment is where most of the cost of copying the system actually sits. And if the process is not documented well enough for a new joiner to follow, automating it will encode the current confusion rather than remove it.

What do you say when the board asks for a number you do not have?

Give a range, a measurement date, and the cost of finding out. "Between 20 and 40 per cent of this queue, and I will have a measured figure by the fourteenth of March because we are timing two hundred cases" is a stronger answer than any single number, because it is true and it commits you to a date the board can hold you to.

The failure mode here is not uncertainty. It is a point estimate invented to end the conversation, which then becomes the number the project is measured against. I have watched a sponsor produce a 70 per cent figure in a board meeting to close a line of questioning and spend the next two quarters explaining why the system was delivering 45. Boards forgive ranges. They do not forgive a revised number that was originally presented as a measurement.

Which questions should you decline to answer?

"Are we behind our competitors on AI" has no useful answer, and answering it as though it does is how budgets get set by anxiety. The useful version of that question is whether a competitor has taken cost out of a process that you still run manually, and whether the gap is visible to your customers or your pricing. When I am asked the original question, I answer the second one and say so plainly, because a board that is deciding on a spend deserves to know which question is being decided.

What should the twelve minutes look like?

One page. The register summary at the top, three numbers in the middle, and a decision at the bottom that names what happens if the numbers disappoint.

The last row is the one that gets skipped. A board will approve a system and forget to approve an owner, and an unowned workflow drifts, because nobody's week changes when its output quality falls.

What changes in the next board cycle?

Before the next update, count the processes in your register that nobody has measured, and measure the two largest. That single action converts most of an update from argument into arithmetic, and it costs about two weeks of one person's attention. If you cannot produce all three numbers yet, say which one is missing and when it arrives; a board will accept a gap with a date, and it will not accept a gap with a narrative wrapped around it. The claim of this article is deliberately narrow: explanation is not the deliverable, three figures and one decision are. Executives who adopt that framing stop being asked to educate their board and start being asked to report to it.