M&S Help Hub

Transforming how 65,000 colleagues find help, from fragmented support channels to a single intelligent experience

Executive Summary

Before Help Hub, there was no single place for M&S store colleagues to find support.

Depending on the problem, colleagues could be faced with around 20 different Microsoft Forms, third-party ticketing platforms or, increasingly, the fastest option: bypassing the formal process entirely and contacting someone they knew in the support centre.

That created problems on both sides.

Colleagues had no reliable way to know where to go, how long a resolution would take or whether their issue was being formally tracked. Support teams received requests through multiple channels, making it difficult to understand the scale and themes of problems. People were also spending significant amounts of time responding directly to repetitive issues that could potentially have been resolved elsewhere.

Help Hub was conceived as a single source for help and support for all 65,000 M&S colleagues.

I led the colleague experience and strategic UX direction, working closely with Product and Engineering to shape the journeys, research the needs of colleagues and determine how the platform should evolve.

The product combined two capabilities: a single route for raising support issues and an AI-powered Help Agent that allowed colleagues to ask questions about M&S's One Best Way guidance rather than searching through more than 100 hours of operational documentation.

The project was one of the most significant D&T launches at M&S in recent years. It was also delayed by nine months following a major cyber attack.

Rather than stopping completely, I used the disruption to continue progressing the colleague strategy, research and validation. When development resumed, we had stronger evidence, clearer priorities and a simplified first-phase proposition.

The eventual launch was phased across regions, reaching approximately 3,000–4,000 colleagues per launch. On launch day, the platform generated 835 sessions, 72 support tickets and 573 Help Agent interactions.

More importantly, it established a new model for colleague support: one place to ask for help, access organisational knowledge and, when necessary, get an issue to the right team.

The Problem Wasn't Finding Help. It Was Getting Help.

The original problem appeared straightforward:

Colleagues needed somewhere to raise support issues.

The reality was considerably more complicated.

There was no central support destination. Colleagues navigated a fragmented collection of Microsoft Forms, third-party ticketing platforms and informal routes into the support centre.

The exact number of formal routes was difficult to establish because the ecosystem had evolved over time, but the estimate was around 20.

And there was another route that was often more effective:

Knowing someone.

If a colleague knew somebody in the support centre who could help, they could simply contact them directly.

For the colleague, this could be faster.

For M&S, it was creating a significant organisational problem.

Support staff were being interrupted with simple, repetitive queries. Issues weren't consistently recorded, meaning there was no reliable picture of what colleagues were struggling with. Without that information, M&S couldn't easily identify recurring problems and address them at source.

The formal support infrastructure existed.

It simply wasn't working as a coherent service.

Creating One Front Door

The initial vision for Help Hub was deliberately simple:

One source for help and support.

Every store colleague and manager should have a clear place to go when they needed assistance.

But simplicity for the colleague meant complexity behind the scenes.

The platform needed to understand what a colleague needed, collect enough information to make the issue actionable and route it to the appropriate support team.

At the same time, we wanted to reduce the number of issues reaching those teams in the first place.

That created a longer-term ambition:

If we could understand the themes behind support requests and make existing knowledge easier to access, we could prevent some problems from becoming tickets at all.

The platform therefore needed to evolve from a ticketing tool into something much more useful.

Designing Around the Colleague's Reality

We spent regular periods in stores in the Manchester region where the product was being piloted.

We didn't simply interview colleagues about how they wanted support to work.

We used the product ourselves during shifts.

When we encountered something we didn't know how to do, we experienced the process of finding help first-hand.

This reinforced the most important requirement:

Speed mattered.

Colleagues understood why M&S needed a formal support process and were willing to use it, but they had limited patience for anything that was slower than their existing informal routes.

The message was effectively:

Give me a quick way to raise the issue, then get me an answer as quickly as possible.

That became a fundamental design constraint.

A theoretically perfect support journey would fail if colleagues simply returned to their existing sources because the new one was too slow.

Making the Support Journey Work

We interviewed support centre teams and their managers to understand which teams were responsible for different categories of problems and what information they needed to resolve them.

This created an important design tension.

We needed to ask colleagues enough information to help support teams resolve issues quickly, without turning the process into another long form.

We therefore looked for the point of balance between:

Speed of submission

and

Quality of information

The initial experience asked colleagues to categorise their own issue before describing the problem.

Research led us to simplify the categories, improve the language and reduce the amount of information required before submitting a ticket.

We also introduced feedback and escalation routes so colleagues had a clearer understanding of what happened after raising an issue.

The result was a deliberate compromise:

Make raising an issue as quick as possible while collecting enough information for the support team to act.

The Cyber Attack

The Help Hub was already in its early foundation stages when M&S experienced a major cyber attack.

Development stopped.

Contractors were removed.

The launch was ultimately delayed by nine months.

The circumstances meant that continuing development in the traditional sense wasn't possible. But that didn't mean the product had to stop progressing.

A Product Manager remained involved part-time while working on the recovery stream. A researcher and I continued developing the colleague strategy.

We used the unexpected time to test more rigorously, explore alternative journeys and challenge assumptions before development resumed.

It also gave us the opportunity to simplify the proposition.

The original ambition was to integrate AI deeply into the support-ticket journey, allowing the system to understand an issue before deciding whether a ticket needed to be created.

Given the time available and the requirements of the eventual launch, we separated the two capabilities for the first phase:

Help colleagues raise an issue.

Help colleagues find an answer.

The deeper integration could follow.

The experience reinforced something I have found repeatedly in product leadership: when circumstances change, progress doesn't necessarily have to stop. Sometimes the most valuable progress during a delivery pause happens away from the code.

Turning 100+ Hours of Knowledge Into a Conversation

The second half of Help Hub addressed a different problem.

