# Follow-ups for a person to do

`task` is a follow-up whose channel says a human must do this. **No drain ever sends a `task` row.** It appears as "For a person to do" on the follow-ups screen and stays there until somebody completes it. It exists because much of what gets promised is not a message: a quotation to prepare, a recording to review, a colleague to ask.

- **Status:** Available
- **Audience:** both
- **In the app:** #/follow-ups, #/needs-you
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/follow-ups/task-channel/

## What lands on it

- **Work that produces something.** "Send the quotation" is not a message — the message is the easy half, and the quotation is the promise.
- **Work that is internal.** "Review the recording", "check with the warehouse", "ask whether we can do Thursday". The customer is not on the other end of any of these.
- **Work that needs a judgement.** Anything where the next step depends on what a person concludes, rather than on a reply being sent.
- **Work that has no channel.** A commitment made in a meeting, or one inherited from a conversation somewhere Connect does not reach.

On a call, `follow_up_channel` makes this split automatically: a call-back goes on `phone`, and a person's own work goes on `task`. You can also set it by hand on any row, which is the right move when a promise turns out to need a person rather than a message.

## Why nothing sends it — and why that is the design

The obvious alternative is to have no `task` channel and simply not record human work. That was the failure this channel exists to fix: a promise made on a call that produces no row is a promise that survives only in somebody's memory of the call. Recording it as a follow-up gives it a due time, a reason and a place in the same queue as everything else owed to that person.

The other alternative — letting a drain attempt it — is worse. A drain that tried to execute "send the quotation" would send a message about a quotation that does not exist. Refusing to act is the only correct behaviour for work that a machine cannot do, and making that refusal explicit in the channel name is better than discovering it at the moment the row comes due.

> **Note** This is the single most common misreading of the follow-up queue: a `task` row sitting past its due time is not a drain that failed. Nothing attempted it, nothing will, and the row is waiting for you.

## Where it appears

| Where | How it reads | What you can do there |
|---|---|---|
| The follow-ups screen | Grouped as "For a person to do" | Complete it, edit it, snooze it or cancel it |
| The person's record | Counted in the open commitments to that person | See everything owed to one relationship in one place |
| Needs You | When it needs a decision rather than an action | Decide, and let the row close |
| A due or overdue view | Ranked with everything else that is late | Judge it against the rest of the day's work |

It is deliberately not a separate to-do application. Splitting human work off into its own list is how the two halves of a promise get separated: the call-back in one place, the quotation it depends on in another, and nobody looking at both.

## Working the task rows

1. Read them alongside the drained rows rather than separately.
   - Result: You see that today's call-back to a customer depends on a document nobody has produced yet, while there is still time.
2. Complete the row when the work is done, not when you have decided to do it.
   - Result: The queue keeps meaning what it says, and the person's open commitment count stays honest.
3. If the work turns into a message after all, change the channel rather than opening a second row.
   - Result: One commitment stays one record, and the duplicate rule is not involved.
4. If the work belongs to somebody else, leave it in the shared queue with a reason that says who and why.
   - Result: The queue is the hand-over, instead of a conversation that has to happen before anyone can act.

## Questions

### Can I make Connect execute a task row anyway?

No. There is no mode, permission or setting that hands a `task` row to a drain. If what you want is a message sent, change the row's channel to the channel that should carry it.

### Does a task row go overdue?

Yes, and it should. Overdue means the commitment is past its time and nothing has happened — which for a `task` row is exactly the state you want made visible, since nothing is going to happen without a person.

### Is the twenty-four-hour lateness rule applied to task rows?

That rule is specific to the phone channel, where a very late call-back is worse than none. A `task` row is not closed for being late; it stays open, because the work still needs doing.

## Related

- [Follow-ups in Connect](https://connectbyjbrh.com/docs/follow-ups/)
- [Choosing the channel](https://connectbyjbrh.com/docs/follow-ups/channel-choice/)
- [Overdue follow-ups](https://connectbyjbrh.com/docs/follow-ups/overdue/)
- [Completing a follow-up](https://connectbyjbrh.com/docs/follow-ups/completion/)
- [Needs You](https://connectbyjbrh.com/docs/autonomy/needs-you/)
- [Executing a follow-up](https://connectbyjbrh.com/docs/follow-ups/execution/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §7 — the `task` channel and its label
- `docs-source/sources/CHANNELS.md` §7 — follow-ups and support
- `docs-source/sources/PHONE.md` §10 — `follow_up_channel`
- Connect capability registry (docs-source/facts.py)