TL;DR — What Changed
- The SDR queue rebuilds itself and ranks every lead automatically each morning, with no manager rebuilding it by hand.
- Reps work the highest-priority accounts first as a matter of course, not the luck of whoever organised the list that day.
- Every day’s queue draws proportionally across all five tiers instead of exhausting the top one first.
An SDR Queue That Ranks Itself Every Morning
Financial Cents needed its SDR team working the right accounts first, every single day, without a manager manually re-sorting a lead list before the team could start dialling. We built an n8n pipeline that generates the team’s daily calling queue automatically, five-tier scored, capped by band, and deduplicated across the whole team’s output.
Overview
Financial Cents builds accounting-practice-management software for the US market, selling into a defined, well-understood buyer base: accounting firms evaluating practice-management tools. The SDR team’s job is to work that base efficiently, which sounds simple until you consider what “efficiently” actually requires: a reliable way to decide who gets called first out of a large contact base, updated daily, without a manager spending part of every morning manually re-sorting a list before the team could start dialling. We built the pipeline that removes that manual step, and we’re describing the specific mechanics of it in some detail, because the mechanics are where the actual value sits, not in the general idea of “a scored lead queue,” which on its own is not a novel concept and isn’t what this case study is actually about.
The Problem
Before this build, generating a prioritised calling list for the SDR team was a manual or semi-manual exercise, done fresh each day or each week, depending on how much time whoever owned that task had available. That creates two problems that compound each other. First, the ranking itself is only as good as the judgement and time of the person doing it that day, which means it’s inconsistent: a list built carefully on a Monday and a list built quickly on a Friday afternoon don’t reflect the same rigour, even though the underlying data hasn’t changed in kind. Second, and more practically, it’s a recurring cost in someone’s time that scales with the size of the contact base rather than shrinking as the process matures, which is backwards: the tooling around a sales process should get more efficient as a team grows, not less.
There’s a quieter version of this problem too, which is what happens on the days the manual process gets skipped or rushed rather than done well. A team that’s used to working from a ranked list adapts to whatever list they’re given, including a poorly ranked one, without necessarily flagging that the ranking behind it was weaker that day. That’s not a failure of the SDR team’s judgement; it’s a natural consequence of asking people to trust an input they have no visibility into the quality of. The result is a sales motion whose effectiveness quietly varies with the rigour of a manual process nobody’s directly measuring, which is a hard thing to diagnose from the outside because the symptoms, inconsistent call outcomes, look like normal sales variance rather than a process problem.
Our Solution
We built an n8n pipeline that generates the SDR team’s daily calling queue automatically, with three specific mechanics doing the real work. The first is five-tier scoring: every contact in the base gets ranked into one of five priority tiers based on a defined set of signals, so a rep opening their queue in the morning sees a ranked list rather than an alphabetical or chronological one, and “who do I call first” has an answer that isn’t just gut feel.
The second mechanic, working alongside the first, is banded contact caps. A pure ranking by score alone has a failure mode: if the highest tier is small, the team burns through it quickly and spends the rest of the day working lower-priority contacts with nothing to structure that work; if the highest tier is large, top-priority contacts can get called repeatedly while others in the same tier never get reached. We capped the number of contacts pulled from each band per day, so the queue draws proportionally across tiers rather than exhausting the top tier first and leaving reps working an undifferentiated tail for the rest of the day. That keeps outreach spread sensibly across the full prioritised base over time, rather than concentrating all effort on a small top slice while everything else waits indefinitely.
The third mechanic, and the one that took the most careful design of the three, is the unique-dial-number constraint. In a practice-management sales motion, the same firm can have multiple contacts, and multiple contacts can sometimes share or be associated with the same phone number in messier real-world data. Without a constraint on this, the queue can generate duplicate or near-duplicate dials, the same number showing up more than once in a single day’s list, which wastes rep time and, worse, risks a contact getting called twice in the same day by two different reps who have no visibility into each other’s queues. We built the queue generation to enforce a unique-dial-number constraint across each day’s output, so every number that goes out to the team on a given day is dialled at most once per queue, regardless of how many separate contact records happen to reference that same number.
How We Deployed It
The unique-dial-number constraint was the piece that required the most iteration, because it interacts with the five-tier scoring and the banded caps in a way that isn’t obvious until you actually run it against real data. A naive implementation, deduplicate by phone number after scoring and capping, can silently shrink the queue below the intended size, because removing a duplicate after the cap has already been applied leaves a gap that never gets backfilled. We rebuilt the logic to deduplicate before applying the banded caps rather than after, so the cap is enforced against the already-unique set, and a removed duplicate gets replaced by the next-highest-ranked contact in that band instead of just leaving a hole in the day’s queue. That’s a small sequencing change, but it’s the difference between a queue that reliably delivers its intended size every day and one that quietly under-delivers on days where the raw data happens to have more duplication than usual.
We also had to decide how the pipeline should behave when the data feeding it was incomplete or delayed, since n8n workflows depend entirely on their upstream systems being available and current, and a workflow that assumes clean, timely data as a given will eventually run against a day where that assumption doesn’t hold. Rather than let a stale or partial data pull silently generate an incomplete or wrongly-ranked queue, we built the pipeline to flag when its source data looked stale against an expected freshness window, so a data issue upstream surfaces as a visible flag rather than a silently degraded queue that looks normal to a rep who has no way to know the ranking behind it was built on old information. We treated that visibility as non-negotiable: a queue that fails quietly is worse than one that fails loudly, because a loud failure gets fixed and a quiet one just erodes trust in the tool over time until someone eventually notices and asks why the numbers have felt off for weeks.
The Outcome
Leads arrive ranked, every day, without a manager manually rebuilding the list. Reps work the highest-priority accounts first as a matter of course, not as a matter of whoever happened to organise the list well that day. We’re describing this outcome in terms of what changed structurally, consistency and automatic daily generation, rather than attaching a conversion or revenue figure, because we don’t have a locked, evidence-backed metric for this build the way we do for some of our other engagements, and we’d rather state the change honestly in the terms we can actually stand behind.
What we can say with more precision is what the pipeline now guarantees structurally, because these are properties of the system rather than claims about downstream sales performance we can’t directly attribute. Every day’s queue draws proportionally across all five tiers rather than exhausting the top one and leaving reps working an undifferentiated tail. Every number in a given day’s queue is unique, so no contact is put at risk of being dialled twice by two different reps working from the same list. And every queue is generated against source data that’s been checked for freshness before it’s used, so a rep working the list has some structural assurance that what they’re looking at reflects current information rather than a delayed or partial pull. Those are the guarantees the build makes, and they’re the guarantees we designed and tested for directly, rather than inferring from a downstream metric that could have been influenced by any number of other factors.
What does five-tier scored actually mean for the SDR queue?
The daily calling queue is scored into five tiers, capped by band and deduplicated across the whole team’s output, so reps aren’t calling the same accounts as each other or working from an unranked list.
Why was the manual version of this a real problem, not just an inconvenience?
Because the ranking was only as good as the time and judgement of whoever built it that day. A list built carefully on a Monday and one built quickly on a Friday didn’t reflect the same rigour, and the cost scaled with contact-base size rather than shrinking as the team matured.
How often does the queue update?
Every morning, automatically, removing the step of a manager manually re-sorting a list before the team could start dialling.
See What This Looks Like for Your Stack
Related: AI Deployment and RevOps Consultancy. More on the team behind this build: About Equanax.