Guest segmentation by recency, frequency and monetary value splits a base into groups that deserve different actions. Set the boundaries as quantiles of your own base rather than as round numbers: the same gap between visits means one thing in a lunch canteen and another in a special-occasion restaurant. Keep as many segments as you have genuinely different actions.
Why split the base when the menu on the table is the same for everyone
The menu is one. The message, the moment and the money you are willing to spend on reaching one guest are not. A restaurant that treats its base as a single list pays the same for every contact and gets back wildly different value: the guest who was here on Friday is irritated by a reminder, the guest who quietly stopped coming in March never gets one, and the guest who leaves three times the average check reads exactly the same generic text as everyone else.
Segmentation is not decoration on top of marketing. It is the answer to one operational question with two words in it — who gets which action this month, and who gets none at all. Everything else on this page is the arithmetic that turns a list of names into that answer.
This page holds the split itself and nothing more. Whether you can recognise a returning guest at all, and what share of guests come back, lives on repeat guests and how to count them. What one guest is worth across the whole relationship lives on guest lifetime value. What a loyalty scheme costs to run lives on loyalty programme economics. Those pages work in shares and in money. This one works in ranks and in intervals, and it does not repeat a single one of their formulas.
The split has to live somewhere a host can see it — a tag on the guest card rather than a column in somebody's spreadsheet. That is a CRM job, and the choice of which system layer takes it is the subject of CRM or ERP: which layer you add next.
Three numbers: recency, frequency, money, and what each one means at a table
Recency — days since the guest's last visit.
Frequency — number of visits inside the observation window.
Monetary value — total spend, or total contribution, inside the same window. Contribution is the better base wherever it can be computed, because a guest who orders the highest-margin part of the menu is worth more than an identical bill made of the lowest-margin part; the term itself belongs to the break-even page, which owns its definition.
Three restaurant-specific warnings sit under those three lines.
Recency only exists for a guest you can identify. A walk-in who paid cash and left has no recency, no frequency and no history — not a low score, no score. The size of that unknown part of your base is the first thing to measure, and it is measured on the repeat-guests page, not here.
The window is a decision, not a constant. A lunch canteen with a working-day base can read a 90-day window honestly. A restaurant people book for anniversaries needs a year or more, otherwise almost every guest shows a frequency of one and the whole exercise degenerates.
Money is not the average check. The average check is a property of the restaurant across all guests in a period, and it is defined on the RevPASH page. Monetary value here is a property of one guest across the window. They share a currency and nothing else; mixing them puts a per-restaurant denominator under a per-guest number.
| Dimension | What it shows | How it lies on its own | Read it together with |
|---|---|---|---|
| Recency | How fresh the relationship is right now | A guest who came once, yesterday, ranks with your best regulars | Frequency |
| Frequency | How firmly the habit is formed | Ten cheap lunches outrank two large dinners that paid for the week | Monetary |
| Monetary | How much the relationship has been worth | One wedding party outranks a year of weekly visits and never returns | Recency and Frequency |
Boundaries: why quantiles of your own base beat round numbers
The usual instinct is to draw round lines — "over 1 000 PLN is a big spender", "more than 90 days is lost". Round numbers feel objective and are not. They encode somebody else's price level, somebody else's format and somebody else's calendar.
Quantile boundary — a cut placed so that a chosen share of the base falls on each side of it. It is robust to outliers and independent of the currency, because it is computed from the order of your own guests rather than from the size of their bills.
The shape of restaurant spending is exactly why round cuts mislead, and Polish official statistics show that shape openly. Statistics Poland publishes average monthly spend per person on the category "restaurants and hotels" broken into quintile groups of households: 51.01 PLN in the lowest fifth against 221.95 PLN in the highest (GUS, Household Budget Survey in 2024, Table 8, opened 26.08.2026) — a factor of 4.35 between the ends. The overall average in the same publication is 98.92 PLN per person per month, which lands between the third quintile (70.40 PLN) and the fourth (100.20 PLN), that is, above the middle of the distribution rather than in it.
Read that with the caveat attached, not without it: this is household expenditure across the whole population on restaurants and hotels together, per person per month, self-declared in a survey. It is not your guest base, it says nothing about how often anybody visited, and no boundary on your page can be taken from it.
Recency and frequency have no official source at all. No public statistical office publishes how many days pass between one person's restaurant visits or how many times a year they return to the same room. That is not an assumption on our side: the Eurostat dissemination catalogue was read through on 26.08.2026 and contains no dataset on visit recency, visit frequency, guest loyalty or customer segmentation; its household-budget family measures consumption expenditure by purpose and nothing about sequence. So this page names no threshold as an industry norm, because there is none to name. It gives the method instead.
The method is four steps and no judgement calls: pull every identified guest with their three numbers over one window; sort the base by one dimension; cut it into equal-sized groups; repeat for the other two. Pulling those three numbers reliably is a measurement job, not a memory job — see analytics for what has to be wired up before any of this is honest.
An identical value cannot be cut in half: half the base sits at one visit
A quantile cuts by rank, and for guests holding the same value the rank is arbitrary: their order in the export was set by the sort, not by their behaviour. In a restaurant this is not a subtlety, it is the most crowded spot in the base.
Cut frequency into five bands of 100. Guests with two or more visits occupy ranks 1 to 232. All 268 single-visit guests stand from rank 233 to rank 500 and land across three bands at once: ranks 233–300 get a score of 3, ranks 301–400 get 2, ranks 401–500 get 1. Three different scores on the same single visit, and the difference between them was decided by row order in the export.
The rule is written down once and then held to: a cut is never placed inside a group of identical values. All such guests get one and the same score, the bands come out unequal, and that is a fact about the base rather than a broken calculation. In this example the bands become 100 / 100 / 32 / 0 / 268 — one of them empties completely.
An empty band is useful news rather than an awkward zero: it says that by frequency you do not have five levels of guest but three, and there is nothing to keep a fifth cell for. Hence the requirement on the export itself: print the band population next to the score. A score without a population looks the same whether the band holds a hundred people or none.
How many segments are worth keeping: as many as you have different actions
Five groups per dimension across three dimensions gives 125 cells. Three groups gives 27. Two gives 8. Nothing stops the software from producing any of those numbers, and nothing in them is wrong — the mistake is downstream, when 125 cells arrive at a team that has two messages.
Actionable segment — a group for which a different action is actually planned. A group with no distinct action attached to it is a description, not a segment.
That definition is the whole rule of segment count. Write down the list of actions you are genuinely able to execute this quarter — a personal message from the manager, an automated second-visit trigger, a table held on a busy evening, nothing at all — and count them. That count is your number of segments. If it is three, then 125 cells are 122 pieces of paperwork.
Segment sizes have to sit next to the segment names, or every group looks equally important on the screen. A cell with four guests in it does not deserve a campaign, and you only see that if the count is printed beside the label; that is what a dashboard is for, and which numbers an owner actually looks at is the subject of the reporting-automation article.
Average cell size: how many guests one cell will actually get
The number of actions sets the ceiling on how many segments you keep. The size of the base sets the floor, and it is one line of arithmetic:
Expected cell size = identified guests ÷ (number of bands)³
identified guests— those with a visit history inside the window, in guests;number of bands— how many bands you cut each dimension into, a plain number with no unit;(number of bands)³— how many cells a split across three dimensions produces, again a number with no unit;- the result — guests per single cell.
On a base of 500 identified guests: five bands give 500 ÷ 5³ = 500 ÷ 125 = 4.0 guests per cell; three bands give 500 ÷ 3³ = 500 ÷ 27 = 18.5; two bands give 500 ÷ 2³ = 500 ÷ 8 = 62.5. Checked backwards: 125 × 4.0 = 500, and 27 × 18.5 = 499.5 — the missing half a guest is the rounding to one decimal.
And the caveat it needs, or the number will mislead: this is an average, and here the average is an upper bound on the smallest cell. Cells do not fill evenly; the section above showed a band of 268 people next to an empty one. The poorest cell therefore sits well below the average, and if the average is already down to single guests, you have too many bands.
Do this line before you choose the number of bands, not after the first export: a cell holding four people does not repay even the work of describing it, and at five bands on a base of five hundred guests most cells will be that size.
The score formula, and the one thing you must not do with it
Score of a dimension = rank of the guest within the base in that dimension, cut into equal groups
rank— the guest's position when the whole base is sorted by that dimension; a position, not a value, and therefore dimensionless;equal groups— how many bands you cut the sorted base into, chosen by you and written down: five bands give scores 1 to 5, three bands give 1 to 3;- the score says "relative to the other guests of this base", and it says nothing about PLN, days or visits.
The industry writes these three scores side by side as a three-digit label — 555 for the best, 111 for the worst — and then adds them into one number. The label is useful shorthand. The sum is not a quantity. A rank has no unit; a sum of three ranks has no unit either, and giving it one by calling it a "guest score" invents a measurement that was never taken.
The arithmetic shows the damage plainly. A guest scoring 3-4-5 and a guest scoring 5-4-3 both sum to 12. The first came a while ago, comes moderately often and spends a lot. The second was here last week, comes moderately often and spends little. Same total, opposite guests, opposite actions. Any table sorted by that total puts them next to each other and hides the difference that the segmentation was built to expose.
The one legal use of the sum is sorting — putting the base in a rough order so a human can start at the top of a list. Sort by it, never report it, and never average it across a segment: an average of dimensionless ranks is a number about nothing at all.
The score drops when the base grows, not when the guest cools
A rank has a property that reports forget first: it is computed against whoever is in the base right now. A guest can change none of their own numbers and still lose a score.
The same guest, with six visits. On a base of 500 identified guests cut into five bands of 100 he stands 95th by descending frequency: 95 ≤ 100, first band, score 5. Over a quarter the base grows to 700 identified guests, the bands become 140 wide, and 60 of the new guests come more often than he does. His rank is now 95 + 60 = 155, and 155 > 140 — second band, score 4. He still has six visits, and the last one is the same day it always was. What fell was not the guest but his place in the queue.
Three consequences follow, and all three are about what may be printed in a report and what may not:
- scores from two different exports are not compared with each other. The line "the average score across the base rose this quarter" means nothing: with equal-sized bands the average score barely moves by construction, whatever the base does;
- scores from two venues are compared even less — each has its own base and its own queue, and a score speaks only about a position inside it;
- the raw three numbers are what you compare — days, visits and PLN. Those carry units, and they do not depend on how many people opened a card this quarter.
So every printed score carries the recalculation date and the size of the base it was computed on. Without those two captions a score is a number with no frame of reference, and the first comparison made with it will compare queues rather than guests.
The lapsing guest: catching the guest before the gap becomes final
Expected gap between visits = observation window ÷ visits of the guest in the window
observation window— the period you pulled the data over, days;visits of the guest in the window— that one guest's visit count, not the base average, visits;- result — days per visit, this guest's own rhythm.
Lapsing test: recency > expected gap × tolerance factor
recency— days since the last visit;expected gap— from the formula above, days per visit;tolerance factor— how many times a guest may exceed their own rhythm before you treat them as slipping away; dimensionless, chosen by the owner and written down;- both sides of the comparison are in days, which is the only reason the test means anything.
Lapsing guest — a guest whose recency has passed their own usual gap between visits, but not yet far enough to be treated as lost.
Worked, on an example base of 500 identified guests over a 365-day window. Guest A made 12 visits: expected gap 365 ÷ 12 = 30.42 days. With a tolerance factor of 2 the threshold is 60.83 days. A has not been in for 78 days, and 78 > 60.83, so A is lapsing. Guest B made 3 visits: expected gap 365 ÷ 3 = 121.67 days, threshold 243.33 days. B has also not been in for 78 days, and 78 < 243.33, so B is behaving exactly as B always behaved.
Same 78 days, opposite verdicts, and no calendar rule could have produced both.
The "hasn't been in for ages" threshold comes from your frequency, not from the calendar
Ninety days is a number from a calendar. It became a habit because quarters are ninety days long, not because anything about guests changes at that mark. Applied flat, it does two kinds of harm at once: it declares your rare-but-loyal guests lost while they are still on schedule, and it lets your weekly regulars drift for eleven weeks without anybody noticing.
The fix is the pair of formulas above, applied per guest rather than per base. It costs one extra column — each guest's own expected gap — and it changes who appears on the list every morning. The tolerance factor is where judgement enters, and it should enter openly: write it down, state why, and keep it stable long enough to compare two periods. A factor near 1.5 reacts fast and produces false alarms; a factor near 3 is calm and catches people late. Neither number is a recommendation — they are the two ends of the trade-off, and the value in between is yours. There is no published norm for it, which is precisely why it must be a recorded decision rather than a default nobody remembers choosing.
Whether a guest who has crossed the line gets a message at all, and when, is follow-up work: see follow-up automation and what happens to an enquiry after the first conversation.
The seasonal guest the segmentation files as lost
This is the degenerate case of everything above, and it is common enough in restaurants to deserve its own paragraph rather than a footnote.
A family that books your room once a year for a communion, a company that holds one Christmas party with you, a couple that comes for one anniversary — each of them has a frequency of 1 in a 365-day window and an expected gap the formula cannot compute honestly, because one visit gives you no interval at all. One visit is a point; an interval needs two. Feed that guest into the lapsing test and the arithmetic will file a perfectly healthy annual guest as lost somewhere around month four.
Two ways out, and both are decisions you record rather than tricks:
- compute the gap only for guests with at least two visits, and hold everyone with a single visit in a separate "new or occasional" group whose action is a second-visit trigger, not a reactivation;
- run occasion bookings on their own window — the interval that matters for a communion or a wedding is a year, and it belongs to the enquiry queue rather than to the guest base. That queue has its own page: event enquiries in a restaurant.
Whichever you choose, print it next to the segment definition. A segment whose rule is not written down is re-invented every quarter by whoever is running the export.
What to do with each segment, and what you must not do with it
The table below is a starting layout, not a prescription. The right-hand column matters more than the third one: most of the damage a segmentation does comes from an action applied to the wrong group, not from a missing action.
| Segment | How it looks in the three numbers | Action | What not to do |
|---|---|---|---|
| Regular | Recency inside their own gap, frequency high, money steady | Recognise them by name, hold the table they like | Discount. They were coming anyway, and the discount is pure lost contribution |
| Lapsing regular | Recency past their own gap, frequency high, money high | One personal message, from a person, with a reason | Put them in a bulk send with everybody else |
| Rare, big spender | Frequency low, money high, recency irrelevant | Contact tied to their occasion, once a year | A weekly newsletter that trains them to ignore you |
| New | Frequency of one, recency very fresh | A second-visit trigger inside their own window | Treat a single visit as loyalty and start rewarding it |
| Long gone | Recency far past their own gap times the factor | One reactivation attempt, then stop paying to reach them | Keep the address in every campaign forever |
The actions in the third column are messages, and messages have a channel, a cost and a legal basis. Delivering different texts to different groups without a person retyping them is what messaging automation is for; deciding what the message actually offers, and whether that offer pays for itself, belongs to loyalty programme economics rather than here.
The segment you must not touch: the regular, and the cost of extra attention
There is one group where the correct action is deliberately nothing, and it is usually the most valuable group on the list. A guest who comes every week already has the habit. Every message you send them does one of two things: it is ignored, which slowly teaches them to ignore all your messages, or it works, which means you paid a discount to move a visit that was going to happen anyway.
Both outcomes are costs, and neither shows up as a cost anywhere. The first is paid in future response rates; the second is paid in contribution and looks in the report like a successful campaign, because the visit did happen. That is the quiet reason a segmentation is worth building at all: not to reach more people, but to stop reaching the ones who were already coming.
Attention has a budget the same way food does. Spend it on the lapsing regular, whose next visit genuinely depends on whether anybody noticed the gap; spend none of it on the guest who booked Thursday before you finished reading the report.
How to check that the split gave you anything at all
Segment share of contribution % = contribution of the segment ÷ contribution of the whole base × 100
contribution of the segment— the money left after variable costs from that group's visits in the window, PLN;contribution of the whole base— the same figure over every identified guest in the same window, PLN;- result — a percentage, because PLN divided by PLN leaves no unit behind.
Checked backwards: 0.2784 × 148 000 = 41 203 PLN, and the rounding closes.
That single comparison — share of base against share of contribution — is the first honest test of a split.
The second test is harder and better: did the action work? A segment that received a message and then came back has not proved anything, because the ones you picked were the ones most likely to come back. Proving it needs a comparable group that got nothing, and that method has its own page — did the promotion work, and how a holdout group answers it. New guests, who are their own segment here, cost money to acquire, and what that costs is measured on the acquisition cost page.
Where the data sits, what the law calls it, and where the arithmetic ends
Everything above is processing of personal data. A guest card with a name, a phone number and a visit history is exactly what the GDPR means by personal data, and grouping people by behaviour to decide who receives which message is exactly what it means by processing. That is not a reason to avoid it; it is a reason to know where the records physically live, who can export them, on what basis you contact anyone and how long you keep a guest who has not been in for four years. Where automation actually puts customer data is the subject of automation and GDPR, and it should be read before the first export, not after it.
And the honest line about the technology, because it is easy to blur. Ranks, quantile cuts, expected gaps and the lapsing test are ordinary arithmetic. Any spreadsheet computes them, no model is involved, and nothing on this page becomes more accurate by adding one. What software genuinely saves is the labour around the arithmetic: pulling the visit history into one place, recomputing the ranks every night instead of once a quarter, and writing five different texts instead of one — that last part is where an assistant helps, and it is covered by messaging automation and the general picture in restaurant automation.
Aura sits on the management layer here: the numbers, the split and the trigger. It does not decide what your restaurant should be worth to a guest.
Frequently asked questions
What is RFM segmentation and does it work for restaurants?
It is a way of splitting a customer base using three numbers about each guest — how recently they came, how often they came and how much they were worth — and it works for a restaurant exactly as far as the restaurant can identify returning guests. With bookings, a card or an account it works well. In a room where most guests pay cash and leave unrecognised, it works only on the identified minority, and the honest first step is measuring how large that minority is.
How do I set the boundaries between segments?
By sorting your own base and cutting it into equal-sized groups, not by choosing round numbers. Quantile cuts adapt to your price level and your format automatically, they survive one enormous banquet bill without distortion, and they can be recomputed every month without renegotiating anything. Round thresholds imported from an article about somebody else's restaurant encode that restaurant's prices and calendar, not yours.
How many segments should a restaurant keep?
As many as you have genuinely different actions ready to execute, and not one more. Three dimensions cut into five bands each produce 125 combinations, which no restaurant team acts on differently. Two segments with two real actions beat twelve segments with one action shared between them, and the count should be driven by the action list rather than by what the export can generate.
When is a guest lapsing rather than lost?
When their recency has passed their own expected gap between visits but has not yet passed it by the multiple you chose as a tolerance. That comparison is per guest, never per base: a guest who normally comes monthly is late after two months, while a guest who normally comes twice a year is not late at all at the same moment. There is no published norm for the tolerance multiple, so it is a decision you record and keep stable.
Can I add up the three RFM scores into one number?
You can compute it, and you should not report it. Each score is a rank, which carries no unit, so their sum carries none either — it is not a quantity and cannot be averaged, compared across periods or treated as a value. Its one legitimate use is sorting a list. Two guests scoring 3-4-5 and 5-4-3 sum to the same 12 while needing opposite actions, which is the shortest demonstration of why the total hides what the split was built to reveal.
How do I know whether the segmentation was worth doing?
Compare each segment's share of the base with its share of contribution: if the two are the same and behaviour is the same, that group is a description rather than a segment. Then test the action, not the split, by holding back a comparable group that receives nothing and comparing the two afterwards. Without a holdout, a segment that was chosen for being likely to return will return, and the report will read as a success either way.
Start with two segments and two genuinely different actions — the lapsing regular who gets a personal message, and everybody else who gets nothing this month. Twelve beautiful groups sharing one action are not worth an hour. When the two-segment version is running and measured, add the third. The restaurant economics section collects the pages that feed it: recognition, value, acquisition cost and proof.