← Back to work

B2B Platform

Designing a multi-sided platform for supply and partners

Leading the end-to-end redesign of the B2B ecosystem at Civitatis, defining a scalable system to support supply, distribution and growth.

Role Principal Product Designer
Company Civitatis (travel tech)
Scope B2B Ecosystem, Supply & Partners
Year 2024–2025
Reading mode
9 min read
B2B Supply Platform — Civitatis affiliates dashboard on laptop

Context

A growing ecosystem hitting its limits

At Civitatis, the marketplace operates through a complex ecosystem of suppliers, agencies and affiliates.

As the company scaled, the internal tools and partner platforms became a bottleneck: fragmented experiences, inconsistent logic and increasing operational friction.

I led the end-to-end redesign of the B2B ecosystem, defining a scalable system to support supply, distribution and growth.

This case study is password-protected.

Why this mattered

This was not a UI problem

It was a business scalability problem.

01

Suppliers struggled to manage operations efficiently

02

Agencies faced friction in booking and invoicing workflows

03

Affiliates lacked visibility into performance

These inefficiencies directly impacted: supply quality, conversion, and operational cost.

My role

Designing the system, not just the screens

Led product design across all B2B platforms

Defined system architecture and interaction models

Worked with product, engineering and business stakeholders

Balanced short-term delivery with long-term scalability

Systems Thinking Product Strategy Interaction Design Stakeholder Alignment Design Systems

Reframing the problem

From isolated platforms to a connected system

The initial approach was to improve each platform independently.

That would have failed.

Instead, I reframed it as:

The reframe

Designing a system that connects supply, distribution and demand through shared logic and differentiated interfaces.

The system

System model

How the ecosystem connects

At the core of the ecosystem, three concepts drive everything: Availability creates supply. Bookings connect supply and demand. Revenue validates the system.

Actor Primary goal Interaction
Suppliers Operate activities Manage availability & bookings
Agencies Sell Create & manage bookings
Affiliates Acquire traffic Track conversion
Suppliers Agencies Affiliates Availability Traffic Bookings Revenue

Each actor interacts differently with the system, but all converge on bookings as the shared entity that drives revenue.

Designing the system

Bookings as the core entity

Bookings became the single source of truth across all platforms.

This required aligning three fundamentally different interactions around a shared object:

01

Creation — Agencies create bookings through a streamlined flow optimized for speed and accuracy

02

Management — Suppliers manage bookings alongside availability, with operational tools designed for daily workflows

03

Tracking — Affiliates track how their traffic converts into bookings, with clear visibility into performance metrics

One system, multiple entry points. The same booking data is surfaced differently depending on the actor’s role and needs — but the underlying logic is shared.

One entity, three perspectives

How each actor sees the same booking

Supplier view

Operations & fulfillment

  • Booking status & details
  • Traveler information
  • Availability management
  • Operational actions

Agency view

Sales & invoicing

  • Booking creation flow
  • Pricing & commission
  • Invoice management
  • Client communication

Affiliate view

Performance & conversion

  • Traffic attribution
  • Conversion metrics
  • Revenue tracking
  • Campaign performance

Shared booking entity, differentiated interfaces.

Key screens

From system model to interface

The system model translated into concrete interfaces for each actor. Below are representative screens that demonstrate how the shared logic manifests differently across platforms.

01

Booking detail

Supplier view vs. agency view — same data, different priorities and actions depending on the role.

02

Booking creation

Streamlined flow for agencies to create bookings with real-time availability checks and pricing.

03

Booking status states

A unified state machine that all platforms share, ensuring consistent behavior across the ecosystem.

Availability & operations

The most complex domain

Suppliers needed to manage dates and time slots, capacity (quotas), cancellations and changes, and upcoming activities.

01

Dates & time slots — Complex scheduling across multiple activities with different frequencies and durations

02

Capacity (quotas) — Managing available spots per session while preventing overbooking

03

Cancellations & changes — Handling modifications without disrupting downstream bookings

04

Upcoming activities — A real-time operational view of what’s happening today and this week

