Hi Edward,
Its a tough one and interested to see what others say.
When I started in my currently job, there were call flows in the medium and on the edge of high too, and I was able to reduce that down to being in the low section, without loosing functionality. For us at least this was just about flow efficiency. Using loops, I was able to replace big chunks where switches had been used to replicate what a loop can do much more efficiently. Using DataTables was another way I could reduce the amount of actions being called. Using variables instead of hard coding everything, especially in conjunction with DataTables is a great way to reduce the number of actions. Variables in conjunction with the Find actions is another good one.
Anywhere where you are doing the same thing multiple times except for some small minor difference, like applying a different skill or Participant data value, consider collapsing it down to 1 action and use a variable in place of the hard coded value. That variable then just needs to be set dynamically elsewhere, again through a datatable lookup or through nested if statements or data action etc. This is definitely doable for things like prompts, or set participant data, or logging or transfer to ACD etc, even for menu prompts if the outcomes are similar enough again using variables to set different things like the Skill, Queue, Priority, participant data etc.
For chunks of actions that you repeat, consider using a repeatable task, that you can use the call task action on or a common module, these can have inputs and outputs to again make them very dynamic and reduce the need to repeat the same actions over and over.
And sometimes its easier to start from scratch. What is the purpose of this flow, is that too many things being achieved here, what are the unique functions that are required like transfer to ACD but specifics like transfer to this queue, just the overall thing that needs doing. Start small you can always build out, then start mapping it out just the core items, and see where you can achieve the same results more efficiently, and then deal with the exceptions and outliers afterwards, again thinking about how those exceptions can be treated more efficiently or in a separate flow entirely.
Hopefully these tips can point you in the right direction, otherwise I hope there is some other suggestions.
------------------------------
Anton Vroon
------------------------------
Original Message:
Sent: 01-25-2022 15:57
From: Edward Wu
Subject: IVR Flow Size
Hi.
I have an IVR flow with flow size on the edge between Medium and High. Basically slight modification will bring it to high. It is extremely slow to load or edit in Architect. Thus we are trying to reduce it. We attempted to use Common module. We moved the logic of a big task to common module and it actually increased the flow size. After discussing with Genesys support, we found that the IVR flow actually embedded the whole common module in the flow. Thus we cannot use common module. We can use an additional flow but we will have to pass a lot of flow data from the original flow to the additional flow thru participant data. We don't want the data to be persisted in the participant data of the call interaction history. Any suggestions?
Thanks,
Ed
#ArchitectureandDesign
------------------------------
Edward Wu
BANK OF HAWAII
------------------------------