Having some issues getting my configuration to work as expected regarding the alignment of bot interaction data. We have deployed a new AI Bot flow within Architect to handle tier-1 support inquiries. The flow logic appears sound, yet the Performance dashboard is reporting a significantly lower “Bot Deflection Rate” compared to the completion rates visible in the Architect analytics view for the same time window (CEST).
Specifically, the dashboard shows 12% deflection, while Architect logs indicate 45% successful resolution without human handoff. This discrepancy impacts our quarterly efficiency reporting.
“Performance dashboard metrics for bots are calculated based on conversation outcomes marked as ‘Resolved’ within the bot node, excluding those transferred to human agents regardless of prior bot interaction success.”
We reviewed the documentation, but the definition of “Resolved” remains ambiguous in the context of multi-turn conversations that eventually route to a queue. Are there specific node configurations or timeout settings in the Architect flow that might cause the dashboard to misclassify these interactions? We need to ensure the business metrics align with the actual operational efficiency.
The official documentation states that bot deflection in the performance dashboard is calculated based on the final disposition of the interaction, not just the success state in the architect flow. if the bot resolves the issue but the user is then transferred to an agent for a “thank you” or confirmation step, the dashboard counts this as a transfer, not a deflection. meanwhile, architect analytics logs the flow completion as successful because the logic tree finished without error.
this discrepancy is common when integrating with external systems like servicenow. if your data action triggers a ticket creation but the conversation remains open, the metrics diverge. to align them, you need to ensure the bot explicitly ends the interaction upon successful resolution. check your flow for a “hangup” or “end interaction” block after the success condition.
also, verify the webhook payload sent to servicenow. if the servicenow ticket status is set to “closed” but the genesys cloud conversation is still active, the dashboard won’t count it as deflected. here is a sample data action configuration to force the conversation closure:
{
"method": "POST",
"url": "https://your-instance.service-now.com/api/now/table/incident",
"headers": {
"Authorization": "Basic {{base64_credentials}}",
"Content-Type": "application/json"
},
"body": {
"short_description": "{{bot_summary}}",
"state": 7,
"close_notes": "resolved via bot"
},
"onSuccess": {
"action": "endConversation"
}
}
ensure the onSuccess action is endConversation. this forces the genesys platform to mark the interaction as resolved, aligning the dashboard metrics with the architect logs. if you are using a virtual agent iframe, also check that the close event is fired correctly in the client-side javascript. this usually fixes the 30% gap in reporting.