Agentic commerce for portfolios: one setup, every property.

What's shared, and what genuinely isn't

Say a small group runs six self-catering cottages across the Lake District, each with its own character, its own calendar, and its own quirks, but all booked through the same underlying system. Making the first cottage properly known, found, trusted and bookable by AI takes real, careful work: the facts, the evidence, the connection to the booking system. The temptation is to assume the other five each need that same work repeated from scratch.

They don't, and treating them as though they do is usually the actual mistake, not a shortcut skipped. The booking system, the calendar logic, the terms and policies that are common across the portfolio, only need connecting once. What's genuinely different from cottage to cottage, the specific facts, the specific character, what each one is and isn't right for, is a much smaller job once the shared groundwork exists.

Shared: the booking and payment system, the operator's standard terms, the cancellation policy, the overall standard of evidence a guest or an AI can expect across every property in the group. Not shared: what each cottage is like, its size, its specific quirks, what it's suited for and what it isn't, a hot tub in one and not another, dog-friendly in four of the six but not the other two. Confusing the two, treating shared infrastructure as though it needs rebuilding per property, or treating property-specific facts as though they can be templated across the group, both produce the same result: either wasted effort or wrong answers.

What goes wrong when it's done property by property

The group that treats each cottage as its own project usually ends up with six slightly different versions of the same cancellation policy, six separately maintained calendars that occasionally disagree with each other, and six inconsistent standards of evidence, one cottage with a proper site visit on record, another with nothing beyond the owner's own description. An AI checking across the portfolio has no way to know these differences are accidents of how the work got done rather than genuine differences between the properties, so it ends up trusting some cottages more than others for reasons that have nothing to do with which one's right for a given traveller. The inconsistency itself becomes a fact an AI can detect, and it counts against the whole group, not just the property where it happened.

Why doing this properly compounds

Once the shared connection exists, adding a seventh cottage to the portfolio is mostly the small job, the specific facts for that one property, not the large one, connecting a whole new booking system from nothing. Groups that get this right find that each additional property gets cheaper to bring on, not more expensive, which is the opposite of how this usually goes when each property is treated as its own separate project.

That's exactly the shape of the problem Selfe exists to solve for portfolios: connect once, at the level that's genuinely shared, and let each property's own specific facts sit on top of that shared foundation, rather than making every cottage in a group repeat the same infrastructure work its neighbours already did. For what that shared connection involves, once, see how we think about booking as a standard job rather than a one-off integration.

Does every property still need its own page or listing?

Yes, its own specific facts still matter and shouldn't be templated away. What's shared is the connection underneath, not the individual character of each place.

What if our properties use different booking systems?

That's more common than it should be, and worth fixing on its own merits regardless of AI. One connection per system, rather than per property, is still far less work than starting from scratch each time.