Key takeaways
- Going live is day 30. Days 31 to 90 are adoption work, which is a different discipline from deployment.
- Configure before you pilot, and pilot before you widen. Reversing that order costs you a week.
- Every phase needs a named owner and an exit criterion, or it will quietly extend.
- The 90 day review must include what did not work, or nobody will believe the rest of it.
Most rollout plans fail in one of two directions. Either they compress everything into a launch week and skip configuration, or they stretch deployment across a quarter and lose momentum before anyone uses anything. This plan puts go-live at day 30, then treats the following sixty days as what they actually are: the work of turning access into habit.
Copy it, change the names, and put the dates in calendars before you start. Phases without dates extend by default.
Days 1 to 30: get live
Week 1: decide
Owner: the person who can approve spend.
- Interview three or four teams about how they actually work and what they find tedious. Write it down in their words.
- Shortlist two providers. Check what is already bundled in a suite you pay for before considering anything separate.
- Check the unglamorous facts: which tier includes single sign-on, what the retention settings are, whether content is excluded from training, contract length and exit terms.
- Read your client agreements for confidentiality and subprocessor clauses if you handle client information.
- Agree the monthly spending ceiling. Decide it now, while nobody is under pressure.
- Exit criterion: a one-page recommendation naming the provider, the tier, the ceiling, and the reasoning, circulated and not objected to.
Week 2: configure
Owner: whoever administers your business systems.
- Buy licences at the right tier under a business agreement, not personal cards.
- Set retention deliberately. Set external sharing of conversations. Restrict invitations to administrators.
- Connect single sign-on, or document the manual offboarding process if you have no identity provider.
- Set the hard spending limit at the provider. A cap, not an alert.
- Create workspaces mirroring your existing team structure, for cost attribution and separation.
- Test deprovisioning end to end with a test account. Do not assume it works.
- Exit criterion: a non-technical person can open the console, see every user, and see a hard cap on the billing page.
The scheduling bottleneck is almost always week 2. Systems administrators are busy and their time is hard to book at short notice. Put their two hours in a calendar during week 1, not when you get to it.
Week 3: pilot
Owner: a manager whose team does the target work.
- Six to eight people, doing their genuine daily tasks, including at least one sceptic with a full workload.
- Three task cards written and tested beforehand, so the first experience is a good one.
- A short session where people work on their own real material rather than a demo scenario.
- Collect what breaks, what confuses, and which prompts need adjusting.
- Exit criterion: at least two thirds of the pilot group used it unprompted on real work in the final three days.
Week 4: launch
Owner: the project sponsor.
- Enable wider access, using the workspace structure you set up.
- Run 45 minute sessions per team, built around that team's three tasks.
- Publish the one-page rules and the task cards where work already happens, not in a separate portal.
- Name a champion per team and give them ninety minutes of extra preparation.
- Brief an internal owner on the admin console so the organisation is not dependent on an external party.
- Exit criterion: a randomly chosen employee in a covered role can complete a named task without asking for help.
Days 31 to 60: make it stick
This phase has no deployment work in it, which is exactly why it gets skipped. It is also where adoption is won or lost.
| Week | Focus | Specific action |
|---|---|---|
| Week 5 | Find the quiet teams | Pull weekly active users by team. Any team below about half is a visit, not an email. |
| Week 6 | Add task cards | One new card per team, drawn from what people asked for in week 4. Small and specific. |
| Week 7 | First cost check | Compare actual spend to the ceiling. Check the model routing is holding and nothing is running on the flagship by default. |
| Week 8 | Champion catch-up | Get the champions in one room for thirty minutes. They know what is really happening. |
The week 5 action matters most. A team with low usage almost never has a technology problem. Usually the manager has not endorsed it, or the tasks chosen for them do not match what they actually do. Both are found by asking, and neither is found by sending a reminder.
Days 61 to 90: review honestly
One page, presented to whoever approved the spend. Six sections:
- What we bought and what it cost. Licences and implementation, stated separately.
- Who is using it. Weekly active users by team against licences held. This is the number that matters most.
- What measurably changed. The two or three processes where you recorded a before state in week 1.
- What changed that we cannot measure. Described specifically, claimed modestly.
- What did not work. Include this. A review with no failures in it is not read as a success, it is read as marketing.
- Next quarter. Seats to reclaim, task cards to add, one workflow worth deeper attention.
Then do the housekeeping: reclaim dormant seats, re-test deprovisioning, confirm the spending ceiling is still the right number, and check whether a cheaper model now handles a task the flagship was doing at launch.
Do not start a second initiative before the 90 day review. The instinct after a successful launch is to add scope immediately. Resist it for one quarter. Consolidating one working thing beats half-finishing two.
What tends to go wrong, by phase
- Week 1 drifts because the shortlist grows from two providers to four. Cap it at two and move on.
- Week 2 slips because the administrator is unavailable. Book their time during week 1.
- Week 3 misleads because the pilot group is all volunteers. Include a sceptic with a real workload.
- Week 4 underdelivers because training is generic. Build every session around that team's own three tasks.
- Days 31 to 60 evaporate because the project was considered finished at go-live. Put the four weekly actions in a calendar now.
- Day 90 never happens because nobody scheduled it. Book the review meeting during week 1, with the sponsor in it.
Frequently asked questions
How long does an AI rollout take?
Going live takes about 30 days for a commercial provider deployment. Days 31 to 90 are adoption and refinement, which is different work and should not be confused with the build.
Should we roll out to everyone at once?
No. Configure, then pilot with one small group on real work, then widen. Reversing the order means spending week four undoing habits formed in week two.
What should we review at 90 days?
Weekly active users by team, spend against the ceiling, dormant seats, which task cards are actually used, what did not work, and one or two additions for next quarter.
What if we miss the 30 day go-live?
Find out which phase slipped and why. It is nearly always week 1 indecision or week 2 administrator availability, and both are scheduling problems rather than technical ones.
Have the 30 days run for you
The Implementation Package covers the whole first phase: provider chosen and configured, models matched to jobs, hard spending limits, admin portal and optional SSO, a rollout plan written with your team, and a how-to guide for staff. Live in 30 days or less, at a fixed price.