To preface my question, here are some assumptions/observations I've made:

- Once a call enters an in-queue flow, Genesys immediately tries to send it to a member of that queue based on the queue's routing and evaluation methods
- If every member of this queue has auto-answer enabled, the call could potentially enter the queue and be answered by an agent in less than one second
- If the call is in the in-queue flow for a short enough duration, basically none of the steps within that flow will occur

This has caused some issues for us in the past with in-queue schedule group evaluation, for example, but now it's causing issues with adding skills to a call upon transfer. Let's say I want to add the same skill to every call that enters a queue - my first solution was to simply call the "Set Skills" action at the very top of the in-queue flow for that queue. Well, as I've discovered, that doesn't always happen because the call seems to be answered before that action takes place. So some of our calls in that queue have the necessary skill attached, but many of the calls do not have that skill attached.

So, I have two questions: is there a foolproof way to add skills during a blind or consult transfer? Is there a way to guarantee that certain actions run in an in-queue flow before a call is routed to agent?


Here are my ideas so far:
1. Create logic in Architect that adds the desired skill at the in-queue flow level. This is not foolproof because calls can be answered before that action is reached and completed.
2. Remove the auto answer functionality for the agents in this queue. This would likely work a large majority of the time, but leadership here is against this solution.
3. Create a data action that adds the desired skill to the conversation, edit our agent scripts so that they have a button specifically for transferring to this queue, and have that button call the data action and then transfer the call. This would work too, but it's a lot of effort just to ensure that certain logic is executed on every call to this one queue, and the effort would only increase if I wanted to add more logic.

#ArchitectureandDesign
#Routing(ACD/IVR)

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

Hi Samuel,
why does the call has to be transferred to an in-queue flow? Why not transferring it to a "normal" flow that processes the desired steps and than gives the call to an in-queue flow?
Best regards
Christoph

To preface my question, here are some assumptions/observations I've made:

- Once a call enters an in-queue flow, Genesys immediately tries to send it to a member of that queue based on the queue's routing and evaluation methods
- If every member of this queue has auto-answer enabled, the call could potentially enter the queue and be answered by an agent in less than one second
- If the call is in the in-queue flow for a short enough duration, basically none of the steps within that flow will occur

This has caused some issues for us in the past with in-queue schedule group evaluation, for example, but now it's causing issues with adding skills to a call upon transfer. Let's say I want to add the same skill to every call that enters a queue - my first solution was to simply call the "Set Skills" action at the very top of the in-queue flow for that queue. Well, as I've discovered, that doesn't always happen because the call seems to be answered before that action takes place. So some of our calls in that queue have the necessary skill attached, but many of the calls do not have that skill attached.

So, I have two questions: is there a foolproof way to add skills during a blind or consult transfer? Is there a way to guarantee that certain actions run in an in-queue flow before a call is routed to agent?


Here are my ideas so far:
1. Create logic in Architect that adds the desired skill at the in-queue flow level. This is not foolproof because calls can be answered before that action is reached and completed.
2. Remove the auto answer functionality for the agents in this queue. This would likely work a large majority of the time, but leadership here is against this solution.
3. Create a data action that adds the desired skill to the conversation, edit our agent scripts so that they have a button specifically for transferring to this queue, and have that button call the data action and then transfer the call. This would work too, but it's a lot of effort just to ensure that certain logic is executed on every call to this one queue, and the effort would only increase if I wanted to add more logic.

#ArchitectureandDesign
#Routing(ACD/IVR)

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

Hi Samuel,
why does the call has to be transferred to an in-queue flow? Why not transferring it to a "normal" flow that processes the desired steps and than gives the call to an in-queue flow?
Best regards
Christoph

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

Original Message:
Sent: 05-31-2023 14:06
From: Samuel Urquhart
Subject: Processing actions in an in-queue flow

To preface my question, here are some assumptions/observations I've made:

- Once a call enters an in-queue flow, Genesys immediately tries to send it to a member of that queue based on the queue's routing and evaluation methods
- If every member of this queue has auto-answer enabled, the call could potentially enter the queue and be answered by an agent in less than one second
- If the call is in the in-queue flow for a short enough duration, basically none of the steps within that flow will occur

This has caused some issues for us in the past with in-queue schedule group evaluation, for example, but now it's causing issues with adding skills to a call upon transfer. Let's say I want to add the same skill to every call that enters a queue - my first solution was to simply call the "Set Skills" action at the very top of the in-queue flow for that queue. Well, as I've discovered, that doesn't always happen because the call seems to be answered before that action takes place. So some of our calls in that queue have the necessary skill attached, but many of the calls do not have that skill attached.

