To know who should book next, you need three numbers for each client. The gap they normally leave between visits, how far past that gap they are today, and whether you can still reach them. Rank by the second number and the queue sorts itself. A client who books every four weeks and is now at seven belongs above a client who books every six months and is at four.
Sorting by last visit date does the opposite. It puts the people who left long ago at the top, and most of them left for a reason.
Key takeaways
- Rank by days overdue relative to each client's own rhythm, not by how long ago you last saw them.
- Every client has a personal interval. A fixed six-week rule flags the wrong half of your book.
- Three numbers are enough: normal gap, days past it, reachable channel.
- A queue you cannot explain is a queue you will not work. Each name needs a stated reason.
- Only one major vendor publishes a numeric definition of "due back", and it is editable, which tells you it was never a standard.
Why "last visit date" is the wrong sort
Open any client list, sort by last visit, and look at the top. Those are the people who have been gone longest. Some moved away. Some changed specialist. Some had one appointment two years ago and were never really yours.
The top of that list is where win-back messages go to die, and working it teaches you that outreach does not work. It does work. You were just starting at the wrong end.
The people worth contacting are not the ones who left longest ago. They are the ones who have not left, but are late.
Every client has their own interval
A person who books a maintenance appointment every four weeks and a person who comes twice a year are both regulars. They are just regular at different frequencies.
Once you accept that, the useful question stops being "when did I last see them" and becomes "how does today compare to their normal". A four-week client at week seven is three weeks late and probably drifting. A six-month client at week seven is early, and messaging them is noise.
You do not need a model for this. Take the median gap between a client's own past visits and use that as their interval. Two or three past visits are enough to be more useful than a fixed rule, such as the six-week threshold most tools ship with.
The three numbers that make a real queue
Normal gap. The median number of days between that client's own consecutive visits. Median rather than average, because one unusual six-month break should not redefine a monthly client.
Days overdue. Today minus their last visit, minus their normal gap. Negative means not due yet. Zero means due now. Positive is your sort key.
Reachable channel. Which channel they read, and whether you still have consent to use it. A client at the top of the queue with no working channel is not actionable, and should be shown as such rather than silently skipped.
| Number. | How to compute it. | What it decides. |
|---|---|---|
| Normal gap. | Median days between that client's past visits. | What "late" means for this person. |
| Days overdue. | Days since last visit minus normal gap. | Their position in the queue. |
| Reachable channel. | Stored channel plus valid consent. | Whether the row can be acted on at all. |
Three columns, one sort, and a list you can hand to somebody else without explaining it.
Why a fixed rule misfires
Most tools ship a single threshold. Square, for instance, defines its default Regulars group as "customers who've visited your business three times in the last six months" and its Lapsed group as "customers who were regulars, but haven't visited in the last six weeks".
That is a reasonable default and a poor rule for everyone. Six weeks is late for a four-week client and early for a quarterly one. Applied across a mixed book, the same number produces two errors at once: it nags people who are not late and stays silent about people who are.
The fix is not a better global number. It is per-client intervals with the global number as a fallback for clients who have only ever come once.
Does contacting people who are due actually work
Yes, and the effect sizes are modest and real, which is the honest way to plan for it.
In a randomised trial of 4,115 adolescents, preventive visits within twelve months reached 65% (centralised reminder/recall trial, 2013) with mailed reminders and 63% (same trial) with phone calls, against 59% (2013 trial) for the control group. The number needed to treat was 17 for mail and 29 for calls - roughly one extra visit for every seventeen letters.
Timing after a miss matters more than volume. A prompt message after a no-show brought patients back within thirty days 22.2% (randomised clinical trial, 2024) of the time, against 11.6% (2024 trial) for the standard letter alone.
And when the person does book, book them close. Across 46,655 appointments, no-shows ran at 9.1% (lead-time analysis, 2015) within a two-week horizon and 38.3% (same analysis) at six months. A win-back that lands on a date four months out is half a win.
What this looks like in Belom
The client record keeps the rhythm, not just the history. Belom computes each client's own interval from their visits, marks how far past it they are, and orders the list by that number rather than by last-seen date. Each row carries the reason it is there, so the person working the list is not guessing.
This is the same loop as the empty-slot side of the product, read from the other end. A cancellation asks "who can take this hour". A rhythm asks "who should be booking at all".
[ORIGINAL DATA] What vendors publish about "due back"
Methodology. On 19 August 2026 we requested the public documentation of six booking and salon platforms with a standard HTTP client. We were looking for one thing: a numeric definition of a returning, regular, or lapsed client. Sample size: three pages returned readable content, one returned a loading error, and two returned HTTP 403 and are marked unverified. We recorded only definitions stated in writing on the vendor's own pages.
One vendor publishes numbers. The rest do not.
Square states both thresholds outright. Regulars is "set to collect customers who've visited your business three times in the last six months". Lapsed "includes customers who were regulars, but haven't visited in the last six weeks". Crucially, the page also says the thresholds are editable: "You can edit the settings of this group by clicking Actions > Edit Group in your directory".
Fresha discusses retention reporting in general terms - tracking "demographics, purchase history, and feedback" - without giving a visit count, a time window, or a retention formula.
Mindbody's Salon Intelligence report page did not render for a non-browser request and returned a loading error, so nothing from it is reported here. Acuity and Booksy returned HTTP 403 and are likewise unverified.
| Vendor. | Numeric threshold published. | Editable by the business. |
|---|---|---|
| Square. | Yes - 3 visits in 6 months; lapsed after 6 weeks. | Yes, stated explicitly. |
| Fresha. | No numeric definition found. | Not applicable. |
| Mindbody. | Page did not render. | Unknown. |
| Acuity · Booksy. | Unverified - HTTP 403. | Unknown. |
[UNIQUE INSIGHT] The editability is the real finding, and it undercuts the number it comes with. A vendor that ships a threshold and then tells you to change it is admitting that six weeks is not a fact about clients - it is a placeholder waiting for your business to replace it. Almost nobody does, so a default written for a general-purpose payments product ends up deciding which beauty clients get contacted. The lesson is not that Square chose badly. It is that the threshold is the most consequential setting in the whole retention feature, it is set once by someone who has never seen your book, and no vendor treats it that way in its documentation.
Definitions used in this article
Normal gap is the median number of days between one client's own consecutive visits, such as 28 days for a monthly client.
Days overdue is days since the last visit minus that client's normal gap, so a positive number means late.
A lapsed client is one whose days overdue has passed a threshold you chose, for example twice their normal gap.
Rebooking rate is the share of completed visits that produce a next booking.
Win-back means contacting a client who is already past their normal gap, rather than one who is simply not booked.
FAQ
How do I know which client to contact first?
Rank by days overdue relative to that client's own normal gap. The top of that list is people who are late by their own pattern, not people who left years ago.
How many past visits do I need to compute an interval?
Two gives you a rough interval, three gives you a usable median. Below that, fall back to a category default and mark the row as an estimate.
Is six weeks a good cutoff?
Only by accident. It is late for a four-week client and early for a quarterly one, which is why per-client intervals beat any single number.
Does win-back messaging actually work?
Modestly and measurably. A reminder/recall trial moved preventive visits from 59% to 65% (2013 trial), with a number needed to treat of 17.
How many people should be on the list at once?
Few enough that every row gets a real message. A list of two hundred names becomes a broadcast, and a broadcast is how you train people to ignore you.
What if the client has no reachable channel?
Show the row as blocked rather than skipping it silently. A missing channel is a data problem you can fix at the next visit.
Where this fits
The measurement definitions behind all of this are in rebooking rate vs client retention, and the wider return loop in the client who comes back. When the answer is "nobody can book because the calendar is full", the page-side fix is in what your booking page should show when there are no free times. The data that makes targeted offers possible is in what a waitlist has to store, and the fifteen minutes after a cancellation in how to fill a last-minute cancellation.
The Belom surface that ranks this list is the rebooking radar.
Editorial note: written by the Belom product team from how the product actually works, not from vendor marketing. More about Belom, or contact us with a correction. Reviewed 19 August 2026.