Case study 02 / Operations & AR
Inventory & receivables KPI flagging
Building early-warning flags at a revenue cycle management firm so low stock and ageing receivables surface before they become a stockout or a 90-day delinquency.
Anonymised for confidentiality — no client data, account details or system screenshots are shown.
01 / The question
How do you flag risk early enough that someone can still act on it?
Two very different problems shared the same shape. Inventory could run low and affect the people who depend on those supplies, because reordering was not tied to how long it actually takes to restock. And receivables that drifted past 60 days were not being pulled into a follow-up queue early enough to prevent them from reaching 90.
In both cases the useful signal was not "this is low" or "this is old" — it was "this will become a problem before the next window to act closes."
02 / The approach
Flags built around time-to-act, not just static thresholds.
-
Inventory: usage history, not gut feel
Used historical usage frequency and counts to understand how quickly each item is actually consumed, rather than relying on a fixed minimum quantity.
-
Restock lead time as the threshold
Combined consumption rate with the time frame needed to restock. An item is flagged when its projected cover is shorter than the restock window — early enough to reorder before users are affected.
-
Receivables: a 60-day action window
Flagged accounts with receivables over 60 days so they enter a follow-up queue while there are still 30 days to resolve them before the 90-day mark.
-
Flags that carry an action
Each flag was designed to point to an owner and a next step — reorder, chase, escalate — instead of adding another number to a report.
03 / What changed
The flags moved work from reactive to planned.
- Reordering decisions were tied to consumption and lead time, so supplies could be restocked before users were affected.
- Receivables over 60 days entered a follow-up queue with 30 days left to act, instead of being discovered at 90.
- Flags pointed to an owner and a next action, which made the alerts usable rather than just informative.
- The same pattern — historical behaviour, time-to-act, exception queue — applied cleanly across two different operational areas.
04 / Limitations
What this analysis is — and isn't.
Thresholds depend on accurate usage history and reliable supplier lead times; both need periodic review as demand and suppliers change. Seasonality and one-off demand spikes can trigger false positives, so flags need an owner who can override them. No client data, account details or system screenshots are published here.