> ## 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, your SMS number or your
Instagram account 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.
By default no journey is involved: the agent simply answers, using everything it
knows about your business. But a journey can also *start* from an inbound
message — see [Routing by keyword](#routing-by-keyword) — which is how you put a
specific flow in front of a specific question.
Those are not the only ways in. The [web widget](/web-widget) puts the same
agent on your own website, and everything on this page applies to it — the
answering settings, the escalation path, and the inbox.
## 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:
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.
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.
## Routing by keyword
A journey's entry step can listen for *"a message arrives on these channels"*,
optionally narrowed to messages that say something in particular. When one
arrives, the sender is enrolled in that journey **before the agent replies**, so
the reply already comes from inside the journey's instructions rather than from
the default agent.
Four kinds of channel can start a journey this way: a **WhatsApp** number, an
**SMS** number, a native **Instagram** account, and a **Facebook Messenger** Page
connected in Boom. The authoring is identical for all four: the picker lists
whichever you have connected.
You configure this on the entry step in the journey builder, in three steps: pick
the channels, then choose what the journey **answers** — every message on them,
or only messages that say a particular word — then test a message to see who
answers it.
**Instagram story tags.** When someone tags your account in their Instagram
story, that arrives as a message with no text. By default the agent does not
reply to one, because a story tag is not a question addressed to you. If a
journey listens on that account, the journey decides instead: branch on the
**Kind of customer's last message** field being `story_mention` to handle or
ignore it explicitly.
Choosing *Keyword* gives you a list of words. Type one and press Enter — or a
comma — to add it; each becomes its own rule, and any one of them enrols the
sender. Once added, the word appears in the form it will actually be compared in,
so you can see the folding.
| How it has to match | What it means |
| - | - |
| Only this word | The whole message has to be just the keyword. |
| This exact phrase | The keyword's words appear together, in order, anywhere in the message. |
| All of these words | Every word appears somewhere, in any order. |
**Several journeys can listen on one number, as long as their keywords differ.**
Exactly one journey answers any given message, and the most specific rule wins:
a keyword beats a journey that answers everything, a narrower match mode beats a
broader one, and a longer keyword beats a shorter one. The third step shows you
which journey wins a message you type, against the real rules, before publishing.
Two journeys cannot claim the *same* number and the *same* keyword — the second
one could never fire, so publishing it is refused rather than silently accepted.
**Two journeys both set to answer *every* message on one number is the same
case**, and the most common one: the builder warns you as soon as you pick the
number, and the way out is to give one of them a word.
Keywords are compared loosely on purpose: capitals, accents and punctuation are
ignored, so `¿PRECIO?` and `precio` are the same keyword. Accent folding also
treats `ñ` as `n`, so a keyword that has to tell `año` from `ano` is not
expressible. The builder shows you the compared form once a word is added.
Two limits worth knowing before you rely on this:
* **A photo or file with no caption has no text**, so it can only reach a journey
that answers every message on the number. If every rule on a number carries a
keyword, an image enrols nobody and the agent answers normally.
* **Someone already in a journey with you stays there.** A keyword does not pull a
customer out of a conversation they are already having — they continue in their
current journey, and the agent answers them.
"Only this word" is the strictest option and rarely what you want: real customers
write "Hola, quería saber el precio" far more often than "precio" on its own.
## 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.
## Testing with your own number
While you are integrating, the same conversation accumulates every edge case you
try, and the agent's replies get worse as it grows. Two commands reset it from
WhatsApp itself.
| Command | What it does |
| - | - |
| `/new` | Starts a new session. The agent forgets the live conversation; earlier sessions stay as background. |
| `/reset` | Deletes the conversation, your engagements and the agent's memory. Journey re-enrollment is unblocked and you look like a new contact. |
`/reset` is permanent. It deletes the conversation, every engagement for that
customer in the organization, and the answers extracted from them. There is no
undo.
The message has to be exactly the command. `/reset now` or `please /reset` is an
ordinary message and reaches the agent normally.
`/reset` is not a full wipe. Your CDP person, its event history and your
initiative participation all survive, so a journey that branches on CDP data
still sees a returning customer.
Both commands only work from a number on your organization's test-number list.
Add yours under **Settings → Test numbers**. Entries expire — renew or remove
them there — and a number that is not on the list gets a normal agent reply
instead.
## Related
The agent that answers, how the knowledge base briefs it, and when it hands
off to a person.
The other direction: a flow you author to start a conversation.
The same answering behavior, reached from your own website.
Why outreach needs an approved opener and inbound does not.
Read conversations and transcripts from an AI tool.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.