The primitives under the plays

An ordered chain of providers where each is called only if the cheaper one before it returned blank, so you pay for exactly one hit per record.

WhenAny field where no single vendor has full coverage (email, mobile, firmographics) and vendors overlap. This is the base primitive under every enrichment play.

How it works
1. 01Rank providers cheapest-first, best-coverage-first as the tiebreak, not by brand.
2. 02Call provider 1; if it returns a value, stop and record the source.
3. 03If blank, fall through to provider 2, then 3, each gated on the prior being empty.
4. 04Stamp every hit with source and confidence so you can audit which vendor earned the credit.

A 4-tool email waterfall reaches ~68% found and ~62% valid, a +23% relative lift on valid-email rate over the best single provider, at ~$0.56 per valid email (site metrics). Stop-on-first-hit is what keeps the lift from costing 4x.

A filter that runs before any paid column, so records outside ICP or inside the freshness window never trigger a credit.

WhenEnrichment spend is rising faster than meetings, or you re-enrich the same records on every batch.

How it works
1. 01Apply ICP and disqualifier filters first; drop out-of-ICP rows before any vendor call.
2. 02Skip records already enriched inside the freshness window.
3. 03Only then hand the survivors to the waterfall.
4. 04Track credits per booked meeting, not credits per record.

Filtering to ICP before enriching kills 40 to 60% of enrichment spend; gating plus cheapest-first cuts cost per enriched record 30 to 50% (site metrics). The cheapest enrichment is the record you correctly decided not to enrich.

An explicit max-age on every signal and enriched field, past which the value is treated as unknown and re-fetched, not trusted.

WhenAnything time-sensitive: buying-window signals, job changes, tech installs, contact data that rots. Wire it into any signal-triggered or scoring play.

How it works
1. 01Store a captured_at timestamp on every signal and enriched field.
2. 02Set a decay window per signal type (funding weeks, job change ~90 days [unverified], firmographics quarters).
3. 03Gate firing and scoring on captured_at within window; expire anything older.
4. 04Re-enrich on a cadence tied to the window, not a fixed annual sweep.

B2B contact data decays ~22%/yr (ZoomInfo puts overall B2B near ~30%/yr; site metrics). A window turns decay from a silent quality leak into a scheduled re-enrichment job, and stale data is worse than blank because it looks trustworthy.

A stable, deterministic join key (normalized domain, email, or a minted external ID) that identifies the same entity across every system, computed the same way everywhere.

WhenAny time two systems sync (warehouse to CRM, enrichment tool to CRM, product to CRM) and you need upsert-by-match instead of blind insert.

How it works
1. 01Pick a natural key and normalize it deterministically (lowercase domain, strip www and subdomain, drop plus-addressing on email).
2. 02Store it in a dedicated indexed external-ID field, not the display name.
3. 03Upsert on that key so a re-sync updates the existing record instead of creating a twin.
4. 04Keep the normalization function in one place; both sides must derive the identical key.

Raw incoming dedupe rates run ~10 to 30% (site metrics). A deterministic key is the difference between an idempotent sync and a duplicate factory. It is the join key that makes reconciliation and idempotency possible.

A written rule declaring which system owns each field, so syncs overwrite only fields they own and never fight over the rest.

WhenTwo or more systems write to the same record (CRM, enrichment, product, billing) and you see values flip-flopping between syncs.

How it works
1. 01List the contested fields and assign exactly one owning system to each.
2. 02Configure every sync to write only its owned fields; make the rest read-only from that direction.
3. 03Encode the ownership map in a data contract, not in tribal memory.
4. 04Log the writing system per field so a wrong value is traceable to a sync, not a mystery.

Owner conflicts are the quiet cause of dashboards that disagree and reps who stop trusting the CRM. Naming one owner per field is how you stop the ping-pong before it becomes an audit.

A unique key on every operation so a retry or replay updates the existing result instead of creating a duplicate.

WhenAny automation that can run twice: webhook retries, batch re-runs, at-least-once queues, manual reprocessing.

How it works
1. 01Derive a stable key from the operation itself (record_id + operation type, or a hash of the payload) so a re-run reuses the same key.
2. 02Check the key before writing; if it already succeeded, no-op.
3. 03Make the write an upsert keyed on it, never a blind insert.
4. 04Persist processed keys long enough to cover your retry and replay window.

It is the primitive that makes retries and event-driven designs safe. Set a workflow success SLO (over 98% is a reasonable start; site metrics) and idempotency is what lets you retry the failures without corrupting data.

