Change detection rather than state reporting. Each day every account is scored and stored; today's risk and alert keys are compared to the previous snapshot. A slip in risk band or a newly appeared high-severity alert emails the platform owners with the health, last active date, session counts, milestone progress and the top six alerts — and opens a follow-up task, deduped against any open task with the same source. Once a day, if anything is at risk, a single digest goes out listing accounts worst-first.
Also called: daily snapshot · risk change notification · at risk digest · retention cron
- 1snapshotOrg writes one row per account per day with score, risk, milestone map, metrics and alerts.
- 2Worsened = today's risk ranks below the previous snapshot's; new high = a high-severity alert key absent from yesterday's list.
- 3Notification emails carry a CTA straight to that account's Success tab.
- 4A task is created for the retention owner with the alert details as the description, priority urgent when churning, due the next day, deduped on a source key.
- 5The digest is rate-limited to once a day through a key-value stamp.
- 6It never emails the tenant — this is the vendor's retention loop.
The route header defines the three triggers and closes with the boundary: 'Never emails the tenant — this is the agency's retention loop.' Snapshotting is what makes change detection possible at all: the module notes the daily cron 'snapshots this so risk CHANGES notify once', rather than re-alerting every day on a standing condition.
- Standing conditions re-alerting daily trained everyone to ignore them.
- Risk detection with no assigned follow-up produced no action.
- Duplicate tasks piled up for the same underlying problem.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →