KabuK Exchange · Product & platform leadership
The product work behind a B2B2B exchange: supplier connectivity, hotel identity, eligible sourcing, and partner-specific commercial and booking workflows.
The brief
Combine eligible direct hotel supply and global inventory behind a simpler distribution connection, while retaining the rules, property identity, and commercial conditions that make the supply usable.
I lead product strategy, roadmap priorities, requirements, and execution across platform and acquisition initiatives. I defined the centralized platform direction and led integration planning, source-of-truth decisions, and buy-versus-build analysis.
Exchange connects the concerns of supply and commercial teams with engineering, operations, finance, analytics, and leadership. My contribution sits in product direction, requirements, integration planning, investment analysis, and cross-functional alignment. Implementation and partner operations are shared delivery responsibilities.
Product direction & scoped availability. Release status is confirmed for the relevant capability, market, property or partner, and connection. Most capabilities in v2.1 are awaiting status confirmation; Platform PMS is marked Planned.
The Exchange proposition addresses a tension for travel distributors. Direct hotel contracting can offer direct relationships and stronger net-rate access, but it also means agreements and source connections to manage. A wholesaler can simplify that relationship and connectivity, while giving a distributor less control over rate conditions and how hotel identity is carried along the chain.
The Exchange proposition brings eligible direct-contract supply and global inventory into a single distribution relationship. The product challenge is to simplify access without treating all rates, properties, and permissions as interchangeable.
Hotel relationships and individually negotiated conditions, with contracting and connectivity work for each source.
A simpler connection and commercial relationship, with rate conditions and content dependent on the source.
Eligible direct hotel net rates and global inventory through a unified API and partner-specific terms.
Participating hotels enter through the hotel-facing Platform foundation. Global supply sits alongside that hotel supply and enters Exchange separately. On the demand side are OTAs, travel agencies, wholesalers, and travel platforms.
Hotel foundation
Rooms, rates & availability
KabuK PlatformOnboarding, eligible controls & visibility
Additional hotel-side routes
HafHOmakastayInventory alongside the Asia-first focus
The exchange
Distribution
A distributor connects to Exchange for its agreed supply and workflows. Participating hotel supply and global inventory enter Exchange separately; external supply is not shown as managed through Platform.
Conceptual product model adapted from the v2.1 decks. Routes depend on eligibility, connection readiness, and agreed terms. This is not a production architecture diagram.
View largerThe conceptual Exchange layer has three parts: resolving multiple supplier records to one hotel, selecting an eligible source, and applying commercial terms for the distribution partner.
That is the product detail behind “one connection.” A property can arrive from several sources, but the distributor needs a coherent hotel identity. Source selection also needs to respect eligibility and conditions; a cheaper-looking rate is not automatically a rate that a particular partner is allowed to distribute.
Relate supplier records to the property they represent.
Consider eligible supply, markets, and rate conditions.
Keep commercial conditions tied to the distribution relationship.
Support the inventory and booking workflows confirmed with the partner.
Conceptual product flow from the v2.1 proposition. It does not specify production algorithms, API endpoints, or implementation details.
Hotel brand and content are part of the proposition too: property name, location, descriptions, images, amenities, and policies remain subject to agreed usage rights. The data model and partner experience need to preserve those conditions alongside the offer.
My broader platform work covers API-driven supplier and partner integrations, normalization, service boundaries, source-of-truth decisions, and buy-versus-build analysis. Exchange gives those decisions a specific distribution context.
The integration planning brings inconsistent supplier and partner data into a shared platform direction, while the Exchange proposition retains eligibility and partner conditions.
A common connection is only useful if the information remains meaningful for the partner that will use it.
Simpler integration cannot mean silently dropping rate restrictions, content rights, or differences that affect the booking.
The product model resolves many supplier records to a hotel, then uses rules to select an eligible source.
The property a traveler understands and the source a distributor books through are related but different concepts.
A coherent hotel record needs to coexist with source-specific availability, rate conditions, and commercial access.
The API proposition is a single Exchange connection for agreed inventory and booking workflows. Supported functions and production access are confirmed through technical review.
A distributor needs a shared understanding of what it can access, what it can book, and what happens when something needs attention.
A simple commercial story should not hide workflow limits, connection readiness, or operational responsibilities.
I conduct buy-versus-build analysis and align platform investment with business goals across technical and commercial stakeholders.
Travel connectivity choices affect implementation effort, ongoing cost, control of the experience, and flexibility for future distribution.
An external capability can shorten initial delivery while creating a longer-term dependency. An in-house capability needs a clear business case for its delivery and operating cost.
Technical review covers current API documentation, supported workflows, access requirements and environments, inventory and content scope, rate restrictions, booking conditions, error handling, and operational responsibilities.
Those are product requirements as much as technical details. They determine what a partner can launch with, which issues it can resolve itself, and where it needs help from the platform organization.
Understand target markets and the partner’s customer mix.
Connect the distribution model with eligible supply and the workflows needed.
Confirm access, integration needs, environments, and responsibilities.
Agree a go-live plan for the scope that both sides are ready to support.
This is the onboarding framework in the v2.1 deck. Sequence and timing are agreed with each partner.
The v2.1 commercial proposition has no setup fees or recurring integration fees, with transaction-based arrangements tailored to each partner. Transaction charges, billing triggers, payment, and settlement provisions are agreed individually.
For product planning, the important boundary is the connection between access and terms: a partner’s markets, rate eligibility, content permissions, integration scope, and operating responsibilities need to agree with the commercial relationship. Access to each source and workflow stays tied to that agreed scope.
Exchange is a continuing platform and distribution initiative. At the v2.1 review point, availability for Asia-first supply, global inventory, eligible direct net rates, hotel content, and unified API workflows still needs confirmation for each partner scope.
The product story centers on defining the offer, connecting the supply model to partner workflows, and making launch readiness explicit.
A partner can access its agreed supply, understand the conditions, complete the supported workflows, and operate the connection with clear responsibilities.
My leadership contribution is connecting this distribution direction to the shared platform roadmap, integration planning, stakeholder requirements, and investment choices described in my KabuK remit.