The bigger picture

BT International was moving away from running its own cloud platforms and towards partner delivered cloud services. In this model BT owns the customer relationship and resells the service, and a supplier provides the platform underneath.

CMS, short for Compute Management System, sat between BT's private cloud customers and the supplier, Rackspace. On the surface it was a login portal. Underneath, it applied BT's pricing, discounts and service identifiers on top of the supplier's costs, which is what made the reseller model work. It cost around £1.3m a year to run. The plan was to close it and give customers direct access to the supplier's platform, without them losing anything.

How I got involved

My manager asked me to support the programme lead on the migration. That was all the context I had. My first calls were deeply technical and full of jargon, and nobody on the programme had worked with a service designer before.

So I went back over the call recordings and transcripts until I understood the basics, and spent time with the senior cloud manager to learn the space properly. Then I made sure the key stakeholders had answered my opportunity shaping questions, and used their answers to write down the things nobody had agreed yet:

• a problem statement
• why the migration was necessary
• the customer outcome and the business outcome
• what the programme needed from service design
• what was in scope, and what was not

The real problem

The supplier had sent a Statement of Work, and from their side the change looked simple. Inside BT, people knew it was not simple, but nobody could say exactly why. The programme lead was not confident enough to sign, and one target date had already slipped.

What I proposed

I told the programme that service design could help by building one shared picture of the service:

1. Map the AS IS with every dependency. If CMS is removed, what depends on it, across the customer, the front stage and every back stage team?
2. Name an owner for each dependency, so every gap had someone to answer it.
3. Design the TO BE together, retire CMS step by step, and take the full picture to the supplier.

The programme lead liked the idea, and we started.

What the AS IS showed

I mapped what customers actually did and all the back stage work behind it, pulling evidence from Product Line, Account Teams, Contract Managers, operations, engineering, finance, billing, support and the supplier. As the map grew, the team grew more confident, because for the first time everyone could see what was really happening.

The "login portal" turned out to be the commercial backbone of the service. It also acted as BT's billing engine, which nobody had planned for. It held BT pricing, the service identifier that linked customer, service and billing, and invoice visibility for Account Teams. None of that was in the Statement of Work, so I made sure those gaps were logged and escalated before anyone signed.

Bringing the supplier into the room

With an owner named for every question, we brought the supplier in and walked them through how the service really worked. It was clear quickly that this was not a simple switch off. They had questions of their own, and over many workshops with the supplier and BT's own teams we found a solution or an alternative for every dependency, so CMS could be retired safely.

1. Ran a 90 minute validation workshop. It was the first time all the stakeholders had been in one room, and it surfaced 12 new findings.
2. Worked out a new way to process billing once CMS was gone, so customers' invoices stayed exactly the same.
3. Designed a handoff where engineering confirms billing was updated, so it was proven rather than assumed.
4. Defined migration success as usable access, not an invitation sent: registered, signed in, correct account visible, right role, no critical issue open.
5. Ran a strategic TO BE walkthrough with Product Line leadership, and an operational one where teams challenged anything they could not actually do.

A simplified version of how I kept evidence, assumptions, risks and decisions apart. The real register held 21 items across the journey stages, each with a named owner.

Decisions and trade offs

• Future reseller and new customer design went to a parking lot, so undefined work could not block closure.
• Migration ran in controlled batches, with access evidence before each batch.
• Losing the BT branded entry point was accepted as a documented, non blocking trade off.

Outcome

Once the AS IS was validated, the programme felt confident enough to sign the Statement of Work. We moved every customer to direct supplier access, the new billing outputs matched the old ones so invoices were not affected, and the programme formally closed.

When I asked for feedback, all five stakeholders gave me 5 out of 5 for challenging assumptions and unclear ownership.

What stakeholders said

Summarised from written feedback, with names removed.

What I learnt

• Shared understanding and alignment across teams is what sped the work up. Once everyone could see the same map, we spent less time explaining and more time deciding.
• A platform is part of a service. Switching it off does not switch off the pricing, billing and responsibilities that run through it.

The problem

Global Fabric is BT International's new global connectivity product, and a strategic one. It is still evolving, so the product was being built and sold at the same time.

