> ## 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.

# Enrolling customers

> Enroll one named customer into a published guide, attest to consent, and let the guide open the conversation itself.

Enrolling puts one real person in front of a published guide. There is no first message to compose and nothing to schedule — **enrolling is the guide's first wake**, and it opens the conversation per its instructions, in its own voice, within moments.

Open the guide's **Outcomes** tab and press **Enroll a customer**. Enrolling is available only on a published guide with at least one channel that can actually reach someone.

## The enrollment form

<Steps>
  <Step title="Contact and company">
    **Contact** is the person the guide talks to — required. **Company** is where they work — optional, shown as the subline on the roster.
  </Step>

  <Step title="How to reach them">
    A **Phone** field appears when texting is on, and an **Email** field when email is on. At least one address matching an enabled channel is required. Phone numbers are checked in full international format (E.164, like `+16105550100`) — a malformed number is refused outright rather than guessed at.
  </Step>

  <Step title="Their record (optional)">
    When a record tool like HubSpot is attached and connected, the form offers to bind this customer to their record — with one-tap suggestions matched by phone, or a search by name, domain, or email. Skipping it is fine and the form says what it costs: without a bound record, this customer's done closes by your tap instead of a verified read.
  </Step>

  <Step title="Their team (optional)">
    A collapsed section for the **account owner** and **AE** — names and emails. These are who the guide can loop in when it escalates. Leave them empty and every page goes to you alone; the form says so rather than leaving it to be discovered.
  </Step>

  <Step title="The consent attestation">
    A required checkbox: *"This customer agreed we may text and call this number about this outcome."* Your attestation — who attested and when — is recorded against your own session.
  </Step>
</Steps>

## Why the consent attestation is required

Consent is the floor under everything a guide sends. The guide checks for recorded consent **before every text**, not just the first, and refuses to send rather than assume. The attestation is that record: a named person, at a stated time, affirming this customer agreed to be texted — and called, with your per-call approval — about this outcome. It is one attestation covering both channels; voice never gets a second consent tier.

If a customer ever replies STOP, that suppression is permanent and org-wide for the address — it outlives the guide, and re-enrolling the number will not text it. See [Compliance](/guides/compliance).

<Warning>
  Attest only to consent you actually have. The attestation exists so that when a carrier, a customer, or your own team asks "who said we could text this person?", the answer is on record.
</Warning>

## What happens after you enroll

The moment you press **Enroll**, the guide wakes for the first time and opens the conversation itself — the modal's done step says exactly that. The opener texts (or emails) the customer in the next few moments, written from the guide's instructions, and the customer's row appears on the Outcomes tab at **Enrolled**, moving to **Reached** when the first message is delivered.

From there the guide is asleep between events. It wakes on three doors, and only three:

* **The customer replies** — an inbound text or email wakes the guide and it answers in seconds, in context.
* **Its own timer fires** — the guide schedules its own check-ins, and each timer wake carries the guide's own stated reason ("check in if Maria hasn't replied by Friday").
* **You tap it** — on the customer's [watch page](/guides/watch-page) you can **Message** the guide, **Nudge now** for an immediate check-in, or **Pause** it (paused, it stops acting but keeps listening).

Every wake, send, read, and receipt lands in that customer's log. When the guide gets stuck or wants a human decision, it pages you — and if the outcome can't be verified from an attached tool, it gathers the evidence and proposes done for your one-tap confirm.

<Note>
  Each enrollment is one person and one conversation. To enroll many customers at once from a CSV, see [Cohorts](/guides/cohorts).
</Note>

## If the Enroll button is disabled

The button's tooltip says why, and each reason has one fix:

<AccordionGroup>
  <Accordion title="Enrolling opens once this guide is published">
    Enrollment is for real customers, so it waits for **Publish**. Rehearsal, by contrast, works on drafts — that's the tool for trying a guide before it's live.
  </Accordion>

  <Accordion title="Turn on a way to reach people first">
    Texting and email are both off. Enable at least one channel on the Design tab — a guide with no channel can't open a conversation.
  </Accordion>

  <Accordion title="Pick a number to text from first">
    Texting is on but no number is picked. Choose one on the Texting row; the guide texts from it and wakes on replies to it.
  </Accordion>

  <Accordion title="Pick who it emails as first">
    Email is on but no sender is picked. The guide emails as a real person on your team — pick them on the Email row.
  </Accordion>
</AccordionGroup>

The same checks run server-side on every enrollment, so a stale page can't slip an unreachable customer through — the server refuses with the same message the button would have shown.

## Before you enroll anyone real

Two habits pay for themselves:

* **Rehearse first.** [Try it live](/guides/rehearsal) runs the same guide against you, with shadowed sends and a fast-forwardable clock — the whole arc in minutes, nothing real touched.
* **Enroll yourself or a teammate** as the first real enrollment. Live sends, live wakes, your own phone — the last check before customers.