Whitbread Expands Microsoft 365 Copilot to 1,650 Staff With AI Agent Governance

Even so, the story gives useful detail for any IT department trying to move beyond a small Copilot pilot. It covers pilot numbers, the rollout, a training programme and a process for deciding when a personal AI experiment can become a shared service.

The headline numbers​

Here is what Whitbread says it has done so far:

• Pilot: 270 support-centre staff at head office. They came from commercial, finance, property, procurement, people (HR), technology and other support functions.
• Training programme: a "Digital Heroes" scheme ran from September 2025 to March 2026. It combined Copilot access with training, practical sessions and a community where people shared what worked.
• Reported benefit: participants reported saving an average of 24 minutes a day, based on feedback collected during the pilot.
• Expansion: based on those results, Whitbread is extending Copilot to 1,650 people across its support centre and to multi-site hotel managers.
• Use cases: staff developed more than 60 role-specific use cases across eight functions. They ranged from summarising meetings and finding information to researching questions that might previously have needed an external adviser.

Group CTO Mark Smith explained why staff enthusiasm alone wasn't enough to justify the spend: as a budget hotel business, he said, Whitbread must "justify every pound that we spend."

The fine print: the 24-minute figure is a self-reported average. Microsoft's story doesn't give a baseline, a measurement method or any breakdown by role. It also doesn't say which Copilot licence tier Whitbread uses, when the 1,650-seat rollout will finish, or how many multi-site managers are included. Treat it as a signal, not a benchmark.

An agent that scores potential hotel sites​

The most concrete example comes from Domenica Sabou, Whitbread's Senior Location Strategy and Data Manager. She used Microsoft 365 Copilot to build an agent that assesses how likely a potential new hotel location is to succeed. It combines factors such as driving distances and local amenities, then scores the site. Sabou uses the score as a data-first starting point for her recommendations, instead of instinct or partial evidence.

She is clear that the agent doesn't make the decision. The judgement, she says, "is still coming from you." She also says she is still learning how to prompt the tool, including what not to prompt.

Over about a year of experimenting, Sabou estimates Copilot is cutting her time on this work by at least a third. She describes her approach as a back-and-forth conversation with the AI rather than a single perfect prompt.

What the story doesn't tell us matters just as much:

• which data sources feed the agent
• how the scoring works or how it has been validated
• which builder or connectors were used; Whitbread only says the agent was built "through Copilot"

Whitbread calls it an experiment and an early example of the agent-based direction it wants to take. It is not described as an automated site-selection system, and nothing in the story says it has been deployed across the company.

The governance gate​

For IT admins, this is the most useful part of the story. Whitbread has set up an AI Enablement Office and a governance process for staff who want to take an agent beyond their own work and make it available to others. The review looks at safety, ownership and cost before an experiment becomes a shared service.

Smith sees that process as the basis for wider adoption. Eventually, he says, everyone will have the chance to build an agent. He also wants to keep people involved where it matters most, which for a hotel company means serving guests.

Whitbread doesn't say which Microsoft admin tools, if any, sit behind its process. Microsoft's current documentation does show how this personal-versus-shared split works in Microsoft 365, which gives useful context for admins:

1. Agents start private. After an agent is created in Microsoft 365 Copilot, a confirmation message indicates that the agent is private and only available to you.
2. Sharing with specific people is a separate step. Microsoft describes two separate paths: Share your agent with specific people or groups. You manage the shared agent, including its sharing settings and updates.
3. Organisation-wide publication requires admin approval. Once an agent is submitted to the org catalog, an admin reviews it in the Microsoft 365 admin center and, after they approve, publishes it to the Agent Store under Built by your org. From there, the agent is available as a trusted, organization-approved solution for users across your tenant.
4. Admins can tighten sharing. Microsoft notes that if sharing options are restricted in your organization, an admin must approve and deploy the agent before it's available to other users in the organization.
5. Agent Builder has limits. Microsoft points out that declarative agents built with Copilot Studio are more customizable and feature-rich than agents created with the Microsoft 365 Copilot Agent Builder. Agent Builder also doesn't support authoring actions that connect to external services; those require Copilot Studio.

