> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thread.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Channels

> Guides work over SMS, email, and voice as one conversation with shared memory — each channel with its own setup and its own floor.

A guide's channels are not separate campaigns — they are **one conversation with shared memory**. Whether the customer texts back, replies to an email, or talks through a call, everything lands in the same per-customer log, feeds the same rolling memory, and shows on the same [watch page](/guides/watch-page). A guide that emailed on Monday remembers it when the customer texts on Wednesday.

You enable channels on the guide page, each configured in place. A guide needs at least one channel ready to publish.

<Note>
  SMS is the most mature channel — it has carried guides from the start. Email and voice are newer: fully supported and documented here honestly, but expect them to keep hardening faster than SMS does.
</Note>

## SMS

Texting is the guide's native rhythm: short messages, real replies, verification between turns.

* **The texting number.** Pick the number the guide texts from, drawn from your organization's own numbers. Getting a number text-ready involves carrier registration — see [phone and registration](/admin-guide/phone-and-registration). Once picked, the row shows **Text ready**.
* **Quiet hours.** Sends are gated to the recipient's local daytime — 8pm to 8am recipient-local is quiet. A text composed during quiet hours is held, and the guide's wake moves to the next open window; the log says so plainly: "Held a text — quiet hours; it will send after \<time>." If the recipient's timezone can't be determined, the send is blocked rather than guessed.
* **STOP handling.** A reply of STOP (or STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT) is captured before the guide even wakes. The conversation ends instantly, the opt-out is permanent, and it applies across every guide in your organization — no guide will text that number again. See [compliance](/guides/compliance).

## Email

Guide email is real email from a real person — not a no-reply blast address.

* **Sends as a real address on your domain.** You pick who the guide writes as: a teammate whose mailbox is connected (it defaults to the guide's creator). The guide sends through that person's own mailbox, so messages come from a genuine address on your domain, thread properly in both inboxes, and read like a colleague wrote them.
* **Wakes on the customer's reply.** Replies route back through your organization's verified email domain and wake the guide, exactly like an inbound text — same conversation, same memory. This requires a one-time domain setup by an organization admin; every guide then inherits it. See [email domain](/admin-guide/email-domain).
* **The sender sees the reply too.** When a customer hits Reply, their message is addressed to two places at once: the sender's own mailbox, and a routing address on your domain labelled with your organization's name (for example "Acme Support"). The reply lands in the sender's inbox, threaded under the message their account sent, and the routing copy is what wakes the guide. The guide owns the conversation — if the sender wants to step in themselves, they pause the guide from the watch page rather than replying from their inbox, because a reply sent from the sender's own mailbox is not the customer's and does not reach the guide.
* **Opt-out applies here too.** An unsubscribe-style reply is captured before any wake and suppresses the address across guides.

In the watch log, outbound emails render as letter cards — subject leading, sender named — so a long send never hides what it said.

## Voice

Voice gives a guide a phone voice by attaching a **published Voice Studio agent** that has a number. The guide decides when a call would help; you decide whether it waits for you.

* **Ask me before dialing.** One switch on the channel, off by default. Off, the guide calls when it judges it's time — the same enrollment attestation covers texts and calls alike. On, it proposes the call with its reasoning and pages you: the watch page shows the **full phone number** next to the **Approve the call** button (the page's email carries a one-tap link to the same approval), and nothing dials until you tap. See [calls and approvals](/guides/voice-studio/calls-and-approvals).
* **The gates don't move with the switch.** STOP, consent, and quiet hours re-run against the stored number in the moment before the phone rings, whoever approved. The number itself is never the guide's to choose — it comes from the enrolled customer's record, not from anything the guide says.
* **Quiet hours refuse, never defer.** A call that comes up during the recipient's quiet hours is refused outright rather than queued — a dial that fires hours later, out of context, is worse than no dial. The guide can come back to it during open hours.
* **No retries, no rapid redials.** A call nobody answered is never retried, and no guide calls the same customer again for several hours.
* **The call comes home.** When the call ends, the outcome wakes the guide like any inbound event, and the call's row in the log opens the full transcript — plus the audio, if the agent records.
* **Recording is the agent's own switch, off by default.** Turn it on in Voice Studio and the call's opening line says so — publish adds the sentence if your welcome doesn't. Leave it off and no audio is stored; the transcript still is. Either way the agent answers honestly when asked. See [recording](/guides/compliance#recording).
* **The AI disclosure is not a switch.** Every published agent carries a rule its author cannot edit out: asked whether it's an AI, it says so plainly. See [compliance](/guides/compliance#ai-disclosure-on-voice).

Building the voice agent itself — voice, language, knowledge — happens in Voice Studio: see [building voice agents](/guides/voice-studio/building-voice-agents).

## One memory, one floor

Whichever channels you enable:

* **One log.** Every send, reply, call, and read lands in the same chronological log per customer, with its channel named on the entry.
* **One memory.** The guide's context carries the whole conversation across channels — nothing resets when the medium changes.
* **One opt-out.** A STOP on any channel is honored across channels: a texted STOP also bars any call to that number.
* **One close rule.** No channel changes how an outcome closes — only [a fresh read or your confirmation](/guides/outcomes-and-verification) does that.

## Related pages

<CardGroup cols={2}>
  <Card title="Building a guide" icon="wrench" href="/guides/building-a-guide">
    Instructions, tools, and channel setup on the guide page.
  </Card>

  <Card title="Compliance" icon="shield-check" href="/guides/compliance">
    The always-on floor under every channel.
  </Card>

  <Card title="Phone and registration" icon="phone" href="/admin-guide/phone-and-registration">
    Getting numbers voice-ready and text-ready.
  </Card>

  <Card title="Email domain" icon="at" href="/admin-guide/email-domain">
    The one-time domain setup that powers guide email.
  </Card>
</CardGroup>
