Automation retainers

Automations are software, and software fails without announcing it. A webhook, the real-time trigger a CRM fires when something changes, stops being delivered and nothing complains. An automation configured inside the CRM's own interface exists nowhere else: no written copy, no change history, no alert when it stops. Even a well-built scheduled job dies quietly when its data outgrows its time limit. In every case the dashboards keep rendering, the numbers are quietly incomplete, and the reports still look normal, so nobody checks them.

The created-before/after pattern

A dead automation leaves a timestamp signature. Every record created before some date has the field it maintained; every record created after does not. Scanning for that boundary is the fastest way to find automations that died without telling anyone, and it is how two were found behind one dashboard at a European PE platform: a webhook stamping stage dates, and a separate in-CRM automation that had stopped months earlier. On a retainer, enforcement jobs re-check the whole book on every run, so a dead upstream automation surfaces the same day as a repair count in a log, not months later as a quiet gap in a funnel chart.

What runs on a retainer

• Scheduled enforcement jobs. Each hygiene rule is written down as an invariant, a statement that must always be true, such as "every deal in a closed stage has a close date". A small scheduled job checks the whole book on a timetable, repairs what it safely can, and flags what it cannot. Repairs fill empty fields only and never overwrite a value a human set, and every job is idempotent: running it twice has the same effect as running it once.
• Stale-deal alerts. Deals with no activity past a threshold, and deals whose expected close date has passed, flagged to the deal owner on a schedule. The alert does not close the deal; a human does. The deal owner then has to act on the alert or explicitly set it aside; it can no longer be ignored by default.
• Self-rebuilding dashboards. A deal-flow dashboard rebuilt automatically from the live CRM and shaped around the questions a partner actually asks on a Monday. Shaping matters as much as freshness: a funnel that shows only each deal's current stage silently drops every deal already killed, while the cumulative funnel counts every deal at every stage it ever reached. Those are different questions, and choosing between them stays a conversation between people.
• Monitoring for silent failures. Every job runs with logs, automatic retries, and real headroom against its time limit, and the created-before/after check runs continuously across the book.

Retained jobs must not become the next silent failure

The jobs doing the enforcement are themselves systems, so they get the same scrutiny. One production lesson: a daily sync at a European PE platform made one API call per company across roughly 3,600 companies, ran about 19 minutes against a 20-minute limit, and died routinely on a single transient server error. Fetching the data in bulk and wrapping every call in automatic retries brought the same job down to about a minute. Without that headroom, a job that works today fails the first time the data grows.

What a retainer includes

• The enforcement jobs, alerts, and dashboard generators, kept in a repository you own and run on a visible schedule with logs.
• New invariants added as your process changes, and existing jobs adjusted when the CRM schema moves.
• When a job breaks, or the CRM changes underneath it, the repair is 80x's problem rather than a task waiting for someone at the fund to notice.

Proof

At a European PE platform, 80x found two silently dead automations behind a deal-flow dashboard using the created-before/after pattern, backfilled 76 date fields across 54 deals from the CRM's own status history, and moved the date stamping into a scheduled job that re-checks everything on every run. The dashboard now rebuilds itself every weekday morning.