The key challenge: balancing flexibility with operational safety. Suppliers need enough control to manage their business, but too much flexibility increases error risk.

01

Calendar / availability

Visual calendar for managing availability across activities, with bulk editing and recurring patterns.

02

Quota editor

Granular capacity management per time slot, with real-time occupancy visibility.

03

Upcoming activities

Operations-first homepage showing today’s and upcoming activities with actionable status indicators.

Supply platform

Supply — bookings table with filters, search and operational actions
Supply — services management with activity listing and status overview
Supply — yearly calendar overview with availability patterns
Supply — statistics dashboard with performance metrics and charts

Sales & distribution

Two types of partners, two interaction models

The distribution side of the ecosystem serves two fundamentally different user types with distinct needs and workflows.

Agencies (power users)

Booking management

Invoicing

Operational workflows

Affiliates (lightweight users)

Conversion tracking

Performance insights

Marketing resources

Agencies

Booking management table

Full-featured table with filters, search, and bulk actions for high-volume booking operations.

Invoice view

Clear billing overview with downloadable invoices, payment status, and commission breakdowns.

Checkout / booking creation

Streamlined multi-step flow optimized for speed and accuracy in daily booking operations.

Affiliates

Conversion dashboard

Real-time performance metrics showing traffic, clicks, conversions, and revenue attribution.

Reports view

Detailed analytics with date filtering, breakdowns by campaign, and exportable data.

Embed / marketing tools

Self-service tools for generating widgets, deep links, and promotional assets.

Agencies platform

Agencies — bookings management table with filters and search
Agencies — embeddable booking widget for partner websites

Affiliates platform

Affiliates — dashboard with conversion metrics and revenue overview
Affiliates — custom banner generator with style and destination options
Affiliates — comparative analytics with performance breakdowns

Key decisions & trade-offs

Every design decision has a cost

Building a multi-sided platform means making hard choices. Here are four key trade-offs I navigated — and the reasoning behind each.

1. Operational focus vs. dashboard exploration

Suppliers didn’t need insights. They needed to get work done fast. We replaced a distributive dashboard with an operations-first homepage.

Trade-off

Lost: visibility and navigation

Gained: speed and clarity

Result: reduced time-to-action and fewer missed operations.

2. Flexibility vs. reliability

A fully flexible availability system increased error risk. We constrained configurations to protect operational integrity.

Trade-off

Lost: edge-case flexibility

Gained: predictability and trust

Result: fewer operational mistakes and support issues.

3. Desktop-first vs. coverage

We prioritised real usage over theoretical completeness. Agencies work on desktop — so we shipped desktop first.

Trade-off

Lost: mobile access

Gained: faster delivery of critical workflows

Result: faster adoption among core users, at the cost of UX debt.

4. Impact-first vs. consistency

We prioritised key mobile use cases for affiliates over full system coverage.

Trade-off

Lost: consistency

Gained: faster impact

Result: improved access to performance data in high-value contexts.

What didn’t work

This system was not perfect

Honest reflection is part of the process. These are the areas where conscious trade-offs created long-term costs.

!

The lack of full responsiveness created long-term UX debt

!

Some constraints in availability limited advanced use cases

!

Fragmentation in affiliate tools impacted consistency

These were conscious decisions, not oversights. Each trade-off was made with full awareness of the cost — prioritising speed-to-value over completeness.

What I’d do differently

Long-term thinking

With hindsight and distance, these are the strategic changes I would make if starting this project again.

01

Invest earlier in a fully responsive system — avoiding fragmentation across devices from the start

02

Define clearer product boundaries between agencies and affiliates — reducing overlap and confusion in the system model

03

Introduce progressive complexity — allowing advanced users more flexibility without compromising usability for the majority

Outcome

From interfaces to systems

This work established a scalable foundation for the marketplace, connecting supply, distribution and demand through a coherent system.

More importantly, it shifted the design approach from:

The shift

From building interfaces

To designing systems that enable business growth

Get in touch

Let's talk.

Open to new opportunities. Based in Madrid, working globally.