# The next best action on a deal

A next best action is a suggestion derived from records you can inspect: the stage, what is already promised, when the person was last spoken to, and what they asked for. It is not a prediction and it is not an act — anything it proposes still passes through the autonomy rules of whichever channel would carry it.

- **Status:** Available
- **Audience:** both
- **In the app:** #/pipeline, #/relationships, #/follow-ups
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/sales/next-best-action/

## What it is derived from

`next_best_action` is one of the Assistant's read-only tools, and the same reasoning appears on a relationship and on a deal. It reads records rather than atmosphere:

- The stage, and what the stage rules say is missing before the deal can advance.
- Open follow-ups and their due times — the strongest signal there is, because a commitment already exists.
- The last contact on any channel, from the timeline, so a suggestion is not blind to a call that happened yesterday.
- The lifecycle stage of the person, which is a different axis from the deal's stage.
- Knowledge and memory that apply to this person, at the tier that owns them.
- Any open case, because chasing a deal while a support problem is unresolved is usually the wrong move.

Each of those is a record with a screen behind it. That is the point: a recommendation you cannot audit is one you cannot safely act on, and the reasoning behind that design is written up in [making a next-best-action defensible](/research/evidence-for-next-action/).

## What it will not suggest

**A price, a discount or a term** — Commercial invention is refused everywhere, and a recommendation is not a loophole. What it may suggest is asking a person for the decision.
**Contacting somebody who is blocked** — A `block:<channel>` directive resolves before anything is proposed, so a blocked person is not offered as somebody to chase.
**A channel that is off** — If voice is off for this workspace, 'ring them' is not offered. It respects the same autonomy configuration the action would.
**A guessed address** — Where no verified way of reaching the person exists, the suggestion is to find one, not to try something plausible.

## Acting on one

1. Read the reason before the recommendation.
   - Result: The reason names the record it came from, so you can disagree with the record rather than with the machine.
2. Accept it, and the work becomes a real record — usually a follow-up with a reason and a due time.
   - Result: It is now visible to everybody, survives your holiday, and is chased by the drain for its channel.
3. Let the channel's autonomy decide what happens next.
   - Result: In `ask_before_send` the drafted message waits in Needs You; in `autonomous` it goes out within the gates; in `draft_only` it is prepared and stops there, deliberately.
4. Where the suggestion is a commercial question, raise the deal for review instead.
   - Result: The question reaches a person with the deal attached rather than being answered by whoever replies fastest.

## When it is wrong

A recommendation is only as good as what it reads, so a wrong one is nearly always a record saying something untrue. Fixing the record fixes it; arguing with the wording does not.

| What it suggested | Usually means | Fix |
|---|---|---|
| Chase somebody you spoke to this morning | The conversation is under a second Person, or was never bridged | Merge, or check the timeline |
| Advance a deal that is plainly stalled | The stage no longer reflects reality | Move it, or record why it is where it is |
| Contact somebody who asked you not to | The request was made in a message and never written as a directive | Record the block against the contact |
| Something the customer already declined | The refusal lives in a thread, not in memory | Write it into memory against the person |

> **Careful** Correcting a recommendation in conversation changes that conversation. Writing the correction into memory changes behaviour. The two feel identical in the moment and are not.

## Questions

### Is this a prediction of whether the deal will close?

No. Nothing scores a deal's likelihood, and no such figure is stored on the record. It answers 'what is the next useful thing to do', which is a question about work rather than about the future.

### Will Connect act on a recommendation without me?

Only where the channel's autonomy already permits it, and within the same gates any other outbound passes. A proposal never raises the authority of the action it describes.

### Two people see different recommendations for the same deal — why?

They should not. If they do, check that both are looking at the same Person rather than at duplicate records, which is the usual explanation for two views of one relationship diverging.

## Related

- [Sales in Connect](https://connectbyjbrh.com/docs/sales/)
- [Stage rules and refusals](https://connectbyjbrh.com/docs/sales/stage-rules/)
- [Follow-ups on a deal](https://connectbyjbrh.com/docs/sales/sales-follow-ups/)
- [Making a next-best-action defensible](https://connectbyjbrh.com/research/evidence-for-next-action/)
- [Customer 360](https://connectbyjbrh.com/docs/relationships/customer-360/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)

## What this page is based on

- docs-source/sources/GENERAL.md §5, §6 and §8 — autonomy, memory tiers and the Assistant's tools
- docs-source/sources/CHANNELS.md §6 and §7 — sales verbs and follow-up reasons
- Connect capability registry (docs-source/facts.py)