Supplier onboarding was fragmented across siloed teams, with little visibility as work passed from one department to another.
Suppliers could not see how long onboarding might take or understand everything required from them at the outset. Internally, much of the process was manual, spread across emails, documents and spreadsheets, and progress was not consistently tracked. My brief was to understand the end-to-end service, expose the gaps between handoffs and define an evidence-led direction for a more coherent onboarding system.
After many partner and user interviews, part of my process was to capture the onboarding steps in a working Excel spreadsheet. I then organised and compared the different onboarding paths, which informed the final service blueprint shown later in the case study.
Working Excel spreadsheet
The initial spreadsheet recorded and compared onboarding paths before the full service process was understood.

Improved process comparison
The next iteration organised the process into shared phases, clarified ownership and made the different onboarding paths easier to compare.

The gaps lived between teams.
No single team held the complete picture of how a supplier moved from introduction to becoming operational.
In some cases, what was flagged as a usability issue was actually a service-level problem: unclear ownership, scattered information, duplicated effort and weak visibility of progress.
Ownership was difficult to see
People did not always know who held the next action or where a supplier was in the process.
Documents lived in too many places
Agreements, evidence and supplier information moved through email, shared drives and separate tools.
Work was repeated
Teams could request, check or enter the same information at different stages.
Suppliers lacked progress visibility
They had limited guidance on what was required, what had happened and what came next.
My first port of call was the internal teams. It became a daisy chain: just when I thought I had reached the final department, they referred me to another. In total, I spoke with seven departments, not counting the individual team members involved.
Map teams and responsibilities
Capture supplier and colleague experience
Synthesise pain points and opportunities
The research clarified the different responsibilities, needs and outcomes across four central user groups.


The most useful shift was to stop treating each complaint as an isolated issue.
The synthesis connected business, people, process and system pain points. It showed that the opportunity was not a patchwork of local fixes, but a more systematic service with clearer ownership, shared information and visible progress.

The final service blueprint became the shared view of the work: frontstage activity, internal actions, systems, handoffs, pain points and opportunities across the onboarding journey.
The public version retains the scale and structure of the original work while keeping identifiable colleagues, internal links and sensitive operational detail out of view.
From a collection of steps to a guided service.
One shared view of progress
Give suppliers and internal teams a consistent understanding of status, ownership and next actions.
Requirements in context
Explain why information is needed, who needs it and how it affects the journey.
Documents connected to tasks
Keep agreements, evidence and approvals close to the work they support.
Different roles, one service
Support distinct responsibilities without creating disconnected versions of the truth.
The complete supplier-onboarding process map.
The final map brought the full journey into one shared view, including teams, supplier touchpoints, internal tasks, handoffs, pain points and opportunities from registration through due diligence and setup.
The research and recommendations became the foundation for a new supplier-onboarding system, which a subsequent design team was commissioned to develop.
My contribution was the research, shared service model and design direction that made the next phase possible. I do not claim ownership of the later team’s implementation.
This case study uses selected, anonymised project artefacts. Identifiable colleague details, internal links and sensitive operational information have been removed or kept below reading size.


