Genesys Cloud - Main

We had a third party company implement Genesys for us about a year ago. Nobody in our company had used Genesys before at that point so we were happy to follow any and all suggestions made by this implementation team. 

Like most call centers we have multiple queues that each have slightly different call flows. The way the implementation team handled this was by having a single in-queue flow that each queue shared. At the top of this flow is a switch statement that branches depending on the name of the queue. Although the implementation team left us with a couple of major bugs, we ironed those out and have been using this one in-queue flow ever since.

I've had to create a couple of new queues recently, and it dawned on me that it might be more simple to have a designated in-queue flow for each queue rather than having one in-queue flow that they all share. My question is this: What is gained by having one in-queue flow that has several branching paths as opposed to one flow for each queue? In my mind it's cleaner and makes more sense to have one in-queue flow for each queue, but I'm a little hesitant to make this change because the implementation team (who I assume are well-versed in this type of thing) chose to do it this other way. Is this just a personal preference issue or am I missing something?

#ArchitectureandDesign
#Routing(ACD/IVR)

------------------------------
Samuel Urquhart
Greenix Pest Control
------------------------------

Hi Samuel

Another way of doing this instead of having switches all over your in-queue flow is to use variables and have each queue's treatment entered into a data table.  Unless there's some major differences in how you want your in-queue experience to go, you can cover most things this way.

------------------------------
Vaun McCarthy
------------------------------

Thanks for responding, Vaun. I hadn't considered the use of data tables, but that's not a bad idea.

------------------------------
Samuel Urquhart
Greenix Pest Control
------------------------------

Original Message:
Sent: 03-09-2023 14:16
From: Vaun McCarthy
Subject: One in-queue flow or multiple

Hi Samuel

Another way of doing this instead of having switches all over your in-queue flow is to use variables and have each queue's treatment entered into a data table.  Unless there's some major differences in how you want your in-queue experience to go, you can cover most things this way.

------------------------------
Vaun McCarthy
------------------------------

I have seen several customers use Data Tables like this, and it works well, however be careful.

As your flows get more complex, they become much harder to debug. If things like Queue Names or Prompts are stored inside Data Tables and dynamically referenced, then none of the Dependency tools will work. You will also find that the usual "checks and balances" fail (for example, allowing you to delete a Queue that is still being referenced). It is also extremely difficult to trace the path a call took when unexpected things happen.

My advice is, if doing this, document thoroughly and include detailed debugging information in Participant Data to leave yourself a trail of breadcrumbs.... Alternatively, up-vote this idea concerning improving debugging!

Just my 10 cents. HTH

------------------------------
Paul Simpson
Eventus Solutions Group
------------------------------

Original Message:
Sent: 03-09-2023 14:16
From: Vaun McCarthy
Subject: One in-queue flow or multiple

Hi Samuel

Another way of doing this instead of having switches all over your in-queue flow is to use variables and have each queue's treatment entered into a data table.  Unless there's some major differences in how you want your in-queue experience to go, you can cover most things this way.

------------------------------
Vaun McCarthy
------------------------------

It's possible that you'll run out of available paths on your switch if you keep adding queues.  Does each of your queues have it's own distinct treatment?  We have multiple in queue flows, but it's not a 1:1 ratio.  Their grouped together by how the calls are treated.  For instance, we have queues that offer a queue voicemail every 5 minutes.  Those are all assigned to the same in queue flow, and the voicemails stay in the queue that they were originally in.  

I would try to avoid the 1:1 ratio of queues and in queue flows if at all possible.  

------------------------------
Jason Tripp
Independent Health Association, Inc.
------------------------------

Thanks for your response, Jason. Our flows are pretty similar across the board...we could probably do with one or two groups as you've described. Running out of paths on our switch statement is also something I hadn't considered, and I appreciate the warning!

------------------------------
Samuel Urquhart
Greenix Pest Control
------------------------------

Original Message:
Sent: 03-09-2023 14:41
From: Jason Tripp
Subject: One in-queue flow or multiple

It's possible that you'll run out of available paths on your switch if you keep adding queues.  Does each of your queues have it's own distinct treatment?  We have multiple in queue flows, but it's not a 1:1 ratio.  Their grouped together by how the calls are treated.  For instance, we have queues that offer a queue voicemail every 5 minutes.  Those are all assigned to the same in queue flow, and the voicemails stay in the queue that they were originally in.  

I would try to avoid the 1:1 ratio of queues and in queue flows if at all possible.  

------------------------------
Jason Tripp
Independent Health Association, Inc.
------------------------------

Others have mentioned a possible solution, I guess the benefits of having a single flow are it is easier to make changes inside one flow rather than having to apply to multiple different flows. E.g. If you are using a hold message prompt in each queue and update it, you only have to republish one flow rather than each individual in-queue flow. 

But it has its drawbacks too. 

------------------------------
James Dunn
Pitney Bowes Inc.
------------------------------

I recommend the "find user prompt"-option in flows. It loads the newest version of the prompt, so you can change prompts without republishing the flow(s) every time.

------------------------------
Christoph Domaschke
CRONBANK AG
------------------------------

Original Message:
Sent: 03-13-2023 05:10
From: James Dunn
Subject: One in-queue flow or multiple