So, I have two questions: is there a foolproof way to add skills during a blind or consult transfer? Is there a way to guarantee that certain actions run in an in-queue flow before a call is routed to agent?


Here are my ideas so far:
1. Create logic in Architect that adds the desired skill at the in-queue flow level. This is not foolproof because calls can be answered before that action is reached and completed.
2. Remove the auto answer functionality for the agents in this queue. This would likely work a large majority of the time, but leadership here is against this solution.
3. Create a data action that adds the desired skill to the conversation, edit our agent scripts so that they have a button specifically for transferring to this queue, and have that button call the data action and then transfer the call. This would work too, but it's a lot of effort just to ensure that certain logic is executed on every call to this one queue, and the effort would only increase if I wanted to add more logic.

#ArchitectureandDesign
#Routing(ACD/IVR)

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

Hello Cristoph,

Thank you for your response.

We have logic in our inbound flows, and those work as expected. I'm specifically referring to situations where a call has gone through one of our inbound flows and has been routed to an agent. When an agent transfers a call, they can only transfer the call to three entities: a specific user, a specific phone number, or a specific queue. Transferring to a queue makes the most sense from an agent and data perspective, but then we run into the situation I've described in my original post because transferring to a queue automatically sends the call through the destination queue's in-queue flow.

As far as I can tell, there's no way for an agent to transfer a call to an inbound flow.

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

Original Message:
Sent: 06-01-2023 02:40
From: Christoph Domaschke
Subject: Processing actions in an in-queue flow

Hi Samuel,
why does the call has to be transferred to an in-queue flow? Why not transferring it to a "normal" flow that processes the desired steps and than gives the call to an in-queue flow?
Best regards
Christoph

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

Original Message:
Sent: 05-31-2023 14:06
From: Samuel Urquhart
Subject: Processing actions in an in-queue flow

To preface my question, here are some assumptions/observations I've made:

- Once a call enters an in-queue flow, Genesys immediately tries to send it to a member of that queue based on the queue's routing and evaluation methods
- If every member of this queue has auto-answer enabled, the call could potentially enter the queue and be answered by an agent in less than one second
- If the call is in the in-queue flow for a short enough duration, basically none of the steps within that flow will occur

This has caused some issues for us in the past with in-queue schedule group evaluation, for example, but now it's causing issues with adding skills to a call upon transfer. Let's say I want to add the same skill to every call that enters a queue - my first solution was to simply call the "Set Skills" action at the very top of the in-queue flow for that queue. Well, as I've discovered, that doesn't always happen because the call seems to be answered before that action takes place. So some of our calls in that queue have the necessary skill attached, but many of the calls do not have that skill attached.

So, I have two questions: is there a foolproof way to add skills during a blind or consult transfer? Is there a way to guarantee that certain actions run in an in-queue flow before a call is routed to agent?


Here are my ideas so far:
1. Create logic in Architect that adds the desired skill at the in-queue flow level. This is not foolproof because calls can be answered before that action is reached and completed.
2. Remove the auto answer functionality for the agents in this queue. This would likely work a large majority of the time, but leadership here is against this solution.
3. Create a data action that adds the desired skill to the conversation, edit our agent scripts so that they have a button specifically for transferring to this queue, and have that button call the data action and then transfer the call. This would work too, but it's a lot of effort just to ensure that certain logic is executed on every call to this one queue, and the effort would only increase if I wanted to add more logic.

#ArchitectureandDesign
#Routing(ACD/IVR)

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

Hello Cristoph,

Thank you for your response.

We have logic in our inbound flows, and those work as expected. I'm specifically referring to situations where a call has gone through one of our inbound flows and has been routed to an agent. When an agent transfers a call, they can only transfer the call to three entities: a specific user, a specific phone number, or a specific queue. Transferring to a queue makes the most sense from an agent and data perspective, but then we run into the situation I've described in my original post because transferring to a queue automatically sends the call through the destination queue's in-queue flow.

As far as I can tell, there's no way for an agent to transfer a call to an inbound flow.

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

Original Message:
Sent: 06-01-2023 02:40
From: Christoph Domaschke
Subject: Processing actions in an in-queue flow

Hi Samuel,
why does the call has to be transferred to an in-queue flow? Why not transferring it to a "normal" flow that processes the desired steps and than gives the call to an in-queue flow?
Best regards
Christoph

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

Original Message:
Sent: 05-31-2023 14:06
From: Samuel Urquhart
Subject: Processing actions in an in-queue flow

To preface my question, here are some assumptions/observations I've made:

- Once a call enters an in-queue flow, Genesys immediately tries to send it to a member of that queue based on the queue's routing and evaluation methods
- If every member of this queue has auto-answer enabled, the call could potentially enter the queue and be answered by an agent in less than one second
- If the call is in the in-queue flow for a short enough duration, basically none of the steps within that flow will occur

