At 20:32, a hotel receives an Instagram message:

“Good evening. We are looking for a room for 5–7 September: two adults and a six-year-old child. Our flight arrives at 01:10—can you collect us from the airport? And can we amend the booking if the flight is rescheduled?”

For the guest, this is one conversation about one future stay. Inside the hotel, the enquiry can easily fragment into several disconnected actions. The social media team sends a screenshot to reservations. The reservations team checks availability, front office confirms the late arrival, the driver checks whether an airport transfer is possible, and someone searches the rate rules for the amendment terms. Later, the guest books on the website using a different email address. The message is closed as “handled” in the inbox, but nobody sees that it ended in a booking. The late-night transfer task, meanwhile, still has no confirmed owner.

This is how the hotel’s invisible conversion funnel emerges: the path from the first message to a decision exists, but its stages, owners and outcome are scattered across channels, systems and departments.

The first reply is not the end of an enquiry. It is only a change of state. Commercial value appears when the hotel preserves the context, provides a verified answer and a clear next step, and traces the enquiry to a known outcome.

The first message starts a separate path to a decision

In conventional analytics, the guest journey often ends when someone enters the booking engine or submits a form. An operational report, by contrast, begins with the number of incoming messages and closed conversations. The two views do not share a common language.

Yet an enquiry about dates, party composition, rate conditions or an additional service is more than a support request. The guest is already doing the work required to buy: checking whether the offer fits their circumstances and reducing the risk attached to the decision. The enquiry should therefore be treated as part of direct sales—without turning every conversation into a pushy sales pitch.

It is equally important not to label every message as part of the same funnel. A hotel receives all of the following at the same time:

  • pre-booking enquiries;

  • questions about an existing booking;

  • requests from guests during their stay;

  • group and corporate enquiries;

  • complaints, refunds and sensitive cases;

  • supplier offers, job enquiries and spam.

Each group has its own correct outcome. For a pre-booking enquiry, that might be a confirmed reservation, a clear no-availability response, or an accepted handover to a groups specialist. For a service request, it is a completed task. Mixing these flows makes the booking conversion rate meaningless and creates a false impression of loss.

The funnel actually branches

The classic funnel image assumes that everyone moves through the same pipe and that every exit on the way down is a loss. Hotel enquiries work differently. They are a sequence of states with valid branches.

Condensed state map

Message captured → intent identified → context sufficient → answer verified → next action offered → guest acts → final outcome confirmed. At any appropriate stage, the path may correctly move to a member of staff, end because there is no availability, change enquiry type or stop at the guest’s initiative.

A proper handover to a person is not a failure. No availability is not a process failure either, provided the guest quickly receives an honest answer or alternative dates. By contrast, a “closed” status with no known outcome is neither success nor loss. It is uncertainty, and it should be measured separately.

Return to our notional enquiry #1842. It has one primary intent—to book a room—and at least three decision conditions: accommodation for the child, a late-night airport transfer and the ability to change the dates. If the system sees only separate sentences, each department may “close its part” while the guest never receives a coherent offer.

Why the path becomes invisible

Analytics stops at the channel boundary

Web analytics can see an advert, a page visit and a click on an Instagram or WhatsApp button. Once the guest crosses that boundary, the conversation often disappears from view. The booking engine, for its part, sees a completed reservation but does not know which conversation removed the doubt that preceded it.

Google Analytics 4 describes funnel exploration as a sequence of defined events: teams can build open and closed funnels, view the time between steps and inspect the next action. Its recommended events for lead generation distinguish lead generation, qualification, work and closure. This is useful logic for designing measurement, but it is not a ready-made hospitality standard or proof that a particular event caused a booking.

One person has several digital identities

A guest may write from a social profile, open a link without signing in, and complete the booking using their partner’s email address. Without a permitted way to connect those events, the systems legitimately see three different users. They should not be merged at any cost: consent, privacy and data-retention rules matter more than a tidy report.

Statuses describe a department’s work, not the guest’s state

“Read”, “replied”, “closed” and “handed over” are convenient inbox labels, but say very little about progress towards a decision. The reply may have been an automated acknowledgement. The link may have led to a generic home page with no dates selected. The handover may have been waiting without an owner.

Manual actions leave no shared trace

A phone call, a screenshot in a private chat, a verbal request to a colleague or a note on paper may save an individual guest experience. At process level, however, each creates a break: the context is not updated, the deadline is not controlled and the outcome cannot be matched to the original enquiry.

Data and accountability are divided between departments

In h2c’s study of AI and automation in hospitality, the data-management section covered 146 respondents: 41% cited data quality, access or integration as barriers; 32% cited cross-departmental data sharing; and 29% cited departmental silos. Only 22% reported having a centralised data structure that feeds AI and automation. The study as a whole collected 189 responses from representatives of 171 unique hotel chains, and results were evaluated by response rather than weighted by chain size. Its findings should not be applied mechanically to every independent hotel. They do, however, illustrate why a separate messaging window does not create an end-to-end process.