Admins also have a central place to manage all this. According to Microsoft, agents are managed in the Agent Registry of Microsoft 365 admin center. As part of agent management, you can review agent requests and determine whether to publish the agent to the store or reject the agent submission.

One independent guide, the candede.com blog, puts the lifecycle simply: "Treat shared = dev, catalog = main." The same guide warns that per-user permission filtering inherits existing oversharing, so ground agents in governed sources and label them.

That warning applies directly to a site-scoring agent. If it pulls from a SharePoint library with loose permissions, sharing the agent doesn't create a new data exposure. It can make an existing one much easier to find.

Section summary: Whitbread's review of safety, ownership and cost fits the gates Microsoft now builds into Microsoft 365. Agents start private, can be shared with named people, and need admin approval for the org catalog. The technical controls only work if someone has decided who owns an agent and who pays for it, and that is the part Whitbread says it has formalised.

"Third workforce" and the headcount question​

Emma Cluett, Head of Delivery Transformation in Whitbread's Group Transformation function, gives the most commercially pointed quote. Her team runs large programmes, which means a lot of business cases, executive presentations, meeting organisation and keeping stakeholders aligned. She says the team has kept its headcount "quite static" by using Copilot as "almost our third workforce."

Critics of workplace AI will focus on that phrase. Holding headcount flat isn't the same as cutting jobs, but it does mean AI is absorbing work that might otherwise have gone to new hires. Cluett also says decisions will always need a human sense-check. Smith talks about keeping frontline roles and keeping people involved in guest service. The story doesn't quantify avoided hiring or cost savings, so the "third workforce" idea is her description, not a measured result.

Keeping training current​

The less glamorous lesson may be the most transferable one. Christopher Adams, Business Change Manager in Technology and Data, and Harprit Takkar, Technical Product Specialist for Frontline and AI, have supported the Digital Heroes programme with:

• group sessions and drop-in clinics
• written guidance
• short recap videos
• formal training alongside all of the above

Adams admits the material they used six months ago is already out of date. Any admin who has written a Copilot guide and watched the interface change a few weeks later will recognise that.

Their answer is to give staff a place to ask questions and regular sessions showing new features, rather than leaving people to work it out alone. According to Whitbread, this also surfaces good ideas from the people closest to the work, which is presumably how 60-plus use cases emerged from 270 pilot users.

For the next phase, every colleague will be offered training. Local champions will keep sharing examples relevant to specific jobs. The stated goal is that people know where Copilot can help and where it shouldn't be asked to decide.

What IT teams can take from this​

Here are practical lessons for organisations planning their own Copilot rollout. These are general industry observations, not claims from Whitbread:

• Pilot across many departments. Whitbread's pilot spanned eight functions, which gives a more honest picture of value than a small group of enthusiasts.
• Measure before you expand. Even a self-reported figure like 24 minutes a day gave Whitbread something concrete to take to leadership. A proper baseline would make it stronger.
• Decide who owns and pays for agents before switching on org-wide sharing. Check your Microsoft 365 admin center settings for who can share agents with the whole organisation, and route broader publication through catalog approval.
• Tidy up permissions first. Agents respect each user's existing access, which also means they respect every existing oversharing mistake.
• Plan for training material to go stale within months. Budget for ongoing enablement, not a one-off launch event.

The bottom line​

Whitbread's story is a Microsoft customer case study, so it naturally leaves out failed experiments, costs and staff who didn't like the tool. It still contains useful detail: a 270-person cross-department pilot, a reported 24-minute daily saving that justified expanding to 1,650 seats, a site-scoring agent that still leaves the decision to a person, and a formal review before personal agents become shared services.

As Smith put it, the aim is better-quality work done more productively, delivering value "to our guests and our shareholders."