How to roll out AI in your team in 30 days
Handing a team AI licences and hoping for the best rarely produces much. A short, deliberate rollout does. This is a four-week plan built around four verbs: pick, pilot, measure and scale.
Pick: the use-case register
A team rollout fails most often at the start, when the choice of what to try is made by whoever is most excited. The register is the fix: one spreadsheet listing every candidate use of AI in the team, with the same columns for each, so the choice is made on comparable information.
| Column | What goes in it | Example row |
|---|---|---|
| ID | Short reference | UC-03 |
| Task | One sentence, as the person who does it would say it | Draft the weekly store performance email from the sales export |
| Owner | Who does the task now and will trial the change | Operations coordinator |
| Frequency and volume | How often, how many | Weekly, one email, about two hours |
| Delegation rung | Inform, draft, decide with review, or decide | Draft |
| Data sensitivity | Public, internal, personal or restricted | Internal (store-level sales, no personal data) |
| Check method | How the output will be verified | Owner reconciles figures to the export; regional manager reads before send |
| Expected benefit | Stated plainly | Two hours to forty minutes; consistent structure |
| Status | Candidate, piloting, adopted, retired | Candidate |
Populate it in a one-hour session with the whole team, aiming for fifteen to twenty-five rows. Then pick two or three for the first month with four filters: frequent (so the pilot produces enough repetitions to judge); low risk (inform or draft rung, data no more sensitive than internal); easy for the owner to check; and wanted by the owner. A pilot run by someone who did not choose it produces no evidence either way.
Choosing the most valuable use case first. It is usually also the most sensitive and the hardest to check. Start with the frequent, boring, checkable one; its success buys permission for the valuable one.
Pilot and measure
A pilot is a comparison, and a comparison needs a before. In week one, before anyone changes how they work, record the baseline for each chosen use case: time per item, an error or rework rate if one exists, and a one-line quality judgement from whoever receives the output.
The pilot runs for two weeks with the owners. Each keeps a short log per item: how long it took, what the model got wrong, what they fixed. The "what it got wrong" column is the most valuable thing the pilot produces; it becomes everyone's review checklist.
Measure four things. Time per item against baseline. Quality, judged on a sample by someone who did not produce the output. Adoption: on how many eligible items did the owner actually use the tool. And incidents: anything that reached a customer, manager or system before a mistake was caught, each with a line in a shared log.
A regional retail operations team of ten piloted three use cases: the weekly store email (draft rung), summarising the Tuesday planning meeting from a transcript (draft rung), and answering store managers' procedure questions from the policy manual (inform rung). After two weeks: the email went from about two hours to forty minutes with one figure error caught at reconciliation; meeting summaries missed action items twice, so the template gained a mandatory actions table; the procedure answers produced one incident, a store told an outdated refund window because the manual existed in two versions. The fix was to the document, not the tool.
Time saved is the metric that misleads most. A task done in half the time with output nobody trusts has saved nothing. Report time, quality and incidents together, every time.
Hold a fifteen-minute stand-up twice a week during the pilot. Owners bring one thing that worked and one that did not. The "did not" list is the best training material the team will ever have.
Training people and the one-page policy
Training that works is short, hands-on and about the learner's own tasks. A ninety-minute session in week one covers three things. The brief: how to give a model the context, audience, format and source material, using the team's own use cases. The review pass: reading output as a sceptical editor, with a starter checklist (invented facts, wrong figures, tone drift, missing items) until the pilot's own list replaces it. The boundary: what the policy allows and why. Afterwards, a shared prompt library, weekly office hours and buddy pairs keep it alive.
The policy is one page of rules people can remember. Draft it with your IT, privacy and legal advisers; the specifics depend on your industry, jurisdiction and contracts, and nothing here states what the law requires. A serviceable draft covers six points.
Approved tools, by category and by the accounts the organisation provides. What data may go in, as a traffic light: public and general internal material is green; internal commercial material is amber and stays within approved, organisation-controlled tools; personal information about customers or staff, financial account details, payment card details, credentials and anything under a confidentiality obligation is red and never enters a model tool without an explicit approval process. Review before release: output is a draft until a named person has checked it, and anything going outside the organisation is checked by someone other than the person who generated it. Disclosure: where and how the team says AI was used. Records: which use cases are logged and where. Escalation: who to ask when unsure, a name, not a mailbox.
A policy people can recite is followed. A policy people have to look up is not.
The week-by-week plan, and the decision to scale
The four phases fit in a month for a single team. Keep the order.
| Week | Actions | Output by Friday |
|---|---|---|
| Week 1: pick and prepare | Register session; choose two or three use cases; record baselines; confirm approved tools; draft the policy with advisers; run the training | Register with baselines; policy draft |
| Week 2: pilot | Owners use the tool on every eligible item and log each; twice-weekly stand-ups; start the prompt library; open the incident log | Per-item logs; first "what it got wrong" list |
| Week 3: pilot and measure | Continue; independent quality review of a sample; count adoption; fix templates and source documents where incidents point | Time, quality, adoption and incident figures against baseline |
| Week 4: decide and scale | Verdict per use case; roll adopted ones to the whole team with the prompt library and review checklist; finalise the policy; schedule the monthly register review | Register updated; next candidates named |
The week-four decision gives each use case one of three verdicts. Adopt, when time or quality improved and incidents were caught by the check method. Adjust and extend, when the direction is right but the template or check needs work; give it two more weeks. Retire, when the owner would not choose to keep using it, whatever the time figure says. Retiring a use case is the process working.
Scaling is the register review becoming a monthly habit: one hour, the whole team, every row's status checked, incidents read, candidates promoted, others retired. The check method stays in place after adoption, because the failures that matter arrive after everyone has relaxed, and the register is owned by someone with the standing to retire a use case a senior person likes.
Try this tomorrow: open a blank spreadsheet, add the nine register columns and fill in three rows for your own team. It takes twenty minutes.
Key takeaways
- Build a use-case register with the same columns for every candidate, and pick the first two or three for frequency, low risk, checkability and a willing owner.
- Record the baseline before the pilot; measure time, quality, adoption and incidents together, never time alone.
- Train in ninety minutes on the team's own tasks: the brief, the review pass and the boundary; then sustain it with a prompt library, office hours and buddies.
- The policy is one page and six rules, drafted with your advisers: approved tools, data traffic light, review before release, disclosure, records and escalation.
- Week four gives each use case a verdict of adopt, adjust or retire, and scaling means the register review becomes a monthly habit.
Learn the whole picture
This article is the lesson text of Module 60. In the course it comes with an interactive exercise and a knowledge check. The Complete AI Practitioner Course has 71 modules across 12 parts, about 18 hours of guided learning, an interactive exercise in every module, a final assessment, and a certificate with a LinkedIn credential. No code needed. US$299, paid once.
Enrol nowSee the curriculum