A 2025 study by McKinsey and Skift, based on a survey of 1,002 travellers and 86 travel executives, most of them based in the United States, gives a related warning: the value of general-purpose conversational assistants is often diffuse and difficult to measure, while incompatible systems limit their impact. This is not a benchmark for converting hotel messages into bookings. The practical conclusion is narrower: automation should cover the process from start to outcome, rather than one visible reply.

Which events and owners need to be recorded

The best model does not start with a colourful dashboard. First, the team agrees what each state means, which event confirms it, and who is responsible for the next move.

Enquiry state

Event that confirms the transition

Owner and control metric

Captured

A unique enquiry ID is created; channel and time are stored

Duty team member or system; enquiry coverage

Intent identified

Enquiry type, urgency and primary objective are tagged

Reservations or routing rules; intent-classification accuracy

Context sufficient

The minimum data required for the next decision is available without repeated questions

Team member or digital assistant; context completeness

Answer verified

Price, availability and policy come from a designated source

Owner of the relevant data; verified-answer rate

Next action ready

A relevant offer, pre-populated booking path or accepted handover exists

Reservations or front office; offer and handover-acceptance rates

Guest acts

The guest selects an option, starts checkout, supplies data or declines

Event recorded by the system; guest-action transition rate

Outcome known

A booking, decline, no-availability result or other outcome is connected

Process owner or analyst; known-outcome rate

The signs of a hidden break appear between these rows: a message remains in a channel-specific inbox; an enquiry containing dates sits in a general queue; the guest is asked again for information already supplied; an unverified promise or generic page is sent; the enquiry is “passed on” but not accepted; or the conversation is closed as “other”.

For enquiry #1842, sufficient context does not mean knowing everything about the guest. Checking availability requires the dates, number of adults, child’s age and whether an extra bed is needed. Arranging the airport transfer requires the flight number and agreement to the service terms. There is no reason to collect a passport number or payment details “just in case”.

A verified answer may depend on several authoritative sources: availability and rate from the booking engine or property management system; amendment terms from the current conditions for that specific rate; and the feasibility of a late-night transfer from the schedule and confirmation of the responsible team. Only then does a coherent next step exist: a suitable room option with the dates already entered, clear conditions, and a controlled task for the airport transfer.

Five false wins

1. “We replied”

An automated “Thank you, we have received your message” usefully confirms delivery, but does not change the state of the guest’s decision. A substantive reply resolves at least one uncertainty or asks a necessary clarifying question.

2. “The conversation is closed”

Closing an inbox item is an administrative action. If nobody knows whether the guest booked, declined, found no availability or is waiting for a colleague, the outcome remains unknown.

3. “The link was sent”

Sending a web address is an action by the hotel, not by the guest. Even opening the link is not yet a booking. It is better to distinguish between these events: offer sent, guest opened the prepared path, checkout started, booking confirmed.

4. “The enquiry was handed over”

A handover is complete not when the status changes, but when a named member of staff accepts it together with a short summary, the unresolved question and a deadline. Otherwise, one queue has merely become another.

5. “There is a booking”

A reservation in the system may be a genuine commercial outcome, but without a link to the conversation the team cannot establish whether this specific enquiry preceded it. Conversely, a booking made after a conversation does not prove that the reply or AI caused it. The accurate term is a conversation-associated booking.

In our example, the offer reaches the guest at 20:44. At 20:49, the guest opens the prepared page; at 20:56, they confirm the flexible rate; and the system links the booking number to enquiry #1842. The commercial branch is complete. The ancillary-service branch is not: front office still needs to accept the airport-transfer task. One conversation can have several outcomes, and each needs an owner.

How to measure transitions, not message volume

Five short messages from one guest represent one enquiry, not five sales opportunities. The unit of analysis should be a unique substantive enquiry that meets predefined criteria. The denominator changes for each transition:

Transition A → B = (number of unique eligible enquiries that reached state B / number of unique eligible enquiries that reached state A) × 100%.

“Eligible” means the enquiry could genuinely have made that transition. A sold-out-date enquiry is a valid exit before the offer stage, not a failed conversion. Similarly, enquiries about existing bookings should not be mixed with pre-booking enquiries.

A useful set of metrics includes:

  • coverage — the share of enquiries from audited channels that entered the shared record;

  • intent classification rate — the share of enquiries assigned the correct category, validated through a manual sample review;

  • context completeness — whether previously supplied dates, party composition, language, conditions and unresolved question were retained;

  • time in state — the median and 90th percentile between two events, such as captured enquiry to verified offer;

  • transition rate — from sufficient context to offer, offer to guest action, and guest action to confirmed outcome;

  • accepted handover rate — the share of transferred cases accepted by a named team member within the defined time;

  • conversation-associated bookings — the share of eligible enquiries for which a confirmed booking was found under a defined matching rule;

  • unknown outcome rate — the share of enquiries closed without an explained outcome;

  • valid exit reasons — no availability, unsuitable terms, group enquiry, existing booking, spam and so on.

