Scoring and Gating: Spending on the Right Rows

Outcome: a scoring column built from cheap data, a threshold derived from your team’s actual capacity, and a gate placed so the expensive columns only ever see rows worth the spend.

Surface: App and MCP server
Level: Beginner
Uses: Formula columns · filters (no paid action)
Credits: 0 to build, saves most of your run cost
Prerequisite: Lessons 02 and 05

What a gate is

A gate is a filter placed between a cheap stage and an expensive one. Rows above the threshold continue; rows below stop and stay in the table.

It is the highest-leverage thing in this course. Cutting a list by 80% before the person-level stage removes 80% of your run cost, and — this is the part that surprises people — usually removes none of your meetings, because the rows you cut were never going to be worked anyway.

The gate does not delete rows. It defers them. A row that scores 4 today may score 8 next month when a signal fires, and the whole point of leaving it in the table is that the next run can pick it up without re-sourcing it.

Scoring in two halves

Score fit and timing separately, then combine. Collapsing them into one number hides the difference between “perfect account, no reason to call” and “urgent event, cannot sell to them.”

Fit score, from attributes

Points for the standing facts from lesson 05. Slow-moving, computed once and refreshed quarterly.

Timing score, from signals

Points for events inside their window, decaying as the window closes. Recomputed every run.

Combine, do not average

Require a fit floor, then rank by timing. fit >= 5 AND timing > 0, ordered by timing descending. Averaging lets a hot signal at an unsellable account outrank a good account — which is exactly the failure the split was meant to prevent.

A worked scoring model

Continuing the developer-tool build. Every input is a cheap column that already exists by this point in the pipeline.

Fit — max 10

Criterion	Points
Employees 50–500	3
Engineering org above 20	3
Uses a competing CI tool	3
Headquarters in a target market	1

Timing — max 10, decayed by age

Criterion	Points
2+ infra roles posted in last 30 days	5
1 infra role posted in last 30 days	3
Engineering leader started under 90 days ago	4
Raised funding under 90 days ago	3
Signal is 60–90 days old rather than under 30	−2

Gate: fit >= 6 AND timing >= 4.

Everything above the gate goes to the person stage. Everything below waits for a signal.

Setting the threshold

Do not pick a number that feels right. Derive it.

Ask what the downstream capacity actually is. Two reps sending 40 personalized touches a week is 80 accounts a week, not 800.
Score your whole list with the gate open — scoring is free.
Sort descending and look at where the 80th row falls. That score is your threshold.
Sanity-check by reading ten rows just above and ten just below the line. If you cannot tell them apart, your scoring model has no resolution and needs a sharper criterion — usually a signal.

The threshold is a capacity decision wearing a data costume. When capacity changes, the threshold moves; the model does not.

Where to place the gate

Immediately before the first expensive column, and again before any second expensive stage.


Find companies      cheap    ──┐
Enrich company      cheap      │  scoring inputs
Tech stack          cheap      │
Job listings        cheap    ──┘
Fit + timing score  free
▸ GATE  fit >= 6 AND timing >= 4
Find people         cheap
▸ GATE  role matches buying centre
Find work email     expensive
Verify email        cheap
AI opening line     expensive

Two gates, not one. The second is nearly free to add and stops you buying emails for the office manager at a company that passed the first gate.

Do this now

Write your fit criteria with point values. Cap at 10. Use whole numbers.
Write your timing criteria, including a decay penalty for signals late in their window.
Build both as formula columns. They cost nothing to run, so build them before any enrichment.
Compute your weekly downstream capacity as a row count.
Score the full list, sort, and read off the threshold at that row count.
Place the gate immediately above your first expensive column, and add a role gate above the contact-data column.
Re-run your lesson 02 cost estimate with the gate in place. Record both numbers.

Check your work

Fit and timing are separate columns
Your threshold came from a capacity number, not intuition
Rows below the gate are still in the table, not deleted
You can state the run cost before and after gating

Where this breaks

A gate built from data you have not yet collected silently passes everything. If timing reads a signal column that has not run for this row, most implementations treat it as zero or null — and depending on how you wrote the comparison, the row either always fails or always passes. Always test a gate on a 20-row sample and count survivors by hand before running it against the full list. A gate that passes 100% is not a gate.

Further automation

Once the gate is stable, the scored table becomes a standing queue rather than a one-off list: re-run the cheap signal columns weekly, re-score, and let rows cross the threshold on their own. Route the newly-crossed rows to your sequencer or CRM and the pipeline runs itself — that build is Signals & ABM lesson by lesson.

Next lesson

07 — Dedupe, hygiene and the source of truth, which is what stops that weekly re-run from re-billing and re-emailing the same records.

Reference for this lesson: Tables, Actions, Credits, AI agents.