Cross guest and spend: the map of your best customers

Almost every hotel counts bookings. Very few count people. The difference looks subtle, but it changes everything: a booking is an event that starts and ends; a guest is a story that returns, spends, refers others and, sometimes, leaves for good without anyone noticing. The guest × spend cross is the piece that turns loose rows from your operation into a readable map of who is genuinely valuable. This essay does not argue why that value matters, we take that as understood, but how the cross is built, step by step, inside Spider Data.

The problem: your best customer is split into pieces

Picture a guest we will call Marina. She stayed in March, came back in July, ordered room service on two nights, booked a massage and, on her last visit, reserved through a different channel than the first time. In the raw database, Marina does not exist as a single person: she exists as five or six scattered rows across bookings, orders, payments and cash movements. Nobody on your team sees the whole Marina. They see a July booking, a dinner order, a spa charge, and none of those fragments, on its own, tells you that Marina is one of your top ten customers of the year.

The cross exists precisely to gather those pieces. The goal is simple to state and powerful to achieve: one row per guest, with everything that person has done and spent over time, no matter which table each piece happened to land in.

The pieces you will join

Spider Data crosses eight sources of your operation into a single structure. For this particular map, four of them matter most, though the others add nuance when you want to fine-tune.

• Guests: the identity. The anchor of the cross. Each person, just once.
• Bookings: the stays. When they came, how many nights, through which channel, at what rate.
• Orders: the extra spend. Restaurant, spa, shop, laundry, everything that is not the room.
• Payments and cash: the real money that came in, to tell what was billed from what was actually collected.

The conceptual key is that the room is only part of the spend. A guest who pays a modest rate but dines out, books spa and shops in the store may be worth more than another on a high rate who buys nothing extra. If you only look at the booking, you see half the story. The guest × spend cross exists to see the whole story.

How it is built, without code

In the report builder you drag the tables and connect them. You do not write queries: you indicate what joins with what. The assembly follows a logic worth understanding, even if you do it with the mouse.

Step 1: anchor on the guest

You start with the guests table. That becomes your base row: one person per line. Everything else hangs from there. If you anchored on bookings, you would end up counting stays again; anchoring on the guest is what forces you to think in people.

Step 2: join the stays and the spend

To each guest you join their bookings and their orders. This is what databases call a join: linking two tables by a value they share, in this case the guest identifier. Spider Data does it for you when you drag and connect; you only decide the direction of the join. One person can have several stays and several orders, so a frequent guest will gather many rows behind their single line.

Step 3: sum over time

Then you group and total. Grouping means folding all the rows of one person into one; totaling is the operation databases call a rollup: summing the spend of all their stays and orders, counting how many times they came, computing their average lead time. The result is one line per guest with their lifetime numbers, not those of a single visit.

Group to see: from the list to the map

A table with thousands of guests sorted by spend is information, but not yet a map. The map appears when you group people into a few clear buckets, based on two simple questions: how much do they spend? and how often do they return? Those two axes are enough to draw segments anyone on your team understands without prior training.

A word of caution about language is in order here. The industry has methods with technical names and acronyms for this segmentation, but acronyms do not help the front-desk clerk or the owner who wants to decide today. Spider Data prefers plain names: instead of cryptic labels, groups that explain themselves.

A segment your team cannot explain in their own words is not a segment: it is a label nobody will ever use.Spider Data design principle

The most useful groups are usually few. Too many segments paralyze; three or four, well defined, drive action. A simple division, as an illustrative example, might look like this:

Look at the middle group, frequent and high-spend. It tends to be small in number and huge in weight. Seeing it isolated, for the first time, is often the moment a hotel understands who truly sustains its month.

What the map enables

A guest map is not a dashboard ornament; it is a list of decisions you could not make before because you could not see who you were applying them to. Once each person falls into their group, concrete actions open up:

1. Recognize those who return: a touch at arrival, treatment that recalls their last visit, a welcome that does not feel like a stranger’s.
2. Care for high-spenders before they drift away: if one of your pillars has not returned in months, the map flags it and you decide how to react.
3. Give one-time guests a reason to return: understand why they did not come back and offer something that changes that story.
4. Measure the effect: because the data is live, you see whether an action moves a person from one group to another over time.

And all of this can come to you without your going to look for it. With scheduled deliveries, the updated map lands in your inbox every Monday; with alerts, it warns you when a valuable guest crosses a certain stretch without returning. You can even ask the system in natural language, in plain words, who your best customers of the quarter are, and get the summary without building anything. The AI can also flag patterns that do not jump out: a group that combines certain dates with certain spend, an anomaly in the behavior of your frequent guests.

An important boundary: the map is yours, so are the decisions

It is worth being clear about what Spider Data does and does not do. Spider Data draws you the map: it tells you who spends, who returns, who combines both, and why the numbers look the way they do. It does not tell you what rate to charge or whom to raise it on. It is not a system that sets prices. It measures and explains; the strategy is yours.

That boundary is deliberate. How you treat a high-spend guest, what you offer someone who came only once, how much you invest in retaining your pillars: these are business decisions that depend on your brand, your margin and your judgment. The map gives you the view you need to decide well. The decision, always, is signed by you.

From counting to seeing

A quiet shift happens the day you build this cross for the first time. You stop watching a booking calendar that fills and empties, and you start watching a community of people who return, who spend differently, who have a history with you. The dashboard stops answering how many rooms did I sell and starts answering whom do I sell to, how often and why.

Crossing guest and spend is not just one more reporting technique; it is a change of lens. When you stop counting bookings and start seeing guests, your true business appears: not the anonymous flow of occupied nights, but the handful of people who, visit after visit, decide your hotel is worth it. That map was always there, split into pieces. The cross simply makes it visible, so that at last you can decide with it in front of you.