This has caused some issues for us in the past with in-queue schedule group evaluation, for example, but now it's causing issues with adding skills to a call upon transfer. Let's say I want to add the same skill to every call that enters a queue - my first solution was to simply call the "Set Skills" action at the very top of the in-queue flow for that queue. Well, as I've discovered, that doesn't always happen because the call seems to be answered before that action takes place. So some of our calls in that queue have the necessary skill attached, but many of the calls do not have that skill attached.

So, I have two questions: is there a foolproof way to add skills during a blind or consult transfer? Is there a way to guarantee that certain actions run in an in-queue flow before a call is routed to agent?


Here are my ideas so far:
1. Create logic in Architect that adds the desired skill at the in-queue flow level. This is not foolproof because calls can be answered before that action is reached and completed.
2. Remove the auto answer functionality for the agents in this queue. This would likely work a large majority of the time, but leadership here is against this solution.
3. Create a data action that adds the desired skill to the conversation, edit our agent scripts so that they have a button specifically for transferring to this queue, and have that button call the data action and then transfer the call. This would work too, but it's a lot of effort just to ensure that certain logic is executed on every call to this one queue, and the effort would only increase if I wanted to add more logic.

#ArchitectureandDesign
#Routing(ACD/IVR)

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

Hello Samuel,

it is possible to do an blind transfer to any flow you like with flowname@localhost. I use this feature in combination with a button in my script. Only problem is, that agents have to use the transfer-button in the script or else it won't work. Afak it works with consulted transfers, too, as long as there are only two participants in the call and not three.
But if we are talking about buttons in scripts, than you maybe can use data actions to add skills to a call instead of transferring to a flow. But I never did that on my own, so I do not know for certain.

Best regards
Christoph

Hello Cristoph,

Thank you for your response.

We have logic in our inbound flows, and those work as expected. I'm specifically referring to situations where a call has gone through one of our inbound flows and has been routed to an agent. When an agent transfers a call, they can only transfer the call to three entities: a specific user, a specific phone number, or a specific queue. Transferring to a queue makes the most sense from an agent and data perspective, but then we run into the situation I've described in my original post because transferring to a queue automatically sends the call through the destination queue's in-queue flow.

As far as I can tell, there's no way for an agent to transfer a call to an inbound flow.

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

Original Message:
Sent: 06-01-2023 02:40
From: Christoph Domaschke
Subject: Processing actions in an in-queue flow

Hi Samuel,
why does the call has to be transferred to an in-queue flow? Why not transferring it to a "normal" flow that processes the desired steps and than gives the call to an in-queue flow?
Best regards
Christoph

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

Original Message:
Sent: 05-31-2023 14:06
From: Samuel Urquhart
Subject: Processing actions in an in-queue flow

To preface my question, here are some assumptions/observations I've made:

- Once a call enters an in-queue flow, Genesys immediately tries to send it to a member of that queue based on the queue's routing and evaluation methods
- If every member of this queue has auto-answer enabled, the call could potentially enter the queue and be answered by an agent in less than one second
- If the call is in the in-queue flow for a short enough duration, basically none of the steps within that flow will occur

This has caused some issues for us in the past with in-queue schedule group evaluation, for example, but now it's causing issues with adding skills to a call upon transfer. Let's say I want to add the same skill to every call that enters a queue - my first solution was to simply call the "Set Skills" action at the very top of the in-queue flow for that queue. Well, as I've discovered, that doesn't always happen because the call seems to be answered before that action takes place. So some of our calls in that queue have the necessary skill attached, but many of the calls do not have that skill attached.

So, I have two questions: is there a foolproof way to add skills during a blind or consult transfer? Is there a way to guarantee that certain actions run in an in-queue flow before a call is routed to agent?


Here are my ideas so far:
1. Create logic in Architect that adds the desired skill at the in-queue flow level. This is not foolproof because calls can be answered before that action is reached and completed.
2. Remove the auto answer functionality for the agents in this queue. This would likely work a large majority of the time, but leadership here is against this solution.
3. Create a data action that adds the desired skill to the conversation, edit our agent scripts so that they have a button specifically for transferring to this queue, and have that button call the data action and then transfer the call. This would work too, but it's a lot of effort just to ensure that certain logic is executed on every call to this one queue, and the effort would only increase if I wanted to add more logic.

#ArchitectureandDesign
#Routing(ACD/IVR)

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

@Christoph Domaschke

Wow, I wasn't aware that you could do that! I'm amazed that nobody has commented on this in the various comment threads and / or ideas related to this. Do you happen to have a link to any documentation on this method?

Hello Samuel,

