Beyond "Deployed but Unused" — Designing Internal AI Adoption
Copilot rolled out company-wide, but usage sits at 10%. Onboarding ended with one briefing, and the winning prompts are buried in someone's personal Notion. This isn't a skills problem — it's a missing organizational design: there's no natural adoption loop.
How to reproduce a natural adoption loop with "AI Champion × monthly LT × hackathon × KPI linkage," covered from both the deploying side (IT / DX / line leads) and the provider side (AI product vendors).
"Deployed but unused" isn't a skills problem — it's a missing organizational design of a natural adoption loop. AI Champion × monthly LT × hackathon × KPI linkage can reproduce that loop inside a closed environment.
- "Deployed but unused" is an organizational design problem, not an employee-skill problem.
- The reason Claude Code / Codex spread via social is three pieces: (1) individuals can try it · (2) a place to post · (3) posters get credit.
- The four-piece set to reproduce that in a closed environment: AI Champion / monthly LT / hackathon / KPI linkage.
- The balance between mandate and self-direction decides outcomes. Light KPI linkage + recognition, evaluated at the team level.
The symptoms and what's really going on
>1-1Failure patterns we keep seeing
- Copilot rolled out company-wide, usage stuck at 10%: licenses handed out, no one touches it
- It ends with the kickoff training: the briefing gets buzz, but three months later only 1 in 10 has opened the tool — it never lands in the team's workflow
- AI lead and field teams are disconnected: the lead's roadmap doesn't line up with the day-to-day problems the field actually has
- Winning examples never get reused: great prompts scatter across personal Notion / Slack, and six months later nobody can reproduce them
>1-2What's really going on
This is not a skill gap on the part of individual employees — it's an organizational design problem:
- "A reason to use it" and "a system where using it gets rewarded" are both missing
- No psychological room to pay the learning cost (the evaluation axes are still old-school)
- Low psychological safety to fail
→ The fix is not pushing a product, but designing a natural adoption loop.
Why did Claude Code / Codex spread on their own?
Before fixing internal AI adoption, observe the natural adoption happening outside. The reason Codex / Claude Code / Cursor exploded is that the five-step loop in Fig.0 kept turning — and the preconditions that keep it turning boil down to three.
On top of that, Codex / Claude Code open-sourced the CLI / Agent layer. This isn't just transparency — it's free distribution of operational know-how: how to drive an AI agent, how to run tools safely, how to design prompts. Dify and n8n follow the same shape.
(1) Individuals can try it (low barrier to experiment)
(2) There's a place to post (social / OSS / community)
(3) Posters get credit (followers / job offers / side income)
→ These three are absent inside companies. That's why it doesn't spread.
The approach for the side rolling AI out internally
For IT / DX / middle managers / AI Champion candidates
Design with three mechanisms
To reproduce the natural adoption loop inside a closed environment, combine three mechanisms.
>3-1AI Champion program (the foundation)
- Appoint AI-savvy employees in each department as official Champions (the volunteer model is essential)
- Their role: run a monthly 30-minute study session / share prompts in a dedicated Slack channel (
#ai-use-cases) / mentor peers - Incentives: recognition, internal points, budget priority, presenting in front of executives, the feeling of becoming an "internal star"
Success case: Sumitomo Corporation's "Copilot Champion" program → ¥1.2B/year cost reduction, 10,000 person-hours/month saved
Minimum viable setup: start with 2-3 Champions → full rollout in 3 months
>3-2Monthly use-case lightning talks (LT)
The mechanism with the fastest payoff.
- Format: lightning talks 5-10 min each, monthly cadence
- Presentation template is required:
Problem → Prompt → Result → Time saved - Non-engineers welcome (in fact, sales / finance / HR examples land hardest)
- Chain effect: when a presenter's "winning example" goes in the company newsletter, next month's submissions double
- Examples: SmartNews Knowledge Share (196 attendees) / at Sen Co., Ltd. it's run by the marketing team — IT doesn't have to lead
>3-3Hackathon (the use-case generator)
Run study sessions = knowledge sharing, and hackathons = use-case generation, as a two-stage system.
| Topic | Recommendation |
|---|---|
| Format | Half-day to one-day prototype on "solve a real work problem with AI" → demo |
| Cadence | Twice a year (monthly is too much load, yearly is too thin) |
| When | Prefer on company time. Saturdays skew participation toward singles and juniors |
| Incentives | Winner gets a dev budget / resources, top entries are considered for production |
★ Balancing mandate and self-direction
This is the biggest open question for internal AI adoption. Leadership wants to tighten with KPIs; the field wants to move on self-direction. How do you resolve that tension?
❌ Pure mandate: "everyone must post a monthly use case" → flood of low-quality posts, atmosphere sours
❌ Pure voluntary: "whoever's interested can join" → only existing fans move, nothing spreads across the org
>4-1The Sumitomo Corporation model (recommended)
- Add "each team must share at least one case" to manager evaluations (team-level, not individual)
- Run the KSFs (Champions, LTs, hackathons) as "a push," not a mandate
- Not duty, but "opportunity creation" — give a stage to those who want to present
- Evaluations are upside (no penalty for not doing it)
>4-2Design notes
- Spread KPI pressure across teams, not individuals so no one is cornered
- Lead with positive incentives (recognition, budget priority); KPI linkage is supplemental
- Have leadership say "experiments are OK, failure is OK" at an All Hands to lock in psychological safety
Measurement: KGI - KSF - KPI hierarchy
>5-1Concrete KPIs and rough ranges
| Metric | Range | Example math |
|---|---|---|
| Minutes saved on meeting notes | △2-5h / mo / person | 100 people × △3h × 12 months = △3,600 hours/yr |
| Meeting time reduction | △10-20% | tens of millions of yen/yr in overtime equivalent |
| Initial response time on inquiries | △30-40% | Customer support |
| Manufacturing / test cycle time | △ x % by industry | Design the measurement per industry |
| Use cases posted | x / month | Slack posts + LT talks combined |
| Use cases in production | x per quarter | Things in production use (excludes PoCs) |
Trying to put a number on everything brings on spreadsheet disease. Deliberately also pick up "things you can't measure but are valuable" (psychological distance between departments shrinks, juniors get more eager to post, etc.).
Aggregate use cases into a "Second Brain"
The raw notes coming out of LTs, hackathons, and Slack should be collected raw at first. Don't aim for clean documentation up front.
cookbook (recipes by workflow) / prompt library / workflow templates / failure log / adoption checklist — raw material extracted and structured from Slack / Notion / Obsidian via Codex / Claude Code.
You could call this the organizational version of Karpathy's LLM Wiki.
→ See Obsidian → LLM Wiki → HTML → AI Deploy for a separate write-up.
>6-1Handling duplicates and disagreements
Keep aggregating long enough and it will happen: multiple teams post different prompts for the same workflow, one insists "this is the right one" while the other has a better alternative, the same prompt yields different results in different teams. The rule is "keep both with context," not "pick a winner and delete the other."
| Situation | Common failure | Recommended approach |
|---|---|---|
| Duplicates (same case from multiple teams) | Delete the older one and overwrite | Keep both and cross-link. Champion decides on consolidation each quarter |
| Different approaches | Snap-judge a winner and delete the other | Show as "Case A / Case B" with context attached (department, data scale, constraints) |
| Same prompt, different result | Report "doesn't work" and stop there | Record under "Known variations." Often the most valuable information |
Organizational use cases are context-dependent. Sales and engineering can legitimately have different "right answers" with the same tool. Calling one "best practice" excludes the other and kills the urge to post. Show all the evidence; let the user decide — this is the same principle whether the Wiki is personal or organizational.
One step deeper: even the same person uses a tool differently depending on context. So the wiki's job is less "build the right classification" and more "pile up the raw material so each reader can make sense of it in their own situation." Meaning-making happens at read-time, not write-time — a Champion's curation is less about organizing and more about keeping things findable.
>6-2Operational mechanisms
Lightweight on classification, heavy on findability.
- Champion's job is findability, not order: keep entries reachable. Don't try to perfect a taxonomy that nobody asked for
- Quarterly Wiki Day: archive only the truly dead. Don't pick a "winner" and delete the rest
- Tags are hints, not classification:
context:sales/context:engjust record "this entry was written in this situation." The reader makes the call - Require date and model name: assume the model will move in six months and the same prompt will yield different results
- Threads for debate, frozen body: edit wars on the main entry are hostile. Keep discussion in the linked Slack thread or comment area
- Assume LLM-based search: build for "ask in natural language, get relevant cases" rather than relying on classification — that's what field-level judgment actually wants
The approach for the side providing AI products
For SaaS vendors / AI product providers / CSMs / solutions engineers
Product alone won't sell: shift to selling KPI consulting
If the provider just "builds a good product and sells it," the client falls into three pains:
- Deployed, but 10% usage
- At renewal, cut for "we can't see the impact"
- Procurement doesn't pass (can't show cost vs effect)
at the same time.
>7-1Co-design the client's KGI / OKR
Break the provider-side KGI (GMV growth) into a product of three factors.
So the provider's plays all converge on "maximize use-case density." Not pushing license counts — the growth headroom in GMV is depth of use per account. That's why the provider should bake Champion / LT / hackathon (from Part 1) into the service itself:
- Propose a Champion program design at onboarding
- Distribute templates for monthly LTs (schedule, presentation format, evaluation rubric)
- Have CSM lead a hackathon six months in
These can be built in as part of the contract.
OSS / community strategy: borrowing trust forward
SaaS / API vendors release OSS not out of altruism but to borrow trust forward.
| Tactic | What it gets you |
|---|---|
| OSS release | Show "easy to switch off" and kill the fear of lock-in |
| Public templates | cookbook / prompt library / workflow templates (distributing know-how) |
| API / SDK access | Lets people learn integration patterns |
| Community ops | User groups / Discord (build a posting culture through peer-to-peer) |
| ★ Host hackathons | A loop where the market discovers use cases for you |
In particular, hackathons are powerful as places where "users discover use cases themselves." You can run internal community + external hackathons in parallel.
Things to move on tomorrow
Execution guide common to deploying side and provider side
First action by role
What matters is not what you read but what you do. Bring it down to the level of "doable today or this week":
3 months + alpha roadmap
Five failure patterns
First, here are the three tension axes we've been discussing, on one page. Most failure patterns come from going all the way to one side of one of these axes.
| Axis | Left: fails if pushed all the way | Right: fails if pushed all the way | The right answer |
|---|---|---|---|
| Mandate vs self-driven | Squeeze with KPIs → self-direction dies | All-voluntary → nothing happens | Light KPI linkage + evaluation incentives |
| KPI vs aggregation | Chase numbers only → spreadsheet disease | Just collect → impact never reaches leadership | Show via KPI, accumulate as knowledge |
| SaaS vs OSS | SaaS only → lock-in / cost bloat | OSS only → ops overhead / knowledge silos | Compete on use-case density (tools are means) |
The typical pitfalls to avoid:
- Running KSFs as a mandate: hard KPI enforcement → self-direction dies
- No posting culture: presenting doesn't get rewarded → no one presents — a vicious cycle
- Leadership doesn't say "experiments are OK": zero psychological safety, no one tries anything
- Use cases never get aggregated: events get hyped, but good prompts scatter across Slack and personal Notion and never become org knowledge
- No KPI story on the provider side: adoption cost and impact aren't linked, procurement stalls
Design the natural adoption loop from both sides: the organization and the provider
The core of internal AI adoption is not pushing a product, but designing a natural adoption loop. The four pieces to line up:
- A place to post (Slack channel / LT / Wiki)
- A culture where posters get credit (Champion program / executive presentations)
- A way to try things small (PoCs / hackathons / start with non-confidential data)
- KPIs that make the impact visible (deliver time and cost savings to leadership)
On top of that:
- Balance mandate and self-direction (light KPI linkage + positive incentives)
- Run KPI and aggregation in parallel (show via numbers, accumulate as knowledge)
- Compete on use-case density, not SaaS-vs-OSS (tools are just means)
Don't order people to "use AI." Instead, both the organization and the provider should set up a design where using AI gets you credit, is fun, and makes tomorrow's work easier. That's the core of internal AI adoption from 2026 onward.