Rollouts stall in the gap between IT and the work
A typical workplace AI rollout goes like this. IT negotiates the licences, configures single sign-on, switches on the features, and sends a launch email with a link to the vendor’s training videos. Activity spikes in the first fortnight. By the second month, a small group use it daily, most people use it occasionally for rewording, and nobody can say what work has actually changed.
The configuration was not the problem. The gap is that nobody decided what the tool is for in each team, what data may go into it, and who checks the output. Without those decisions, careful staff hold back and less careful staff paste whatever is nearest.
This engagement closes that gap. I work with your administrator on the platform side and with a pilot group on the work side, so the two sets of decisions are made together.
Each platform raises different questions
The three workplace platforms I support most often have different admin models, and the readiness questions differ accordingly:
- ChatGPT Enterprise or Business: a separate workspace your staff bring information into. The questions are what people may paste or upload, which apps and connectors to enable, how custom GPTs and projects are shared, and what the plan’s admin controls allow.
- Microsoft 365 Copilot: grounded in content your organisation already holds, through each user’s existing permissions. The first question is whether those permissions are right, because anything overshared becomes easy to find.
- Google Workspace with Gemini: built into Gmail, Docs, Drive and the Gemini app. The questions are what your edition lets an administrator control, how Drive sharing is set up, and which teams should have which features on.
The platform pages each give a platform-specific readiness exercise and pilot approach. Read the one that matches your tenant.
Running a fair comparison
If you have not yet chosen, I run the comparison on your work, not on demonstrations. We choose eight to fifteen representative tasks from two or three teams, write down what a good result looks like for each, and run them in each candidate under the same data rules. Where practical, reviewers judge output without knowing which tool produced it.
Output quality is only part of the decision. The admin model, how the tool reaches your existing content, what your current licensing already includes, and how staff will actually open it during the day often matter more. The comparison report records all of these, with the evidence, so your sponsor can see why the recommendation was made.
The signature deliverable
You receive an approved-tool pilot, configuration coordination and adoption support, documented as three artefacts:
- Decision record. Data, access and sharing decisions for the pilot, with who made each and why. Illustrative entries: “Customer personal data: not permitted in the assistant during the pilot. Owner: data protection lead.” “Third-party connectors: off until the pilot review. Owner: IT.”
- Test plan and results. Tasks, success criteria, reviewer, and outcome for each.
- Adoption report. Repeat use on the named workflows, time and quality against the baseline, staff feedback, and a rollout, revise or stop recommendation.
The entries above are illustrative examples, not a client’s decisions.
How acceptance is judged
Your workplace technology lead and the business sponsor agree the measures before the pilot starts. Acceptance means the decision record is signed off by the people who own each decision, the test plan was run as agreed, and the adoption report states what changed and what did not. Vendor dashboards are used as one input; the measure that counts is repeat use on the named workflows. The adoption measurement resource explains the approach.
Ownership and handover
Your administrator owns the tenant throughout; I never hold admin credentials. A named adoption owner takes over the workflows, coaching material and measures. For a wider rollout without me, the AI champions programme builds internal coaches.
Engineering tools are a different pilot
If the tool in question is GitHub Copilot, Claude Code, Cursor or another coding assistant, the pilot needs tests, code review and delivery measures rather than document workflows. Use AI engineering enablement for software teams or the coding-agent rollout page instead.