It was designed for customers buying one site and one configuration at a time. Sales teams quoting large managed customers needed prices for 20 to 30 sites at once, sometimes more. No tool existed for that, so specialists stitched quotes together across several systems, and it took days. The sales team was struggling, and the people building the product could not easily see what sales actually needed, because nobody had visualised the process.

Engineering had started building a quoting solution on its own assumptions, and most reviews ended in disagreement or rework.

After talking to sales, pricing and engineering, I wrote the problem down in one place so everyone could agree on it:

There is no tool within Global Fabric that supports multi site access pricing. The product can only price one site and one configuration at a time, but our customers often ask for bids covering many sites at once. Without bulk pricing, sales responses are slower and less competitive.

My problem statement, shortened

What the mapping showed

I mapped how sales specialists, pricing and quoting teams really worked, from the pricing tool to getting access prices, including the back stage steps nobody saw. Four places stood out where the journey broke down.

One thing jumped out of the data. About 80% of access price requests were for a 36 month term, yet users couldn't search by term. I raised it, along with partial download, which users told us was a must have.

What I did

My first job was to understand the problem from the sales side, then make it visible so everyone could see the same thing.

1. Built an Excel prototype and a portal prototype, so everyone could see what sales needed, and tested both with sales specialists.
2. Compared their feedback against the original business goals, not just user preference.
3. Ran working sessions with engineering, walking through the flow and the reasoning, and acted as the bridge until Product and Engineering aligned directly.
4. Facilitated an alignment session with Product, Pricing and Sales, and walked new sales specialists through the planned journey.
5. Took each issue I found to the right Product Owner and handed it over, so it became a ticket in their backlog rather than staying on the map.

Outcome

• Reviews moved from stalled and disagreement heavy to a shared, validated design both sides trusted.
• The design was confirmed against user and business need before build, which avoided rework.
• Stakeholders reported that several issues I raised were fixed, and that everyone now shared an understanding of a very complex process.
• The work helped de risk a Global Fabric revenue pipeline worth around £1bn.

What colleagues said

Summarised from written feedback in my quarterly reviews, with names removed.

What I learnt

A design that users like isn't enough on its own. I now test every design against the business goal too, because something people like can still miss the outcome.

The problem

I worked in the setup and onboarding squad of BT Enterprise's High Volume Journey programme, which aimed to make it easier for small and home office customers to do business with BT. BT sent these customers routers and extra devices, but many never got plugged in. The business put the cost of that unused equipment at around £5m a year and set a goal to bring it down.

Finding out why

With the Product Manager, I went through NPS comments, customer calls, chats and bot conversations, help page behaviour and analytics, and then ran interviews. The answer was simple: customers did not understand what the devices were for, so they did not bother setting them up.

The interviews also showed me things nobody had planned for:

• Customers formed a view of a product from its pictures and headlines, then read everything else to fit that first impression, even when it was wrong.
• Even in firms of 1 to 10 people, the person who ordered was often not the person who set things up, so we could not assume the installer knew anything about the order.
• Product names and language were not consistent across devices, which left customers guessing what each one did.

Seeing the whole journey

Instead of only fixing the setup page, I mapped everything a customer saw: the order call, emails, order tracking, the box, the setup pages, the app and the website. I built personas and scenarios to show how different customers moved through it, and AS IS and TO BE journey maps to agree what should change.

What we changed

1. Order tracking. The tracker was one of the most visited pages, but it told customers nothing about what they were receiving. I reframed it as a chance to explain each device and why it mattered, and improved tracking for appointment days, engineer status and supplier delays.
2. Order emails, so customers knew what happens next.
3. The box. I led user testing of box guides, installation instructions and benefit messaging, and A/B tested new designs against the existing ones. The result was clearer benefits printed inside and outside the box, with plain statements and no marketing language.
4. Setup pages, redesigned so customers could fix problems themselves.
5. Product names. I challenged confusing names and marketing language wherever they stopped customers understanding what a device was for.

Highlighted touchpoints are the ones my work changed.

Outcome

This work was part of an initiative aimed at reducing around £5m a year of unused equipment. The more customers set up their devices, the fewer setup calls reach the service desk, and the better the experience is for the customer.

What I learnt

A setup problem is rarely just a setup page problem. Here the fix was spread across the emails, the tracker, the box and the setup pages.