Automatic retries with exponential backoff and jitter on transient failures, capped at a fixed attempt count before the item is parked.

WhenEvery external API call in a GTM workflow: enrichment vendors, CRM APIs, sequencers. They rate-limit, time out, and 5xx under load.

How it works
1. 01Retry only transient failures (429, 5xx, timeouts); fail fast on 4xx auth or validation errors.
2. 02Back off exponentially with jitter (1s, 2s, 4s plus random) so retries do not stampede.
3. 03Cap attempts (3 to 5 is a common default [unverified]); after the cap, route the item to a dead-letter queue.
4. 04Honor the provider Retry-After header when present.

Transient failures are guaranteed at volume; backoff turns a blip into a self-healing pause instead of a lost record. Without a cap plus DLQ, one bad endpoint stalls the whole batch.

A holding store for records that failed after all retries, kept with their error and payload so they can be inspected and replayed instead of silently dropped.

WhenAny pipeline where a single bad record must not block the batch and a lost record must not vanish unnoticed.

How it works
1. 01After the retry cap, write the failed item, its error, and its payload to a DLQ (a table, a queue, or a tagged sheet row).
2. 02Let the rest of the batch continue; one poison record should not halt the run.
3. 03Alert on DLQ depth crossing a threshold, not on every single failure.
4. 04Fix the root cause, then replay the DLQ through the same idempotent path.

It converts silent data loss into a visible, replayable backlog. A green dashboard over dropped records is the failure mode a DLQ exists to kill.

A scheduled job that counts records on the source and destination and flags the gap, catching writes that reported success but never landed.

WhenAny recurring sync between two systems, especially warehouse to CRM and enrichment to CRM. Run it independently of the sync that it audits.

How it works
1. 01On a schedule, count (and optionally checksum) the entities on both sides keyed by the external ID.
2. 02Diff source vs destination; surface missing, extra, and mismatched records.
3. 03Alert when the drift exceeds a tolerance, with the offending IDs attached.
4. 04Replay the missing records through the idempotent write path.

Reconciliation is the systems pulse that no per-run status can give you. It is how you notice 250 rows quietly missing before they route reps onto stale data.

A checkpoint that holds an automated action for human approve or reject before it commits, sized to the blast radius of the action.

WhenIrreversible or high-blast-radius steps: AI-written fields, outbound sends at volume, owner reassignment, anything an LLM generated.

How it works
1. 01Classify actions by blast radius; auto-commit the reversible, gate the irreversible.
2. 02Route gated items to a review surface (an approval queue or chat action) with the full context inline.
3. 03Log the decision and the deciding human on the record.
4. 04Sample-audit the auto-committed path so the gate does not become a rubber stamp.

AI enrichment lands ~$0.05 to 0.13 per field (site metrics), cheap enough to run at scale, which is exactly why an ungated agent can corrupt thousands of records fast. The gate is what makes agentic workflows shippable.

Trigger work on the event that changes state (a webhook), not on a nightly batch that re-scans everything.

WhenAnything latency-sensitive or wasteful to re-scan: inbound lead routing, signal firing, status-change syncs.

How it works
1. 01Subscribe to the source event (form submit, record change, signal) via webhook.
2. 02Process only the changed record, synchronously, through enrich, score, act.
3. 03Fall back to a periodic batch as a safety net for missed or replayed events.
4. 04Make the handler idempotent, since webhooks fire more than once.

Speed-to-lead is the highest-ROI inbound lever and 65% of buyers expect a response under 1 hour (site metrics); routing latency, not rep effort, is usually what blows the window. Batch adds hours of latency and re-scans records that did not change.

Run a new model or rule alongside the live one, writing its output to a shadow field with no downstream effect, until it beats the incumbent on real outcomes.

WhenBefore any scoring model, routing rule, or AI classifier is allowed to control an action reps feel.

How it works
1. 01Compute the new logic into a shadow field; do not act on it.
2. 02Backtest against the last 2 to 4 quarters of won and lost (or the current live rule) to confirm the new top tier converts higher.
3. 03Promote to production only after it beats the incumbent on your own outcome data.
4. 04Keep the shadow field running post-promotion to detect drift.

There is no settled public benchmark for scoring lift [unverified]; the only defensible proof is that the scored top tier converts above the incumbent on your closed-won base. Shadow mode is how you earn a number you can defend in a QBR before it touches routing.