CRM
The next-action principle in CRM: who does what by when?
Turn active opportunities into executable work with one primary next action, an evidenced reason, owner, due time, result and safe return path.
Short answer
Every active opportunity needs exactly one primary next action: a named person performs a concrete action by an unambiguous time because a verified customer or process event justifies it. Store status, note, reminder and buyer commitment separately. `Waiting on the customer` is complete only when the expected event, its date and the team's action if it does not arrive are known. After execution, read the actual result back from the CRM; only then should the action be completed, replaced or the case deliberately paused or closed.
Key takeaways
- Separate activity, stage, buyer commitment, reminder and primary next action; a maintained history is not yet an executable work plan.
- Write every action against the correct business case with an owner, observable verb and object, unambiguous due time, evidenced reason and expected result.
- Allow four operating positions: seller action, expected buyer action, external blocker or deliberately no justified action; elapsed time alone is not a contact reason.
- Read the result back from CRM and end the action as complete, superseded, stopped or reviewed before creating another task.
A pipeline shows position — the next action directs work
A fictional Monday morning: the opportunity says `proposal sent`, the latest note reads `customer reviewing internally`, and a task is called `follow up`. The pipeline looks maintained. Yet the next person cannot answer three basic questions: who is waiting on whom, when was a response agreed, and what should happen if it does not arrive?
This is not a lack of activity. The conversation, proposal and task all exist. What is missing is an executable agreement for the next state transition.
A next action is not a hope that the deal progresses. It states who owns which verifiable step by when and for what reason.
Qualitative discussions in sales and CRM communities describe versions of the same issue: `follow up soon`, task lists with no daily working view, a handoff buried in a note or `waiting on customer` without an internal fallback. Others describe the opposite failure: a mis-mapped event closes many tasks while the real work remains open. These individual reports provide useful test cases, not a market prevalence or effectiveness estimate.
Separate activity, status, commitment, reminder and action
All five items may point to the same deal, but they do not mean the same thing.
Item | Question answered | Example | Why it does not replace a next action |
|---|---|---|---|
activity | what happened? | proposal sent on 14 September | records the past, not the next responsibility |
status or stage | where is the case? | proposal / open | groups cases but names neither action nor time |
buyer commitment | what did the other party say it would do? | procurement will reply by Friday | the expected action does not automatically belong to the seller |
reminder | when should somebody look? | Friday at 10:00 | does not yet say what must be decided or done |
primary next action | who does what, when and why? | Lea checks for procurement approval Friday at 10:00 and calls only if the agreed response is missing | executable and verifiable in its outcome |
A meeting note can hold the reason. The stage can represent business state. A reminder can attract attention at the right moment. The next action connects these facts to work. It should not exist solely as free text in the latest note.
The next-action sentence prevents “follow up sometime”
A small team can use one fixed sentence pattern:
`[Owner] + [verb and object] + [by time] + [based on] + [expected evidence]`
Example: `Lea sends procurement the two missing security answers by Tuesday 14:00 because they were promised in the call; the action is complete when the email is logged against the correct opportunity.`
The format does not make the customer message robotic. It structures the internal commitment. A useful verb is observable: send, call, review, confirm, prepare, approve or close. `Keep warm`, `work`, `stay on it` and `follow up` remain too vague without an object and result.
A complete next-action card contains:
Field | Content | Protection provided |
|---|---|---|
opportunity ID | the specific business case, not just a contact | prevents follow-up on the wrong deal |
current state | stage, status and confirmed blocker | provides context without guessing the action from it |
latest relevant event | conversation, reply, proposal, appointment or failure | evidences the reason |
who owes what to whom? | seller, buyer, partner or internal role | separates a buyer commitment from the team's task |
primary action | verb, object and expected result | makes work executable |
owner | exactly one eligible person | prevents shared pseudo-ownership |
`due_at` | date, time, timezone and business calendar | replaces `soon` with one point in time |
fallback | permitted step after absence or failure | prevents endless or unchecked follow-up |
action state | planned, due, complete, superseded, stopped or review | separates technical from operating outcomes |
rule version | origin and current operating rule | makes automated decisions explainable |
Not every field needs to dominate the daily interface. The underlying data must still be sufficient to explain the work and its origin.
Four operating positions instead of one universal follow-up
An active opportunity can occupy four different working positions. Only one means the seller must act immediately.
Position | What is evidenced? | Appropriate next action |
|---|---|---|
seller action due | the customer or process is waiting for a specific output from the team | create the action with owner, due time and result |
buyer action expected | the other side committed to a specific result or reply | store the expectation and date; schedule the team's review or agreed response |
external blocker | approval, partner, authority or delivery date remains open | record blocker, external role, expected event and internal review date |
no justified action | no concrete signal, commitment or useful reason for another contact | deliberately pause, move into permitted nurture or close |
Elapsed time alone is not a reason to contact someone. If no next step was ever agreed and no new information exists, a seven-day reminder produces activity only. It proves neither buyer interest nor customer value. Sometimes the right CRM action is internal: reassess fit, clarify the missing basis or end the sales attempt.
`Waiting on customer` needs its own return path
`Waiting on customer` is valid when the expected action is specific. `Customer will get back to us` is incomplete. A complete state would contain:
expected event: procurement approval or a question;
agreed or internally selected review time: Friday, 16:00 Europe/Berlin;
evidence: conversation on 14 September, participant and summary;
internal action: check for the event, then remind once under the agreement if absent;
owner: the person who recognises the reply and forms the next state;
stop: no automated message if a reply, rejection, booking or other decision already arrived.
If the reply comes early, it supersedes the planned review. If it does not arrive, do not simply repeat the same message. First check whether the agreement still applies and which step provides a reason for the customer.
This logic also prevents an inflated pipeline. A deal should not stay active indefinitely because its next-action date keeps moving. After a bounded review defined in advance, it needs a new operating decision: continue, pause, take another route or close.
One primary action, several supporting tasks
“Exactly one next action” does not mean only one person may contribute to a complex deal. A proposal may need technical review, pricing and approval in parallel. Those subtasks support one primary state transition, such as `send the approved proposal to the customer by Wednesday`.
Task | Role | May it replace the primary action? |
|---|---|---|
review technical feasibility | supporting internal task | no; the result feeds approval |
approve pricing | prerequisite or decision | no; the customer process still points to the same main action |
send proposal | primary customer-facing action | yes; exactly one owner supplies completion evidence |
complete CRM note | administrative follow-up | no; it must not imply that the business case progressed |
The deal stays unambiguous in daily management while internal collaboration remains visible. If every subtask becomes an equal `next action`, the CRM shows many open items but not the decisive customer progress.
From the current case to an evidenced result
From the current case to an evidenced result
Read the case
Check opportunity ID, state, latest customer interaction, buyer commitment, open tasks and existing action.
Decide the obligation
Determine who owes what and the smallest step that changes state or resolves a concrete uncertainty.
Set the action
Store verb, object, reason, result, exactly one owner and unambiguous due time against the correct case.
Evidence the result
Read the target state back; complete, supersede, stop or review, and create a new action only with cause.
Ambiguous opportunity, action already exists, newer customer event, unclear owner or unapproved operating decision?
Do not duplicate, guess the latest deal or contact blindly. Preserve candidates, conflict, current event, owner and due time in a review card.
Recommended flow: read the correct case and latest event, determine the obligation, set exactly one primary action and read the result back.
1. Read the case and latest relevant event
Start from the specific opportunity ID. Read stage, status, owner, latest customer interaction, open tasks, buyer commitment and any planned action. One contact can have several opportunities; `latest deal` is not a sufficient business match when two cases are open in parallel.
2. Decide the obligation, blocker and permitted step
Determine who currently owes what to whom. Distinguish a buyer commitment, internal output, external blocker or the absence of a justified next step. Describe the smallest action that changes state or resolves a concrete uncertainty. Sensitive pricing, legal or concession decisions remain with the responsible person.
3. Set one primary action with owner and due time
Write the verb, object, reason, expected result and `due_at`. Assign exactly one eligible person. Do not duplicate an existing active action; a new customer reply may supersede a waiting action. Supporting tasks remain subordinate to the primary outcome.
4. Read the result back and form the next state
A task is complete in operating terms only when the expected result is visible against the correct case. Close it as complete, superseded, stopped or reviewed. Only a new evidenced event or deliberate decision creates another action. If the result is missing, the opportunity remains in a visible exception.
These events require a new decision
Not every CRM update needs another task. Useful decision boundaries include:
a new enquiry is accepted as a distinct business case;
a conversation ends with a buyer or seller commitment;
a proposal or requested document is demonstrably delivered;
an appointment is booked, held, cancelled or missed;
a reply changes need, blocker, fit or stakeholder;
an opportunity is handed over and accepted by the new owner;
an existing action becomes overdue without the expected state;
a partial failure leaves it unclear whether the task, message or CRM update took effect.
A simple field edit, internal note or automated timestamp is not automatically enough. The rule must state which change matters to the business process. Otherwise every synchronisation creates another task and the daily working view loses meaning.
Four working views are enough for daily operations
A small team does not need an elaborate dashboard first. Four exception views expose the work:
View | Filter | Decision |
|---|---|---|
due today | active primary action due during the current working day | execute, re-plan or stop visibly |
overdue | due time passed and no confirmed result | inspect the cause; do not blindly repeat a message |
external event expected | buyer or partner owes a specific event and review time has not passed | monitor; end the old action if the event arrives early |
action missing or invalid | active opportunity without exactly one understandable action, owner or due time | clarify, pause or close |
A manager may also filter by stage, age or owner. Those views do not replace the four working states. An old deal may hold a valid long-term decision date; a new deal can already be orphaned without an owner or action.
The Salesforce documentation for Opportunity Reports lists stage, age, next step and opportunity owner as separate columns in another CRM. It is not a description of ONE LOOP. It illustrates the model boundary: age and stage provide context but do not automatically form an executable next action.
Automation should expose exceptions, not invent decisions
The safest automation is bounded mechanics:
create a predefined task with owner and due time after an unambiguous event;
produce a daily view or internal reminder for due and missing actions;
stop a planned action when the expected customer event has already arrived;
route a case without an action, with an unavailable owner or beyond a threshold to review;
update result state and the new action together after a controlled decision.
Risky shortcuts include:
inferring an unchecked pricing, legal or contact decision from a meeting summary;
contacting the customer solely because time passed;
creating another task on every opportunity update;
equating task completion with a won stage;
choosing the latest record when several opportunities could match;
overwriting an existing owner without checking relationship, permission or acceptance.
A system can connect tasks, date fields, owners and opportunity state. It can respond to changes or extended stage inactivity. That does not tell it whether the buyer is genuinely waiting, the next message adds value or a complex case is intentionally remaining in one stage for several weeks. Operating meaning remains a business rule.
What the external survey shows — and what it does not
HubSpot says it surveyed 1,000 global sales professionals for its 2025 State of Sales Report. Its public summary names lack of perceived product fit at 37% and poor perceived value for money at 35% as the two most commonly reported deal killers.
Two commonly reported deal killers concern perceived fit and value
Share of surveyed sales professionals · Page updated 9 September 2025; fieldwork dates not disclosed
- Lack of perceived product fit37 %
- Poor perceived value for money35 %
View data table
| Category | Share of surveyed sales professionals |
|---|---|
| Lack of perceived product fit | 37 % |
| Poor perceived value for money | 35 % |
Two independently reported deal killers; not parts of a 100% whole and not evidence of next-action effectiveness.
Source: HubSpot · 2025 State of Sales Report · Page updated 9 September 2025; fieldwork dates not disclosed. 1,000 global sales professionals according to the published summary; country and role mix not disclosed on the page.
Question wording, multiple-response logic, weighting and fieldwork dates are not disclosed. Global vendor self-report, not observed deals or a Germany/SME subset. No causal, next-action, conversion or ONE LOOP effect. Both values shown independently on a 0–100% scale.
The values are independent responses, not parts of one whole, and they must not be completed to 100%. The public page does not disclose exact field dates, role and country mix, question wording, response logic or weighting. It is a global self-report from a CRM and sales-software vendor, not observed opportunity data and not a German SME subset.
The chart does not prove that a next-action field rescues deals. It supports a narrower editorial point: a real action should address a specific open fit, value, approval or decision question. `Just checking in` creates no new basis when the actual obstacle remains unclear.
Currency is a separate data state
A perfect action description can become wrong tomorrow. The buyer replies early, the stakeholder changes, an appointment is cancelled or the opportunity closes. The card therefore needs event linkage, update time and a state transition instead of overwritten free text alone.
The Salesforce reference on identifying opportunity next steps that were not updated describes how another system requires historical trending and field configuration for that visibility. It is not effectiveness evidence. It illustrates one distinction: `the field is populated` and `the content is current` are separate checks.
ONE LOOP therefore invalidates or reviews an action on relevant events. A new customer reply must not coexist with an old automated reminder. An owner change must not silently inherit a stale commitment. A reopened opportunity needs a new reason and action; the latest closed task is not simply reactivated.
Overdue and stale are different exceptions
An action is overdue when its unambiguous due time has passed without the expected result. An opportunity is `stale` when it has remained without a specified activity or stage change for the configured period. The two states can overlap, but they are not equivalent.
Case | Action | Stage | Appropriate treatment |
|---|---|---|---|
callback due yesterday, deal only two days old | overdue | not stale | immediate working exception |
procurement decision agreed in six weeks | not due | possibly unchanged for a long period | do not trigger early contact |
deal in same stage 30 days with many internal notes | unclear | trigger may have reset | review buyer state and genuine action |
no action, event or decision, case still open | invalid | stale depending on threshold | operating decision rather than automatic message |
A stale rule is a searchlight, not a contact instruction. It may alert the owner or populate a review queue. Before any external communication, read the latest customer contact, commitment, reply, suppression, appointment and current status again.
Partial failure must not multiply tasks
A workflow can create the task and then fail on the opportunity update. A reply can arrive during a retry. Or a contact can have two open opportunities while a search returns only an earliest or latest match. Restarting from the beginning is unsafe.
Recovery checks:
Which technical event or decision triggered the action?
Which opportunity ID was selected, and why?
Does an active primary action already exist for this trigger?
Has a newer customer, appointment or status event arrived?
Did the owner change, and was acceptance confirmed?
Does the task exist while its result state is missing, or vice versa?
Which single technical or operating action remains incomplete?
If the correct task exists, do not create it again. If a customer reply arrived, supersede the waiting reminder. If the opportunity is ambiguous, stop with candidates and an owner in a review card. A technical failure must never guess that the newest deal is the right business case.
Twelve tests before the pilot
The following cases are fictional system tests, not measured ONE LOOP outcomes.
Test case | Required evidence |
|---|---|
call ends with seller promising a callback tomorrow | one concrete callback action with owner, time and call reference |
buyer promises documents by Friday | expected event plus internal review; no immediate seller task |
proposal sent without a review date | operating decision about a useful next step, not an invented buyer deadline |
stakeholder reports absence until month-end | old reminder stopped; new permitted review date with source |
opportunity has several stakeholders | primary action identifies the right recipient and case, not any contact |
one contact has two open opportunities | trigger updates only the unambiguously matching case |
owner is absent on the due date | visible fallback and accepted ownership, not anonymous team ownership |
user marks task complete without recording a result | opportunity remains an exception; no result state is invented |
buyer replies while a reminder waits | reminder ends; the reply may form a new action |
stage changed manually while the old task remains open | rule chooses explicitly between acceptance, supersession and conflict review |
same webhook delivered twice | one primary action and trigger, no duplicate customer message |
lost opportunity reactivates with a specific new need | new case state and action; closed historical task remains closed |
A test passes only when opportunity, latest activity, expected event, owner, primary action, due time and result state agree in the destination system. A green automation or task tick is insufficient.
Metrics should measure work clarity, not reminder volume
Define numerator, denominator and review period before the pilot. Keep absolute counts next to percentages.
Metric | Numerator | Denominator |
|---|---|---|
valid action coverage | active opportunities with exactly one understandable primary action, owner and due time | all active opportunities not deliberately paused |
overdue actions | primary actions past due without an evidenced result | all primary actions that became due |
orphaned cases | active opportunities without an eligible owner or valid action | all active opportunities at review time |
vague action rate | audited actions missing an unambiguous verb, object or result | all audited actions in the sample |
evidenced waiting | waiting states with expected event, source, review time and internal response | all opportunities in `waiting on external` |
result coverage | completed actions with an evidenced result state | all primary actions marked complete |
superseded correctly | planned actions ended because a newer event arrived | all actions receiving a newer relevant event before due time |
duplicate action rate | triggers with more than one unintended primary task | all unique triggers in the period |
time to action formation | duration from relevant event to valid next-action card | distribution across all eligible events |
pause/close audit | pauses and closures supported by the defined reason | all sampled paused or closed cases |
Completed-task count alone is easy to increase and says little about customer progress. A team can close many generic reminders while real decisions remain open. Conversely, a deliberately closed opportunity is not a failure of the principle when no justified step exists.
How ONE LOOP runs a bounded pilot
Choose one pipeline, two adjacent stages and one clear event type, such as a completed conversation or demonstrably delivered proposal. Define the next-action card, four operating positions and permitted result states. Decide which owner creates the card, who takes over during absence and which customer events supersede a planned action.
ONE LOOP can connect opportunity, owner and date fields, tasks with descriptions and due dates, internal notifications and conditional workflows. Changes and extended stage inactivity can trigger review. Before launch, test opportunity context, several deals per contact, owner synchronisation, trigger operators, re-entry, relative due dates, weekends and result read-back. The platform does not automatically invent the correct business action.
Run the twelve fictional cases first. Then take a bounded set of real open opportunities and let the team work from the four views for two weeks. Inspect missing actions daily and review vague descriptions plus tasks closed without a result weekly. Automate external messages only after the internal state logic is dependable.
CRM or spreadsheet supports the system choice. Distribute leads fairly decides who accepts a new case. Lead qualification forms its appropriate first state. ONE LOOP can then configure the next-action pilot with you.
Conclusion
An active pipeline does not become dependable through more notes or reminders. It becomes dependable when exactly one primary next action connects the current case to real work: unambiguous opportunity, evidenced reason, owner, verb and object, due time and verifiable result. Buyer commitment and waiting receive their own return path; elapsed time alone does not justify customer contact. After every result, read the state back before deliberately continuing, pausing or closing. The CRM can then answer the most important daily question: who does what today — and why?
FAQ
