Genesys Cloud - Main

 View Only

Sign Up

  Thread closed by the administrator, not accepting new replies.
  • 1.  Is there a way to tell in an in-queue flow if the call is a consult?

    Posted 08-26-2020 19:49
    No replies, thread closed.
    I'm trying to share the same in-queue flow in both Architect flows and set as the default at the Queue level for calls made to it directly or as a consult/blind transfer.

    What logic can I use in that flow to identify the call is a consult vs coming through from an IVR?

    #Routing(ACD/IVR)

    ------------------------------
    Vaun McCarthy
    NTT New Zealand Limited
    ------------------------------


  • 2.  RE: Is there a way to tell in an in-queue flow if the call is a consult?

    Posted 08-27-2020 02:30
    No replies, thread closed.
    Hello Vaun,

    I had a quick look into the properties set on a call and I do not see anything that you can use to identify if a call is part of a consult/blind transfer.

    The consult/blind transfers are directly into the queue? And the other calls first pass an IVR flow before being assigned to the ACD Queue? If this is the case you can set some participant data in the IVR flow and verify in your In-Queue flow if this is set. If so, the call is not a transfer.

    Kind regards,

    Dieter

    ------------------------------
    Dieter Wijnen
    Telenet BVBA
    ------------------------------



  • 3.  RE: Is there a way to tell in an in-queue flow if the call is a consult?

    Posted 08-27-2020 03:39
    No replies, thread closed.
    Thanks Dieter

    I have a feeling that any participant data added within the IVR is going to still be there all the way through to the in-queue call flow.

    ------------------------------
    Vaun McCarthy
    NTT New Zealand Limited
    ------------------------------



  • 4.  RE: Is there a way to tell in an in-queue flow if the call is a consult?

    Posted 08-27-2020 03:48
    No replies, thread closed.
    Hello Vaun,

    Correct, the participant data will stay on the call object even after the call has been disconnected. You'll need to set the participant data in the IVR flow to identify a none-transferred call (as the transferred callls go directly into the queue) and after you have your logic in the in-queue flow executed for none-transferred calls you'll need to update the participant data. The update in the in-queue is needed just in case the none-transferred call would be transferred by an agent to a queue. Else the system will think that it's a none-transferred call as the participant data has a specific value set.

    Do you think this solution would solve your problem?

    ------------------------------
    Dieter Wijnen
    Telenet BVBA
    ------------------------------