Why we pooled the experience catalog

When you build a product for travel agencies, the first instinct is to give each one its own catalog, neatly enclosed and entirely theirs. We chose the opposite: a shared pool of experiences, pooled across the agencies that use Compass. This note explains why. It is not yet a shipped feature, it is a vision still being built, and we want to be transparent about the reasoning that guides it as much as about the safeguards it imposes.

The problem with a proprietary catalog

A travel agency does not just sell destinations: it sells concrete experiences. A characterful place to stay in Kyoto, a reliable French-speaking guide in Marrakech, a cooking class that truly lives up to its promises. This knowledge is built file by file, sometimes over years. And as long as it stays locked inside a single agency's catalog, it remains fragile: it depends on one advisor's memory, on a spreadsheet, on a contact book that does not get passed on.

The proprietary catalog has another, more structural limitation. The smaller an agency is, the fewer destinations it covers in depth. It writes solid programs for its areas of expertise, and improvises elsewhere. A shared pool reverses this logic: coverage no longer depends on the size of an agency, but on the full set of agencies that feed the pool.

Why sharing creates more value

The value of an experience catalog is not linear, it is combinatorial. An isolated experience is worth what it is worth. The same experience, connected to hundreds of others, qualified by several agencies, tied to seasons, traveler profiles and budgets, becomes a usable point on a map. It is this map that Compass's AI already uses to produce a first draft program in about thirty seconds; the denser and more reliable it is, the better the first draft, and the less time the advisor spends correcting it.

In concrete terms, here is what a shared pool makes possible where an isolated catalog quickly reaches its limits:

• Covering destinations that an agency only handles occasionally, without starting from a blank page.
• Drawing on experiences already qualified by other industry professionals, not by anonymous reviews.
• Speeding up AI generation by giving it rich, structured material rather than a sparse base.
• Pooling the update effort: an experience that closes or changes is flagged once, for everyone.

The real tension: competition versus shared value

The first objection is legitimate and we take it seriously: why would an agency share its best finds with potential competitors? This tension is real, and brushing it aside would be dishonest. Our answer is not a speech, it is a design stance.

What makes an agency distinctive has never been the raw list of its contacts. It is the way it assembles a trip, the tone of its client relationship, its judgment about what suits a given profile. A place to stay shared in the pool says nothing about how an agency will frame it within a program. The pool shares the raw material; it shares neither the know-how, nor the relationship, nor the brand, which remain the true differentiating factors.

We also start from a conviction observed in the market: most agencies do not compete head-on. They operate in distinct territories, client bases and specialties. For the majority of them, what another agency brings to the pool is a net gain, not a threat.

The safeguards we impose on ourselves

A product vision is only worth as much as the limits it sets for itself. Three principles frame the experience pool from its very design, even before the first line of production code.

1. Agency control: each agency decides what it contributes to the pool and what it keeps private. Sharing is an explicit choice, never an imposed default.
2. Anonymization: an experience enters the pool detached from its commercial origin. We share a place, a service, a professional qualification, not the identity of the agency that contributed it nor its negotiated terms.
3. No client data disclosure: the pool contains no information from the traveler CRM. Profiles, preferences expressed during the swipe test, a client's history all stay strictly within the agency's scope. The shared catalog and the client database are two watertight worlds.

Where we stand

Let's be clear: the shared catalog is a direction, not a given. It is under construction. We are documenting this reasoning now, as the product takes shape, because this kind of choice cannot be fixed after the fact. Pooling or compartmentalizing, anonymizing or tracing, giving control to the agency or centralizing it: these decisions are written into the architecture, and it is better to lay them out in the open.

Our bet, already at work in the Compass philosophy and illustrated by groups such as Borealis Travel Group that unify several agencies under a single platform, is that value will come from what circulates between agencies, not from what they lock away. A shared experience pool, controlled by each agency and watertight to client data, is the concrete expression of that bet. We will move forward in stages, and we will keep writing down what guides our trade-offs.