Genesys Cloud CX

 View Only
Discussion Thread View
  • 1.  IVR Flow Size

    Posted 01-25-2022 15:57
    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
    ------------------------------


  • 2.  RE: IVR Flow Size

    Top 25 Contributor
    Posted 01-25-2022 21:50
    Edited by Anton Vroon 01-25-2022 21:55
    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
    ------------------------------



  • 3.  RE: IVR Flow Size

    Top 25 Contributor
    Posted 01-25-2022 22:26
    Also Bots

    ------------------------------
    Anton Vroon
    ------------------------------



  • 4.  RE: IVR Flow Size

    Posted 01-26-2022 14:09
    Thanks for the detail suggestion Vroon.  Our challenge was that we were 1 year into this new IVR flow developed by Genesys consultants so I could see how it's justified for a rebuild or any major changes.

    ------------------------------
    Edward Wu
    BANK OF HAWAII
    ------------------------------



  • 5.  RE: IVR Flow Size

    Posted 01-25-2022 22:32
    @Anton Vroon is spot on with the reduction of tools by the use of reusable common modules and if a module is used in multiple places, it will only be copied once into the flow, so not take up multiple iterations in your original flow.  As for data, I agree that it is a pain to pass information back and forth.  Best is to just hash the data you are passing, write it to an attribute, then in the next flow, read the attribute and decrypt the hash.  You can use any key for the hash and most people looking at the conversation will not know how to decrypt it.  You can also rewrite the data in the secondary flow when you are done with it, so one thing you could do is write a string of attribute pairs, read them into the new flow and then write out NOT_SET to that attribute.​

    ------------------------------
    Robert Wakefield-Carl
    Avtex Solutions, LLC
    Contact Center Innovation Architect
    robertwc@avtex.com
    https://www.Avtex.com
    https://RobertWC.Blogspot.com
    ------------------------------



  • 6.  RE: IVR Flow Size

    Posted 01-26-2022 14:12
    Hi Roberts.  Do you have any examples of hashing variables passing back and forth thru I assume participant data?  Thanks.

    ------------------------------
    Edward Wu
    BANK OF HAWAII
    ------------------------------



  • 7.  RE: IVR Flow Size

    Posted 01-26-2022 17:25
    You will need to send your data to a web service that can hash it for you.  Soon, you will be able to have services like this in a data action.

    You can try these methods:

    http://www.sha1-online.com/

    https://opendsa-server.cs.vt.edu/ODSA/Books/CS3/html/HashFuncExamp.html


    https://www.geeksforgeeks.org/what-are-hash-functions-and-how-to-choose-a-good-hash-function/

    ------------------------------
    Robert Wakefield-Carl
    Avtex Solutions, LLC
    Contact Center Innovation Architect
    robertwc@avtex.com
    https://www.Avtex.com
    https://RobertWC.Blogspot.com
    ------------------------------



  • 8.  RE: IVR Flow Size

    Posted 02-04-2022 19:17
    In order to break out one of the biggest tasks from the original flow to a secondary flow, I will need to pass about 70 flow variables forth and back between the original flow and the secondary flow.  Any more suggestions?

    ------------------------------
    Edward Wu
    BANK OF HAWAII
    ------------------------------



  • 9.  RE: IVR Flow Size

    Posted 02-04-2022 20:26
    I am stuck.  You can't create dynamic data sets in Common Modules to read and write participant data and you can't use dynamic variables for the name when setting the participant data or updating data.  Without hard-coding the names and a VERY long Set Participant Data step, I can't see a way around it.

    ------------------------------
    Robert Wakefield-Carl
    Avtex Solutions, LLC
    Contact Center Innovation Architect
    robertwc@avtex.com
    https://www.Avtex.com
    https://RobertWC.Blogspot.com
    ------------------------------



  • 10.  RE: IVR Flow Size

    Top 25 Contributor
    Posted 02-07-2022 15:08
    70 flow variables that need to be passed around, to me is a symptom that the flow is overly complex, and should be ripe for simplification.
    If you need to pass 70 variables then in the next flow you need to do something with 70 variables on the other end. That is a lot of actions that need to be performed. And I am struggling to imagine a scenario in a Bank (I too work at a bank) where that many variables and unique actions are required.

    You can have the name on Set Participant Data as an expression that might help, but I think ultimately that flow needs a redesign, which I understand can be difficult and frustrating if you have already spent a lot of time and effort on it. But often those flows that have grown organically over a year are precisely the flows that need to be redesigned.

    ------------------------------
    Anton Vroon
    ------------------------------