I’m optimizing our routing strategy to use Bullseye routing with a BPO fallback.
We have 3 Bullseye rings for our internal agents. If the call reaches Ring 3 (60 seconds) and still isn’t answered, the ‘In-Queue Flow’ is supposed to use a ‘Transfer to Number’ block to route the call to an external BPO over a SIP trunk.
However, the call simply disconnects. I checked the queue settings and ‘Max Time in Queue’ is set to 60 seconds. Does the Queue Timeout override the In-Queue flow’s ability to execute a transfer if they happen at the exact same time? How do we ensure the call successfully bridges to the BPO instead of dropping?
I evaluate hundreds of interactions and I see this configuration error constantly.
Yes, the ‘Max Time in Queue’ (Queue timeout) is an absolute hard limit. If the Bullseye ring expands at 60 seconds, and the Queue timeout is also 60 seconds, the routing engine terminates the interaction before the In-Queue flow has a chance to execute the transfer block. You need to pad the Queue timeout. Set your Max Time in Queue to 65 seconds to give the In-Queue flow the 5 seconds it needs to process the logic and initiate the SIP transfer.
We had to redesign our custom desktop around this exact behavior.
Another thing to keep in mind: when you use ‘Transfer to Number’ in an In-Queue flow, it acts as a blind transfer. If the BPO’s SIP trunk is full or rejects the call, the customer is dropped immediately. If you want a true ‘Fallback’ where the call stays in the queue if the BPO fails, you shouldn’t use an In-Queue flow transfer. Instead, set up the BPO agents as a 4th Bullseye ring using a generic ‘External Contact’ routing model. It keeps the analytics cleaner, too.