How to build a signal-scored account queue in Clay
A list tells you who exists. A queue tells you who to work this week and why. Here is the fit, timing and reachability model we wire into Clay, and how the queue reaches a rep's desk.
Executive summary
- Score three separate things: whether an account fits, whether now is the moment, and whether you can reach the people who buy.
- Fit barely moves. Timing has to decay, or last quarter's funding round keeps an account at the top forever.
- Every row in the queue carries its reason. A rep who can see why an account is there will act on it.
Why a list is not a queue
Most outbound teams have a list. It was built once, filtered on industry and headcount, and handed to sales with an instruction to work it. There is nothing wrong with the accounts on it. The problem is that nothing on the list says which of them to call this week, so reps pick by instinct, by logo, or by whoever replied last.
A queue is the same universe with an order and a reason attached. It changes as the world changes: an account that hired a new security leader on Tuesday moves up on Wednesday. That is the difference between a database and a system, and it is the part most teams never build.
| Attribute | Account list | Account queue |
|---|---|---|
| Order | None. Reps choose. | Ranked every week |
| Reason | None | Written on every row |
| Changes when | Someone rebuilds it | A signal fires |
| Where reps see it | A spreadsheet | Their CRM view |
The three layers of a score
A single blended number hides why an account ranks where it does. We keep three sub-scores and only combine them at the end, so anyone can open a row and see which layer is doing the work.
Fit: would we win here if they were buying?
Industry, size, region and the technology they already run. For a cybersecurity vendor this is usually where stack data earns its keep. Fit changes slowly and rarely needs to decay.
Timing: is something happening right now?
Funding rounds, leadership hires, job posts for roles your product supports, compliance deadlines, visits to your pricing page. Each is evidence that the account might be moving. All of it goes stale, which is why timing gets its own section below.
Reachability: can we get to the people who decide?
A perfect account with no verified contacts is a research task, not an outbound one. Reachability scores how much of the buying committee you can actually contact, which keeps the top of the queue workable.
| Signal | Layer | Typical source | Weight | Decays |
|---|---|---|---|---|
| Industry and headcount match | Fit | Firmographic enrichment | 30 | No |
| Runs a compatible security stack | Fit | Technographic provider | 20 | Slowly |
| Raised a round in the last 90 days | Timing | Funding data | 15 | Yes |
| New security leader hired | Timing | Job change data | 15 | Yes |
| Visited the pricing page | Timing | Website visitor identification | 10 | Fast |
| Verified email for two or more buying roles | Reachability | Enrichment waterfall | 10 | No |
Building it in Clay
The build runs in this order because each step depends on the one before it. Skipping ahead to scoring before the universe is clean is the most common reason a queue gets ignored.
- Import the account universe. One row per company, keyed on domain. Deduplicate before anything else runs.
- Enrich fit attributes once. Firmographics and technographics rarely change, so run them on import rather than on a schedule.
- Attach timing signals on a schedule. Each signal gets a column for the value and a column for the date it was observed.
- Find and verify the buying committee. Run contact search for the two or three roles that sign, then verify emails through a waterfall.
- Score, rank and write the reason. Three formula columns for the layers, one for the total, and one plain-language column that says why.
The reason column is the one teams skip and the one reps actually read. A formula that strings together the signals that fired is enough:
// Reason column: plain language, newest signal first
const reasons = [];
if (row.new_security_leader_days <= 30) reasons.push("New CISO in the last month");
if (row.funding_days <= 90) reasons.push("Raised " + row.funding_round);
if (row.pricing_visits_7d > 0) reasons.push("Visited pricing this week");
return reasons.join(". ") || "Fit only, no current trigger";If a rep cannot see why an account is at the top, they will work the one they already like.
Making timing decay
A signal is worth most on the day it is observed and close to nothing a month later. Multiplying each timing weight by a decay factor keeps the queue honest: full weight on day 0, about 65 percent after a week, 40 percent after two, and close to zero by day 30.
- Day 0
- Day 3
- Day 7
- Day 14
- Day 21
- Day 30
A common failure. Teams add decay to the score but not to the reason column, so the queue says “Raised a Series B” about a round from last spring. Decay both, or drop stale reasons once the factor falls below a threshold.
Running the queue weekly
The queue only compounds if it arrives somewhere a rep already looks. We push the top accounts per owner into the CRM as a view, with the reason column visible, every Monday morning. Anything worked gets logged back, so the next week's ranking knows what was already tried.
Review the weights once a quarter against what actually closed. If accounts with a particular signal keep converting, that signal is underweighted.
Questions
Do we need Clay for this, or will our CRM do?
The scoring logic works anywhere you can store signals with dates. Clay makes the enrichment and the formulas faster to build and change, and the output still lands in the CRM where reps work.
How many signals should we start with?
Fewer than you think. Two or three per layer is enough to produce a useful order. Add more only when you can show a new signal changes which accounts rise to the top.
How long before the queue produces meetings?
The first ranked queue can be live within weeks. The compounding part, where weights are tuned against closed deals, takes a few quarters of honest feedback.