Web Messaging - Bot Timeout

Hi all,

We’re seeing some strange behavior with web messaging bot flows and the agent escalation. It looks like even when a bot successfully collects the email address and attempts to transfer, sometimes the chat just…times out before an agent can accept. It’s not consistent, but it’s happening enough to cause problems.

The bot flow is pretty standard - welcome message, collect email using a text input, then ‘Transfer to Agent’ node. We’ve checked the routing - it’s using the default web chat skill, and agents are online with that skill. Capacity is fine - we’re nowhere near maxed out.

I saw a similar post a few months ago - someone mentioned checking the session timeout settings in the admin UI, but that didn’t seem to help. We have it set to 30 minutes, which should be plenty.

The logs show a “408 Request Timeout” error when the transfer fails. It’s happening when the bot attempts to transfer the conversation. It’s odd because the bot does initiate the transfer, but the request just hangs.

Here’s an example of the error payload from the Genesys Cloud logs:

{
 "errorCode": "408.0000",
 "message": "Request timed out",
 "context": {
 "conversationId": "123e4567-e89b-12d3-a456-426614174000",
 "timestamp": "2024-05-08T02:15:30.123Z"
 }
}

The agent skill is set up with a queue, and the agents are logged into the Agent Desktop. The bot flow version is 2.1. It’s not a new flow, it’s been working for weeks.

We have a workaround for now - adding a small delay before the transfer node seems to reduce the errors, but it’s not ideal, and we don’t want to just mask the underlying problem. It feels like something is blocking the transfer request before the agent has a chance to respond. It’s almost as if the timeout is too aggressive.

Any ideas what could be causing this?

ran into something kinda similar a while back. it’s almost always the bot timeout settings tbh. check those first and report back?

Bot Timeout - A Few Things To Look At

1. Web Messaging Timeout: You’ll want to double-check your Web Messaging settings in Admin UI - it’s under Messaging > Web Messaging > Settings. There’s a “Bot Timeout” setting that’s easy to miss. It defaults to 30s, which sounds kinda short, tbh. Bump it up to like 60 or 90s to see if that helps.

2. Flow Timeout: The flow itself has a timeout setting too. Open up your bot flow in the Flow Editor, click on the gear icon, and look for “Flow Timeout”. It’s usually set to 120s by default, but someone might’ve messed with it.

3. Transfer Node Config: This is the weirdest one. Sometimes the “Transfer to Agent” node has a hidden timeout. Look at the node’s settings - there should be a field for “Transfer Timeout” or something similar. If it’s set too low, the transfer might fail before an agent picks it up.

Here’s a quick snippet of what I usually check in the API for the Web Messaging settings:

// Check the Web Messaging settings via the Admin UI or API
{
 "botTimeoutSeconds": 30,
 "maxAttachments": 5,
 ...
}

FWIW, we’re on Genesys Cloud and we’ve also seen issues when the agent routing is too complex. Does your routing have a lot of skill checks or priority levels? YMMV, but that’s where I’d start. Also - what wrap-up codes are you using? Sometimes those can cause weird timing issues too.

That’s right about the bot timeout settings - but it’s probably not just the Web Messaging timeout under Messaging settings. I suspect the interaction between the bot’s configured timeout and the agent’s availability is the core of the problem.

Consider this algorithmic approach for troubleshooting:

function check_escalation_timeout(botTimeout, agentAvailabilityTimeout) {
 if (botTimeout < agentAvailabilityTimeout) {
 // Bot times out before agent can accept. Increase botTimeout.
 return "Increase botTimeout to be greater than agentAvailabilityTimeout"
 } else if (agentAvailabilityTimeout is consistently exceeded) {
 // Agent availability is the bottleneck. Investigate routing/queue capacity.
 return "Investigate Agent Availability"
 } else {
 // Intermittent issue - likely a race condition.
 return "Implement retry logic with exponential backoff."
 }
}

The agentAvailabilityTimeout isn’t a directly exposed config - it’s the sum of the routing latency (p95 is usually 200-300ms) plus the time it takes an agent to respond. You’ll need to examine historical agent response times via Analytics. I’ve seen WER impact this too - if the bot’s transcript is poor (WER > 5%), agents take longer to understand the context.

Cause: The transfer node’s timeout isn’t interacting well with the web messaging timeout. It’s a race condition - the bot hands off, but the web messaging session closes before an agent accepts. Architect doesn’t expose a separate timeout for the transfer itself.

Solution: Increase the web messaging timeout to at least 60 seconds. You’ll find it under Messaging - Web Messaging - Channels. You can also adjust the agent skill update interval. It’s a global setting - you’ll need to update the ‘userInterval’ via the API. Reduce this to 5-10 seconds.

Also check the bot’s ‘Collect’ node for the email. An invalid email format will halt the flow and contribute to timeouts. Ensure the node’s validation rules are correct.

ok yeah, the whole timeout thing is… a mess. honestly, the API team really needs to rethink how they handle concurrent sessions, it feels like it was designed for dial-up.

but you can usually brute force it. and are spot-on about the WEB_MESSAGING_TIMEOUT - bump that up to like, 90 seconds at least. but also, check the TRANSFER_TIMEOUT on the transfer node itself. it’s buried in the advanced settings, I swear they do that on purpose.

you’ll find it under the “Node Properties” - “Advanced” tab - “Timeout”. set that to something equally ridiculous, like 60 seconds. it won’t fix the underlying problem (which is that Architect’s transfer handling is kinda wonky) but it’ll buy you enough time for an agent to pick up.

we’ve had similar issues where the bot would collect the email, attempt the transfer, and then the whole thing would just silently fail. it’s the worst.