hero · b2b platform
Designing a multi-sided platform for supply & partners
I redesigned Civitatis's three B2B platforms, suppliers, agencies, and affiliates, around a shared booking entity, from system model to shipped screens.
specs
hero-visual
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 redesigned all three platforms: availability, quota and booking management for suppliers; booking creation and invoicing flows for agencies; and conversion dashboards, reports and marketing tools for affiliates.
why-this-mattered
This was not a UI problem
It was a business scalability problem.
Suppliers struggled to manage operations efficiently
Agencies faced friction in booking and invoicing workflows
Affiliates lacked visibility into performance
These inefficiencies directly impacted: supply quality, conversion, and operational cost.
my-role
Designing the system, not just the screens
Defined the shared booking entity and its state machine, used by all three platforms
Designed the supplier availability calendar, quota editor and operations-first homepage
Designed the agency booking-creation flow, bookings table and invoice views
Designed the affiliate conversion dashboard, reports and banner generator
reframing-the-problem
From isolated platforms to a connected system
The initial approach was to improve each platform independently. That would have failed, all three platforms operate on the same bookings, so fixing them in isolation would have reproduced the inconsistencies.
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 |
All actors converge on bookings, 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 meant aligning three different interactions around a shared object:
Creation, agencies create bookings through a streamlined flow optimized for speed and accuracy
Management, suppliers manage bookings alongside availability, with tools designed for daily operations
Tracking, affiliates track how their traffic converts into bookings
one-entity-three-perspectives
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
availability-and-operations
The most complex domain
Suppliers needed to manage four things at once:
Dates & time slots, complex scheduling across multiple activities with different frequencies and durations
Capacity (quotas), managing available spots per session while preventing overbooking
Cancellations & changes, handling modifications without disrupting downstream bookings
Upcoming activities, a real-time operational view of what's happening today and this week
The key challenge: balancing flexibility with operational safety, enough control to run a business, not enough to break it.
supply-platform
sales-and-distribution
Two types of partners, two interaction models
Agencies (power users)
Booking management
Invoicing
Operational workflows
Affiliates (lightweight users)
Conversion tracking
Performance insights
Marketing resources
agencies-platform
affiliates-platform
key-decisions
Every design decision has a cost
I navigated four deliberate trade-offs: an operations-first homepage over an exploratory dashboard, constrained availability configurations over full flexibility, desktop-first delivery for agencies, and impact-first mobile coverage for affiliates. The full case study covers the reasoning, and the cost, of each.
key-decisions
Every design decision has a cost
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. I replaced an exploratory, data-heavy 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. I 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
Agencies work on desktop, so I designed desktop first, prioritizing real usage over theoretical completeness.
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
I prioritized 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.
retrospective
What didn't work, and what I'd change
Some trade-offs were conscious decisions, not oversights, but they still created long-term costs.
Desktop-first created lasting UX debt. I'd invest earlier in a fully responsive system, avoiding fragmentation across devices from the start
Availability constraints locked out advanced use cases. I'd introduce progressive complexity, more flexibility for advanced users without compromising usability for the majority
Affiliate tools stayed fragmented. I'd define clearer product boundaries between agencies and affiliates, reducing overlap in the system model
outcome
What shipped
Three redesigned platforms, running on one shared booking entity and state machine.
Suppliers, operations-first homepage, availability calendar, quota editor and bookings management
Agencies, booking-creation flow, bookings table, invoicing and an embeddable booking widget
Affiliates, conversion dashboard, comparative reports and a banner generator
contact