Scenario to feed calls to 80 outbound Services

Hello, Team!

We have a customer with 80 outbound services (BPO) and they are using the “Run Scenario Variable” on all of them in order to screen popup their CRM url with call context.

They have created 80 scenarios (has turned very complex to administrate), each one is just a popup of the same URL with find agent block pointing back to the originating call Service. using the $(service.name) variable to identify.

my idea is to use just one Scenario for the task, using “IF” block, branched to each service identification by $(service.name) variable condition, then request skill then goto find agent by skillgroup.

should look like this ( just populated for first service)

My point is that this scenario would be handling around a high Calls per second rate probably 60 to 130 so i prefer to ask you about this and i just want to make sure if there is any performance risk on doing this.

Other way would be to make the request skill to read the $service.name Variable on receiving the call, but i think isn’t possible.

I would gladly appreciate any suggestion on how to handle this using the less systemic effort.

Logic leveraging the IF block would work just fine. I currently have a customer that uses the same type of approach for managing the IVR functionality of about 80 of their retail stores. Another option which I have used is leveraging the List Management API to store retail (or for you, BPO) specific content in the list. You would then have your single scenario that would then query the List Management API for the stored content of the record item you are after. Then you can parse and write those values to variables and use them through the rest of the scenario.

On a similar note. I have another customer that runs all of their traffic through a singular inbound scenario and only branches out to accessory scenarios when the call path needs to divert to a specific group. You should not have any issues with performance using any of the approaches mentioned for the volume you are describing.

Thanks Derek!
Great explanation and pretty clear.