Course resource

Internal Pilot Proposal

Getting permission to do AI work inside your own organisation — the lowest-risk way to build a track record.

Why start internally

You have what an external consultant does not: you know which processes are actually painful, you have access to the data, and you can measure the before because you live it. A single internal pilot with a real number is worth more than a certificate.

Pick the right first pilot

Do not pick the biggest problem. Pick the one you can finish. A completed small pilot buys you permission for the big one.

The proposal

One page. Managers approve one page.

# PILOT PROPOSAL: [NAME]

## THE PROBLEM
[What happens now, who does it, how often]
Current cost: [HOURS PER MONTH x ROUGH RATE, or ERROR RATE, or DELAY]

## WHAT I PROPOSE
[Two sentences, plain English, no tool names]

## SCOPE
In scope: [THREE THINGS]
Out of scope: [BE EXPLICIT]

## WHAT I NEED
Time: [HOURS] over [WEEKS]
Access: [SYSTEMS]
Budget: [TOOL COSTS, USUALLY SMALL]
Approval: [FROM WHOM, FOR WHAT]

## HOW WE WILL KNOW IT WORKED
Baseline: [MEASURED, NOT ESTIMATED]
Target: [SPECIFIC]
Measured by: [WHO, HOW]

## RISKS AND CONTROLS
| Risk | Control |
|---|---|
| Wrong output reaches someone | Human reviews every output before it is used |
| Confidential data exposure | Only [APPROVED TOOL], no customer data |
| It does not work | We stop at week [N] and I write up what we learned |

## DECISION POINT
At [DATE] we either continue, adjust, or stop. I will bring the numbers.

Why this format works

Cost first. Managers approve things that address a cost they recognise.

Out of scope named. Signals you have thought about it and prevents the scope conversation later.

A stop condition. The single thing that makes approval easy. You are not asking for an open commitment; you are asking for four weeks with a decision point.

Risks stated by you. If you raise them, you look competent. If they raise them, you look unprepared.

The conversation

Do not send the document cold. Have the conversation, then send it.

"[PROCESS] takes us about [HOURS] a month. I think I can cut that
significantly. I'd like four weeks and no budget beyond a [TOOL] licence
to try. If it doesn't work by [DATE], I'll stop and write up why.
Can I put a page together?"

Short, bounded, reversible. Most reasonable managers say yes to that.

Objections you will hear

Objection Response
"Is this secure?" Name the tool, the tier, the data classification, and the human review step. Have the answer ready before you are asked.
"We don't have budget" Most pilots need none. Say the number — it is usually under a monthly software subscription.
"Who maintains it?" "I will, and I'll document it so I'm not a single point of failure." Then actually do that.
"What if it's wrong?" "A human reviews every output. It drafts; it doesn't send."
"IT needs to approve it" Good — ask what they need. Going around IT is how pilots get killed permanently.
"We tried AI, it didn't work" Ask what they tried. Usually a broad tool with no specific process. Yours is narrow and measurable.

During the pilot

The write-up

Whatever the result:

RESULT
Baseline: [X]   After: [Y]   Change: [Z]

WHAT WORKED
WHAT DIDN'T
WHAT I'D DO DIFFERENTLY
RECOMMENDATION: [CONTINUE / EXPAND / STOP]
WHAT THIS SUGGESTS FOR [NEXT PROCESS]

If it failed, say so clearly and recommend stopping. This is counterintuitive and it is the single best thing you can do for your credibility. The person who honestly reports a failed pilot gets approved for the next one; the person who oversells a mediocre result does not.

After a success

Do not immediately ask for the next pilot. Ask:

"This saved about [HOURS] a month. I'd like to look at [NEXT PROCESS],
which I think is similar. Same shape: four weeks, a decision point,
and I bring the numbers."

You are establishing a pattern, not requesting a favour. After two of these, people start bringing processes to you — which is the actual goal.

Back to dashboard