Bot Intent Confidence Threshold Behavior Under High Load

What’s the best way to configure intent confidence thresholds when running JMeter simulations with 500 concurrent sessions? The bot incorrectly routes to the default fallback action as API latency increases, causing a spike in failed interactions in Genesys Cloud US-E.

{
“intent_confidence_threshold”: 0.7,
“fallback_action”: “human_agent”
}


> What is the correct way to configure intent confidence thresholds when running JMeter simulations with 500 concurrent sessions?

The issue isn't really the threshold itself, but how the API handles latency spikes during high-concurrency bursts. When you push 500 concurrent sessions, the WebSocket connections often time out before the intent scoring completes, causing the platform to default to the fallback action.

Try adding a jitter parameter to your JMeter script to avoid thundering herd effects. Also, check if you're hitting the standard API rate limits for the analytics endpoints that feed the bot logic. If the latency is over 2 seconds, the confidence score might not even be returned. You might need to increase the timeout in your JMeter HTTP Request sampler or implement a retry strategy with exponential backoff. The platform API docs suggest keeping concurrent threads under 200 for stable intent resolution unless you have a dedicated load test environment.