How to Use This Toolkit
Your company bought AI licenses. Someone sent the launch email. A few people are enthusiastic, most tried it twice, and you’re now the person expected to make something happen.
That’s the situation this toolkit is built for. It’s not an argument that AI is useful — you’ve heard that argument. It’s the operational part: what you do, in what order, to get from access to actual use.
Who this is for
A manager of roughly 5 to 30 people. No technical background assumed. You don’t need to know how any of this works under the hood; you need to know what to do on Monday.
Where something differs for engineering teams, it’s called out specifically. Everything else applies the same whether your team writes code or writes contracts.
The order of operations
If you take one thing from this page, take this. Five steps, in this order.
Before step one
Ask security, legal, or IT for your data rules in writing. Send it the day you start — every other step here is under your control and this one isn't.Getting the yes →
Ground rules
Nobody experiments freely while they’re guessing at what’s allowed. This is the step everything else waits on.
You come out with
- Written data rules you can quote, not guess at
- One named owner, with protected hours
- A baseline — you can’t recreate one later
- The one-page policy, published where people work
carries forwardRules people can state from memory, and a baseline to measure against
Pilot
Two or three people, not the team — and they needn’t even be on it. Not to prove AI works, but to come out holding real before-and-after examples, which is what makes the workshop land.
You come out with
- Two or three workflows that demonstrably work
- Before-and-after numbers from the people who do the work
- The failure modes you’ll warn the room about
Running a pilot · Scoring sheet + pilot tracker · A scored + tracked pilot
carries forwardThree or four examples from your own team. This is what makes the room turn up
Workshop
Converts "I’ve heard about it" into "I’ve done it." A one-hour kickoff a week ahead gets the whole team installed and using it — then everyone builds one real thing themselves and shows it.
You come out with
- One thing built, per person, by them
- A prompt library that starts with a shape, not a blank page
- A showcase people outside the team actually saw
Hosting a workshop · Workshop template · The compressed version
carries forwardThings your team built themselves — which is what there is to maintain
Habit
This is where it’s actually decided. A workshop with nothing after it becomes a story about a fun week in the spring.
You come out with
- An owner named for everything still in use
- Outputs somebody has actually checked
- Usage that’s boring and unremarked
carries forwardThe count of what’s still in real use — the number that survives scrutiny
Report
An honest write-up for whoever paid for the licenses — specific enough to check, which is what makes the next ask credible.
You come out with
- An update specific enough for anyone to check
- One clear ask, made credible by the rest
Then go round again with the next two use cases from your scoring sheet. Two short rounds beat one long programme, because each one ends in something real and neither is ever the thing that gets cancelled when the quarter gets busy.
The connectors are the argument. Run the workshop before the pilot and you walk into the room with no examples from your own team, so you fall back on a vendor demo — which convinces nobody. Skip the baseline in step one and step five has nothing to compare against, and no amount of later effort recovers it. The “carries forward” lines are the dependency, not decoration.
Step two is not a pilot of your team. It’s a pilot of the use case — two or three people, one of whom is you, and they needn’t even be on your team. You’re finding out whether a workflow is amenable and what the before-and-after actually is, sitting next to each of them while they do it.
Which is why the pilot comes before the workshop, not after. The common objection is that people can’t pilot something they don’t know how to use yet — but the skill bar rises across the sequence rather than starting high. Three people with you beside them, then everyone installed and trying it at the kickoff a week before the workshop, then everyone building alone on the day:
| Who | Working how | |
|---|---|---|
| Pilot | 2–3, incl. you | With you, one to one |
| Kickoff (1hr, week before) | Everyone | Guided install, 3 uses as homework |
| Workshop | Everyone | Independently, then demo |
You can sit next to three people. You cannot sit next to fourteen. And the workshop needs something the pilot alone can produce: a colleague’s real before-and-after, without which you open the day with a vendor demo.
Go as fast as you can hold. There’s no minimum duration here, and nothing about this needs to be a quarter-long programme — each step ends in something real, so getting through all five in a month is doing it properly rather than cutting corners. The compressed version is that month, written out: about four hours of your team’s time, end to end.
The one thing you can’t compress is step one, because it depends on someone else replying to you. Start it today and do everything else while you wait.
What’s in it
Five guides, meant to be read in order, which are the argument:
- How to use this toolkit — this page.
- Setting the ground rules — who owns it, getting the data rules signed off, and the one-page policy. Everything else waits on this.
- Running a small pilot — a few weeks of finding out whether a workflow is amenable, and coming out with before-and-after examples from your own team.
- Hosting an AI workshop — a day and a half where everyone builds one real thing and demos it.
- Making it stick — ownership, measurement, skeptics, and what to do about your own AI use.
Nine working documents, which are the artifacts — the things you fill in, send, and hand out. The guides tell you why; these are what you actually use. Three are worth naming here because people miss them:
- The worked example — every template in the toolkit filled in for one (invented) 14-person team, including the two verification failures they found and the four things that went wrong. If a blank template is hard to start, open this beside it.
- Getting the yes — the email that gets your data rules confirmed, and what to do when nobody replies. This is the step that stalls most rollouts, and it’s the one to send today.
- The compressed version — all five steps above in 30 days and three hours, for when the full pace is more calendar than you can hold.
The rest — the full playbook, the policy template, the operating templates, the workshop template, the prompt recipes, and the starter project — are listed at the bottom of this page.
Not starting at step one?
Most people don’t. The sequence above reads from day zero, and almost nobody arrives at day zero — they arrive three weeks after a workshop that produced nothing, or holding a tool nobody will tell them the rules for, or with a skip-level on Thursday and something to show.
Find the row that describes your week and start there. The sequence will still be waiting.
- Licenses landed, nothing has happened, and it is now your problem
- Onboarding your team
- Nobody will tell you what data your team is allowed to paste in
- Getting the yes
- You need this done in a month, or you can’t hold much of anyone’s calendar
- The compressed version
- The workshop already happened and none of it survived
- Making it stick
- Someone above you wants to see something by the end of the month
- Operating templates
- Your team is on Copilot, Gemini, or ChatGPT rather than Claude
- Prompt recipes
- You want to see what all of this looks like finished, first
- The worked example
- You’d rather read the whole argument in one document
- The full playbook
How to get the most out of it
Send the approval request today. Before the policy, before the pilot, before you plan anything. Every other step here is under your control and that one isn’t — it depends on someone in security, legal, or IT replying to you. Start the clock now and do the rest while you wait. Getting the yes is the how.
Do the ground rules before anything else reaches your team. The single most common failure isn’t a bad tool or a bad workshop — it’s that people don’t know what they’re allowed to paste in, so they either avoid the tool or use it in ways nobody can see. One page, four rules, and a named person to ask. That’s the whole job.
Copy the specificity, not the answers. The downloads are Markdown for a reason — they’re a starting shape, not a script. But when you adapt them, adapt down to your team’s actual nouns. A policy that says “confidential data” changes nobody’s behaviour; one that names the specific report, system, or record type does. That’s the thing worth taking from the worked example.
Don’t skip the pilot to get to the fun part. The workshop is the part people enjoy planning. It’s also the part that fails loudest when the room has never seen AI do anything useful with your team’s actual work.
Be honest with the numbers. There’s a whole section on this in the last guide, and it argues for claiming less than you could. That’s not modesty — it’s that the first inflated number someone checks discredits everything else you did, including the parts that genuinely worked.
If it goes wrong, it goes wrong here
Each of the common failures traces back to a specific step, which is the other use for the diagram above — when something has stalled, find the step and go read it.
- Nothing happens at all. Step 1 — adoption belonged to everybody, so it belonged to nobody. Name a person with two protected hours.
- Only the enthusiasts use it. Step 1 — no written data rules, so the cautious majority quietly opted out. Usually this isn’t a refusal; it’s an unanswered email nobody chased.
- The workshop fell flat. Step 2 was skipped — the room had never seen the tool do anything useful with your team’s own work, so you were left demoing somebody else’s software.
- Great week, nothing survived. Step 4 — no owners named, so it rotted by the following quarter.
- It never started. The plan was bigger than the calendar you could hold: a day and a half booked, then a reorg, then next quarter, then never. Run the short version instead.
- Tools instead of habits. Not a step — a reflex. Buying a second tool because the first one isn’t used is a very expensive way to avoid the actual problem.
Take the documents
The guides are the readable version. These are the working files — the ones you fill in, hand out, and edit.
Most of these come two ways — read the formatted page in your browser, or download the raw file to edit and hand out. The downloads are plain Markdown and ZIPs, not web pages.
Everything
The full bundle: playbook, worked example, one-page policy, approval guide, operating templates, compressed version, workshop guide, prompt recipes, and the starter project.
Start here
Worked example
One invented 14-person team with every template above filled in — the policy, the scoring, the pilot, the verification, the update, and what went wrong. Copy the specificity, not the answers.
One-page policy
Fill-in-the-blank AI use policy. Do this one first — everything else depends on people knowing what is allowed.
Getting the yes
How to get the data rules in writing: who to ask, the email to send, and what to do when nobody replies. Send this before anything else — it has the longest lead time.
Running it
Operating templates
Six fill-in tools: use-case scoring, a data-use decision aid, pilot tracker, output-evaluation checklist, ownership record, and leadership update.
The compressed version
A 30-day plan and a three-hour session, for when you can’t hold a day and a half of calendar. Roughly 70% of the outcome for 20% of the time.
Workshop guide
The full day and a half: timeline, agendas, project lists, surveys, remote/hybrid variant, copy-paste emails.
Hand to your team
Prompt recipes
Copy-paste prompts for whatever assistant your company approved — Copilot, Gemini, ChatGPT. Start here if your team is not on Claude.
Starter project (Claude only)
The folder you copy and hand out at the kickoff — skills, commands, and context files. Needs Claude; on any other assistant use the prompt recipes instead.
The reasoning behind it
The AI onboarding process (diagram)
The whole sequence as one image — five steps, what each hands the next, and which step each common failure traces back to. Print it, or drop it in a deck.
Full playbook
The whole argument in one document: rollout sequence, policy, use cases, skeptics, ownership, measurement, and a 90-day checklist.
Edit the downloads, cut what doesn't apply, and make them yours — none of it is meant to survive contact with your team unchanged.
If you’d rather not choose: send the email in getting the yes today, read the worked example while you wait for the reply, and start guide two by naming an owner.
The takeaway: none of this is about the tools. It’s about someone being responsible, people knowing what’s allowed, and everyone having built one real thing themselves. Do those three and the rest is detail.