Designing the alignment that made a stalled transformation move

Different teams held different pieces of it. The B2B workstream knew the partner requirements. The B2C workstream knew the consumer journey. Engineering knew what Salesforce would and wouldn't support. Compliance knew what a regulated checkout had to include. Nobody had a complete model of how all of those things connected.

Before I designed anything, that model had to exist.

The customer problems were real. Users lacked confidence in how much currency to buy, and the distinction between a cash order and a travel card top-up was not clearly surfaced. Three Travelex products — the travel money checkout, the Money Card, and the Wire transfer service — had no unified entry point.

The partner problems were equally real. Sainsbury's and others needed a branded FX experience that felt like their own — requiring promotional flexibility, account management integration, and margin control.

Both problems were understood individually. The relationship between them — how partner configuration decisions shaped what consumers experienced — was not mapped anywhere.

I then held conversations with the Global Head of Channel, who led the B2B workstream, and the Head of Direct Consumer Channels, who led the B2C side. My objective was not just to gather requirements — it was to understand where the two teams' understanding of the problem diverged. The divergence turned out to be significant. What the B2B workstream needed to solve for its partners was not always compatible with what the B2C workstream had designed for its consumers, and neither had a clear framework for resolving those conflicts.

I also needed to understand what was fixed. Salesforce Commerce Cloud's SFRA architecture was the platform — partner customisation had to work within its skinning and configuration model, not through bespoke code. Compliance requirements were equally fixed: KYC checks on all first-time customers, sanctions checks at order submission, document upload requirements as a fallback for KYC exceptions, and 3D Secure payment authorisation. These were mainstream journeys that had to be designed from the start, not deferred.

There was no research budget. User testing was eliminated by COVID-19. I worked within those constraints by using internal staff unfamiliar with the product as a proxy for non-digital users, and by designing a post-launch A/B testing framework that would allow the programme to learn from real customer behaviour after deployment.

No document mapped how a currency order moved through the full journey — from a customer researching their travel destination, through product selection, checkout, payment, KYC, and fulfilment — while simultaneously mapping what that journey required from a retail partner, and what Travelex had to operate underneath. Without that document, any prioritisation decision or scope conversation was operating without a shared frame of reference.

I created the first draft of what became the Oreo B2B2C Service Blueprint.

The blueprint mapped three distinct journeys across the same end-to-end experience. The customer journey tracked what users experienced, needed, and felt at each stage — with emotional state tracked alongside actions, because a financial transaction is not a neutral experience. The partner configuration layer mapped what a retail partner like Sainsbury's needed to control: branding, promotional content, margin settings, account management. The Travelex operational layer mapped what the business had to operate underneath — fulfilment routing, compliance, product inventory, and the handoffs between internal teams.

The three-layer structure was a deliberate choice. Building separate documents would have preserved the silos. Building one document that placed all three layers in relationship to each other made visible what had previously been held separately — where partner decisions affected consumer experience, and where Travelex operational constraints shaped what partners could offer.

I validated the first draft with the Head of Product. It then went through working sessions with the wider programme team — B2B, B2C, engineering, and operational leads. The version that became the working reference across the programme was V1.1.

What changed when the blueprint existed was the quality of the conversations. Before it, scope discussions were abstract — teams were debating requirements without a shared map of where those requirements sat in the overall system. With the blueprint in the room, disagreements became locatable. A question about account login could be pointed to a specific stage in the customer journey and a specific configuration requirement in the partner layer. Decisions that had been stuck became unstuck — not because the blueprint resolved the disagreement, but because it gave the disagreement a precise location.

The Global Transformation Director reviewed the blueprint and used it to anchor subsequent programme decisions. It remained the working reference for the duration of the project.

Sequencing by impact was a deliberate product decision. The most significant risk was spending engineering effort on a part of the journey that customers never reached because an earlier step had already lost them.

