Nobody sends a goodbye email. B2B customers do not churn, they fade. They order a bit less, then a bit later, then they stop, and the only record of it is a gap in your order history that nobody is looking at. The signal is already sitting in your ERP. It is just not sitting in a report.
The account you lost without a goodbye
It is a Tuesday and you are looking at a customer list sorted by last year’s revenue. Somewhere in the top thirty there is a name that stops you, because you cannot remember the last time you saw a PO from them.
You ask the rep. The rep says they have gone a bit quiet. You ask when they last ordered and the rep is not sure — sometime in the spring. Nobody fell out. There was no lost RFQ, no price war, no complaint that escalated. At some point a short-ship went out and nobody rang to apologise, and the buyer got a call from someone else that week, and the next order went there instead because it was easier than explaining. Then the one after that went there too, because by then they had an account.
That is what losing a customer actually looks like in this business. Not an event. An absence. And absences are invisible in every system you own, because every report you have is built on transactions that happened. Nothing reports on the order that did not arrive.
The frustrating part is that the information was there the whole time. A buyer who has ordered from you every five weeks for three years, and has now been silent for eleven, has told you something as clearly as if they had written it down. You just needed something watching for it.
Why “no order in 90 days” is the wrong rule
Everybody who tries this starts here, because it is the rule you can build in an afternoon. Pull customers with no order in the last ninety days. Give the list to the reps. Done.
Then you look at the list and it is useless, for two reasons that pull in opposite directions.
The first is the false alarms. Your quarterly buyers — the shop that orders a pallet of consumables every three months, the contractor who buys for a project and then goes quiet until the next one — cross ninety days as a matter of routine. They are not leaving. They are on schedule. But they show up on the list every single cycle, which means the list is mostly noise, which means after the second week the reps stop opening it.
The second is the misses, and they cost more. Your weekly and fortnightly buyers are usually your best accounts: high frequency, predictable, the ones who treat you as a default. When one of those goes quiet for a month, that is a loud signal — and a ninety-day rule will not say a word about it for two more months. By then they are not quiet, they are gone, and they have a new supplier with an account, a price and a credit line.
Tightening the threshold does not fix it. Loosen it and you miss more of the frequent buyers; tighten it and you drown in quarterly ones. One number cannot work, because the number that means “late” is different for every customer on the list.
Late against their own rhythm
Here is the rule that works, written out so you can hand it to whoever runs your reports.
For every customer with at least four orders, take the gaps in days between their order dates and find the median one. That is their rhythm. Then measure the days from their last order to the most recent order date anywhere in the export, and divide that by their rhythm. Anyone sitting at one and a half times their own usual gap or worse gets flagged.
Four small decisions in there do most of the work, and each one is there because the obvious alternative breaks.
At least four orders. Three orders give you two gaps, and two gaps give you no idea whether either of them is normal. A new account that has ordered twice is not dormant, it is new, and putting it on a win-back list sends a rep to have a confusing conversation.
The median, not the average. One Christmas shutdown, one plant relocation, one long gap after a trial order — any single outlier drags an average far enough to make a regular buyer look irregular. The median shrugs it off.
Measured from the end of the export, not from today. If you pull a report in October and it only has data to June, measuring against today makes every customer look four months late. Measuring against the last order date in the file tells you what the file actually knows.
Same-day orders count once. A split shipment, a corrected order re-entered, two POs that land together on a Monday — each of those puts two order dates in the same day, and a zero-day gap in the data drags the median toward nothing, which makes a steady customer look permanently overdue. Collapse the orders to one point per day for the rhythm, then count every one of them for revenue.
The data you need is three columns, which every ERP on earth can export:
| Column | What goes in it |
|---|---|
| customer | The account name or number — whatever you group by. Consistent spelling matters more than which one. |
| order_date | The date the order was placed. Either 2026-03-04 or 03/04/2026, month first. |
| amount | Order value. Currency symbols and thousands separators are fine. |
Run it on your own order history
The calculator below does this two ways, and they answer different questions.
The first tab is a back-of-envelope estimate: how many customers you have, what an average one is worth in a year, what share of them you think are past their usual reorder time, and what share of those you think you could win back. It takes thirty seconds and gives you a range rather than a number, because every input in it is a guess. Useful for deciding whether this is worth an afternoon.
The second tab is the real answer. Export the three columns, drop the file in, and it applies the rule above and names the accounts — their usual gap, how long they have been quiet, how late that is as a multiple of their own rhythm, and what they spent in the last twelve months. It will take up to fifty thousand rows, it maps your column headers if they are named something else, and you can download the flagged list as a CSV to hand to a rep. If you do not have an export handy there is a sample file to try it with.
One thing worth being plain about: the second tab does not upload your file. Your browser reads it, the arithmetic happens on your machine, and the result is drawn from what is already in memory. Nothing is sent anywhere, nothing is stored, and closing the tab disposes of it. If you would rather verify that than take our word for it, open your browser’s network tab before you drop the file in — there is no request to see.
Two things usually come out of the first real run. One is a handful of names nobody had noticed, which is the point. The other is a few customers who are flagged because something administrative broke — an account that went on credit hold and never came off, a ship-to that was deactivated, a portal login that expired. Those are the easiest revenue you will recover all month, because nothing is wrong with the relationship at all.
What to say when you reach out
The flagged list is the easy half. What goes wrong next is the message, and it goes wrong in the same way every time: somebody leads with a discount.
Leading with a discount does three things, none of them good. It tells a customer who left for a service reason that you think they left over price. It teaches the ones who were about to come back anyway that going quiet is worth money. And it gives you no information — you still do not know why they stopped.
The first move is to find out whether something went wrong. Short-ship nobody closed out. Credit hold nobody mentioned. A price increase that landed without a conversation. A rep who left and took the relationship with them. Any of those is fixable, and none of them is fixed by a discount.
Three messages that work, all short, all from the rep rather than from a marketing address:
When you think something broke:
Hi Dana — I was looking at your account and realised we have not shipped you anything since March, which is unlike us. Did something go wrong at our end? If there is an open credit or a short-ship still outstanding I would rather know and sort it than leave it sitting there.
When nothing obviously broke and you want the real answer:
Hi Marcus — no agenda here. You used to order the 4400 series every few weeks and that has stopped, so either your project mix changed or we gave you a reason to go elsewhere. Either is useful to know. Which was it?
When the account changed hands:
Hi Priya — I have taken over your account from Tom. Before I start sending you anything, I would rather ask: what did he get right that I should keep doing, and what was annoying? I can see what you have been buying, so I do not need the history — just the bit that is not in the system.
What those have in common is that none of them asks for an order. They ask a question that is cheap to answer, and they make it easy to say the thing a buyer will not volunteer. Pricing conversations can happen later, once you know whether price was ever the issue.
How a Reactivation Agent does this every day
You can run the analysis above once a quarter by hand, and it is worth doing. The trouble with running it by hand is that it is a chore, and chores drift — the first one happens, the second one happens late, the third one does not happen at all, and the whole thing turns back into a list nobody opens.
The version that keeps working runs daily and does the boring parts. It recalculates each customer’s rhythm as new orders arrive, so a buyer whose pattern genuinely changed stops being flagged instead of nagging a rep forever. It checks the account for an administrative reason before it bothers anyone — open credit, an unresolved return, a hold, a dead contact. It drafts the note with the specifics already in it, for the rep to read and send under their own name. And it routes the reply to whoever can act on it, rather than into a mailbox.
There is a longer write-up of how that one is built — what it reads, where the approval line sits, and what gets measured — in the Reactivation Agent section of the RevOps page.
Checklist: before you run this on your own data
None of these are blockers. Each one you can tick makes the flagged list shorter and more believable.
- One customer record per customer. If the same account exists three times because somebody typed the name differently, it will show up as three customers with too few orders each and be skipped entirely.
- Parent and child accounts decided. A buying group with eight branches is either one rhythm or eight. Both answers are defensible; pick one before you look at the output, not after.
- Project business separated out. Customers who buy once for a job and then legitimately go quiet will always look dormant. If you can tag or exclude them, the rest of the list gets much cleaner.
- At least two years of order history. Enough for four orders from your slower buyers, and enough that a seasonal pattern looks like a pattern rather than a drop-off.
- Credit holds and inactive flags are current. Half the useful finds are administrative, and they only show up as administrative if the account status in the system is actually true.
- A named owner for the list. Someone who decides who gets contacted, who does the contacting, and what happens when there is no reply. A list with no owner is read once.
- A place to record the reason. When a customer tells you why they stopped, that answer is worth more than the order you recover. It needs somewhere to live that is not a rep’s memory.
Where to go next
If the analyser named accounts you did not expect, the useful next question is which of the gaps around them to close first — the quiet customers themselves, the quoting that happens when they do come back, or the reporting that would have shown you this months ago. The RevOps Agents page covers the first two, and AI Reporting & Dashboards covers the third, including customer health as a view you can actually look at.
If you would rather have the question answered than read another page: the Agent Opportunity Assessment takes about three minutes, asks about a dozen questions about how your operation runs, and comes back with the three agents that would pay off first in your business — worked out from your own answers, the same way the analyser above works out from your own file.