Be clear with yourself about how thin your signal is walking into a meeting like this. What normally reaches you is a line from a rep — the prospect is interested in personalization in the booking path and in the onboard experience — and that is the whole of it. Going in you will not know their reservation system, their revenue-management platform, their cloud, their current personalization stack, who owns it, whether they have already built a version of this, or who the economic buyer is. So this script deliberately does not pretend. Everything cruise-specific in the demo is the public surface any traveller already sees — the booking site, the Cruise Line App, the Trip Planner, and a loyalty programme with published tier thresholds — and nothing in it names anyone’s internals, because you will not know their internals. What the demo is for is to be recognisable enough that they correct it. Several stages end with a question rather than a claim, and that is on purpose: the corrections are the discovery. If you walk out with an accurate picture of what they have already built, how fresh their deck plan really is, and who owns the booking path, the session worked, whether or not they agreed with a single slide.
I want to start at one step in your booking path, because everything I am going to show you today hangs off it. It is stateroom selection. A family gets all the way through the sailing, the date, the cabin category and the guest count, they reach the deck plan, and that is where they stop. They close the tab. And they come back, and they do it again. I am guessing that step shows up in your funnel data the way it shows up in everyone else's, and if it does not, I would genuinely like to hear that, because then I have the wrong problem. Now let me be honest about the position I am in. This is our first real conversation about this problem. I do not know your reservation system, I do not know your revenue-management platform, I do not know what you have already built in this area, and I would not be surprised to learn you have built a good deal of it. So what you are about to see is not a proposal. It is a shape that we think is roughly right, put on the screen so you can tell me where it is wrong, and the places you correct me are the most valuable part of this hour. One more thing before I show you anything. Redis does not price the cruise and Redis does not decide the promotion. Your revenue management and your offer engines do that, and they should — you are the people who know what a balcony on a March sailing is worth. What Redis does is assemble the shopper's cross-session context and the live inventory picture so that those engines decide with the whole picture in front of them, inside the page render. That is the only claim I am making today, and it is meant to be argued with.
Let me name what I do not know before I walk this, because otherwise the diagram will look more confident than I am. I do not know what your reservation and inventory system is. I do not know what runs your revenue management or your promotions. I do not know your cloud, and I do not know which of these boxes you have already built. So read this with your logos left off on purpose. I have drawn it as a hypothesis, and I would like you to tell me where it is wrong. Sources tier, and this is the part I am guessing at most: your reservation and stateroom inventory system, your revenue-management and fare platform, the Compass Club loyalty system of record, your promotions and campaign catalogue, and whatever warehouse your analytics and feature history live in. None of that moves in this picture. Ingest tier: Redis Data Integration runs change data capture out of those operational systems — cabin-level availability and holds, fares and promotion eligibility, loyalty tier and points balance, and the shopper's own session and filter history — with seconds of lag and no batch window. Context tier: Redis holds one live view of the shopper and of the sailing. RAM for what the page render needs in this instant, Flex for the longer browsing history at tiered cost, Redis Search for similarity across sailings and shopper behaviour. Then the decision tier, and I want this one to be visually obvious: that is yours. Your pricing engine sets the fare. Your offer engine picks the promotion. Redis does neither. It hands them the assembled context and the live inventory picture and gets out of the way. Act tier: the booking site, the Cruise Line App, the Trip Planner, and your call centre and travel-agent channels all reading the same view rather than each keeping their own copy. So my question at the end of this stage is a real one, not rhetorical. Is that shape roughly right? Where would you redraw it? Because if you already have a serving layer doing the context job here, I want to know that now rather than in twenty minutes.
Let me get out of the diagram and walk one shopper through eighteen days, because that is where this gets specific.
Jennifer Alvarez. Compass Club Sapphire, sixty-eight cruise points. Onyx is eighty, so she is twelve points short and she knows it. She is shopping a seven-night Eastern Caribbean sailing for four people: herself, her husband Marco, and their children Sofia, who is fourteen, and Mateo, who is nine. This is her seventh session across eighteen days. Four of those sessions were on mobile, three on desktop. And here is the part I want you to sit with: in every single one of those seven sessions she applied the same three filters. Balcony. Four guests. Connecting. Not similar filters — the same three, seven times. Twice she got all the way to the deck plan and closed the tab. She is back right now, on desktop, logged in. So what is she actually doing? She is not price shopping. Somebody price shopping changes their filters — they widen the cabin category, they try a different week, they look at an inside stateroom to see what it saves. She has done none of that. She has held the same three filters for eighteen days, which means she is not looking for a better fare. She is looking for two cabins that connect, on a sailing she already wants, and she has not been able to find them. And this is where I think cruise is genuinely different from airline retail, which is the comparison people reach for. In air, the seat map is a nice-to-have. The transaction closes without it. Here, she eventually has to choose a specific physical cabin, and for a family of four that means connecting or adjacent cabins — which is real, scarce, physical inventory that moves while she is shopping. So the deck plan is not the last decorative step of your funnel. It is the step where the hardest constraint in the whole purchase finally gets tested, and it is tested against a page. Twice now, that page has not been able to answer her, and she has left. That is not an engagement problem. She is about as engaged as a shopper gets.
So what would the page need to know to answer her, and how fresh would it have to be? That turns out to be two very different questions.
There are two clocks running in this problem and they have almost nothing in common, and I think that is the whole engineering story. The first clock is slow. Jennifer's history is eighteen days long and it spans seven sessions and two devices. To be useful it has to survive weeks, survive her switching from her phone to her laptop, and still be readable at page-render time. That is a persistence and identity problem. The second clock is fast, and it is brutally fast. Cabin 10248 is either available right now or it is not, and it can change between the moment your page starts rendering and the moment she clicks. Holds expire. Group blocks release. A travel agent books the pair four minutes ago. So one half of this view has to remember eighteen days and the other half has to be true this second, and the page needs both at the same instant. Change data capture is how you get the fast half honestly. Redis Data Integration reads the change log from your reservation and inventory systems and keeps the cabin-level picture current with seconds of lag — no nightly extract, no batch window, no hand-written sync job for somebody to own. The systems of record stay authoritative; Redis holds a read-optimised projection of the narrow slice a page render actually needs. And your warehouse stays your analytical layer. This is not a second copy of truth sitting beside it. Now here is the question I most want answered in this meeting, and I am not asking it to score a point. How fresh is your deck plan today, really? Not the number in the design document — the number in production, at peak, on a hot sailing. Because in most estates that answer is measured in minutes, and there is usually a very good reason for that, which we will come to. If your deck plan is genuinely current to the second against live inventory, then a large part of what I am about to show you is already solved and I would like to know that now. If it renders from a cached snapshot, that is the thread I would pull on for the rest of this session.
Assume for a moment the fast half and the slow half are both there. Here is what the page could then read about her in one call.
This is one call, seven point eight milliseconds, and it is the same call whether the website makes it, the app makes it, Trip Planner makes it or your call centre makes it. Look at what is in it, because there are really only three facts here and they almost certainly live in three different systems in your estate today. First fact: eighteen days of filter intent. Seven sessions, four mobile, three desktop, the same balcony–four guests–connecting filter every time, and two abandonments recorded at the deck plan specifically. That probably lives in your digital analytics or your session store. Second fact: live cabin availability for the March fourteenth Horizon sailing, down to which specific staterooms are open and which pairs actually connect. That lives in your reservation and inventory system. Third fact: sixty-eight points, Sapphire, twelve short of Onyx at eighty. That lives in your loyalty system of record. Now — each of those three is easy to get on its own. You can get any one of them today. A report can get all three by tomorrow morning. What is hard is having all three in the same place, at the same moment, inside a page render, with the inventory half true to the second. That is the actual engineering problem, and it is the reason this is a data-layer conversation rather than a merchandising one. Because think about what the three of them together say that none of them says alone. The filter history alone says she likes balconies. The inventory alone is a yield question. The points balance alone is a progress bar in her account page. Put them in one view and they say: here is a shopper who has been trying for eighteen days to find two connecting balcony cabins, there are exactly three such pairs left on the sailing she keeps returning to, and this booking would carry her past Onyx. That is not a smarter prediction. It is the same shopper, finally visible in one place, at the moment the page has to decide what to draw.
Your engine does not read a screen, though — it reads features. So here is what actually gets served to it.
A hundred and twenty-four features, served in four point six milliseconds. Let me be exact about whose work is on this screen, because it matters. The feature definitions and the scoring are yours. The context is ours. Look at what the hundred and twenty-four are made of: loyalty tier and points-to-next-tier distance, cabin category filter persistence across sessions, guest-count and party-composition signals, connecting-cabin requirement, deck and venue proximity for a nine-year-old and a fourteen-year-old, abandonment step and recency, device mix across the journey, live cabin availability and hold state at the individual stateroom level, connecting-pair availability, fare band and promotion eligibility, days to sailing, and days since first session. None of those are model outputs. They are facts about a shopper and a sailing, served at read time. And they are the same definitions your team would use offline, which matters more than it sounds: the feature that went into training is the feature the engine reads when the page renders, so nobody is debugging a gap between what the model learned and what it sees in production. I will say the split once more because it is the sentence I would want you to remember from this stage. The price is yours. The context is ours. Nothing on this screen asks you to move a pricing model, retrain anything, hand a decision to a vendor, or leave whatever platform your team has standardised on. What changes is that the features arrive fresh enough and fast enough to be used while she is looking at the page, rather than in a batch that ran last night.
So with those features in front of it, here is what your engine decides — and the second card is the one I want to argue about.
Before I read this ranking, the boundary again, because this is the stage where it matters most. Redis did not price any of these and Redis did not choose any of these. Your revenue management set the fares. Your offer engine picked the promotions and applied your policy. Redis made the context readable in time for those decisions to be made with the whole picture. That is the entire division of labour on this screen. Number one, scored zero point nine one: Horizon, March fourteenth, staterooms 10248 and 10250 — a connecting balcony pair — at her Sapphire rate. Read why it wins. There are exactly three connecting balcony pairs genuinely available on that sailing, and this is one of them. It is first among the three because it is the only pair with both Kids Club and a teen space within two decks, which for a nine-year-old and a fourteen-year-old is the difference between a holiday and a logistics exercise. Her Sapphire rate is in the first price she sees, not three steps later after she has already anchored on a higher number. The page notes that this sailing clears eighty points, which is Onyx. And the pair is held for the duration of her session, so the thing she came for does not evaporate while she reads about it. Now number two, and this is the card I actually want to talk about, because it is where a price-led ranking gets this wrong. Aurora, same week, lower fare. Cheaper. And it ranks second, at zero point zero seven. A ranking built primarily on price would have put it first, and it would have been wrong — because there are no connecting balcony pairs left in her band on that sailing. What she has failed to find for eighteen days is not a fare. It is two cabins that connect. Show her a cheaper sailing that cannot house her family the way she needs and you have not made her a better offer, you have made her do the deck plan again, which is the exact thing she has already walked away from twice. Third card, zero point zero two, and suppressed: the live inside-stateroom campaign. This is the promotion running right now with the biggest discount attached to it. It loses here on purpose. She has never booked an inside or an oceanview stateroom in four sailings, and she has filtered to balcony in seven consecutive sessions. The discount is real and it is simply not for her. That is a discount losing on purpose, which I think is the healthiest thing on this screen, because the campaign still exists and still works — for someone whose behaviour says they would take it. Does that ranking look like something your engines could produce if the context were in front of them? That is a genuine question.
Let me put arithmetic on that, and be honest about which parts of the arithmetic are mine rather than yours.
Same boundary next to the money, so let me say it plainly: Redis does not price the cruise and does not pick the promotion, so Redis does not claim the booking's revenue. What this arithmetic describes is what the architecture makes possible, and every input on the screen is labelled. Three inputs. First: sessions abandoning at stateroom selection per year, and I am using one point two million. That is a Redis assumption. I do not have your funnel and you do. Second: the recovery rate, which is the one input I vary to build the range. Third: contribution per recovered booking, and I am using four hundred dollars. That is also a Redis assumption. Conservative case, recovering one percent of those sessions: four point eight million dollars a year. Midpoint, at two percent: nine point six million. Aggressive, at four percent: nineteen point two million. Notice how that range is built, because it is not a spread designed to make the number look safe. The volume stays at one point two million in all three. The contribution stays at four hundred dollars in all three. Exactly one input moves. That is deliberately boring, and it means you can attack it precisely instead of arguing with a black box. And this is gross of any Redis licence — I have not netted our own cost out of it and you should, when you get to that stage. So here is my actual ask on this screen, and it is the most useful thing that could come out of this hour. Two of these three numbers are mine, and they are the weakest part of my case. What are yours? You know how many sessions die at stateroom selection, because it is in your funnel data, and you know what a recovered family booking contributes. If your abandonment volume is a third of what I have assumed, I would much rather learn that in this room than defend a number I invented. Take the model. It is more useful to you with your numbers in it than it is to me with mine.
Let me show you both versions of Jennifer's seventh session side by side, because that is what the arithmetic is actually made of.
Same shopper, same sailing, same session, two page renders. Left side, cached snapshot. The deck plan loads and it looks fine. It shows her a grid of staterooms, several of which are already sold, because the snapshot is minutes old and those cabins went in the meantime. It does not mark which pairs connect, so she is left reading cabin numbers and guessing at adjacency. Her Sapphire rate appears three steps later, after she has already anchored on a higher price. Nothing tells her this sailing would carry her to Onyx. Nothing is held. And I want to be careful here, because nothing on this side is broken in a way you could file a bug against — every component did exactly what it was built to do with the data it had. She closes the tab. That is abandonment number three, at the same step as one and two. Right side, one view. The page opens directly on the three connecting balcony pairs genuinely available on the March fourteenth Horizon sailing, with 10248 and 10250 first, because it is the only pair with both Kids Club and a teen space within two decks. Her Sapphire rate is in the first price she sees. The page notes that this sailing clears eighty points and takes her to Onyx. The pair is held for the session. Eighteen days of context, assembled in seven point eight milliseconds. Same shopper. Same inventory. Same engines making the pricing and promotion calls on both sides. The only thing that changed between those two renders is what the page was able to know at the instant it drew.
Let me close by handing the pricing and the promotions back to you, and then ask you the question I actually came with.
Let me hand the important parts back to you before I finish, because they were never on the table. Pricing is yours. Redis does not price the cruise. Promotions are yours. Redis does not pick the promotion. Your revenue-management platform and your offer engines keep every decision they make today, and they should, because you are the ones who know what a connecting balcony pair on a March sailing is worth. The reservation and inventory systems stay authoritative. Your warehouse stays your analytical layer. The only claim I have made in the last fifteen minutes is one architectural claim: that the shopper's journey is measured in weeks and the cabin inventory is measured in seconds, and the page has to be right about both at the same instant — which is a data-layer problem rather than a merchandising one. And I should be straight with you about where this leaves me. I came in here without knowing how you have built this. Everything you have seen is a shape I inferred, and if it is wrong in its bones I would much rather hear that today. So the three things I would like to leave with are not commitments. First, what have you already built here — because if you have a serving layer that gives every channel the same shopper context fast enough to use at render time, then most of what I showed you is solved and I should be talking to you about something else. Second, how stale is your deck plan today, in production, on a hot sailing. And third, who actually owns the booking path — because personalization in the booking path and personalization onboard are different conversations with different owners, and I do not yet know which one I have been having. If I leave with honest answers to those three and no agreement at all, this was a good use of your time and mine.