From a business continuity perspective, routing callbacks to the original agent is critical for high-value accounts.
If a VIP customer calls during a system outage and requests a callback, they expect to speak to the same person when the system recovers. Our after-hours flow captures the original agent’s userId and stores it as conversation data. When the callback fires during business hours, the flow checks if that agent is available before falling back to the general queue.
How do I actually set this up? I keep hearing about ‘preferred agent routing’ but I can’t find the setting in the admin panel.
Is it a checkbox somewhere, or do I have to build a complicated flow? We only have 20 agents so I just want simple callbacks to go back to whoever talked to the customer originally.
Preferred Agent Callback Routing
FWIW, there’s no checkbox - you build it in Architect. Here’s the pattern:
- Original Call: In the wrap-up flow, store the agent’s userId in a conversation attribute:
Set Conversation Data: preferredAgentId = {agentUserId}
- Callback Flow: At the top of the callback flow, read
preferredAgentId and use a Transfer to User action targeting that ID.
- Fallback: Add a timeout. If the preferred agent doesn’t answer in 20 seconds, transfer to the ACD queue.
// Architect pseudo-logic
IF preferredAgentId IS SET
Transfer to User(preferredAgentId, timeout: 20s)
ON TIMEOUT -> Transfer to ACD Queue
ELSE
Transfer to ACD Queue
YMMV, but this pattern has a 70% same-agent hit rate in our deployments.
There’s actually a subtle bug in the Python SDK when reading conversation attributes in the callback flow.
In SDK version v2.5.0, the get_conversations_callback method returns the attributes as a flat dictionary, but the conversationData key is nested one level deeper than documented. I opened Issue #421 on GitHub with a full repro script. Until it is patched, access the data via response.raw_body['participants'][0]['attributes'] instead of the SDK object.