How GuestMaker's voice agent inherits settings from group to hotel to venue, so a new property answers calls correctly on day one, no rebuild required.
Ask a hotel group's operations director what it takes to bring a new property's phone line online, and the list is longer than you'd think. A script. An escalation contact for when the AI can't help. Business hours. Someone who understands what makes this hotel different from the one three towns over, so the receptionist doesn't sound like a form letter. Multiply that by a dozen properties, or four dozen, and "add a hotel" quietly becomes a project with its own project manager and its own backlog.
That is the problem GuestMaker's voice agent was built to make disappear, not by generating forty near-identical configurations for you, but by not requiring forty configurations in the first place. A new property's phone line can go live already knowing the group's policies, the group's tone, the group's escalation rules, its knowledge base scope, its recording consent script, because it inherited every one of them the moment the line was activated. Nobody configured anything for it. It just started working, on day one, before anyone on the hotel's team has opened a settings screen.
We've written before about how one phone number can hold one brain for an entire group. This is what happens to that idea once the group stops being one hotel and becomes forty.
Underneath the call center agent is not a single prompt copied across every property, and it isn't forty separate agents that happen to share a vendor either. It's one configuration lattice with three levels, group, hotel, and venue, where any level can override exactly the piece of itself that's genuinely different, and everything left untouched falls back to the level above without anyone having to ask for it.
At the top sits the group-wide configuration: which voice engine answers the phone, the escalation triggers, the recording and consent settings, the base system prompt, standard business hours, the trunk the calls actually arrive on. This is what every phone number in the group starts from, whether that number belongs to the flagship property or the one that opened last month. For Spanish geographic numbers, the carrier may require identity documents and proof of an address matching the number's area code. Completing that registration is a paperwork problem turned into a claim button.
A single hotel can override roughly fifty of those settings where it makes sense for a property to sound like itself: its own greeting, its own escalation phone number, its own hours, its own agent name and persona, even the slice of the knowledge base it should search first. Leave a setting untouched at the property level and it isn't blank, it's inherited, and a value of zero or false counts as a real, deliberate choice rather than a gap the system misreads as "not configured." That distinction matters more than it sounds: a property that genuinely has no after-hours line needs the system to know that, not guess that nobody got around to filling it in.
Some things are deliberately never overridable at the hotel level, on purpose: whether the module is switched on at all, the SIP trunk itself, which voice engine is running underneath. Those stay group-wide because letting them drift per property is how a rollout turns into forty different products wearing one name.
Below the hotel sits the venue, the spa, the restaurant, the golf course, the parts of a property that increasingly answer their own phone lines. A venue can go one rung further and override just for itself, its own greeting, its own voice, its own line, while still drawing on everything the property and the group already know, which is how a spa can sound nothing like the front desk. A venue that changes nothing at all resolves to a configuration that's byte for byte identical to its parent hotel's. Most venues never touch a single setting. The ones that do need to touch exactly one.
Precedence at call time follows the number that was actually dialled: the line's own language and routing settings first, then any hotel override sitting above it, then the group default underneath everything else. One resolver makes that call for every incoming ring, which matters more than it sounds like it should, because the same decision also determines which slice of the knowledge base the agent is allowed to search, which escalation contact gets notified, and which tools it's permitted to use. If the prompt and the retrieval layer answered to two different ideas of who picked up the phone, a caller could hear one hotel's greeting and get a sibling property's information a minute later. They can't, because there's exactly one place that resolves the scope, and every downstream system reads from it.
The clearest way to see the inheritance model working is a hotel with a restaurant that has its own phone number.
Dial the restaurant, and the agent that answers is the restaurant's, not the hotel's wearing a different hat. It knows the restaurant's own menu and hours before it reaches for anything else, then the property's general information, then whatever the whole group knows, in that order, and it deliberately never reaches sideways into a sibling venue's knowledge, even when that sibling sits inside the same building. Ask the restaurant's line where to park and it can still tell you, because that's the property's own knowledge. Ask what's on the restaurant's menu at a hotel with two restaurants and it won't guess between them, because the venue that answered the phone is the venue whose menu it searches first.
That scoping isn't a suggestion sitting in a prompt for the model to honor if it feels like it. It's enforced at the point every tool actually executes, availability checks, knowledge search, reservation creation, all of them validate the caller's scope against what the dialled number is allowed to know before they run, not just against what the system prompt politely asked the model to remember.
None of this is really about any single setting. It's about what happens to the arithmetic of a rollout once the inheritance model exists.
Bringing a hotel group's phone lines onto an AI voice agent, one property at a time, without this model, means building something close to a full configuration for every single property before its line can go live: a greeting, a persona, business hours, escalation contacts, a knowledge scope, checked and rechecked before anyone dials in. With the inheritance model, a new property's line goes live pre-configured with everything the group has already gotten right, and the only work left is the handful of things that genuinely make that hotel different, a different escalation number, a different set of hours, maybe a different name for the AI itself. A group scaling from a handful of properties into the dozens isn't rebuilding a voice agent dozens of times. It's writing down what's actually different about property number thirty-one, which is usually a short list.
This was proven against real phone calls, not a simulator. A live line scoped to a specific property answered with that property's own override greeting on every call, pulled from both its own knowledge and the group's shared knowledge, and never once leaked a sibling property's information across the line, across a run built specifically to try.
The interesting failure mode this design avoids isn't a hotel configured wrong. It's a hotel configured not at all, and what happens to it by default. In a system without deliberate inheritance, an unconfigured property is a blank one, an agent with no greeting, no escalation contact, nothing to say. In this one, an unconfigured property is simply running the group's own defaults, correctly, indefinitely, until someone decides there's a reason to change that.
That's the quiet promise underneath all of this: nothing you don't touch is broken by omission. It's inherited. A hotel group can activate a voice agent across every one of its properties on day one, let the ones that need something different ask for it when they're ready, and never once have to explain to a new hotel's team why their phone line doesn't know what the rest of the group already does.
For a closer look at how the knowledge base itself is structured to support this, or to see the voice agent in its full form, both are worth a visit.
Thirty minutes, your real properties, no generic demo environment.
Most hotel phone lines go unanswered, are picked up blind, or recite a script. GuestMaker's voice agent gives every property and venue a real memory instead.
A hotel's spa or restaurant can carry its own agent name, voice, hours, and rules in GuestMaker, inherited from the property by default until one field is deliberately changed.
Spain makes a hotel group register a local phone number province by province. Most platforms leave that paperwork to you. GuestMaker turns it into a claim button, and lets a website chat become a live call without a dial tone.
