You make real-time personalisation pay in three steps: name the short list of moments where speed changes the outcome, fix the identity and data those moments fire from, then build real-time only there and leave everything else on batch. The discipline is not making the whole stack fast. It is being precise about where fast is worth the cost.
The trap with real-time is treating it as a setting to switch on across the board. It is not. It is an expensive capability that earns its keep in a handful of moments and wastes money everywhere else. This playbook is the sequence to find those moments, build the foundation under them, and keep the rest of your stack sensibly slow.
Step 1: Name the moments where speed changes the outcome
Start by refusing to make everything real-time. Walk your funnel end to end and, at each point where you personalise, ask one question: if this response arrived fifteen minutes late, would it still work?
Most of the time, the answer is yes. A product recommendation, a lifecycle email, a win-back offer, all of these survive a day of age without losing value. Mark them batch and leave them alone.
A short list will fail the test. In almost every business it is the same three. Cart recovery, where intent cools by the hour and a next-day chase catches a customer who has already moved on. In-session next-best-action, where the useful nudge is the one that lands while the customer is still browsing. And service recovery, where a fast, acknowledged response right after something breaks is the difference between a retained customer and a churned one.
Write that list down. It is your real-time scope, and it is deliberately small.
Owner: the customer or lifecycle lead, working from the funnel, not the vendor’s feature list. Measure the step by its output: a named, agreed list of real-time moments and an explicit decision to leave the rest on batch. If the list has more than five entries, challenge it.
Step 2: Fix the record the real-time moments fire from
Speed multiplies whatever quality you already have. A real-time response reacts to the customer the system can see in that instant. If it cannot identify the person across app, web, and store, or the data it holds is stale, you react fast to the wrong customer or the wrong context. That is worse than being slow.
This is why real-time is a high-difficulty fix, and why it comes after two others in the series, not before. It sits on top of resolved identity and clean data. 43% of companies struggle to maintain accurate, real-time customer data, and 29% cannot give internal teams a single source of truth (Contentful). You cannot orchestrate in the moment on a record that is neither current nor agreed.
So before you build anything fast, harden the foundation under your named moments only. Make sure the customer resolves instantly across the touchpoints those moments span, the work in identity resolution. Make sure the fields those moments read, cart contents, last action, service status, are trustworthy and fresh, the work in data quality. You do not need a perfect single view of everything. You need a reliable view of the few signals your three moments depend on.
Owner: the data lead, with a scope limited to the fields and identities the real-time moments touch. Measure it by resolution and freshness on those signals: can you identify the customer in the moment, and is the data they fire from current. Do not proceed to Step 3 until this holds.
Step 3: Build real-time only there, keep the rest on batch
Now build, and only on the list from Step 1. Wire the streaming or event-triggered response to the named moments and nothing else. Cart recovery fires within the hour, not the next morning. In-session next-best-action reflects the current session. Service recovery responds while the problem is still fresh.
For everything outside the list, keep the batch flow exactly as it is, on purpose. This is the discipline most teams miss. Having felt the pain of lateness, they buy streaming infrastructure and point it at the whole stack, spending real money to make weekly emails a few hours fresher. Do not. Scope the infrastructure to the moments that pay for it. A day-old recommendation is not a defect you need to fix.
Owner: engineering builds it, the lifecycle lead owns the outcome. Measure each moment against its own number: cart recovery conversion at one hour versus next day, in-session action taken versus ignored, retention after a fixed service-recovery response. If a real-time build cannot move its moment’s metric, it did not need to be real-time, and you have learned that cheaply.
How to train your team to hold the fix
The instinct this fix fights is “real-time everywhere”. Marketers hear that a competitor went real-time and want the same badge across every flow. Teach the opposite reflex. The goal is not speed, it is speed where speed pays, and slowness everywhere it does not cost anything.
Make the batch-versus-real-time decision a standing question, not a one-off project. When someone proposes a new personalised flow, the first ask is: does this moment fail if it arrives late? Most will not, and naming that out loud stops the stack sprawling into expensive real-time it never needed.
Give the real-time list a single owner who guards its length. The list should grow slowly and only with evidence that a new moment loses money to delay. And keep the foundation honest: whenever you add a real-time moment, someone confirms the identity and data under it hold first, so the team never ships fast on top of a record it cannot trust.
Where Morphy helps
This is a scoping and sequencing job before it is a build, and that is how we run it. In a four to six week engagement we walk your funnel, name the real-time moments that actually change the outcome, and check the identity and data foundation under them. Then we build real-time on that short list and leave the rest of your stack on batch, so you are not paying streaming prices for flows that were fine slow.
The metric we commit to is the moment’s own number, measured before and after: cart recovery conversion inside the hour, in-session action rate, or service-recovery retention, whichever your named moments are. You leave with a small, working real-time capability where it pays and a clear decision to keep everything else batch, not a platform running fast on data it cannot trust.
Go deeper on customer data maximization
Three ways forward. Pick the one that fits where you are.
- Get the playbook. Practical notes on turning the customer data you already own into revenue, straight to your inbox. Join the newsletter at the foot of this page.
- Take the assessment. Score your customer data maximization in four minutes and see your top revenue blockers. Start the assessment →
- Book a meeting. Bring your data problem. Leave with a prioritised fix, not a platform pitch. Book a call →
The playbook companion to Why is your real-time personalisation always late, and how do you fix it?. Post 14 of 25 in the Customer Data Maximization series.
Frequently asked questions
How do you decide which use cases need real-time?
Walk your funnel and ask one question at each point: if this response arrived minutes late, would it still work? Where the answer is no, you have a real-time moment. Where a day-old response is fine, keep it on batch. Most of the funnel stays batch. A short list earns real-time.
What foundation does real-time personalisation need first?
A resolved customer record and current data. Real-time fires from whatever it can see in the moment, so if you cannot identify the customer across app, web, and store instantly, or the data is stale, you react fast to the wrong context. Fix identity resolution and data quality before you add speed.
Is it worth buying streaming infrastructure for personalisation?
Only for the moments that lose money to delay. Buying streaming to make weekly recommendations a few hours fresher is spend without a return. Scope the infrastructure to cart recovery, in-session next-best-action, and service recovery, and leave the rest of the stack on batch.
How do you measure whether real-time personalisation is working?
Measure the named moments directly. Cart recovery conversion at one hour versus next day. In-session action taken versus ignored. Service-recovery retention after a fixed real-time response. If a real-time build cannot move its own moment's number, it did not need to be real-time.