Before
Each request worked out by hand against statutory rules that differ by country, plus company policy on top.
Case study · AI enablement · 2026
From AI access to AI behaviour, across a 1,400-person workforce.
What we delivered at a ~1,400-person HR-tech company, what its people showed each other, what the numbers do and do not show, and what all of it means for a pilot with about ten people.
Use the arrow keys or the buttons below. Press S to read this as a page.
Part 1 of 7
The starting point
01 · The starting point
The tools were there. The habits were not.
A ~1,400-person HR-tech company had already given its people AI tools and training on how to use them. Leadership wanted AI proficiency to be a baseline skill for every employee, with a company-wide certification goal for the year. Access alone was not getting them there.
Already in place
- AI tools, already in people’s hands
- Tool training from the company’s own teams
- Leadership backing and a stated goal
Still missing
- Consistent adoption across teams
- Time to experiment
- Clear use cases for each role
- Confidence, in place of fear and resistance
- A shared view of what responsible use looks like
- 110 of 271named not having enough time to learn as their biggest blocker.
- 127 of 207already placed themselves at the third of four levels of AI use.
Live poll answers from the first topic. The first figure is across three sessions, the second across the two sessions where that poll was recorded.
This was not a room of beginners. The gap was time, and knowing where to point it.
Part 2 of 7
The approach
02 · Our lane
Their teams taught the how. We taught the when and the why.
The programme ran alongside the company’s own tool training, not in place of it. That split kept every session about judgement and habits, and kept it largely independent of any one tool.
The company’s own teams
- How each tool works
- Scheduling and logistics
- Tracking certification
- Governance policy
Our sessions
- When to reach for AI, and when not to
- How to judge what it gives back
- Designing a use case from your own work
- Mindset and habits that last past the session
- Two facilitators in every session
- One mental model throughout
- Live demos on real work
- One small commitment per session
- Every session measured
Tool training tells people which button. This was about which problem.
03 · One mental model
Four levels, used in every session
The AI Spectrum gives everyone the same picture of where they are and what the next level looks like for their role. It was used in every session.
You earn the top level by doing the one below it first.
04 · Programme design
Four tracks were designed. This case covers what we have records for.
Enablement was planned as more than classes: a baseline for everyone, a way for good examples to spread, and support for the people who carry adoption inside teams.
Baseline topics. Four topics for all employees, each run three times so people could pick a date.
DeliveredShow and tell. Short open sessions where employees present something they built: the problem, how they built it, what went wrong, the result.
Delivered (three sessions on record)Ambassadors. A ten-person group to lead adoption inside departments, with a kick-off and eight check-ins.
Designed; redirect proposedManager session. One session to help managers coach their teams through adoption.
Scoped
Status reflects our delivery records up to late July 2026. “Scoped” and “designed” mean exactly that: we do not claim them as delivered.
The design bet: classes start it, and colleagues showing real work spreads it.
05 · How each session worked
Short input, real work, one small commitment, then measure
Every session followed the same loop, and what the room told us in the first topic shaped the second.
The polls were not decoration. They are where the numbers later in this page come from.
Part 3 of 7
What was delivered
06 · The delivery record
Four topics, twelve sessions, thirteen weeks
Each topic ran three times as a two-hour virtual session with two facilitators. The first session was on 18 March 2026 and the last on 16 June. The show and tell sessions followed.
- 4baseline topics
- 12sessions delivered
- 13weeks, first session to last
- 3apps built for the sessions
Everything on this line has a delivery record behind it.
07 · Built for the room
Three small apps, so people did the thing instead of watching it
Each app was built for one topic and used live in its sessions, in the browser.
-
A workflow card lab.
Each person types one workflow they run regularly. The tool returns a card to download.
-
A role-matched verification lab.
Pick the scenario closest to your role, check an AI-written document for errors, and download a personalised checker to keep.
-
A verification game.
Everyone checks the same AI-written memo. An AI judge scores each verdict on a live leaderboard.
Also delivered
- A passcode-protected programme site with the results (attendance, polls, satisfaction and written feedback, by topic and across sessions).
- A resource section on the same site, with 14 handouts across the four topics.
We did not instrument the apps, so we do not quote usage counts.
Built so people would leave with something they had made, not something they had been shown.
Part 4 of 7
What people showed
08 · The build closest to your world
People Operations colleagues built a leave-entitlement calculator
The team built this during the company’s own AI week, then presented it at a show and tell session we ran. They had not built with the AI assistant before, and no coding was needed. Leave rules differed by country, with company policy on top, so every request meant manual calculation and back and forth. They described the problem to it in plain language, and kept refining.
Now
A calculator covering several countries, published in the company’s internal wiki in two views: one for employees, one for HR. The team uses it every week.
How they got there
Start from the problem. A plain statement of what was hard, not a specification.
Feed in the policy. Every existing policy and process document went in first.
Keep asking for the simpler way. Plain-language feedback was enough.
Test on real cases. Checked against incoming requests and past cases, and against the manual process.
Publish where people already look. Inside a tool the company already had. The yearly policy review is the checkpoint for keeping it right.
As presented by the builders at one of the show and tell sessions we ran; the build was theirs. No time saving was measured, so none is claimed.
The builders tested it on real cases and put it where colleagues already look.
09 · Two more, from other teams
A first agent, and a tracker one person built for themselves
A small commercial operations team
A dispute triage agent
It reads each new case, looks at how similar cases were handled, classifies type and urgency, names the right owner and drafts a summary with next steps.
Status when presented: a working first version, started by hand, still being tested. Before it, triage took one to two hours a day. No saving has been measured yet.
One account manager, no engineering background
A product-release tracker
It gathers release and roadmap updates from scattered sources into one filterable view, refreshed each morning.
Weekly research went from 1 to 3 hours to under 5 minutes, by the builder’s own estimate.
The three show and tell sessions we hold records for drew 372 seats (one seat is one person at one session), the largest 207.
The lesson the triage team drew, paraphrased
Define the problem and map the process first. The agent comes last.
None of these builds came from an engineering team.
Part 5 of 7
The impact
10 · What the records show
Numbers we can stand behind, and how we know each one
Every figure here comes from attendance records, live polls or anonymous evaluations. Each says what it rests on. A seat is one person attending one session, so seats are not people.
- More than1,200participant seats
- More than600people
- 4.7 out of 5for facilitator expertise
- 4.3 out of 5for the session overall
How we know: attendance counts for 11 of the 12 sessions add up to 1,235. The count for the very first session was not recorded and is left out. Seats are attendances, not people.
How we know: at least 603 different people appear in the attendee lists we hold, which cover 8 of the 12 sessions. The true figure is higher.
How we know: more than 260 anonymous evaluations, scored 1 to 5.
How we know: the same evaluations. Most of them (207) came from the first topic, so later topics rest on small samples.
Smaller samples, stated as counts
- After one activity in the second topic, 66 of 76 respondents said they were ready or nearly ready to design an AI use case of their own.
- Asked how likely they were to apply the session within two weeks, respondents in the later three topics averaged between 4.1 and 4.3 out of 5 (25 to 34 responses per topic).
- In each topic that asked, a hands-on activity topped the “most useful” poll. In the final topic, 8 of 13 respondents named the verification lab.
Clear about what we measured, and about what we did not.
11 · What we cannot claim
What these numbers do not say
- Certification. The company tracked it. We hold no attainment data, so we claim none.
- Financial return. No cost or time saving was measured for the programme as a whole.
- Before and after skill. The polls were not the same people answering the same question twice, so we do not present them as one.
- App usage. Not instrumented.
- Individual savings. The one time figure in this case study is a single builder’s own estimate.
“I started with rudimentary AI knowledge and now I feel competent building agents and skills.”
“I really liked that you were not overly hyping AI but starting with realistic baby steps.”
A pilot with ten people can measure what a programme for 1,400 could not.
Part 6 of 7
What we learned
12 · Three lessons
What did not work as planned
-
A commitment is not a habit.
At the second topic we asked how the small commitment from the first had gone. Of 169 respondents, 94 had not started and 40 had tried it properly.
What followed: the third and fourth topics each put a working app in people’s hands during the session.
-
Attendance and time in the room fell as the topics went on.
Seats fell from 458 in the second topic to 264 and then 191, and one late session had 43 people. The first topic is left out of that seat comparison because one session’s count was not recorded. Typical time in the session was 104 to 111 minutes in the first topic and 51 to 57 minutes in the third.
What we take from it: the sources do not show why attendance and time fell. Small, role-specific cohorts are a design choice for the pilot, not something these numbers prove.
-
Feedback asked for afterwards dries up.
Evaluations fell from 207 in the first topic to 34 in the second and 27 in the fourth.
What we take from it: build the measure into the session.
More from the written feedback (paraphrased)
- In the second topic the demos moved too fast for people who lacked the tool basics.
- In the third, the core idea needed more grounding before people applied it.
- Mixed skill levels in one room came up repeatedly.
- Generic examples did not land. Examples from people’s own roles did.
- Of the 603 people we can trace across the first three topics, 325 came to one topic, 210 to two and 68 to all three.
Every one of these points the same way: small, specific, and built in the room.
13 · What changed along the way
The plan moved along the way.
- The scope. The written scope reached its third version by mid April.
- The ambassador track. Designed, then overtaken by a change in the company’s own plans. In June we proposed redirecting the same time to where it would be used.
- The verification lab. Simplified two days before its first session: one stage cut as too abstract, the examples tightened.
- The closing game. Swapped in late for a different live exercise. Only 1 of 13 respondents later named it the most useful part.
- Show and tell. Planned as eight 90-minute sessions. Run as 30-minute sessions, twice a month.
Most of the changes made things shorter, simpler or closer to real work.
Part 7 of 7
What this means for a Total Rewards pilot
14 · From that programme to your team
The lessons point at the pilot we discussed
You do not need the programme. You need the part of it that worked, sized for about ten people.
What we learned there: Attendance and time in the room fell as the topics went on
So, for the pilot: About ten people from one team, one to two hours a week, for three to four weeks.
What we learned there: Generic examples did not land
So, for the pilot: One theme, chosen by you, from your team’s real work. A short discovery first, so an outsider can test the choice.
What we learned there: A commitment is not a habit
So, for the pilot: One or two sessions with homework between, with me on hand, and no session without a real application.
What we learned there: Feedback afterwards dries up
So, for the pilot: The measure is built in: the pilot ends with one agent or workflow up and running.
What we learned there: The build closest to your world lived inside a tool the company already had
So, for the pilot: Built where your team already works, with your tools and timing mapped in discovery.
- Short discovery
- Sessions on one theme
- Homework, with support
- One workflow live
- Review, then decide on a wider group
The employee builds in this case study were made in an AI assistant that may differ from the one your team uses. The method carries over. What your own tools can and cannot do is one of the first things discovery checks, so we promise nothing here that we have not tested there.
Ten people, one theme, one thing live at the end.
15 · Next steps
Three steps from here
You: pick the one theme or use case you think would matter most to your team.
Me: a couple of discovery prompts your team can run beforehand, so everyone arrives prepared.
Together: a follow-up call within the month, ideally with the leaders who need to be part of the decision, to talk through the pilot.