Reporting to the board

Board reporting on AI tends to go wrong in one of two ways. Either it's a usage dashboard, which tells the board that people logged in and nothing about whether the organisation is better off. Or it's a strategy deck about the future of AI, which tells them what they've already read in the papers. Neither answers the questions board members actually have, and both leave them less confident than before.

A good board paper on AI adoption is short, specific and honest. It says what's been done, what difference it made, what the risks are and how they're being handled, and what's needed next. This playbook is how to write one, usually in partnership with your sponsor, who may well be the person presenting it.

Step 1: find out what the board wants to know

Before you write anything, ask. Your sponsor or the company secretary will know why the item is on the agenda. Common reasons:

• Return on spend. Licences cost money; is it worth it?
• Risk. Are we exposed: data, accuracy, regulation, reputation?
• Competitive position. Are we keeping up?
• People. What's happening to roles, skills and morale?
• A specific trigger. A news story, a regulator's comment, a question from an investor.

Ask your sponsor directly:

What's the question behind this agenda item? What would make the board feel this went well?

The answer shapes everything.

Also find out the format: paper length, whether you present or your sponsor does, how much time is allocated, and the deadline for papers. Board papers usually go out well before the meeting. Work back from that date.

Step 2: gather the evidence

Pull together what you already have, rather than generating new data for the occasion:

• Workflow results. For each workflow you've worked on: before and after, adoption, method (see Measuring time saved honestly).
• Reach. How many teams and people have been through sessions or are using a named workflow. Not licence logins.
• Governance. The usage policy, the working arrangement with IT and security, incidents and how they were handled.
• What didn't work, and what you did about it.
• Spend, from finance, in the form they use.
• What's next, and what it needs.

Step 3: write two pages

Boards read a lot of papers. Short and clear stands out. Use this structure:

1. Purpose (two lines)
What this paper is for and what, if anything, the board is asked to do: note, discuss or decide.

2. Summary (four or five bullet points)
The whole paper in brief. A board member who reads only this should have the picture.

3. What we've done (one short paragraph)
The approach: focused on specific workflows, trained teams on their real work, put a usage policy in place. Name the teams and workflows.

4. What difference it's made (a short table)
One row per workflow: before, after, adoption, method. Plus any quality or service changes that don't reduce to hours.

5. Risks and how we're managing them (a short table)
Data, accuracy, unapproved tools, people. For each: the risk in one line, what's in place, what's still open.

6. What hasn't worked (two or three lines)
Workflows where it didn't help, and what you learned.

7. Next six months (a short list)
The next workflows and teams, and what you need: budget, decisions, time.

Appendix (optional)
Method notes, the usage policy, more detail on any workflow.

Some drafting rules:

• Lead with outcomes, not activity. "[Workflow] now takes roughly [new time] instead of [old time], for [n] of [m] people" beats "We ran twelve sessions". Activity belongs in section 3, briefly.
• Label every number. "Team estimate", "timed sample", "system data". Board members are good at spotting soft numbers, and labelling them first takes the sting out.
• Don't extrapolate. If you've measured three workflows, report three workflows. Don't multiply up to the whole organisation. If someone asks for a company-wide figure, say what it would take to produce one honestly.
• Name the risks yourself. A board that raises a risk you didn't mention loses confidence in the rest of the paper.
• No jargon. Write for an intelligent non-specialist. If you need a technical term, define it once.

Step 4: prepare for the questions

Draft answers to the questions you'd ask if you were on the board. These come up often:

• "How confident are you in these numbers?" Explain the method in two sentences, and say what would make them firmer.
• "What's the total return on the licence spend?" Give the honest answer: you can show specific workflows, here's what they add up to, and here's why you haven't extrapolated.
• "What are competitors doing?" Only say what you actually know. "I don't have reliable information on that" is better than repeating an article.
• "What happens if something goes wrong?" Walk through the incident route and the policy.
• "What does this mean for headcount?" This is usually not your call. Agree beforehand with your sponsor who answers it and what they'll say.
• "What do you need from us?" Have a specific answer ready.

Step 5: the meeting itself

If you're presenting, assume the paper has been read and don't walk through it. Two or three minutes:

The paper covers where we are. Three things to draw out. First, [the strongest result, with its method]. Second, [the most important risk and what we're doing about it]. Third, [the decision or support we need]. Happy to take questions.

Then answer questions directly. If you don't know, say so and offer to follow up in writing.

If your sponsor is presenting, brief them on the three points and the likely questions, and ask whether you should attend to answer detail. Many boards prefer to hear from the person doing the work for part of the item.

Step 6: after the meeting

• Write down what was asked and what was agreed, including any actions.
• Send any promised follow-ups within a week.
• Adjust your plan for anything the board asked for, and say so in your next sponsor update.
• Set up the next paper. If the board will want an update in six months, start the evidence log now: one line per workflow, per month, with the number and its method.

Mistakes to skip

• A usage dashboard as the headline. Logins aren't outcomes.
• Overclaiming. One inflated number undermines everything else in the paper, and the board will remember it next time.
• A strategy essay. The board doesn't need your view of the future of AI. They need to know what's happening here.
• Leaving out what didn't work. It makes the rest less credible, not more.
• Being surprised by the headcount question. Agree who answers it before the meeting.
• Too long. If it's over two pages before the appendix, cut.

At the end you should have

• A clear understanding of why the board is asking and what they want to know
• A two-page paper with labelled numbers, named risks and specific asks
• Prepared answers to the likely questions, rehearsed with your sponsor
• A short opening if you're presenting
• A record of what was agreed, and an evidence log for next time

The Role Book includes the 90-day report template that feeds straight into a board paper, plus the fortnightly sponsor update that means you're never assembling the evidence from scratch.