Deploying an AI assistant across an organisation is mostly not a technology project. The technology works; the difficulty is governance, adoption and knowing whether it delivered anything.
The most common expensive mistake: buying licences for everyone at once. Usage concentrates in a small fraction of them, the rest lapse, and at renewal nobody can demonstrate value. Start with the teams that have named use cases and expand on evidence.
Decisions to make before rollout
| Decision | Why it matters |
|---|---|
| Which teams first | Determines whether early evidence is convincing |
| Data policy, in specifics | Vague policy is not followed |
| What requires human review | Defines the risk boundary |
| Who owns it internally | Unowned rollouts stall |
| What you will measure | Decided after the fact, it is unmeasurable |
| How shadow usage is handled | It already exists |
Writing a data policy people follow
- Name the categories. "Customer bank details, employee records, unreleased financials, credentials" — not "sensitive information".
- Say what the tier does with data, in plain language, because misunderstanding drives both over-caution and recklessness.
- Give an approved path for the cases people are trying to solve. Prohibition alone produces workarounds.
- State what is never delegated — decisions with legal, financial or personnel consequences.
- Name a person to ask. Ambiguity resolved by guessing is resolved badly.
Every policy that says "use appropriate judgement" is a policy that has delegated the decision to whoever is least equipped to make it.
A rollout sequence that produces evidence
- Identify two or three teams with repetitive, reviewable work.
- Establish the baseline — current time or volume on the specific tasks. Without this, no later claim is credible.
- Roll out to those teams with training on their actual workflows, not a generic demonstration.
- Support intensively for two weeks. This is where adoption is won or lost.
- Measure at six weeks against the baseline.
- Publish what happened internally, including what did not work.
- Expand to teams with similar work, using peer examples.
Capture the baseline before rollout. It takes an hour and it is the difference between "the support team handles 30% more tickets at the same quality" and "people say it helps". Only one of those survives a budget review.
Why adoption stalls
| Cause | What fixes it |
|---|---|
| No specific use case given | Name the workflows, with examples |
| First attempt produced poor output | Show good prompting for their actual tasks |
| Unclear what is permitted | Specific written policy |
| Fear about job security | Address it directly rather than avoiding it |
| No time to learn | Allocate it explicitly |
| Nobody to ask | A named person, available early |
The job security point is worth not skipping. Teams read an unexplained AI rollout as a prelude to headcount reduction, and quiet non-adoption is a rational response to that reading. Saying what the intent is — plainly, once — costs nothing and removes a real barrier.
When to move beyond the standard product
- The same context is pasted daily — package it.
- Live system data is the missing piece — build a connection.
- Output quality varies by person — package the workflow.
- Governance requirements exceed the platform's controls — consider a custom application.
- The workflow must run unattended — that is a different kind of build, with different risks.
What to report upward
- Weekly active users as a proportion of licences.
- Task-level metrics against the baseline, for the targeted workflows only.
- Quality signals — rework, complaints, escalations.
- What was tried and abandoned, and why.
- The specific next investment and what it depends on.
Planning a rollout, or holding unused licences? Tell us where it stalled. See our ChatGPT plugin service, the custom GPT guide, and rolling out to teams.