it is possible to do an blind transfer to any flow you like with flowname@localhost. I use this feature in combination with a button in my script. Only problem is, that agents have to use the transfer-button in the script or else it won't work. Afak it works with consulted transfers, too, as long as there are only two participants in the call and not three.
But if we are talking about buttons in scripts, than you maybe can use data actions to add skills to a call instead of transferring to a flow. But I never did that on my own, so I do not know for certain.

Best regards
Christoph

Hello Cristoph,

Thank you for your response.

We have logic in our inbound flows, and those work as expected. I'm specifically referring to situations where a call has gone through one of our inbound flows and has been routed to an agent. When an agent transfers a call, they can only transfer the call to three entities: a specific user, a specific phone number, or a specific queue. Transferring to a queue makes the most sense from an agent and data perspective, but then we run into the situation I've described in my original post because transferring to a queue automatically sends the call through the destination queue's in-queue flow.

As far as I can tell, there's no way for an agent to transfer a call to an inbound flow.

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

Original Message:
Sent: 06-01-2023 02:40
From: Christoph Domaschke
Subject: Processing actions in an in-queue flow

Hi Samuel,
why does the call has to be transferred to an in-queue flow? Why not transferring it to a "normal" flow that processes the desired steps and than gives the call to an in-queue flow?
Best regards
Christoph

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

Original Message:
Sent: 05-31-2023 14:06
From: Samuel Urquhart
Subject: Processing actions in an in-queue flow

To preface my question, here are some assumptions/observations I've made:

- Once a call enters an in-queue flow, Genesys immediately tries to send it to a member of that queue based on the queue's routing and evaluation methods
- If every member of this queue has auto-answer enabled, the call could potentially enter the queue and be answered by an agent in less than one second
- If the call is in the in-queue flow for a short enough duration, basically none of the steps within that flow will occur

This has caused some issues for us in the past with in-queue schedule group evaluation, for example, but now it's causing issues with adding skills to a call upon transfer. Let's say I want to add the same skill to every call that enters a queue - my first solution was to simply call the "Set Skills" action at the very top of the in-queue flow for that queue. Well, as I've discovered, that doesn't always happen because the call seems to be answered before that action takes place. So some of our calls in that queue have the necessary skill attached, but many of the calls do not have that skill attached.

So, I have two questions: is there a foolproof way to add skills during a blind or consult transfer? Is there a way to guarantee that certain actions run in an in-queue flow before a call is routed to agent?


Here are my ideas so far:
1. Create logic in Architect that adds the desired skill at the in-queue flow level. This is not foolproof because calls can be answered before that action is reached and completed.
2. Remove the auto answer functionality for the agents in this queue. This would likely work a large majority of the time, but leadership here is against this solution.
3. Create a data action that adds the desired skill to the conversation, edit our agent scripts so that they have a button specifically for transferring to this queue, and have that button call the data action and then transfer the call. This would work too, but it's a lot of effort just to ensure that certain logic is executed on every call to this one queue, and the effort would only increase if I wanted to add more logic.

#ArchitectureandDesign
#Routing(ACD/IVR)

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

To preface my question, here are some assumptions/observations I've made:

- Once a call enters an in-queue flow, Genesys immediately tries to send it to a member of that queue based on the queue's routing and evaluation methods
- If every member of this queue has auto-answer enabled, the call could potentially enter the queue and be answered by an agent in less than one second
- If the call is in the in-queue flow for a short enough duration, basically none of the steps within that flow will occur

This has caused some issues for us in the past with in-queue schedule group evaluation, for example, but now it's causing issues with adding skills to a call upon transfer. Let's say I want to add the same skill to every call that enters a queue - my first solution was to simply call the "Set Skills" action at the very top of the in-queue flow for that queue. Well, as I've discovered, that doesn't always happen because the call seems to be answered before that action takes place. So some of our calls in that queue have the necessary skill attached, but many of the calls do not have that skill attached.

So, I have two questions: is there a foolproof way to add skills during a blind or consult transfer? Is there a way to guarantee that certain actions run in an in-queue flow before a call is routed to agent?


Here are my ideas so far:
1. Create logic in Architect that adds the desired skill at the in-queue flow level. This is not foolproof because calls can be answered before that action is reached and completed.
2. Remove the auto answer functionality for the agents in this queue. This would likely work a large majority of the time, but leadership here is against this solution.
3. Create a data action that adds the desired skill to the conversation, edit our agent scripts so that they have a button specifically for transferring to this queue, and have that button call the data action and then transfer the call. This would work too, but it's a lot of effort just to ensure that certain logic is executed on every call to this one queue, and the effort would only increase if I wanted to add more logic.

#ArchitectureandDesign
#Routing(ACD/IVR)

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