M&S has a huge amount of operational knowledge contained within The M&S Way—the documentation describing how stores should operate, how tasks should be performed and what colleagues should do in different situations.

The information was accessible.

The problem was finding an answer within it.

There were more than 100 hours of content to read.

A colleague with a specific question could theoretically find the answer, but doing so required time they often didn't have.

We saw an opportunity for AI to change that interaction completely.

Instead of asking colleagues to navigate a vast knowledge base, we could allow them to ask a question in natural language.

"What do I do if...?"

"How should I handle...?"

"What's the M&S way of doing this?"

The Help Agent could then retrieve an answer from the approved knowledge base.

Designing Trust Into AI

The biggest challenge wasn't making the AI answer questions.

It was making sure it answered them safely and accurately.

The Help Agent was deliberately constrained to trusted sources, principally The M&S Way and, where appropriate, existing solved support tickets.

We rigorously tested the system by bombarding it with questions and cross-referencing its answers against the underlying documentation.

We also tested it in stores, using real situations colleagues encountered.

One important discovery was that we couldn't simply assume colleagues would provide enough information.

People naturally wanted to speak their question aloud in a sentence, but when typing they often entered a very short, basic version of what they wanted to know.

The UX therefore had to encourage enough context for the AI to identify the right answer.

When the system couldn't confidently answer, it could ask for additional information or help the colleague raise a support issue rather than presenting an uncertain answer as fact.

This was particularly important for sensitive operational areas where incorrect guidance could have serious consequences, such as food safety.

Designing for How People Actually Use AI

The most interesting discovery wasn't about the technology.

It was about behaviour.

People wanted to use the AI.

They understood the value of being able to ask a question rather than search through documentation.

But they didn't necessarily interact with it in the way we expected.

This meant the design problem wasn't simply:

"How do we build an AI chat?"

It was:

"How do we help a colleague express enough of their problem for AI to help them?"

That distinction influenced the structure, prompting and interaction model.

For the first phase, the AI was deliberately visible as a distinct feature on the Help Hub homepage. The longer-term ambition was more integrated: AI would increasingly work in the background, identifying opportunities to help before a colleague needed to raise a ticket.

Leading Across a Complex Organisation

Help Hub required alignment across Digital & Technology, Stores and multiple support functions.

The stakeholder group included senior leaders including the Chief Digital & Technology Officer, Food Director, Fashion, Home & Beauty Director and Director of Central Operations.

The expectations were high.

The AI element in particular created understandable concerns about hallucinations and the potential consequences of incorrect information.

Our response was evidence rather than reassurance.

We tested.

We cross-referenced.

We took the product into stores.

We used real colleague questions.

We challenged the answers.

As colleagues began responding positively to the AI, stakeholder confidence increased.

The same principle applied to the support journey.

Rather than arguing that the new model would work, we created a controlled regional pilot that allowed M&S to understand the operational implications, including ticket volumes, resolution times and support capacity.

Launching at Scale Without Losing Control

The eventual launch was phased across regions rather than released to all 65,000 colleagues simultaneously.

Each regional launch provided a controlled environment in which usage and support capacity could be monitored.

On launch day:

835 Help Hub app sessions

72 Support tickets submitted

573 Help Agent messages

Usage peaked at 9am, reflecting the operational rhythm of store colleagues.

88% of sessions came through Teams/IRIS, confirming that the product was being accessed through the channels colleagues already used.

The platform recorded 1,214 sessions during the preceding seven days, with 825 occurring on launch day.

The most frequently submitted ticket category was Product Availability in Food.

Knowledge at Scale

The AI experience also demonstrated significant demand for the underlying M&S Way content.

The documentation averaged:

49 visits per hour

with a peak observed rate of:

104 visits per hour

The highest recorded day generated:

5,264 page views

This reinforced the underlying premise of the product.

Colleagues had a genuine need for operational knowledge.

The opportunity was to make that knowledge considerably easier to access.

What Changed

Help Hub changed more than where colleagues raised tickets.

It began changing the behaviour around support.

Previously:

"I need help. Who do I know that can help me?"

The new model became:

"I need help. Help me solve it."

Support teams became more organised and began receiving issues through a more structured route.

M&S gained a centralised view of the problems colleagues were experiencing.

The M&S Way gained greater visibility—and the product also exposed places where the documentation itself needed improvement.

The AI experience demonstrated a practical purpose for AI within colleague products.

Other product teams subsequently began pointing colleagues towards Help Hub for support, while some began integrating Help Hub into their own products as a source of resolution when something went wrong.

The platform was becoming part of the wider colleague product ecosystem rather than remaining a standalone support destination.

Reflection

The Help Hub started as a ticketing tool for collecting issues.

The real problem was what happened afterwards: how long those issues took to resolve, who received them and whether M&S could learn from the problems colleagues were experiencing.

The most difficult product decision was how to balance simplicity for colleagues with enough information to enable fast resolution.

The most interesting thing about the AI wasn't how it worked.

It was how people interacted with it.

The project also reinforced something important about leadership during disruption.

The cyber attack understandably changed priorities and stopped development for nine months. But it didn't have to stop progress.

We used the time to research more deeply, challenge assumptions and simplify the proposition before development resumed.

I'm proudest that we continued to operate strategically when the circumstances around us had changed completely.

My contribution was creating the foundations of the platform: defining the colleague experience, shaping the journeys, establishing the UX writing and tone of voice, challenging how AI should be integrated and working with Product and Engineering to find the balance between colleague needs, technical reality and business requirements.

The next evolution is clear.

AI should increasingly become part of the support experience rather than a separate destination—helping colleagues understand and resolve an issue before they ever need to raise a ticket.

The ultimate measure of success isn't how many tickets Help Hub can process.

It's how many problems colleagues can solve without needing to raise one.