# Follow-up

A **follow-up** is a dated commitment to make contact: a time it is due, a channel it will happen on, and the reason it exists. Connect creates them from promises made in conversations and from stage changes, drains the ones it is permitted to act on, and shows the rest to a person. One channel — *task* — is never sent by anything.

- **Status:** Available
- **Audience:** both
- **In the app:** #/follow-ups
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/glossary/follow-up/

## The three parts, and why the reason is one of them

A due time alone produces a queue nobody trusts. Six weeks later the row says *ring Acme Traders on Tuesday* and nobody can remember whether Tuesday was agreed with them or invented by somebody clearing a backlog. The reason is stored because it is the part that decides whether the contact should still happen at all.

The channel is the third part, and it is a commitment too. A promise to email somebody is not discharged by ringing them, and a workspace that has [switched a channel off](/docs/glossary/autonomy/) has not thereby agreed to the same message arriving another way.

| Channel | What draining it does |
|---|---|
| email | Sends, or holds for approval, under the mailbox's autonomy |
| whatsapp | Replies on the WhatsApp conversation under the same rules |
| sms | Depends on a provider that carries SMS — see [SMS in Connect](/docs/sms/) |
| phone | Places a call through the same gates any outbound call passes |
| any | Leaves the channel open; the contact is made on whichever suits |
| task | Nothing. It is work for a person, and appears as *For a person to do* |

## How the phone queue drains, and when it refuses

Phone follow-ups are the strictest case, because a call cannot be recalled and a badly timed one is worse than none. Two are attempted per engine tick, each through the ordinary outbound-call gates, and the outcome is recorded against the row: a call placed, an approval waiting, or a refusal with its reason.

1. The row comes due and the line is checked.
   - Result: A line that is not ready does not fail the row — it is retried in an hour.
2. The gates run: autonomy, suppression, budget, business hours.
   - Result: A refusal is written onto the row with its reason, so the queue explains itself rather than going quiet.
3. If the row is more than 24 hours late, it is closed as missed.
   - Result: Nobody is rung. A call-back a day after it was promised does more damage than the one that never came.

> **Careful** That last rule surprises people who expect a queue to be exhaustive. It is deliberate, it applies to phone, and a row closed this way stays visible with its reason rather than disappearing.

## Against approval, reminder and calendar entry

**An [approval](/docs/glossary/approval/)** — One prepared action waiting for a yes, now. A follow-up is a commitment for later that may itself need approval when its moment comes.
**A reminder** — A nudge aimed at a person. A follow-up is aimed at the contact, and most of them are discharged without anyone being nudged.
**A calendar entry** — A booked slot in somebody's diary. Connect does not manage a diary; a follow-up says contact is owed by a time, not that a meeting exists.
**A [Needs You](/docs/glossary/needs-you/) item** — The queue a person works. A `task` follow-up is work for a person and so is an item there in spirit — but the two lists are separate and drain differently.

## Questions

### What happens if the same promise is captured twice?

Duplicate follow-ups are a known failure and are surfaced rather than silently merged, because two rows can be a genuine double commitment. [Duplicate follow-ups](/docs/follow-ups/duplicates/) covers how to tell the two cases apart.

### Can Connect promise a call-back it will not be able to make?

That is the failure the phone queue is designed against: a promise made on a call becomes a row with the same gates the call itself passed, so a promise the workspace cannot keep is refused visibly instead of being made and forgotten.

### Who can complete a follow-up by hand?

Anyone in the workspace who can act on that channel. Completing it records who did, which matters when the question later is whether the contact happened at all rather than when it was due.

## Related

- [Approval](https://connectbyjbrh.com/docs/glossary/approval/)
- [Opportunity](https://connectbyjbrh.com/docs/glossary/opportunity/)
- [Follow-ups in Connect](https://connectbyjbrh.com/docs/follow-ups/)
- [Follow-ups for a person to do](https://connectbyjbrh.com/docs/follow-ups/task-channel/)
- [Preventing a voice agent from promising a call-back it cannot keep](https://connectbyjbrh.com/research/callback-promises/)

## What this page is based on

- docs-source/sources/GENERAL.md §7 — channels, the task channel, the phone drain
- `backend/app/followups.py` — the queue and its channels
- `docs-source/facts.py` — MEASURED phone_followup_max_late_hours