## TL;DR
A bot stuck "awaiting reply" is waiting for input it will never recognize: the timeout is too short, the reply matching is too strict, or the user already answered in a way the bot ignored. Set timeouts that match real user behavior, accept flexible reply formats, and always define what happens at timeout: handoff, ticket, or graceful close. Awaiting reply must never be a dead end.

## The query

```text
intercom "custom bot awaiting reply timeout" stuck conversation
```

## Use this when

- Bot conversations stall awaiting user replies
- Timeouts abandon conversations silently
- Users reply but the bot does not continue
- You are tuning custom bot flows

## Not for

- Designing bot conversation scripts
- Training bot understanding
- Human handoff strategy
- Bot analytics

## Steps

### 1. Check what the bot is actually waiting for

Open a stuck conversation and read the bot's last message. Then check the reply-matching rules: keywords, buttons, or free text. Users often reply in a format the bot does not accept, like typing when it expects a button tap.

Expected output: the expected reply format versus what users actually send.

### 2. Loosen reply matching

Accept typed equivalents of button options, normalize case and whitespace, and handle common variants. Strict matching manufactures stuck conversations out of normal user behavior.

Expected output: matching accepts the reply formats users actually use.

### 3. Set timeouts to real user behavior

Timeout too short abandons users who stepped away; no timeout strands conversations forever. Base the timeout on measured reply times for the step, and make the timeout path explicit.

Expected output: timeouts set from data, timeout path defined.

### 4. Define the timeout path: handoff, ticket, or nudge

At timeout, the bot should do something useful: send a nudge and wait longer, hand to a human with context, or create a ticket. "Do nothing" is not a timeout path.

Expected output: a designed timeout behavior per bot flow.

### 5. Monitor stuck-conversation counts

Track how many conversations sit in awaiting-reply beyond the timeout. A rising count means matching or timeouts drifted. Review weekly alongside bot completion rates.

Expected output: stuck-conversation metric tracked and reviewed.

## Template: the checklist

```text
Bot awaiting-reply timeout:
[ ] Expected reply format compared against actual user replies
[ ] Matching loosened: typed, case, and whitespace variants accepted
[ ] Timeouts set from measured reply behavior
[ ] Timeout path defined: nudge, handoff, or ticket
[ ] Stuck-conversation counts monitored weekly
```

## Variant phrasings

### intercom bot stuck waiting for reply

Steps 1 and 2. See what it wants, accept what users send.

### custom bot timeout too short

Step 3. Measure reply times, set the timeout from data.

### bot conversation abandoned at timeout

Step 4. The timeout path is the missing design.

## Why it happens

Bot builders imagine ideal users who reply promptly in the expected format. Real users multitask, type instead of tapping, and answer a different question than the one asked. The gap between the imagined reply and the actual reply is where conversations get stuck, and a missing timeout path turns stuck into abandoned.

## Edge cases

- Multi-question steps: users answer one of three questions. Accept partial answers and ask the rest.
- Language variation: replies in another language fail keyword matching. Detect and route.
- Users who reply after timeout: define whether a late reply revives the bot or goes to a human.
- Bot-to-bot conversations: automated replies from the other end never match. Detect and hand off.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_t-WLPxW0IHED2G0O7ijtnA