These are working notes, not a finished operating model. They're kept here so nothing gets lost, but the routing, ownership and ideas below still need to be thought through with the team and built out. Don't treat this page as the source of truth yet.
Current guest-experience priorities
Recent internal direction on brand voice and guest experience is reflected in the sections that follow.
-
Speed
GX reply time is now the core accountability metric
Fast beats verbose—a broken HVAC unit needs action, not a long acknowledgment. The CSAT bar for a premium brand is well above where the team sits today.
-
Unified messaging
One thread, any channel
The top priority solve: the local team should be able to reach a guest on whatever channel they're actually on, from one place—not have the channel decide who can even see the message. See the routing and SpokePhone sections below for where that split lives today.
-
Proactive check-ins
Wellness check moving earlier
Moving to a few hours post-check-in via SpokePhone, with a simple thumbs-up/thumbs-down reply. The open piece is routing a thumbs-down straight to an immediate human response, not just logging it.
-
Stay-risk score
A real-time, weighted risk score is being explored
Combining signals like recent home reviews, in-stay issues, and messaging sentiment, updated regularly with visible and adjustable weighting. More on the concept in the recovery-loop section below.
-
Resolution speed
Refunds should be fast to execute, not just fast to approve
If a guest has a real issue, the instinct should be to make it right—the open question is execution, not whether to do it at all.
-
Concierge & VAS
Push value-added offers earlier, into more markets
Concierge and VAS offers moving earlier in the booking window, not just at check-in, with an eye on markets that have almost no concierge presence today.
Six steps, from first contact to a resolved need
Every guest contact—OTA message, direct email or text, SpokePhone, a phone call, or an automated system event—moves through the same basic pipeline before it lands with the right team.
-
A contact comes in
Through an OTA message thread, direct email or SMS, SpokePhone, a phone call or IVR, the website, or an automated system event.
-
Zendesk classifies it
It links whatever reservation context is available, tags the stay stage (booked, upcoming, check-in day, in-stay, checkout day, checked out) and the reason for contact, and routes the ticket toward a team.
-
The reason for contact decides whether Duckie may answer
A classification taxonomy sets, per topic, whether the AI agent is eligible to respond at all—separately from whether it actually can, for this specific ticket.
-
Duckie reads the ticket and reservation context, then acts
It answers and resolves, answers and hands off, hands off silently with no guest-facing reply, routes to GX, Reservations, VIP, or Concierge, opens an operations case, or fails and requires a human.
-
A human team owns whatever Duckie can't finish
The receiving team needs a specific, unresolved task to act on—not a generic handoff with nothing attached to it.
-
SpokePhone carries the local, human thread
System automation stays authoritative for transactions, compliance, the Booking Hub, check-in instructions, access codes, parking, and wifi. SpokePhone is where a named local team talks to the guest directly.
Where a message goes first
Destination is decided by precedence, most specific first: an immediate safety issue or a guest locked out always wins, then VIP or member status, then a hotel-specific queue, then a functional specialist, and only then general Guest Experience. A contact with no real guest request behind it—an automated notification ping, say—gets closed rather than dropped into a live queue.
| Contact type | Typical destination | Owns the next step |
|---|---|---|
| Airbnb guest message | Guest Experience, or an Airbnb-specific specialist for platform policy questions | GX for the guest's need; the Airbnb/Reservations specialist for anything policy- or alteration-related |
| VRBO or another OTA message | GX for in-stay needs, Reservations for booking changes | Whichever specialist owns the specific ask—never left in general GX with nothing to do |
| Direct or website contact | GX, Reservations, Payments, or Concierge, based on intent | The destination team owns the next action |
| In-stay issue (maintenance, safety, wifi, HVAC, pests, pool) | GX, with an operations case opened when needed | GX owns the guest conversation through closure, even when Field Ops owns the physical repair |
| Check-in-day or access issue | GX, or a hotel-specific queue for hotel guests | A human takes over the moment a code fails, identity is uncertain, or relocation becomes possible |
| VIP or member guest | VIP Team | VIP Team owns service recovery and higher-touch follow-through |
| Hotel guest | The property's front-desk or hotel queue | Front desk owns physical arrival and room readiness; GX owns after-hours and escalations |
| Concierge request | Concierge or Concierge Estates | Concierge owns vendor and service fulfillment plus guest follow-up |
| Reservation change, extension, cancellation, or pricing | Reservations | Reservations owns approval, price, inventory, and any OTA-side action |
| Payment or refund request | Payments, Reservations, or GX, depending on the cause | A human owner must confirm the amount, the authority to act, and that it's actually done |
| Relocation need | Relocations | Relocations owns placement; GX owns the guest conversation until the handoff is accepted |
| Phone call | Whichever voice queue is staffed for that call type, including VIP and Reservations lines | The team that answers owns the interaction and any follow-up it creates |
What Duckie can, and can't, do
Duckie is AvantStay's AI agent inside Zendesk. Eligibility to answer is set per topic, not guest by guest—so "eligible" only means the ticket is allowed to reach Duckie, not that Duckie will resolve it.
-
Duckie may answer when
- The ticket is explicitly eligible under the current topic taxonomy
- Guest, booking, property, and stay context are all sufficiently matched
- The answer is backed by an approved source or tool result, not invented
- No conflicting prior answer already exists on the thread
- The action doesn't require an unsupported promise, an exception, or a financial or legal judgment call
-
Duckie must hand off to a human for
- Emergencies, safety threats, injury, fire, flooding, gas, or a guest unable to get into the home
- Relocation decisions
- Refunds, compensation, negotiated rates, or any financial commitment
- Legal, fair-housing, assistance-animal, privacy, fraud, or policy-exception questions
- Reservation changes that require action on the OTA side or in inventory
- Conflicting facts, uncertain guest matching, or a stay that's visibly deteriorating
- Sensitive service recovery, where judgment and discretion matter more than a fast reply
The guest email layer
Email runs on the same booking-level journey as Zendesk, OTA messages, voice, and SpokePhone—it isn't a separate system with its own ownership rules. A guest reply to any of these routes the same way a text or OTA message would: matched to the booking, classified by intent, and sent to the most specific team, not left in general GX.
| Stage | Purpose | |
|---|---|---|
| Booking | Booking confirmation | Confirm the reservation, introduce the Booking Hub, surface payment or policy requirements |
| Booking | Guest invite | Give an invited traveler access to the trip and the Booking Hub |
| Booking management | Modified reservation / cancellation confirmation | Confirm what changed, or that a cancellation is complete |
| Compliance | ID verification & guest agreement reminders | Explain the outstanding requirement and link to completion |
| Pre-arrival | Check-in pending steps | Tell the guest exactly what's still blocking their check-in instructions |
| Pre-arrival / arrival | Check-in instructions | The authoritative arrival, access, parking, and wifi details, once payment, IDV, and agreement clear |
| Hotel arrival | Get-ready / room-ready email | Set arrival expectations for hotel guests, release room detail only once actually ready |
| Concierge | Intro, then two marketing follow-ups | Introduce Concierge, then offer eligible services—chefs, experiences, transportation, provisioning, wellness |
| Optional offers | Early check-in, late checkout, mid-stay clean, extension | Purchasable, inventory-dependent add-ons surfaced when eligible |
| Post-stay | NPS / review survey | Solicit feedback once the stay is complete |
Collision rules worth calling out: a stale offer should suppress itself after a cancellation or inventory loss, a declined or opted-out guest shouldn't get a repeat Concierge campaign, and the post-stay survey shouldn't go out while an active, unresolved service-recovery issue is still open—the human recovery owner reaches the guest first.
SpokePhone: the local team, not the system
The line between what's automated and what's a real person texting the guest is deliberate. System automation owns anything transactional or compliance-related; SpokePhone owns everything that's supposed to feel like a person on the ground.
-
System automation owns
- Booking confirmation, payment, IDV, and agreement requirements
- The Booking Hub, check-in instructions, access codes, parking, and wifi
- Eligibility-based offers, room-readiness release, and post-stay surveys
-
SpokePhone owns
- Local-team introduction and staffed hours
- Local recommendations and quiet-hours reminders
- Proactive, situational human support—not restating credentials the system already sent
This lines up closely with the real message shown on the comms map's check-in-day page—same structure, same local-team framing, same after-hours fallback to Guest Experience.
When a stay is at risk: the recovery loop
A real-time, weighted stay-risk score is one concept being explored to formalize this—replacing a looser, proposed set of triggers with a single, continuously updating signal.
A stay-risk score, as one possible design
-
What could feed the score
- Recent reviews on the home
- Open or recent in-stay issues
- Messaging and ticket sentiment across channels
-
How it's meant to behave
- Updates regularly, from check-in through checkout
- Weighting and inputs are visible and adjustable, not a black box
- A proactive GX outreach during the stay can itself move the score back up
- Comes with a visual breakdown of why a stay is flagged, not just one number
What should trigger proactive outreach today
-
Signal-based
- Sentiment scanning points to a likely one- or two-star stay
- Repeated unresolved contact, or the guest asking again for the same fix
- An unresolved safety, cleanliness, access, HVAC, wifi, or maintenance issue
-
Process-based
- A Duckie handoff has sat without clear human ownership
- A promised follow-up, repair, or callback is overdue
- The guest expresses real dissatisfaction, threatens a review or chargeback, or stops responding after a material failure
Where this actually stands: an idea under exploration, not a built system. It would need real data validation and leadership sign-off before becoming a formal, adopted process.
What "done" actually means
A workflow isn't finished when a reply goes out—it's finished when the guest has a correct, current answer, the task has a named owner, and anything promised is confirmed, not just requested.
-
GX / VIP / hotel team
- Owns the guest relationship and keeps them updated as it moves
-
Field Ops, vendor, or specialist team
- Owns the functional execution—the repair, the refund, the reservation action
-
CX leadership
- Owns urgent coordination and escalation when normal ownership stalls
-
Recovery caller
- Owns the proactive check-in itself, not the underlying fix unless explicitly assigned
Optimize, upsell, and build a better experience
Reading the routing model against what's already built on the rest of this site—the personas, the hotels reputation scorecard, the earlier brand-voice feedback—surfaces a few concrete places to act.
-
Risk reduction
Fix the wellness-check double-send first
Both system automation and SpokePhone can independently send a "how's everything going?" message a few hours after check-in. That's flagged as a required control, not yet solved. Two identical check-ins from two different senders reads as impersonal—the opposite of the local-team promise this whole map is built around.
-
Reviews & revenue
Get a real-time stay-risk score built, not just discussed
This is the single highest-leverage step for the hotels page's actual goal: catching a likely one- or two-star stay while there's still time to recover it protects the review and the rebooking at once. Give it an owner and a response-time SLA, and feed it from the reputation scorecard so lower-scoring properties get priority coverage.
-
Upsell
Personalize Concierge marketing by persona
The two-email Concierge follow-up sequence looks like one generic offer for every eligible guest today. The personas already built on the vacation rental page—hot-air-balloon-level concierge for the Ashworths, group packages for a Bailey-style celebration, family bundles for the Whitfields—are ready-made hooks for raising attach rate on a touchpoint that already exists.
-
Brand voice
Bring "the local team" forward from check-in day
The SpokePhone welcome text is the first point a guest hears from a named local team instead of a centralized system—exactly the local-identity feedback noted on the comms map. The Concierge intro and check-in-instructions emails are still centralized voice; introducing local-team language there would make the handoff to SpokePhone feel less abrupt.
-
Upsell
Give recovery a middle option between apology and refund
The recovery workflow is explicit that a generic refund shouldn't be the opening move—and leadership separately wants refunds to actually be fast to execute once they're warranted. Both are true at once if there's a defined lightweight resolution—an on-property credit, a late-checkout comp, a discount on the next stay—for lower-severity saves, with the full refund path reserved for when it's genuinely warranted. A defined middle tier turns a real recovery into a soft rebooking play instead of a pure cost.
-
Reviews & revenue
Join the review-watch list to the reputation scorecard
This routing model flags review risk from sentiment and handoff signals; the hotels page flags it from actual TripAdvisor, Google, and Booking.com scores. The two aren't connected yet. Starting the Sunday/Monday executive review from confirmed low scores, not just inferred sentiment, tightens a loop this doc itself still calls proposed.
Before this is the operating source of truth
The source document is explicit about separating confirmed behavior from observed patterns and proposed controls. These are the pieces it flags as still needing an owner, a sign-off, or a live export.
-
Pending
Stay-risk score: owner & SLA
An idea, not a built system. The weighting and inputs still need to be worked out and validated before this is a real, adopted model with a named owner and a response-time target.
-
Pending
Executive & VRBO outreach ownership
Splitting the high-risk review-watch list among CX leaders and executives, with explicit Sunday/Monday coverage, is proposed but not yet assigned.
-
Infrastructure gap
Zendesk Admin export
Exact trigger and automation order, group IDs, business hours, overflow rules, SLAs, and the live IVR tree all live in Zendesk Admin configuration and aren't reflected in this document yet.
-
Infrastructure gap
Per-market SpokePhone template audit
Welcome-message coverage is strong across active markets but not universal, and exact send times, wording, and opt-outs vary by market—a full audit is still needed to confirm no market collides with the system-owned messages.
-
Open question
The sample guest journey
A fictional end-to-end walkthrough (booking confirmation through post-stay survey, with real message and SMS mockups) exists in a private, time-limited review build. It hasn't been folded into this public page yet.