n8n + n8n: Deal Velocity Tracker — Weekly Pipeline Speed Benchmark
Your CRM shows you which deals are open. It does not show you which deals are dying. A deal that has sat in "Proposal Sent" for 40 days looks identical to one that landed there yesterday — same stage,
Your CRM shows you which deals are open. It does not show you which deals are dying. A deal that has sat in "Proposal Sent" for 40 days looks identical to one that landed there yesterday — same stage, same amount, same little card on the board. By the time a rep flags it as "gone quiet," you have already lost the two weeks where a nudge would have mattered. Deal velocity is the metric that exposes this rot, and almost nobody tracks it because calculating it by hand every week is tedious. This template does it automatically in n8n.
The problem: stage counts lie, aging tells the truth
Pipeline reviews obsess over the wrong number. Everyone stares at total pipeline value and stage distribution, but a $2M pipeline where half the deals have not moved in six weeks is not a $2M pipeline — it is a $1M pipeline with a $1M graveyard attached. Static snapshots hide time. A deal's stage tells you where it is; only its age-in-stage tells you whether it is actually progressing.
The second problem is that "stalled" is relative. A 30-day-old deal is healthy for a business with a 90-day sales cycle and a corpse for one that closes in 20. Without a baseline computed from your own won deals, any stall threshold you pick is a guess. Founders end up either chasing every deal that goes quiet for a day (burning rep trust) or ignoring aging deals until the quarter closes and the number comes in short.
What you actually need is two things, refreshed every week: an honest days-to-close benchmark derived from deals you have actually won, and an automatic flag on every open deal that has aged past a multiple of that benchmark. That is precisely what the Deal Velocity Tracker builds.
The solution: a self-calibrating velocity benchmark
The workflow runs on a weekly schedule and does three things. First, it pulls your closed-won deals from the last 90 days and computes the average number of days each took from creation to close — this is your rolling velocity baseline. Because it uses only won deals, it reflects how fast money actually moves through your pipeline, not how long dead deals linger.
Second, it pulls every open deal and calculates its current age. Third, it compares each open deal's age against baseline × 1.5. Anything past that line is aging 50% slower than a typical winning deal and gets flagged as stalled. The 1.5x multiplier is the sweet spot: tight enough to catch trouble before it is terminal, loose enough that normal deal friction does not trigger noise. The output is a ranked list of stalled deals with days-over-baseline for each, delivered to Slack or email every Monday morning before your pipeline review.
The benchmark self-calibrates. As your team gets faster or your deal mix shifts, next week's baseline moves with it. You never hardcode "45 days" and let it go stale — the number is always earned from recent wins.
Step-by-step: building it in n8n
The template ships assembled, but here is the anatomy so you understand what runs and can wire it to your own CRM.
1. Schedule Trigger. Add a Schedule Trigger node set to a weekly cron — 0 8 * * 1 for 8am Monday. This fires the whole run once a week, ahead of your pipeline meeting.
2. Fetch won deals. Use your CRM node (HubSpot, Pipedrive, or a generic HTTP Request node against your CRM's REST API) to pull deals with status = won and a close date inside the last 90 days. In the HubSpot node, set the resource to Deal, operation to Get All, and add filters on dealstage and closedate. Return the createdate and closedate properties — you need both to measure duration.
3. Compute the baseline. A Code node does the math. For each won deal, calculate (closedate - createdate) in days, then average across all of them:
const days = items.map(i => (new Date(i.json.closedate) - new Date(i.json.createdate)) / 86400000);
const baseline = days.reduce((a,b)=>a+b,0) / days.length;
return [{ json: { baseline } }];
4. Fetch open deals. A second CRM node pulls all deals with status = open, returning createdate, dealname, amount, and owner.
5. Flag the stalled ones. Merge the baseline into the open-deals stream with a Merge node (or reference it via a static workflow variable), then run a Code or Filter node. For each open deal compute age = (now - createdate) in days and keep only those where age > baseline * 1.5. Attach daysOver = age - baseline so the report can rank by severity.
6. Sort and deliver. A Sort node orders the flagged deals by daysOver descending. Feed that into a Slack node (or Gmail / Send Email) using an expression to build the message body — deal name, amount, owner, and how many days over baseline. Now every Monday your channel gets a clean "these are the deals bleeding out" list, worst first.
Why this changes your pipeline reviews
The immediate benefit is that intervention becomes proactive instead of forensic. Instead of discovering at quarter-end that six deals quietly died, you get a weekly hit list while there is still time to act. A rep can re-engage, a founder can jump on a call, or you can consciously disqualify the deal and stop letting it inflate your forecast.
Forecast accuracy improves as a side effect. A pipeline where stalled deals are flagged and either revived or removed is a pipeline whose total value means something. You stop forecasting off zombies.
It also creates accountability without micromanagement. The report is objective — it is your own won-deal data drawing the line, not a manager's gut feel. Reps trust a threshold that came from real closes, and the conversation shifts from "why haven't you touched this" to "this one crossed 1.5x, what's the play." And because the benchmark recomputes weekly, the whole system stays honest as your business evolves. No dashboards to maintain, no spreadsheet someone has to update — it runs itself and shows up in the channel you already read.
Common pitfalls to avoid
Too few won deals. If your 90-day window holds only a handful of closes, the average is volatile — one outlier six-month deal skews everything. Widen the window to 180 days, or use a median instead of a mean in the Code node (days.sort() then take the middle element) to blunt outliers.
Timezone and date-format mismatches. CRMs return dates as Unix milliseconds, ISO strings, or their own format. If your duration math produces negative or absurd numbers, the culprit is almost always a parsing mismatch — normalize every date through new Date() and verify with a single deal before trusting the average.
Measuring from the wrong start point. createdate is when the deal record was made, which is not always when the opportunity truly began. If your team logs deals late, velocity looks artificially fast. Pick a consistent anchor — deal creation or entry into your first real sales stage — and use the same one for both baseline and open-deal age.
Blindly trusting 1.5x. The multiplier is a strong default, but a long, complex enterprise cycle may need 1.3x to catch stalls earlier, while a noisy transactional pipeline may want 2x to cut false alarms. Watch the flag list for a couple of weeks and tune the constant in the Filter node until it surfaces real trouble, not routine friction.
Firing the alert into a void. A report nobody owns is noise. Route it to a channel tied to your Monday review and make acting on the top three flagged deals part of that meeting. The workflow surfaces the problem; a human still has to make the call.
Ja construimos isso pra voce
Nao comece do zero. O Deal Velocity Tracker — Weekly Pipeline Speed Benchmark e um workflow n8n pronto para instalar — conecta suas ferramentas em minutos, sem codigo.
Instalar por $79 →
