For Brisbane Gateway Resort (brisbanegateway.com.au), I built dual AI booking agents - text chat and OpenAI realtime voice over WebSockets - that collect arrival dates, duration, and guest count, present accommodation options (caravan, lodge, and more) with property images in the chat, capture guest details by voice or form, and generate a Newbook checkout link so payment completes on the booking system. Both agents use a RAG memory layer for resort guidelines and prior conversation context.
Brisbane Gateway Resort is an Australian holiday park where guests expect fast answers about stays - and a clear path from “when can I come?” to a paid booking. Front-desk staff were answering the same availability and product questions repeatedly, especially outside business hours.
I designed and shipped dual AI booking agents on the resort website: a text chatbot and a voice chatbot. Both run the same commercial flow end to end - intake, options, in-chat property selection, guest details, then a Newbook checkout link for payment - while a RAG memory layer keeps answers aligned with resort guidelines.
Two channels, one booking outcome
Guests pick how they want to talk:
| Channel | How it works | Best for |
|---|---|---|
| Text AI chat | Typed conversation in the site widget | Quiet browsing, sharing links, comparing units |
| Voice AI chat | Spoken dialog via OpenAI realtime over WebSockets | Hands-free, phone-like speed, accessibility |
Either path can finish a booking handoff. Voice is not a separate product - it is the same agent skills with a realtime audio transport.
The booking flow (text and voice)
1. Stay intake
The agent asks for the essentials first:
- When are you arriving?
- How long will you stay?
- How many guests are in your party?
Structured extraction turns those answers into validated fields the rest of the flow can trust - no guessing party size from vague chat.
2. Accommodation options
Based on dates and party size, the agent presents available stay types - for example:
- Bring your own caravan / powered site
- Stay in a lodge or cabin-style unit
- Other on-site resort accommodation options
Guests are not dumped into a generic search page mid-conversation - they get ranked, relevant choices in context.
3. Property media inside the chat
When a guest explores an option, the agent can show property images and/or property links directly in the chat UI. Selecting an image or unit sets the booking target for the rest of the conversation - the UX feels like a sales associate sharing photos, not a form wizard.
4. Guest details - speak them or type them
Once a property is chosen, the agent collects guest details:
- Name
- Phone
- Street address (and related contact fields)
On voice, those details can be spoken into the OpenAI realtime session. Guests who prefer privacy or accuracy can manually enter the same fields in the UI. Both agents accept either path.
5. Newbook checkout link
The agent does not take card numbers in chat. It generates a Newbook booking / checkout link prefilled from the conversation. The guest opens the link, confirms payment on Newbook, and the reservation is complete.
That boundary matters for trust and PCI scope: conversation handles discovery and data capture; Newbook handles money.
Voice architecture notes
The voice agent is built around OpenAI realtime / structured conversational APIs, with WebSockets carrying the low-latency audio and event stream between browser and backend.
In practice that means:
- Bidirectional audio while tools still run (availability, property selection, link generation)
- The same booking state machine as text - so product rules stay consistent
- Optional form fallback when a guest wants to type an address or email instead of dictating it
For deeper realtime voice patterns (telephony, LiveKit, transfers), see my production voice AI architecture write-up - Brisbane Gateway is the hospitality-site variant of that discipline.
RAG memory: guidelines and continuity
Both text and voice agents sit on a RAG-based memory layer:
- Resort knowledge - Brisbane Gateway policies, FAQs, and operational guidelines so answers stay on-brand and factual
- Conversation memory - prior turns in the session (and relevant prior encounters where configured) so the agent does not re-ask dates it already captured
Without RAG, hospitality bots invent pool hours. Without session memory, they frustrate guests mid-booking. The combination is what made the deflection durable - roughly ~30% fewer front-desk inquiries, with 500+ guest interactions handled monthly after launch.
More on the retrieval pattern: RAG vector memory for AI agents.
Working with resort operations
This was not a demo dropped on a marketing page. I worked with non-technical operations stakeholders to map real guest journeys, then iterated from daily feedback:
- Australian English and local place names
- Which stay types to prioritize by season
- When to push Newbook vs when to escalate to staff
- Transcript reviews for edge cases (groups, accessibility, late arrivals)
Stack at a glance
| Layer | Approach |
|---|---|
| Site | Embedded on brisbanegateway.com.au |
| Text agent | LLM conversational UI with tool/function calling |
| Voice agent | OpenAI realtime-style voice + WebSockets |
| Knowledge | RAG over resort guidelines and FAQs |
| Inventory / UX | Stay intake → options → in-chat property media |
| Checkout | Generated Newbook payment / booking link |
| Ops | Transcript review + daily stakeholder feedback |
Results
- Dual text + voice booking paths on the live resort site
- End-to-end flow through Newbook checkout (no card data in chat)
- In-chat property images / links for selection
- RAG grounding for guidelines and conversation continuity
- ~30% reduction in front-desk inquiry volume
- 500+ guest interactions handled monthly
What hospitality teams should copy
- Offer text and voice if your guests split between browsers and phones - keep one booking state machine.
- Collect dates, duration, guests before flooding the UI with every cabin.
- Put photos in the chat - selection conversion jumps when guests can see the unit.
- Hand payment to a real PMS / booking engine (Newbook) via a generated link.
- Ground the bot with RAG so policy answers match the property, not the model’s imagination.
Related work
Common questions
What did the Brisbane Gateway Resort chatbot do?
It offered text and voice booking agents on brisbanegateway.com.au. Guests shared stay dates, duration, and party size; saw available accommodation options with images in chat; selected a property; provided contact details by voice or form; and received a Newbook checkout link to complete payment.
Does the voice agent use the same flow as text chat?
Yes. Voice follows the same intake → options → selection → details → Newbook link path. Voice runs on OpenAI realtime communication over WebSockets, with optional manual entry for street address, phone, name, and email.
What is Newbook in this flow?
Newbook is the resort booking and checkout system. The agent does not take card data in chat - it generates a Newbook link so the guest completes payment on a trusted checkout page.
How does RAG help a resort booking agent?
A RAG memory layer retrieves Brisbane Gateway guidelines and FAQ content, and keeps relevant prior conversation context so the agent does not invent policies or re-ask questions it already resolved.
What accommodation types does the agent present?
Depending on availability for the requested dates, guests can choose options such as bringing their own caravan, staying in a lodge, or other on-site resort accommodation - each with images or property links shown in the chat UI.