Coperama: centralised procurement platform for NH Hotels
Case Study · Lead Product Designer

Coperama: Giving 340 Hotels the Buying Power of One.

Client
NH Hotels Group
Scope
B2B Web Platform · 340+ properties
Type
Procurement · Enterprise Dashboard
Tools
Figma · Maze · Confluence · Jira
Scroll
01

When 340 hotels buy alone, nobody wins.

Every NH Hotels property negotiated with suppliers on its own, placed its own orders, and tracked spend in a disconnected spreadsheet. The group had no visibility into what 340 hotels were collectively buying, which meant no leverage with suppliers and no way to spot savings at scale.


The operational cost was just as real. Procurement teams spent an average of 4 days processing a single purchase order, chasing approvals across departments and reconciling invoices against fragmented local budgets.

4 days

Average time to process a single purchase order, before the redesign.

Source: Procurement audit · pre-launch baseline

Discovery workshops with 12 buyer personas across hotel operations, finance, and central procurement mapped the full purchasing journey, from request to approval to delivery, and exposed three failure points: duplicate ordering across properties, zero group-level spend visibility, and supplier management stuck in spreadsheets and email chains.


None of this was a UI problem on its own. It was an information architecture problem wearing a UI costume, and it needed to be solved for three very different users at once.

The insight that changed everything
"This wasn't a purchasing-form problem. It was a visibility problem, disguised as 340 separate ones."

We weren't designing a better order form. We were designing the first shared picture of spend NH Hotels had ever had, without taking away the autonomy each hotel manager needed to run their own property.

02

My role and the north star.

I joined as Lead Product Designer, owning the full lifecycle, from stakeholder mapping and discovery to the design system and engineering handoff, for a B2B platform serving three distinct user types at once: central procurement managers, hotel general managers, and finance teams.

North star metric
Group spend visibility
Every decision measured against whether it made spend legible at group level without blocking property-level speed
Role
Lead Product Designer
End-to-end ownership: discovery → DS → handoff
Platform
B2B Web Platform
Three roles: central procurement, hotel GMs, finance
Scale
340+ properties
Phased onboarding across the NH Hotels group
Timeline
6–12 months
Discovery → launch → year-one iteration

The north star wasn't adoption, it was group spend visibility. A platform hotels merely tolerated would still have fixed the data problem. We chose to also make it a tool hotel managers wanted to open, because the data is only as good as the habit of using it.

03

The process before a single screen was designed.

With 340 properties and three user types, the risk of designing for the wrong persona first was high. Before opening Figma, we ran a structured discovery phase with four research tracks running in parallel.

Week 01

Procurement audit + stakeholder mapping

Discovery workshops with 12 buyer personas across hotel operations, finance, and central procurement. We mapped the full purchasing journey, from request to approval to delivery, and exposed three critical failure points.

Stakeholder discovery
Week 02

Hotel manager interviews

Structured interviews with hotel GMs who had been purchasing independently for years. Their biggest fear wasn't the new tool, it was losing control. Any centralised system that felt like it was taking decisions away from them would be quietly ignored.

Property-level discovery
Week 03

Spend data audit

Working with finance to pull a year of fragmented spreadsheet data across properties, we quantified the actual overlap: how often the same supplier was invoiced separately by hotels a few kilometres apart, at different prices.

Data audit
Week 04

Workshops + north star definition

Cross-functional workshops with PM, engineering, and business stakeholders to agree on what would ship first. Group-level visibility won over joint ordering as the true first-release priority, because visibility alone already created pressure to consolidate.

Stakeholder alignment
Discovery workshop output — procurement journey map across 3 hotel roles

Stakeholder journey map from discovery workshops — 12 buyer personas across hotel operations, finance, and central procurement. The red zones mark the three critical failure points in the existing process.

The output was a prioritised problem map with two layers to solve at once: visibility (give the group a shared picture of spend for the first time) and consolidation (let properties bundle orders without losing local control). The design system would be the layer underneath both.

04

Three decisions that shaped the product.

01

Centralised spend dashboard, filtered by role

We designed a real-time group dashboard giving central procurement full visibility into spend by category, property, and supplier, for the first time in the chain's history. Hotel managers kept a local view filtered to their own property, preserving autonomy while still feeding the group picture.

Decision: one shared data model, two very different views. The group view and the property view are the same dashboard with different defaults and permissions, not two separate tools. This kept engineering effort to one system while giving each role exactly the level of visibility it needed, and nothing it would resent.
02

Joint order flow with automatic cost-sharing

The core workflow lets multiple hotels bundle individual purchase requests into a single consolidated order. The system calculates each property's cost share automatically, routes the order through a configurable approval hierarchy, and notifies each hotel's finance team once confirmed.

Decision: make the cost-share calculation and the approval routing invisible to the hotel manager. They add their line items to a shared basket and the system handles the rest. Removing that friction was what brought the average procurement cycle from 4 days to under 14 hours, the single biggest lever in the whole project.
03

Configurable approval hierarchy, not a fixed one

Early interviews made it clear that no single approval chain would fit 340 properties of different sizes and ownership structures. A rigid hierarchy designed for the biggest hotels would have been rejected by the smaller, independently-run ones.

