Build it with AI
Create a deal tracker that makes next action and risk visible.
Build a focused opportunity tracker for stage, amount, owner, close date, activity, risk, and next step.
Introduction
What a deal tracker has to hold.
Most teams end up with a deal tracker the same way: a pipeline report that shows amounts and stages but not whether anything is actually moving. A rep carrying eight deals can hold every one in their head, and the tracker is overhead. At twenty-five across a team, the state that matters — who has gone quiet, what is waiting on whom — exists nowhere except in three people’s recollection.
The tracker shows a deal as open right up until it is lost, because nothing in it captures the absence of progress. There is no record of what the deal is waiting on, no owner for the next step that is distinct from the owner of the deal, and no signal when the elapsed time since the last contact stops being normal.
What follows covers building a deal tracker: the records it holds (opportunity, amount, owner, close date, last activity, risk signals, and the committed next step), the systems it reads (Salesforce and HubSpot), and what it does not fix.
The problem
Deals move in conversations the system never sees.
CRM opportunity records model the commercial facts — amount, stage, close date — and are almost silent on the operational ones, which is why the actual state of a deal lives in a rep’s notes app. Project tools model the next step well and have no concept of a close date.
The records are opportunity, amount, owner, close date, last activity, risk signals, and the committed next step, and the authoritative copy of most of them already lives in Salesforce or HubSpot. The close date in the CRM was set at creation, the close date in the rep’s head moved twice, and the forecast is built from the first one.
The cost is not the inconvenience: a quarter is committed on deals that stopped progressing weeks earlier.
You're likely here because
- The answer to what a deal is waiting on comes from a person, not a system
- The tracker shows a deal as open right up until it is lost, because nothing in it captures the absence of progress.
- When it is wrong, a quarter is committed on deals that stopped progressing weeks earlier
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Deal table
- • Risk flags
- • Stage summaries
Operated through Grow
- • Follow-up
- • Meeting scheduling
- • Pipeline actions
Systems it reads
- • Salesforce
- • HubSpot
- • Google Calendar
The record model
What a deal record has to hold.
- What it is waiting on
- The operational state, held separately from the commercial one. Almost every tracker fails by conflating the next step with the stage, and the next step is the field a manager actually needs.
- Owner of the next step
- Distinct from the owner of the deal, because the thing blocking it is frequently owned by legal, finance, or the customer rather than by the seller.
- Last genuine contact
- Inferred from email and calendar. A tracker that asks a rep to log activity is accurate for three weeks and then confidently wrong in a way nobody notices.
- Close date history
- Every value it has held, not just the current one. Four one-week slips look reasonable individually and are a three-month pattern in aggregate.
- Risk flag with its basis
- The flag plus why it fired, so a rep can correct a wrong inference instead of arguing with an unexplained warning. Unexplained flags get ignored within a month.
- Segment
- Because three weeks of silence is alarming in one motion and normal in another, and a single blended threshold produces noise that discredits the whole view.
- Amount and its confidence
- Held apart from the forecast category, so an optimistic amount cannot quietly become a committed number.
How it runs
From remembered state to recorded state.
Step 01
Describe what a deal tracker has to do
Model what a deal is waiting on as a first-class field with an owner and a date, separately from the stage. The next step is the operational state, and almost every tracker fails by conflating it with the commercial one.
Step 02
Connect the systems of record
Email and calendar supply the last genuine contact and whether the meeting happened; the CRM supplies amount and stage. The tracker infers activity rather than asking a rep to record it.
Step 03
Build the operating surface
A deal table with amount, owner, close date, last contact, what it is waiting on, and a risk flag derived from elapsed time rather than from sentiment.
Step 04
Start narrow
A view of open deals ranked by days since last contact, with the amount alongside. That one list will change the next pipeline meeting more than a full tracker built over six weeks.
Step 05
Route the exceptions
A deal that passes its risk threshold surfaces to the manager with the last three interactions attached, so the intervention is informed rather than a request for an update.
Step 06
Measure how far in advance a slipped deal becomes visible
Measure the share of deals slipping their close date more than once. Slippage is the honest indicator, and it responds within a single cycle to a tracker that surfaces silence early.
Implementation path
Tracking deals without adding data entry.
- 01
Define risk as elapsed time against something observable rather than as a rep’s confidence rating. Confidence ratings correlate with personality more reliably than with outcomes.
- 02
Baseline the slip rate — how often a close date moves, and by how much — for the last two cycles. It is the number the tracker has to move.
- 03
Connect email and calendar before adding a single field, so that last contact is inferred rather than typed. A tracker that requires manual activity logging is a tracker that will be accurate for three weeks.
- 04
Run the risk view alongside the existing forecast for one cycle and check whether the deals it flagged were the ones that slipped. If they were not, the threshold is wrong, and that is worth knowing before anyone relies on it.
- 05
Build the narrowest useful version first: a risk view listing deals whose close date has moved more than once, with the reason recorded.
- 06
Deriving the risk threshold from your own closed history — how long deals that closed went between contacts — takes an afternoon with an export and is the difference between a useful flag and a nuisance. Connecting email and calendar is the technical core. One ranked view of open deals by days since contact within a week, then one cycle of running it beside the existing forecast to check the flags predicted the slips.
- 07
After slip rate has responded, add waiting-on categories and measure where the time actually goes — legal, procurement, customer silence. That data changes which part of the process gets attention, and it is invisible in any stage-based view.
Controls
Controls that matter.
Control 01
Risk derived from observable activity rather than from a subjective confidence field, so the flag is challengeable with evidence
Control 02
Manager visibility scoped to their own team, since a deal tracker is also an activity record for the people working the deals
Control 03
The last-contact inference shown with its source, so a rep can correct a wrong inference rather than argue with an unexplained flag
Examples
Three ways risk becomes visible earlier.
The deal that went quiet in August
Days since last genuine contact, computed from email and calendar rather than from logged activity, surfaces the silence in week two instead of at the quarterly review.
Waiting on legal, apparently
Modelling what the deal is waiting on with an owner and a date turns a recurring status answer into a tracked item, and makes visible how often waiting on legal means nobody has sent it yet.
The close date that moved four times
Retaining every previous close date rather than overwriting it turns a pattern that everyone half-remembers into a fact the forecast conversation can use.
How it goes wrong
Three ways deal tracking loses trust.
Risk is derived from a rep-entered confidence rating, and the ratings turn out to track personality rather than outcomes.
Derive risk from observable activity and elapsed time. Confidence fields measure disposition, they are not comparable between people, and they are the first thing to be gamed once anyone acts on them.
Half the mailboxes are connected, so the tracker is systematically wrong about the reps it cannot see.
Partial connection is the dangerous state. Either connect the channel or exclude those deals from silence-based flags and say so on the view, because a confident wrong flag costs more trust than an absent one.
Managers get visibility across the whole company and the tool is read as surveillance.
Scope visibility to the team, show the inference source, and let reps correct it. Those three choices decide how a deal tracker is received far more than anything in the feature list.
Limitations and considerations
What tracking will not tell you about a deal.
- Elapsed-time risk flags misfire on long enterprise cycles where three weeks of silence is normal. Thresholds set per segment work; a single blended threshold produces noise that trains people to ignore the flag.
- A tracker sees the channels it is connected to. Deals worked over a phone or in a channel you have not connected will look silent while being actively progressed, and the flag will be wrong in a way that damages trust in it.
- Nothing here judges whether a deal is real. It can tell you a deal has been quiet for forty days; whether that means dead or slow is still a human call.
- If reps carry under ten deals each and the manager knows every one, this is overhead. If the mailboxes cannot be connected for policy reasons, build something else — a deal tracker fed by manual activity logging will be accurate briefly and misleading thereafter.
- Connector coverage varies: Salesforce, HubSpot, Google Calendar are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a deal tracker with AI: common questions.
How is this different from the opportunity record we already have?
The opportunity record holds the commercial facts. A tracker adds the operational ones — what it is waiting on, who owes the next move, how long the silence has run — which most CRMs either omit or hide inside a free-text note that no report can read.
Will this feel like surveillance to the sales team?
It does if the flags are unexplained and the visibility is unbounded. It does not if the inference shows its source, a rep can correct it, and manager visibility stops at their own team. Those three choices decide how the tool is received far more than the feature set.
What threshold should a risk flag use?
Derive it from your own closed history rather than picking a round number. Look at how long the deals that closed went between contacts, and set the flag beyond that. Segment it if enterprise and mid-market behave differently, which they usually do.
Does it need every email connected?
It needs enough that silence means silence. Partial connection is the dangerous state: the tracker looks authoritative and is systematically wrong about the reps whose mailboxes are missing.
What should the first version contain?
A risk view listing deals whose close date has moved more than once, with the reason recorded. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure how far in advance a slipped deal becomes visible against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build a deal tracker around the process you actually run.
Infer last contact rather than asking anyone to log it, set the risk threshold from your own closed history, and judge it on slip rate.