Others have mentioned a possible solution, I guess the benefits of having a single flow are it is easier to make changes inside one flow rather than having to apply to multiple different flows. E.g. If you are using a hold message prompt in each queue and update it, you only have to republish one flow rather than each individual in-queue flow. 

But it has its drawbacks too. 

------------------------------
James Dunn
Pitney Bowes Inc.
------------------------------

I agree, although it does break the Dependency viewers!

TBH, I don't understand why Genesys require Flows to be re-published when updating a Prompt. For me, it removes much of the value of having fully encapsulated and dereferenced prompts in the first place!

I'm sure they have their reasons....

------------------------------
Paul Simpson
Eventus Solutions Group
------------------------------

Original Message:
Sent: 03-14-2023 03:24
From: Christoph Domaschke
Subject: One in-queue flow or multiple

I recommend the "find user prompt"-option in flows. It loads the newest version of the prompt, so you can change prompts without republishing the flow(s) every time.

------------------------------
Christoph Domaschke
CRONBANK AG
------------------------------


Original Message:
Sent: 03-13-2023 05:10
From: James Dunn
Subject: One in-queue flow or multiple

Others have mentioned a possible solution, I guess the benefits of having a single flow are it is easier to make changes inside one flow rather than having to apply to multiple different flows. E.g. If you are using a hold message prompt in each queue and update it, you only have to republish one flow rather than each individual in-queue flow. 

But it has its drawbacks too. 

------------------------------
James Dunn
Pitney Bowes Inc.

Hi Paul,

if you use "Find User Prompt" in Flows you do not have to republish a flow after updating a prompt. This also allows you to use dynamic prompts depending on entries in a data table. In my company for example there are different greetings, depending witch division is called. The different prompts are named in the data table. So "find user prompt" uses the promptname from the data table, finds the prompt, loads the newest version of the prompt - and thats it.

Best
Christoph

------------------------------
Christoph Domaschke
CRONBANK AG
------------------------------

Original Message:
Sent: 03-16-2023 08:54
From: Paul Simpson
Subject: One in-queue flow or multiple

I agree, although it does break the Dependency viewers!

TBH, I don't understand why Genesys require Flows to be re-published when updating a Prompt. For me, it removes much of the value of having fully encapsulated and dereferenced prompts in the first place!

I'm sure they have their reasons....

------------------------------
Paul Simpson
Eventus Solutions Group
------------------------------


Original Message:
Sent: 03-14-2023 03:24
From: Christoph Domaschke
Subject: One in-queue flow or multiple

I recommend the "find user prompt"-option in flows. It loads the newest version of the prompt, so you can change prompts without republishing the flow(s) every time.

------------------------------
Christoph Domaschke
CRONBANK AG


Original Message:
Sent: 03-13-2023 05:10
From: James Dunn
Subject: One in-queue flow or multiple

Others have mentioned a possible solution, I guess the benefits of having a single flow are it is easier to make changes inside one flow rather than having to apply to multiple different flows. E.g. If you are using a hold message prompt in each queue and update it, you only have to republish one flow rather than each individual in-queue flow. 

But it has its drawbacks too. 

------------------------------
James Dunn
Pitney Bowes Inc.

Christoph,

Thanks, but I was aware of that. The problem, however, is that you then can't use any of the Dependency tools to find flows that consume a particular Prompt. It also seems (to me) to be a work-around to  problem that needn't exist in the first place....

------------------------------
Paul Simpson
Eventus Solutions Group
------------------------------

Original Message:
Sent: 03-16-2023 10:48
From: Christoph Domaschke
Subject: One in-queue flow or multiple

Hi Paul,

if you use "Find User Prompt" in Flows you do not have to republish a flow after updating a prompt. This also allows you to use dynamic prompts depending on entries in a data table. In my company for example there are different greetings, depending witch division is called. The different prompts are named in the data table. So "find user prompt" uses the promptname from the data table, finds the prompt, loads the newest version of the prompt - and thats it.

Best
Christoph

------------------------------
Christoph Domaschke
CRONBANK AG
------------------------------


Original Message:
Sent: 03-16-2023 08:54
From: Paul Simpson
Subject: One in-queue flow or multiple

I agree, although it does break the Dependency viewers!

TBH, I don't understand why Genesys require Flows to be re-published when updating a Prompt. For me, it removes much of the value of having fully encapsulated and dereferenced prompts in the first place!

I'm sure they have their reasons....

------------------------------
Paul Simpson
Eventus Solutions Group


Original Message:
Sent: 03-14-2023 03:24
From: Christoph Domaschke
Subject: One in-queue flow or multiple

I recommend the "find user prompt"-option in flows. It loads the newest version of the prompt, so you can change prompts without republishing the flow(s) every time.

------------------------------
Christoph Domaschke
CRONBANK AG


Original Message:
Sent: 03-13-2023 05:10
From: James Dunn
Subject: One in-queue flow or multiple

Others have mentioned a possible solution, I guess the benefits of having a single flow are it is easier to make changes inside one flow rather than having to apply to multiple different flows. E.g. If you are using a hold message prompt in each queue and update it, you only have to republish one flow rather than each individual in-queue flow. 

But it has its drawbacks too. 

------------------------------
James Dunn
Pitney Bowes Inc.