← Back to work
Service Design Research

Secret Escapes

Virtual card payment service

Designed a virtual card payments service, increasing the company’s cash flow and profit.

On this project, I was leading all research and service design activities to help deliver a new payment flow between Secret Escapes and all their hotel partners. Building this virtual card payment service was part of a revenue management initiative, involving several functions of the business — tech, product, finance, and sales. The goal was to enable faster payments and additional generated revenue from rebates.

Service Designer, UX Researcher

  • Phase one — build a PoC
  • Phase two — all suppliers are paid via virtual cards
  • 0% opt-out rate on the new payment process

All suppliers are subscribed to the new payment service with an opt-out rate of 0%.

  • Facilitating an Event Storming workshop
  • Applying my Service Design knowledge into practice
  • Utilising a goal-setting framework OKRs (Objective and key results) to deliver value both to the service user and the business
  • Research: gathering domain knowledge
  • Planning
  • Discovery
  • Delivery
  • Feedback
  • Service events flow
  • User task flows
  • Email designs
  • CMS designs
  • Service blueprint map
100%
Adomption of the service
£1M
Made in rebates by lauching the service.
SUVC1

SUVC2

SUVC3

SUVC10
01
Runnung an Event Storming workshop

Extremely valuable as it cleared risks early and set the foundations of our PoC.

02
Running stakeholder interviews

This was key to help the team uncover further scenarios we needed to cater for and have minimal disruption of current processes.

03
Last minute re-prioritisation

Capturing feedback from our partners and different teams involved, helpes us prioritise the most critical friction points towards the end of the project.

1. Gathering domain knowledge, aligning & visualising

To kick off the initiative I chose to run an Event Storming workshop, originating from the context of domain-driven design. The product manager, team lead and myself considered this type of workshop fit for the initiative due to the project's underlying complexities and multiple business functions involved. The format allows for those complexities to come to surface early as well as to align the different domain experts and enable them to learn about the service together, with each bringing their own expertise to the table.

SUVC2

2. Roadmap planning for the PoC

After having aligned the domain experts on the ideal events flow of the service, as a cross functional team, we were able to make a decision on how to break down the work for the PoC build and the chunks of work were put into the delivery backlog.

3. Discovery

After we had a clear view of the technical work required for the PoC, the product manager and myself started planning the discovery work and prioritised it in alignment with delivery. The Event Storming workshop we ran as a kick off uncovered the complex areas which was our cue of where we need to do further investigation and ideate on potential solutions. Cancellations and refunds were two key areas holding unknowns and complexities. Interviewing members of the customer service team and finance helped us understand the multiple work streams that were in place in order to make customer refunds and cancellation possible. We were able to identify the key user needs and make sure those are met with the implementation of the new service. Some of the design solutions proposed fitted the existing user flow, the ones that didn't were usability tested and iterated upon before the build.

SUVC11

SUVC12

4. Delivery

Working with the engineers in two work streams — current and future. For the current work I was involved in the delivery process by doing design reviews of the solution implementation before release. For the discovery future work stream, I would communicate and collaborate with the developers to explore the problem space and potential solution as well as understand the technical limitations.

SUVC6

5. Feedback

After PoC was live for a limited number of users, we were able to gather feedback on how the service is performing and identify pain points. To communicate the severity of the issues, their position in the service and correlation with the initiative's objective, I used a service blueprint created and validated with the domain experts. The blueprint clearly pointed out to the areas that required iteration, which helped the stakeholders agree on prioritising the work.

SUVC2

SUVC4