Decision: let each property configure its own approval thresholds within group-defined guardrails, rather than hard-coding one flow. This added real complexity to the permissions model, a trade-off I'd revisit (see "What I'd do differently" below), but it was the difference between adoption and quiet resistance from the properties with the most purchasing volume.
Joint order flow — multiple hotels bundling requests into a single purchase order

The joint order flow — hotels add individual line items to a shared basket. The platform consolidates them into a single supplier order and automatically calculates each property's cost share.

05

A design system built for procurement complexity, not around it.

The system had to serve three audiences with different mental models: central procurement (goal: control and strategic visibility), hotel GMs (goal: speed, minimal friction), and finance (goal: auditability). Same token layer, same components, different configurations.

Figma
Enterprise component library
Dense data tables, multi-level approval flows, supplier catalogue cards, and cost-allocation widgets, built to handle real procurement complexity without overwhelming the person using it.
→
Zeroheight
Living documentation
Every component published with usage guidelines and code specs, so engineering had one source of truth across a platform shipping to 340+ properties.
→
Confluence
Shared knowledge base
Decisions documented alongside components: rationale, permission edge cases, and the reasoning behind the configurable approval model.
Coperama design system — component library for enterprise procurement UI

Coperama Design System — enterprise data tables, multi-level approval flows, supplier catalogue cards, and cost allocation widgets, all designed to handle real procurement complexity without overwhelming users.

06

What testing changed.

Validation wasn't a checkpoint at the end, it shaped the final decisions, especially the ones where the group's interest and a hotel manager's interest pulled in different directions.

Maze · n=12 sessions
Dashboard prototype, both roles tested separately
Testing the group dashboard with central procurement first, then with hotel GMs using the same base component, confirmed the shared-model approach: GMs didn't want a "simpler" dashboard, they wanted their own numbers without the group noise.
Usability testing · Joint order flow
The cost-share breakdown needed to be visible before confirming
Early prototypes calculated each hotel's cost share only after the order was placed. Testing surfaced real anxiety about this: finance teams wouldn't approve what they couldn't see first.
Moved the cost-share breakdown before the confirm step, not after. Trust in the automation only appeared once the number was visible before commitment, not as a receipt afterward.
Pilot · 12 properties
Approval configuration, tested before full rollout
Before onboarding all 340 properties, a 12-hotel pilot tested the configurable approval hierarchy against real purchasing volume. Two property types needed thresholds outside the ranges we'd designed for, caught here instead of at scale.
Stakeholder interviews · Continuous
Adoption tracked by behaviour, not survey
Rather than ask hotel managers if they liked the dashboard, we tracked whether inventory updates became more frequent after launch, the real signal that the tool had earned a place in their routine instead of being tolerated.
07

Year one, group-wide.

Results were measured across the first 12 months post-launch, covering all 340+ onboarded properties. Cost savings were validated against baseline spend data from the previous year; processing time was tracked through the platform's built-in audit log.

−23%
Procurement costs
Reduction in purchasing costs through consolidated buying power and renegotiated group supplier contracts in the first 6 months post-launch.
340+
Hotels onboarded
NH Hotels properties across Europe migrated to the centralised platform within the first year, replacing fragmented local purchasing processes.
−65%
Order processing time
Average procurement cycle reduced from 4 days to under 14 hours through automated approval routing and consolidated order management.
€2.4M
Estimated annual savings
Projected group-wide savings in year one, based on volume discount gains and reduction in duplicate supplier contracts across the chain.
Coperama — group spend dashboard with category breakdown and hotel filter

The centralised spend dashboard — procurement managers see real-time spend across all properties, broken down by category and supplier. Individual hotels see only their own slice.

The cost reduction was the metric the business cared about most, but the processing-time drop was the one that changed daily behaviour: a 4-day task becoming a same-day one is what turned a mandated tool into a used one.

08

What I'd do differently.

01

The configurable approval hierarchy earned its complexity, but I'd cap it sooner

Letting each property set its own approval thresholds was the right call for adoption, but we let the configuration options grow further than they needed to during the pilot, chasing edge cases from a handful of properties. In retrospect, I would have set a hard limit on configurability from day one and handled true outliers as documented exceptions, not as new options in the system, to keep the permissions model easier to reason about as the platform scaled past the pilot.

02

Change management deserved its own workstream, not a training deck

We treated hotel manager adoption as a UX problem: make the tool clear enough and habits would follow. Some did, through the design. But managers who had run their own purchasing for years for genuinely good reasons needed more than a clear interface, they needed a case for why the group view helped them, not just the central team. If I were starting again, I'd scope a lightweight change-management workstream alongside the design work, not after launch.

03

The 12-hotel pilot should have included the smallest properties, not just representative ones

We picked pilot hotels to represent a spread of property sizes, but weighted toward mid-size ones that mirrored the group average. The smallest, most independently-run properties surfaced the most friction once the full rollout reached them, friction a pilot skewed toward the average case didn't catch early enough. I'd deliberately over-sample the extremes next time, not just the middle of the distribution.

Within a year, 340+ hotels that had never shared a purchasing picture were buying with the leverage of one group, while keeping the autonomy each property needed to run its own operations.

€2.4M in estimated annual savings was the number the business cared about. The 4-day-to-14-hour drop in processing time was the one that told me people actually started using it.

← All case studies