Hotel groups and partner portals in AI Otel: one login, and portals for agencies and companies

Multi-property hotel software runs several hotels from one login while keeping each property's data separate. In AI Otel, single hotels and groups share one system, and travel agencies and corporate clients book through their own portals. Built, ahead of launch: no agency or company is connected yet.

A group with six hotels often runs on six logins, a shared spreadsheet and a reservations inbox that three people answer. The agency on the other end has the same problem in reverse: it knows the rate it agreed, and it still has to ask. After reading this, you will know what multi-property hotel software actually has to do, what a partner portal replaces, and which questions to put to any vendor before you sign.

What does multi-property hotel software actually have to do?#

It has to give a group one place to work across its hotels while keeping each hotel's records, rates and bills apart. Those two demands pull against each other, and the design either resolves them or it does not.

Multi-property hotel software is one system serving more than one property. The alternative is one installation per hotel, each with its own logins and its own copy of the guest list. The difference sounds small until a guest stays at two properties in the same group and neither system knows about the other.

Three kinds of people need a door into the same rooms: the hotel team, whether a single hotel or a group; the travel agency; and the corporate client. Each needs a different view of the same inventory, and each must not see the others' terms.

One login is the easy half. The hard half is what happens when two hotels' records meet: a negotiated rate that must not leak to another agency, or a bill that belongs to one property only. The common failure is one shared database with a property filter applied in the screen. It looks correct until someone builds a new report, exports a list or connects an outside system.

The test you can apply to any vendor: ask whether the separation is enforced in the database or only in the application layer, and ask to see it demonstrated rather than described.

The last column is a requirement to check, not a feature list.

How does one login work across a group without mixing the hotels' data?#

Each hotel's data is separated at the database level, so the group login is a way to reach several separate sets of records, not one pool with a filter on top.

A tenant, in plain language, is one customer's slice of a shared system. Tenant isolation means that slice is kept apart by the database itself, not by the screen the person happens to be looking at. The same person signs in once and switches between properties; behind each switch sits a different set of records, and the system enforces which set is being read.

The database level matters because an application filter can be forgotten by a new report, an export or a partner connection. A boundary held by the database is checked on every read and every write.

Be precise about what a group login does not automatically give: a single combined profit figure, one guest profile shared across hotels, or rates pushed from the center to every property. Ask for these explicitly; do not assume them from the login.

The operational edges a group should test: how the night audit closes a business day across several properties, how a charge moves between properties when a guest is upgraded, and who can grant and remove access when a manager leaves.

What is a travel agent portal, and what does it replace?#

A travel agent portal is a signed-in place where an agency sees the rates a hotel has contracted with it and books against them, instead of emailing the reservations desk and waiting.

What it replaces, concretely: the email or phone request, the allotment spreadsheet kept on two sides, the wait for a confirmation, and the re-keying of the same booking into the hotel's system once it is agreed.

Contracted rates mean the agency works with the net and the rules the hotel agreed with that agency, not with the hotel's public price. The portal is where the agreement is applied, not where it is invented.

Confirmation works in two modes: one engine confirms instantly for connected hotels and routes the request to hotels that confirm by hand. Instant confirmation is a decision about trust in the hotel's own rules; manual confirmation keeps control and keeps the delay.

Every quote shows its working: the hotel's net, each pricing rule that fired and the final price. A disputed rate can be settled by reading the quote rather than by searching an inbox. This is the design behind quotes that show their working in the distribution hub.

The portal is built and ahead of launch, and no agency is connected yet. Nothing in this section is a report of agency usage.

The trade-off a group should weigh: a portal that only mirrors email changes nothing. The gain comes when the booking lands in the hotel's system already shaped like a reservation.

What does a corporate booking portal change for a company account?#

It moves a company's bookings out of one named person's inbox and into a place where the company's own bookers can see the rates it agreed and book them.

Start from the agreement: a corporate rate is a contract about room types, dates, volumes and conditions, not a discount code. The portal is where that contract is applied to a booking. If the contract is badly written, the portal cannot fix it; see agreeing corporate rates with companies.

On the company side, several people may book under one account: an assistant, an HR team, a travel coordinator. The hotel-side gain is mechanical: the booking arrives as a reservation with a rate attached, rather than as a message a receptionist retypes at the end of a shift.

Before switching a company onto a portal, settle: which rates and room types, which date ranges, who at the company may book, what happens when the agreed allocation is used up, and who the hotel calls when something is wrong.

The corporate portal is built and ahead of launch, and no corporate client is connected yet.

How do the portals relate to the distribution hub and one room inventory?#

They are three views of the same rooms: the portal is where an agency or a company books, the hub is the pricing and confirmation engine behind it, and the inventory is the single count of rooms all of them draw from.

The inventory principle: one room inventory feeds the hotel's own website, the booking sites, travel agencies and AI assistants at once, so a room sold in one place is not offered in another. This is the design of one room inventory feeding website, booking sites, agencies and AI assistants.

The mechanism that makes it safe is the hold: a hold takes the room out of the count, and when the hold expires the room returns to inventory. Without one count, each channel keeps its own and the hotel sells the same room twice.

The hub sits behind the portals: hotels publish contracted rates to travel agencies on their own terms, and every quote shows the hotel's net, the rules that fired and the final price. It is built, with seed data; no agency is connected yet. The portals are the front door for an agency or a company, not a fourth inventory and not a separate price list.

Availability and rates reach the major booking sites through our Channex integration, now in pre-production testing, and no agency or OTA is connected today. The question this raises for any vendor: how many inventories does the system keep, and which one wins when two channels sell the last room.

What is built today, and what is not?#

The group login and the two portals are built and working, ahead of launch. No agency or corporate client is connected yet.

Built means working software that is ahead of launch and not yet in customers' hands. It is not the same as live. In AI Otel's case, the system runs single hotels and groups from one login, travel agents and corporate clients book through their own portals, and each hotel's data is separated at the database level.

OtelCiro works with paying hotel clients today, and the hotel operating system is built and working, ahead of launch.

The honest zeros: no connected agencies, corporate clients, OTAs or partners; no count of hotels, bookings or users on the technology; no client names and no testimonials. Also not claimed here, though readers will ask: consolidated cross-hotel reporting, central rate push, a described permission model, and any connection to the large agency distribution networks.

The zeros are printed because a group that signs on the strength of a demo deserves to know which parts of the demo are running and which are designed.

What should a group ask any vendor before signing?#

Ask for the separation, not the dashboard: where the boundary between two hotels' data sits, and who can cross it.

Ask for a demonstration with two real properties, not a slide: the same guest, the same date and the same room type in both, and what each login can see. Ask where the boundary is enforced, in the database or in the screen, and what happens when a new report or an outside connection is added next year. Ask how access is granted and removed when a group manager changes role, and ask to see the removal, not the grant.

Ask what the group view computes and from which hotel's records, so a combined figure is never mistaken for an audited one. Ask how an agency sees its own rates and not another agency's, and how a company sees its own agreement and not another company's. Finally, ask for the status in plain words: built, in testing, or live with clients you can call. A vendor that answers this precisely is easier to trust on everything else.

More governance questions are in the multi-property governance checklist for owners.

What to do next#

Start with the boundary question, not the dashboard: ask any vendor to show where two hotels' data separates and who can cross it, then ask which parts of the demo are running today. The group login, the two portals and the hub are one design, and the design only holds if the inventory behind them is one. If you want those questions answered against the running system, request a briefing.