# Follow-ups on a deal

A deal creates dated commitments, and each carries a reason — a commitment without one is useless to whoever inherits it. The channel is part of the record, `task` means a person does it and no drain ever sends it, and two commitments with the same timing for the same person are treated as one.

- **Status:** Available
- **Audience:** both
- **Channels:** email, whatsapp, phone
- **In the app:** #/follow-ups, #/pipeline, #/needs-you
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/sales/sales-follow-ups/

## What raises one

- A stage change, where the new stage implies a next contact.
- A promise made in a conversation — 'I will send that on Thursday' becomes a record, not a memory.
- A demo being scheduled, which is a commitment with a time already attached.
- A commercial question going for review, so the customer is not left waiting silently.
- A person, or the Assistant's `create_followup`, deciding one is needed.

Whatever raised it, the shape is the same: a person, a time, a channel and a reason. `schedule` writes it; `due` and `upcoming` are how the queue is read; `complete`, `attempted`, `cancel` and `snooze` are how it ends or moves.

## Choosing the channel

| Channel | What happens when it comes due | Use it when |
|---|---|---|
| `email` | A reply is drafted and sent under the mailbox's autonomy | There is something to read, attach or refer back to |
| `whatsapp` | The same, on the WhatsApp thread | The conversation already lives there |
| `phone` | `chase_phone` drains due rows and places the call through the ordinary gates | A conversation is faster than a thread |
| `sms` | Depends entirely on the configured provider | Only where a provider that carries SMS is configured — the live carrier does not |
| `any` | The engine picks from what is available for that person | You care about the outcome, not the medium |
| `task` | Nothing is sent. It appears as 'For a person to do' | The work is not a message — preparing a document, ringing a supplier, making a decision |

> **Note** `task` is not a lesser channel. It is the honest way to record work that a machine is not going to do, and a queue that mixes both is the only one that describes what is actually outstanding.

## The phone drain, in detail

Phone commitments are worth understanding because they behave least like the others. `chase_phone` runs every tick and takes two rows, placing each call through the same gates any outbound call passes — line readiness, autonomy, budget.

**Outcomes are recorded literally** — A row ends as a placed call, as awaiting approval, or as refused with the reason attached. There is no ambiguous middle state.
**A line that is not ready waits an hour** — Rather than retrying immediately against a line that is still unavailable.
**Very late rows are closed, not rung** — A commitment more than a day late is closed as missed. A call-back a day and a half after it was promised does more harm than silence.
**Two per tick is deliberate** — It bounds how much of a workspace's day the queue can consume, and keeps one busy afternoon from becoming a wall of calls.

## The duplicate rule

A commitment with the same timing for the same person is a duplicate, and is not created twice. That rule catches the common cause — two paths deciding the same chase is needed within the same window, typically a stage change and a promise in a reply.

- It compares the person and the when. It does not compare the wording of the reason.
- So two differently-timed chases for the same purpose both stand, and both go out, which is how one customer ends up hearing from you twice.
- `stop_for_thread` and `stop_for_person` are the blunt instruments for that situation, and they are the right ones when a customer has clearly had enough.
- `snooze` is for a chase that is right but early; `cancel` is for one that should not happen at all.

> **Careful** Before adding a chase by hand, read `upcoming` for that person. The duplicate rule protects against identical timing, not against your not having looked.

## When a deal closes

Closing an opportunity records an outcome on the deal. The commitments are separate records keyed to the person and the thread, so walk the queue afterwards: complete what happened, cancel what the outcome made pointless, and leave anything genuinely still owed. A chase that goes out a week after a deal was lost is the most avoidable bad impression in this whole section.

## Questions

### Why does a commitment need a reason?

Because somebody else will inherit it. A row that says only 'follow up Tuesday' forces whoever opens it to reconstruct the intent from the thread, and half the time they get it wrong.

### Can Connect chase without asking me?

Only where the channel's autonomy allows it. Under `ask_before_send` the drafted chase waits in Needs You; under `draft_only` it is prepared and stops there. The queue does not raise the authority of the send.

### What happens if nobody ever completes a task-channel item?

It stays visible and becomes overdue. Nothing sends it, nothing closes it quietly, and that visibility is the entire point of recording work a person has to do in the same queue as work Connect does.

## Related

- [Follow-ups in Connect](https://connectbyjbrh.com/docs/follow-ups/)
- [Choosing the channel](https://connectbyjbrh.com/docs/follow-ups/channel-choice/)
- [Duplicate follow-ups](https://connectbyjbrh.com/docs/follow-ups/duplicates/)
- [Closing a deal: won and lost](https://connectbyjbrh.com/docs/sales/won-and-lost/)
- [The next best action on a deal](https://connectbyjbrh.com/docs/sales/next-best-action/)
- [The same person is being chased repeatedly](https://connectbyjbrh.com/docs/troubleshooting/too-many-follow-ups/)

## What this page is based on

- docs-source/sources/CHANNELS.md §7 — follow-up channels, verbs and the duplicate rule
- docs-source/sources/GENERAL.md §7 — chase_phone, outcomes and the late-row rule
- Connect capability registry (docs-source/facts.py)