Within each sprint, I used wireframes not as finished designs but as hypothesis surfaces — artefacts that made assumptions explicit so that engineers, product managers, and stakeholders could challenge them before they became engineering commitments. An assumption uncovered at wireframe stage is almost free to correct. The same assumption discovered after a Salesforce sprint has already been built and paid for.

Each sprint also required compliance validation. KYC checks on first-time customers, document upload requirements as a fallback, sanctions checks, 3D Secure payment authorisation, and the design implications of customers entering an 'under review' state — these weren't decisions to defer. They were decisions that shaped the checkout flow at every step, validated with the compliance team and Salesforce engineers at each sprint stage.

SFRA's architecture shaped every design decision. The platform determines what partners can configure versus what is fixed in the shared checkout engine. Designing within multitenancy constraints meant making decisions at the system level, not just the screen level.

The platform strategy was built on a clear premise: solve the problem for Sainsbury's first, and you solve it for most other partners.

Sainsbury's was Travelex's largest B2B partner. Their scale, their brand standards, their customer base, and their operational requirements were representative of what other major retail partners would need. Getting it right with Sainsbury's would validate the platform model at the level of complexity that mattered.

I held sessions with Sainsbury's stakeholders focused on understanding what a branded FX experience needed to do for their customers that the generic Travelex checkout did not. The most significant findings were around two areas. The first was promotional flexibility: Sainsbury's needed to surface their own promotional content and loyalty-adjacent messaging within the checkout flow. The second was customer account management: the login and account recognition journey needed to feel like a Sainsbury's experience — using their authentication patterns and their account model — rather than a Travelex one overlaid with a different brand skin.

These findings were not separate from the service blueprint. They were fed back into it. The partner configuration layer — what a partner could control, what they could customise, and what remained fixed — became more specific as a result of those conversations. The blueprint iterated to reflect what the partner sessions had added.

The A/B testing framework I designed for post-launch validation was developed with Sainsbury's stakeholders as collaborators, not simply as recipients. The specific hypotheses we agreed — including where to position the account login step relative to order fulfilment — were shaped by their understanding of how their customers shopped.

What the workshop consolidated was the output of everything that had come before: the service blueprint findings, the UX audit, the partner sessions, the technical discovery, the compliance requirements. What it produced was a shared, agreed scope for Phase 3 that each function had contributed to and could stand behind.

The Must Have requirements that emerged — partner branding configuration, margin control at the product and delivery type level, customer account integration, basic promotional content display — went directly into the sprint delivery plan.

The Sainsbury's entry module was the first proof of the model in practice.

At sainsburys.co.uk/money, with Sainsbury's orange branding applied to the Travelex checkout infrastructure, step one of a five-step journey asked a question that the original travelex.co.uk checkout had never surfaced directly: how would you like your travel money?

Three options: Cash, Card, or Both. That selector resolved the core confusion problem identified in the UX audit. Customers arriving at a currency checkout frequently didn't know which Travelex product they needed. The existing experience required them to arrive already knowing. The product type selector surfaced the distinction clearly at the point of entry, and gave customers a decision they could make rather than a taxonomy they had to decode.

Destination-based spend guidance addressed the confidence problem — customers had no reliable reference for how much currency to buy for a specific trip. A guaranteed buy-back option, surfaced at entry rather than at the end of the order, addressed the risk anxiety specific to currency purchases. Trust signals were embedded at the stages of the journey where the service blueprint had identified emotional state was lowest — not as static footer badges, but at the points where a customer was being asked to do something that felt risky.

What the platform design preserved was the boundary between what Sainsbury's controlled and what Travelex operated. Sainsbury's controlled their branding, their promotional content, their margin settings by currency and delivery type, and their account management integration. Travelex controlled the checkout engine, the compliance layer, the fulfilment logic, and the product taxonomy. That boundary was a design decision as much as a technical one, and it had to be agreed before a single screen was finalised.

I left the programme before deployment to live customers. Post-launch conversion data was not available to me. The A/B testing framework was designed to capture the learning I knew I wouldn't be there to see.