80 clients, 13 retailers, one 90-day rule. Nobody's opening a spreadsheet every morning anymore — it checks itself, and sends the reminder when it's due.
Status: live and running daily.
The rule was simple: if a client hasn't sent updated assortment data in 90 days, someone should ask for it. Enforcing that by memory meant checking it every day, across roughly 25 clients and up to 13 retailers each — not a realistic habit to keep up indefinitely by hand.
The sheet does the remembering, not the data entry — I still log the date whenever a client sends updated assortment data. From that one date, everything else works itself out automatically: status, urgency, whether a reminder's due. A scheduled flow reads the sheet once a day, acts on whatever's actually due, and logs the result back into the same row it just handled.
Every row works out its own status live, and a daily flow reads it to see what's actually due today.
Whatever's due gets sent, automatically.
A sample of the actual mechanics underneath, each with a walkthrough of one client moving through the system.
A scheduled trigger fires once a day. It pulls every row from the tracking table, filters down to only what's currently due, then loops through each one: writes today's date back to that exact row, and sends the reminder. Sheet and flow only talk to each other through that one table — nothing lives in the flow itself.
Trigger fires at 08:00.
Pulls all ~80 rows, filters to the 6 currently due.
Loops through those 6 — each one gets a logged date and a reminder.
Four formulas decide everything: how long since the last update, whether a reminder already went out, and whether a hold is active. Opening the sheet on any day shows the true current state.
Client A, Store 1 — last update 94 days ago, no reminder sent yet.
Status shows: OVERDUE.
The daily flow picks it up, sends the reminder, logs today's date.
Status flips to: SNOOZED, automatically, for the next 10 days.
Ten days after a reminder goes out, the same formula reverts SNOOZED back to OVERDUE on its own if nothing's changed. No follow-up step needed from me.
It watches, decides, and sends — but it can't read what comes back. Clients reply in whatever format they use, no shared structure, so there's no reliable way to log it automatically. If that side were ever standardized, the same pattern could extend further: read the reply, pull out the data, update the table itself.
This isn't really about assortment data. Any recurring deadline nobody's reliably tracking by hand — contract renewals, certification expiry, price list refreshes — could run on the same shape. Only the rule and the recipient change.