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.
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 |
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_threadandstop_for_personare the blunt instruments for that situation, and they are the right ones when a customer has clearly had enough.snoozeis for a chase that is right but early;cancelis for one that should not happen at all.
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.