# Choosing the channel

Two things decide it: what was promised, and what can carry it. A call-back becomes `phone`; a person's own work becomes `task`; a written commitment usually stays on the channel the conversation was on. `any` defers the choice until the row comes due. `sms` is the one to check before promising it, because outbound SMS depends on a provider that carries SMS.

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

## What the channel actually decides

Not the wording, and not the urgency. The channel decides **who executes** — which drain picks the row up, and therefore which gates it goes through, which allowance it spends, and what the customer experiences when it fires. Choosing `phone` for something you meant to email means a person's phone rings.

| The promise | Channel | Why |
|---|---|---|
| "I'll ring you back" | `phone` | The commitment was a call; anything else breaks it |
| "I'll email the details" | `email` | Executed through the mailbox and autonomy that own the thread |
| "I'll message you" on a WhatsApp thread | `whatsapp` | Continuity matters more than medium here — the person expects the same thread |
| "I'll send the quotation" | `task` | Nothing drains this: producing a document is a person's work |
| "I'll get back to you" | `any` | The promise was about content, not about a medium |
| "I'll text you" | `sms` | Only where a provider carries outbound SMS — see below |

## How a call decides it

`follow_up_channel` makes the choice from what was said. A call-back goes on `phone`. A person's own work — "send the quotation", "review the recording" — goes on `task`. And "no follow-up needed" schedules nothing at all, which is a real outcome rather than a failure to book.

That split is the useful part. Without it, every promise made on a call would land on the phone channel and the drain would ring people to tell them a document was coming, instead of somebody sending the document. When the classification is wrong, the row is editable — but check the reason first, because a `task` row that looks misfiled is often a promise that really was about work rather than about contact.

## `any`, and when it earns its keep

`any` means the commitment was about getting back to somebody, and the medium is open. It is the honest choice when the promise genuinely did not name one, and it lets the row be executed on whatever fits the relationship when the time comes — the thread that is already open, the address the person actually answers on.

It is the wrong choice when you know the answer. `any` on a commitment that was plainly a call-back loses information that was in the original conversation, and the reason field then has to carry it, which is a worse place for it.

## Before you promise SMS

Outbound SMS is **provider-dependent**. Inbound handling, STOP and suppression exist, but sending depends on a configured provider that carries SMS — and the live carrier does not. On that account the Phone screen says so plainly rather than presenting a thread that cannot send, and an `sms` follow-up scheduled there is a commitment nothing can keep.

> **Careful** In India, outbound SMS also depends on DLT registration, which is registration data held against the workspace rather than something a follow-up can arrange for itself. Check the channel is genuinely sendable before you promise a customer a text.

## Changing a channel after the fact

1. Open the row and read the reason before changing anything.
   - Result: You find out whether the channel is wrong or the reason is — the second is more common.
2. Change the channel on the existing row rather than cancelling and re-creating it.
   - Result: The row keeps its due time, its history and its place on the person's record, and you do not trip the duplicate rule.
3. If you are moving something onto `phone`, check the due time is still sensible.
   - Result: The phone channel closes anything more than 24 hours late instead of ringing it, so an old row moved to `phone` may be closed rather than dialled.

## Questions

### If I pick `any`, what does Connect actually use?

Whatever fits the relationship when the row comes due — typically the thread or address the person is already being talked to on. That is the point of `any`: the decision is made with information you did not have when the promise was made.

### Can one follow-up cover two channels?

No. One row, one channel. Two commitments — ring them, and send the document — are two rows, which is also how they end up in front of the right person: one for the drain, one for a human.

### Does the channel decide who approves it?

Indirectly. Execution runs through the channel's ordinary gates, so the autonomy rule that governs that channel is the one that decides whether the action goes out or waits for a person.

## Related

- [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/)
- [Executing a follow-up](https://connectbyjbrh.com/docs/follow-ups/execution/)
- [A follow-up that is too late](https://connectbyjbrh.com/docs/follow-ups/stale/)
- [Sending SMS: what is available today](https://connectbyjbrh.com/docs/sms/sms-outbound-status/)
- [Creating a follow-up](https://connectbyjbrh.com/docs/follow-ups/creating/)

## What this page is based on

- `docs-source/sources/PHONE.md` §10 — `follow_up_channel`
- `docs-source/sources/CHANNELS.md` §3 and §7 — SMS status and the follow-up channel list
- Connect capability registry (docs-source/facts.py)