You need a sales pipeline that tracks not just deal stages but also how fast deals move through each stage. Standard Notion databases can store contact names and deal values, but they lack built-in velocity metrics. This article explains how to build a Notion database that calculates time spent in each stage and overall pipeline velocity using formulas and rollups.
You will learn to set up stage timelines, compute duration formulas, and create a dashboard view that highlights stalled deals. The system uses a combination of date properties, linked databases, and formula fields to produce velocity scores. By the end, you will have a functional pipeline that surfaces slow-moving deals automatically.
This approach works for sales teams managing 10 to 1000 deals. It requires no external tools — only standard Notion features available on all plans. The setup takes about 30 minutes.
Key Takeaways: Building a Sales Pipeline with Velocity Tracking in Notion
- Date properties for each stage: Capture the exact day a deal enters and leaves a stage to enable duration calculations.
- Formula property with dateSubtract and dateBetween: Compute the number of days a deal spent in a stage or the entire pipeline.
- Rollup from a linked database: Aggregate velocity metrics across multiple deals in a master pipeline database.
- Filtered views with conditional formatting: Highlight deals that exceed your target stage duration by more than 50%.
What This Sales Pipeline Database Does and What You Need Before Building
The pipeline database tracks each deal as a separate record. Each record contains date fields for when the deal entered a stage and when it moved to the next stage. A formula field then calculates the difference in days between those two dates. That difference is the stage velocity.
To calculate overall pipeline velocity, you need a master database that rolls up the stage durations from a linked child database. For example, a Deal database links to a Stage History database where each stage entry has its own start and end date. A rollup in the Deal database sums the stage durations to give total pipeline time.
You need a Notion workspace with database creation permissions. No special integrations or paid add-ons are required. The formulas used are dateSubtract and dateBetween — both available in Notion’s formula editor.
Prerequisites
- Notion account (any plan works)
- Familiarity with creating databases and adding properties
- Basic understanding of formula syntax
Steps to Build the Sales Pipeline Database with Velocity Tracking
This section covers two methods. Use Method 1 for a simple single-database pipeline where each deal has fixed stage dates. Use Method 2 for a multi-database setup that tracks every stage change separately.
Method 1: Single Database with Stage Date Columns
- Create the Deal database
In your Notion workspace, create a new database. Name it Sales Pipeline. Add properties: Name (title), Deal Value (number), Stage (select with options: Prospecting, Qualification, Proposal, Negotiation, Closed Won, Closed Lost). - Add date properties for each stage entry
Add a date property named Stage Entered. Add another date property named Stage Exited. These will capture when a deal enters and leaves any stage. For a simple pipeline, you only track one move — from current stage to next. For full tracking, use Method 2. - Create the velocity formula
Add a formula property named Stage Duration (Days). Enter this formula:dateBetween(prop("Stage Exited"), prop("Stage Entered"), "days"). This returns the number of days between the two dates. If either date is empty, the formula shows nothing. - Add a target velocity threshold
Add a number property named Target Days. Set it to the number of days you expect a deal to spend in that stage — for example, 7 for Prospecting. Then add a formula property named Velocity Status with:if(prop("Stage Duration (Days)") > prop("Target Days"), "Slow", "On Track"). - Create a filtered view for slow deals
Click the + Add a View button in the database. Name it Slow Deals. Add a filter: Velocity Status is Slow. Sort by Stage Duration (Days) descending.
Method 2: Multi-Database Setup with Stage History
- Create the Deal database
Create a database named Deals with properties: Name (title), Deal Value (number), Stage (select). - Create the Stage History database
Create a second database named Stage History. Add properties: Stage Name (select), Entered Date (date), Exited Date (date). Then add a relation property named Related Deal that links to the Deals database. - Link each stage entry to a deal
In the Stage History database, create a new entry for each stage move. Set the Stage Name, Entered Date, Exited Date, and link it to the correct deal in the Related Deal property. - Add rollup to Deals for total pipeline time
In the Deals database, add a rollup property named Total Pipeline Days. Configure it to roll up the Stage History database. Set the property to Exited Date and the aggregation to Sum. This will sum all the Exited Date values — but you need a formula in Stage History first. - Add duration formula in Stage History
In Stage History, add a formula property named Duration Days with:dateBetween(prop("Exited Date"), prop("Entered Date"), "days"). Then update the rollup in Deals to roll up Duration Days with aggregation Sum. - Create a velocity dashboard view
In the Deals database, add a view named Velocity Dashboard. Group by Stage. Add a filter: Total Pipeline Days is greater than 30 (or your threshold). This shows deals that have been in the pipeline longer than your target.
Common Mistakes and Limitations When Tracking Velocity
Formula Returns Negative Numbers
If you enter the Exited Date before the Entered Date, the formula produces a negative number. Always enter the Entered Date first. To prevent this, add a validation check in the formula: if(prop("Exited Date") >= prop("Entered Date"), dateBetween(prop("Exited Date"), prop("Entered Date"), "days"), "Check dates"). This shows a warning instead of a negative value.
Rollup Shows Zero or Blank
A blank rollup means the relation is not connected. Open the Stage History entry and confirm the Related Deal property links to the correct deal. Also verify the rollup property in Deals points to the Duration Days formula, not the Exited Date raw field.
Velocity Does Not Update Automatically for Past Deals
Formulas only recalculate when you edit a property. If you change a date on a closed deal, the formula updates. But if you change the formula itself, all existing records recalculate immediately. No manual refresh is needed.
Stage History Database Becomes Cluttered
Over time, the Stage History database accumulates many entries. To keep it manageable, add a checkbox property named Archived. Create a filtered view that hides archived entries. Archive old stage moves once a deal is closed.
Single Database vs Multi-Database Setup: Key Differences
| Item | Single Database (Method 1) | Multi-Database (Method 2) |
|---|---|---|
| Setup time | 10 minutes | 20 minutes |
| Stage history detail | Only one stage move tracked per deal | Full history of every stage change |
| Velocity accuracy | Limited to current stage | Aggregates all stages for total velocity |
| Maintenance | Low — dates updated manually | Medium — must create new stage entry for each move |
| Best for | Small teams with simple pipelines | Teams needing detailed velocity analysis |
You can now build a Notion sales pipeline that tracks how fast deals move through each stage. Start with the single-database method if you need a quick setup. Use the multi-database method when you need to analyze velocity across multiple stage transitions. Add conditional formatting to your velocity status column — set a red background for “Slow” values — to surface stalled deals at a glance.