Turn an executive's AI mandate into a scoped pilot

Executives often state an AI request as a method plus a number: "AI on every customer email", "costs down by a third". The wording answers a pressure they face, such as a board question, a budget round, or a rival's announcement.

The method and the number stand in for an outcome. A lead's job is neither yes nor no: it is to turn the request into a commitment the team can keep and both of you can check. A yes to an unchecked target sets the team up to miss it or to cut corners. A flat no leaves the executive with nothing to report, and the decision gets made without you.

Separate the outcome (cost per customer, response time, room to grow without hiring, quality) from the method ("AI on every email"), which is one possible route to it. Confirm the outcome with a few questions:

• Which outcome matters most if only one can move?
• How will we know it improved: measured how, and by when?
• What is fixed: the budget, hiring plans, quality rules?
• What do you need to say, and to whom?

Then restate it: "I read the goal as X by Y. Is that right?" A confirmed goal lets you question the method without refusing the executive. Measures follow the outcome; the prerequisite question "Define a user outcome and baseline" covers outcomes, proxies (stand-in measures that are easier to count), and baselines.

Public guidance starts here too: the NIST AI Risk Management Framework, a voluntary US guide, asks organizations to understand and document their goals for an AI technology, and the UK government's service manual says to understand the problem before you commit to building a service.

Size the work before you discuss the number.

1. Hours. Volume times minutes per item gives hours; compare them with the team's total handling hours.
2. Budget. Multiply the share of hours by the share of the budget that pays for people's time.
3. Best case first. Suppose the tool did all of a type's work with no human minutes. If even that misses the target, the target needs to change, not the plan.

A generic example (not the scenario's figures): a queue uses 400 of a team's 5,000 handling hours (8%), so even removing all of it moves at most 8% of hours. A tool that halves its time frees 200 hours, 4% of handling hours. If people's time is 75% of the budget, that is 3% of the budget, before fees.

Then keep the estimate honest:

• A vendor's claim is a hypothesis. Test it on your own work, counting review, edits, discarded drafts, and repeat contacts caused by wrong replies.
• Time saved is not money saved. Freed hours lower spending only if hiring, overtime, contractors, or staffing change; otherwise they buy speed, quality, or room for growth. Say which.
• Count the tool's cost: its fee and the setup time.

Some limits hold however urgent the request is. Check each type of work for:

• Rules that require a person. A company rule, or sometimes a regulation, says a person must decide or respond. Legal questions go to counsel.
• Authority over money or commitments. Credits, refunds, discounts, and contract changes need someone allowed to grant them; an AI draft must not grant or promise them.
• Data the tool cannot see. If a correct reply needs a system the tool cannot read, the draft will guess.
• The cost of a wrong reply. Repeat contacts, complaints, harm. Work with many repeat contacts already multiplies mistakes.
• Review time that remains. When a person approves every draft, they still read every item. Fluent drafts can be wrong (NIST calls confidently stated false content "confabulation"), and reviewers can come to over-trust a tool that is usually right (automation bias).

The prerequisite question "Choose which team workflows to hand to AI" teaches how to pick an automation level. The five levels are:

1. No AI
2. AI suggests, a person does the work
3. AI drafts, a person approves each item
4. AI acts, a person audits a sample and handles exceptions
5. AI acts alone, with monitoring

The prerequisite "Choose which team workflows to hand to AI" covers what to write down before any pilot: the baseline, the success measure, the stop rule, and the owner. A pilot that answers an executive's target also needs these fixed before the start, so nobody can argue about them afterwards:

Agree the three possible outcomes in advance too: expand, change and rerun, or stop.

The UK government's service manual describes the same habit for any new service: try out solutions with prototypes, do the minimum you need to test your riskiest assumptions, and treat stopping as an acceptable result. At the decision date, the NIST framework asks whether the system achieves its intended purposes and stated objectives, and whether deployment should proceed.

A commitment has three parts: what you will do, by when, and how it will be judged. Without all three, it is a hope.

• Decline in the executive's terms: the rule, the figure, or the risk, one sentence each. "AI is not ready" gives the executive nothing to repeat; "custom orders need a site survey first" does.
• Offer something usable now: a sentence for the board, and a date when evidence arrives.
• Give estimates as ranges with the assumption named, such as "if the vendor's claim holds on our emails".
• Agree check-ins and what result would change the plan.

Saying what you will not commit to is part of the commitment: it stops the original request from returning as the target you are judged on.

The team will hear about an AI pilot from you or from rumor. Tell them early and plainly:

• Why: the outcome you are working toward, not "management wants AI".
• What changes in the pilot and for whom, and what does not.
• Accountability: the person who approves a draft is accountable for what is sent, can reject or edit any draft, and knows how to flag a bad one.
• Training: a short session on what to check, such as amounts, dates, and promises.
• Their voice: their measures and comments decide the next step.

On jobs, say what you know, what you do not, who decides, and when they will hear more. Never promise beyond your authority. The rollout question in this topic covers this conversation in depth.

Use the scenario above.

Use the scenario above and your sized table.