The common failure
Buying licences and announcing them. Adoption follows from specific named workflows, visible examples from colleagues, and someone to ask — none of which come with the subscription.
Written for the person responsible for making an AI assistant rollout produce something measurable rather than a row of unused licences.
Where teams get value quickly
| Function | Task that works well | Why it fits |
|---|---|---|
| Sales | Call notes into structured summaries | Repetitive, format matters, low risk |
| Support | Drafting replies to common issues | High volume, human reviews before sending |
| Marketing | Adapting one piece across channels | Volume work with clear inputs |
| Operations | Turning messy input into consistent records | Tedious and rule-based |
| Finance | Explaining variances in plain language | Analysis is done; the writing is the cost |
| Engineering | Review, tests, documentation | Output is verifiable immediately |
The tasks that work share one property: someone competent checks the output before it matters. Where that check is absent — anything published, sent, or acted on unreviewed — the risk profile changes entirely, and so should your approach.
A rollout that actually lands
- Pick one team and one workflow they perform repeatedly. Not a pilot across five departments.
- Have someone competent do it well and document how — the prompt, the context, what good output looks like.
- Share that with the team as a concrete recipe, not as encouragement to experiment.
- Be available for two weeks. The questions come early and unanswered ones end adoption.
- Measure the specific thing — time on that task, volume handled, quality complaints.
- Then expand, using the first team's examples as evidence.
One team doing one thing well produces more organisational change than a company-wide announcement, because the second team believes the first team rather than the memo.
Governance worth setting before rollout
- What data may and may not be entered — specific categories, not "be sensible".
- What must be reviewed before it goes to a customer or into a system of record.
- What is never delegated — decisions with legal, financial or personnel consequences.
- Which tier you are on and what that means for training and retention.
- Who to ask when someone is unsure.
Write the policy as examples rather than principles. "Do not paste customer bank details, employee records or unreleased financials" is followed. "Exercise appropriate judgement regarding confidential information" is not, because nobody knows where the line is.
When custom development starts to make sense
| Signal | What it points to |
|---|---|
| Everyone pastes the same context daily | Package it as a skill or plugin |
| Output quality varies by person | Package the workflow for consistency |
| "It would help if it could see our data" | A connector to that system |
| Manual copying between the assistant and a system | An integration |
| One person is dramatically more effective | Capture their method and distribute it |
Each of these appears from usage. Building them before people use the standard product means guessing at which workflows matter, and the guess is usually wrong.
Measuring honestly
- Time on the specific task before and after — not "productivity".
- Volume handled by the same headcount.
- Quality signals — complaints, rework, corrections.
- Weekly active use, which tells you whether adoption is real.
- What people stopped using it for, which is as informative as what stuck.
What to be realistic about
It will not replace judgement, it will produce confident-sounding errors, and it is not a substitute for a documented process — an assistant applied to a broken workflow produces broken output faster. Teams that treat it as a capable assistant needing supervision get more from it than teams expecting autonomy.
Rolling out to a team, or seeing licences go unused? Tell us what the team does daily. See our Claude plugin service, packaging team workflows, and plugin vs MCP server.