Do not compare automatically handled and manually handled enquiries without adjusting for complexity: employees often receive exceptions, complaints and high-value group enquiries. Season, price, occupancy, campaign activity, availability of a specific room category, lead time and post-purchase cancellation also affect the outcome.

Three levels of linking a conversation to a booking

1. Deterministic link. The guest follows a path prepared for that enquiry with the parameters preserved, and the system returns the confirmed booking number to the conversation record. This is the most reliable operational method, but even it establishes a sequence of events rather than proving how many bookings would not have occurred without the conversation.

2. Probabilistic link. The system matches permitted signals—for example, a verified contact, stay dates and a defined time window. The result should be labelled probabilistic, supported by deduplication rules, and reported with the share of ambiguous cases visible.

3. Aggregate diagnosis. The team compares groups of similar enquiries: with and without an offer, with and without a known outcome, or before and after a process change. This helps locate weak points, but it does not isolate the effect of the conversation from demand, price and availability.

The claim that “AI generated these bookings” requires a controlled causal study, not mere proximity in time. For day-to-day management, it is more honest to say: “These bookings were associated with conversations under this rule; here is the share linked deterministically, linked probabilistically and left unmatched.”

How to start measuring one type of enquiry

1. Select a homogeneous cohort

Start only with pre-booking enquiries that include dates or a desired stay period. Use a continuous observation period—for example, four weeks—and extend it if volume is low, without adding existing reservations, in-stay requests or spam.

2. Reconstruct boundaries, not every message

For each unique enquiry, record the time and channel of arrival, intent, context sufficiency, source of verified data, proposed action, whether a handover was created and accepted, and the final outcome. Mark duplicates and anything that cannot be reconstructed separately: the proportion of such records is itself a measure of data quality.

3. Agree an event dictionary

Define one observable event, one owner and an acceptable time limit for each transition. Agree how “received” differs from “substantively answered”, “handed over” from “accepted”, and “booking created” from “booking confirmed”. Add precise exit reasons instead of a universal “other”.

4. Configure one end-to-end branch

Preserve the dates and party composition already supplied, designate the authoritative source for price and availability, create a relevant next step, and return the confirmed booking number to the conversation record. For handovers, add explicit acceptance by a named team member—not merely a notification.

5. Audit the records manually

Calculate transitions, time in each state, unknown-outcome rate and valid exit reasons. Review a random sample: was the intent classified correctly, was context lost, and was a generic reply counted as an offer? Compare only similar enquiries and record changes in price, availability and demand. Then select the single gap with the greatest volume or risk—and only then expand the process.

Where AI helps—and where a person is required

AI is most useful here as a state coordinator: it can create a unique enquiry ID, tag intent, carry forward conditions the guest has already provided, monitor handover acceptance and flag cases whose outcome has not been recorded.

No state should be marked “verified” unless the price, availability or policy came from a designated source. The system must not invent these facts, guarantee an unconfirmed airport transfer, make an exception to a rate condition, resolve a payment dispute, or conceal that an authoritative source is unavailable.

Good automation does not try to keep every conversation away from a person. It recognises the boundary of its authority, hands over all collected context and monitors acceptance. The objective is not the fewest employees in the conversation, but the fewest blind transitions.

How Greetio fits into this model

In this model, Greetio can act as a connecting layer between linked channels, data sources and teams. Conversation history, source and status help preserve the original context. A connection to the hotel’s property management system, booking engine or calendar makes current availability data accessible; confidence rules route ambiguous cases to a team member; and tasks assign the next action to the right department.

The value of such a system is not determined by the number of automated replies alone. It appears when the hotel can see the enquiry state, the source of each fact, the owner of the next step and the recorded outcome. How complete that view is depends on which channels and systems are actually connected, how current the data is, and whether the team has agreed its outcome rules.

For enquiry #1842, this means one record instead of a chain of screenshots: dates and party composition are preserved; the room and rate are confirmed from the appropriate source; the amendment terms are attached to the offer; the booking is linked to the conversation; and the late-night transfer task has a named owner and an acceptance marker.

Conclusion

After the first message, the guest does not simply enter “support”. They continue making a decision about their trip, while the hotel begins an invisible relay between data, people and systems.

A managed funnel does not require every conversation to be counted as a sale. It requires the hotel to separate enquiry types honestly, define observable states, preserve context and know the correct outcome for every branch. A reply, a closed conversation and a sent link are only intermediate events.

Start with one homogeneous enquiry type and trace each case from its channel to a known outcome. Measure where the most context disappears: during intent identification, data verification, offer preparation, human handover or matching to a booking. If a large share ends as “unknown”, that is already a useful finding and a specific place to improve.

Greetio can help bring this journey into a shared workspace—provided the hotel connects the necessary sources and defines its own transition rules. The first step towards a visible funnel is not a new report but one agreement: no important enquiry is complete until its outcome is known; until then, it must remain with the team member who accepted responsibility.