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

# Inbound conversations

> When a customer writes first, the same agent answers, with the same context it uses for outreach.

Everything else in these docs starts with you reaching out: an audience, an
initiative, a journey that sends the first message. Inbound is the other
direction, and it needs none of that.

When a customer messages your WhatsApp number without being enrolled in
anything, the conversation is answered by **the same agent** that runs your
outreach. Same knowledge base, same policies, same voice. It is not a separate
support bot with its own configuration to keep in sync, which is the point: an
agent that already knows your business, your product and your rules can handle
someone asking a question just as well as someone answering one.

No journey is involved. A journey exists to carry a conversation you started,
so it has a trigger, a first message, and a path. An inbound conversation has
none of those. It starts because the customer decided to write.

## Where it goes

The agent answers, and can [hand off to a person](/the-agent) at any point in
the conversation, not only at a step someone designed in advance. Escalated
conversations land in the shared inbox, where a person replies with the whole
history in front of them.

That is the difference worth internalizing. In outreach, escalation is a node
you place. Inbound, escalation is a judgment the agent makes whenever the
conversation calls for it.

## What has to be configured

Answering inbound is a setting, not a default. Each channel resolves its own
answering behavior, falling back to the organization when the channel says
nothing: whether the agent replies at all, and which agent replies. You set both
in the Boom app, not through this API. A channel can be set to reply even when
the organization's default is not to.

The behavior when this is unset is deliberate, and it is worth knowing before
you go looking for a bug:

<Note>
  If no agent is configured to answer a channel, or the configured agent is
  disabled, an inbound message is received and stored, and nothing replies. It
  waits in the inbox for a person. Boom does not pick an agent on your behalf,
  because guessing which agent should speak for you is worse than staying quiet.
</Note>

So "we pointed our number at Boom and the agent never answered" is almost always
this: the channel has no answering agent set, or the one it has is off.

## What you can read back

Inbound conversations are readable the same way any conversation is, through the
transcripts and messages endpoints on the [API](/api-reference/overview) and
over [MCP](/use-mcp).

One asymmetry to plan around: [extraction schemas](/extraction) are defined on an
initiative, so structured fields come from conversations that belong to one. A
customer who writes in while enrolled in an active initiative is answered inside
that conversation and is covered by its schema. A customer who writes in cold
belongs to no initiative, so there are no typed fields for that conversation,
only the transcript and whatever your team records from the inbox.

## Related

<CardGroup cols={2}>
  <Card title="The agent" icon="user" href="/the-agent">
    The agent that answers, how the knowledge base briefs it, and when it hands
    off to a person.
  </Card>

  <Card title="Journeys" icon="route" href="/journeys">
    The other direction: a flow you author to start a conversation.
  </Card>

  <Card title="WhatsApp templates" icon="message-square" href="/template-variables">
    Why outreach needs an approved opener and inbound does not.
  </Card>

  <Card title="Use MCP" icon="plug" href="/use-mcp">
    Read conversations and transcripts from an AI tool.
  </Card>
</CardGroup>
