CRM deals, stages, activities and tasks
Last real interaction and time in stage against the stage's threshold
Healthy, watch or at risk, with a reason
Daily message per owner and AI agent
What it solves
- A stalled deal shows up the week it stalls, not at the end of the quarter.
- Each owner gets only their own deals, with the reason and what to do.
- The alert respects each stage's pace and does not fire for nothing.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- CRM connected with deals, stage history, activities, tasks and users
- The acceptable time per stage and each pipeline's exceptions, agreed with the team
- An output channel: Slack, WhatsApp, Google Chat or a CRM task
What you get
- A table per open deal with status, reasons, days without interaction and days in stage
- A daily message per owner with the deals that changed status
- A weekly panel of deals entering and leaving risk
- An AI agent that answers questions about stalled deals
Where to activate
On Slack, WhatsApp or CRM chat, only the deals that entered or left risk, with reason and link.
One task for the owner on each deal that became at risk, without duplicates in the window.
Answers which deals are stalled, why and whose they are.
The rules are simple. The work is calibrating each stage's time and the exceptions with the sales team, or the alert turns into noise. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
A deal can sit in the same stage for months without anyone noticing. Measuring stalled by the last modified date makes deals look alive when an automation only edited a field, and a single 30 day cutoff asks the same of a proposal stage and a signature stage. The alert turns into noise and the team stops reading it.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
The stalled yardstick is the last interaction: a completed activity (call, meeting, email, message) or a stage change, whichever is more recent. The last modified date does not work: automation, syncs and field edits change the date without the deal moving.
Calculate the entry into the current stage from history: hs_v2_date_entered_current_stage or hs_v2_date_entered_<stageId> in HubSpot, stage history in other CRMs. The deal's update date only approximates the entry and resets with every edit.
Set the acceptable time per stage and, if possible, per deal size, from history: a good cutoff is the 75th or 90th percentile of the time won deals spent in the stage. In final stages, some teams use a hard rule: above the cutoff, the deal is at risk whatever the rest.
A deal with a meeting or task scheduled in the future is not stalled, even without recent activity. Stages covered by automation (a 7 day WhatsApp cadence, a booking that goes straight to the calendar) have their own deadline, agreed with the team, or the alert chases what the machine is already doing.
Besides time, flag: no owner or a deactivated owner (matching the owner against the active users list by email), no next activity, overdue task, zero amount, past expected date, expected date pushed two or more times, and owner changes. Each signal is a separate reason, so the owner knows what to do.
Classify as healthy, watch or at risk by fixed rules and show every reason that applies. The status given by the manager or by a follow up form can override the rule, with a record of who and when. A 0 to 100 index, if there is one, supports the reading; it is not a probability of closing.
Send each owner the deals that became at risk since the last send and the ones that left risk, not the whole list every day. Keep a send history and do not repeat the same alert within the agreed window. Send on business days, with the holiday calendar.
From the date the alert started, classify each alerted deal as resolved (moved or closed), engaged (had activity but is still in the stage) or still stalled. That is what shows whether the alert works.
Reasons a deal can receive
Each reason is a column. The status is the agreed rule over them.
Definitions
Pitfalls that already happened
A daily list with every critical deal repeated the same names and the team stopped opening it.
Send only deals entering and leaving risk.
A stage covered by a 7 day automatic WhatsApp cadence was held to a 2 day deadline and fired an alert every day.
Own deadline for automated stages, agreed with the team.
Service done through the WhatsApp app, outside the CRM, created no activity, and deals in the middle of a conversation showed up as stalled.
Bring conversations in as activities or declare the stages where the CRM cannot see the contact.
The owner came as an empty string, not as null, and orphan deals did not show up in the alert.
Treat empty strings as null before testing the owner.
Deals merged or deleted in the CRM stayed in the raw data and showed up as stalled every day.
Exclude merged ids (hs_merged_object_ids in HubSpot) and check the active ids regularly.
Acceptance test
The case is done when every item passes.
- Every open deal in an acquisition pipeline has one row per day with status, days without interaction, days in stage and reasons.
- No deal with a future task or meeting appears as without interaction.
- For one owner and one day, the message sent holds exactly the deals that entered and left risk since the previous send.
- No won or lost deal appears in the table.
- In a sample of 20 at risk deals checked in the CRM, the last interaction and the stage entry match the screen.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Deal health - Source: health table (open deal x day), with status, days without interaction, days in stage, stage threshold and reasons. - Stalled = no real interaction: a completed activity or a stage change. The last modified date does not count. - Days in stage come from the stage history, never from updated_at. - Threshold per stage: <stage> = <days>. Automated stages: <stage> = <days>. - A future task or meeting suspends the interaction alert. - Status: healthy, watch or at risk, always with the reasons. A 0 to 100 index, if there is one, is not a probability of closing. - When listing at risk deals, group by owner and show the reason and the last interaction. - To assess the alert's effect, use resolved, engaged and still stalled since <start date>. Client exceptions: - <client>: the follow up form status overrides the rule. - <client>: send Monday to Thursday and on Sunday; Friday, Saturday and holidays do not send.
Build the "Deal health + alert agent" case in my Nekt workspace following the rules at https://academy.nekt.com/en/casos/saude-de-deals.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
A model reads the day's table and the team playbook and writes the leadership summary, without citing deals outside the table.
The same rules on the CS pipeline: days without contact, long stage and zero tasks as churn risk signals.
In lending and post-sale, a deadline per workflow phase instead of a sales stage.