Spa · Cross-selling · Follow-up

A guest asks about the spa.
What happens next?

The interest is there. A useful proposal requires confirmed availability and terms, a timely response and a clear owner of the conversation.

A fictional demonstration of my methodology. It does not make bookings or check real availability. The options are illustrative assumptions, not hotel results.

01 · Try the journey

One enquiry. Three possible situations.

Choose a situation and progress through the confirmations. See what can be offered and what remains pending.

Guest enquiry · Fictional example

«Can we book two massages this afternoon?»

Interest expressed; no booking has been confirmed yet.

Reception

Record and follow through

Requested service, number of people, preferred time and reply channel. A person owns the enquiry.

Enquiry recorded

Spa team

Validate the proposal

Staff and treatment room availability, duration, price and terms. An offered time may need revalidation when booking.

Awaiting verification

Guest

Decide and confirm

Receive a clear proposal, accept or decline it. A booking requires final confirmation from the spa.

No proposal yet

The enquiry has an owner. Availability is still pending.

Reception can record the interest and ask the spa for confirmation. An unverified time or price should not be promised.

This simulation shows process rules. It does not attribute these decisions to AI.

Enable JavaScript to try the buttons. Record the enquiry, check availability and terms, send a proposal, capture the decision and obtain final spa confirmation. Escalate if there is no response; close the enquiry if the guest declines.

02 · What I would analyse

Where does the opportunity lose continuity?

I would review incoming enquiries, response times, availability checks and follow-up ownership. I would verify information freshness and how unsuitable requested times are handled.

Cross-selling should respond to a guest's interest. A pending enquiry does not justify repeated offers or treating a proposal as a booking.

03 · What I would design and deliver

The workflow behind the proposal.

Information and statuses: What is recorded and how to distinguish an enquiry, pending validation, sent proposal, acceptance, confirmed booking and closure without a sale.
Owners and rules: Who replies, who confirms price and availability, when to review an alternative and how to escalate an unanswered enquiry. Timelines are agreed with the hotel.
Confirmation and follow-up: Revalidate availability before confirming. If it changes, consult the guest again. Define proportionate follow-up, permissions and closure.
A basis for implementation: Functional map, sources, fields, permissions, exceptions, system dependencies and test criteria. The technical team verifies feasibility and integrations.

04 · Where AI could help

Draft responses using approved information.

If justified by the assessment, generative AI could draft a response from the catalogue and confirmed terms, or summarise pending enquiries for their owner. I would define sources, permissions and human review.

It should not invent times, prices or health recommendations. Availability and bookings require checks with the authorised system and team. Notifications and follow-up may use conventional automation.

How I would validate the improvement's value

I would measure eligible enquiries, response time, proposals, acceptance, completed bookings, cancellations and service margins. I would compare periods of similar demand and capacity. A booking does not automatically mean additional revenue: costs, cancellations and displacement of other sales must be checked.

Sales increases and savings are not assumed. A pilot must verify what changes and how service is affected.