Genesys Cloud CX - Beta HQ

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

Hi Steven - yes, happy to share and thanks for asking! 

We are planning for the users to be licensed as GC1 and up.  Access to digital channels (SMS and email) will be based on GC license level as it is today for other interactions.

The current setup includes a single "Direct Routing" queue users will be members of.  Membership will be based on the association of a new 'directrouting' tag to users' contact fields on their profile.  This association can be done via SCIM, API, or bulk user import and will add users to the correct queue and add the specific contact info/field (voice, SMS, or email) to the appropriate routes. 

We may adjust this approach depending on feedback but that is the current plan!  Stay tuned, and happy to answer any more questions you have.

Thanks!

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

My two cents: a single permission, or one per media type, that triggers this direct routing is probably easier to manage and see as an admin than a contact field tag - and still easily manageable via SCIM or API.

Hi Steven - yes, happy to share and thanks for asking! 

We are planning for the users to be licensed as GC1 and up.  Access to digital channels (SMS and email) will be based on GC license level as it is today for other interactions.

The current setup includes a single "Direct Routing" queue users will be members of.  Membership will be based on the association of a new 'directrouting' tag to users' contact fields on their profile.  This association can be done via SCIM, API, or bulk user import and will add users to the correct queue and add the specific contact info/field (voice, SMS, or email) to the appropriate routes. 

We may adjust this approach depending on feedback but that is the current plan!  Stay tuned, and happy to answer any more questions you have.

Thanks!

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

The concern is that users can have multiple DIDs and email addresses, and the system needs to know which specific contact information to use for Direct Routing.  This requires some indication on the individual profile contact fields.  E.g. user could have:

Work Phone 1 = Direct Routing for voice
Work Phone 2 = internal only (not expected to track as ACD interactions)
Email 1 = Direct Routing
Email 2 = personal email (not expected to track as ACD interactions)

The channels available to a user via Direct Routing are also gated by the license type, e.g. Digital (SMS and email) interactions require GC2+ and/or Digital add-on.

Does that make sense?

My two cents: a single permission, or one per media type, that triggers this direct routing is probably easier to manage and see as an admin than a contact field tag - and still easily manageable via SCIM or API.

Hi Steven - yes, happy to share and thanks for asking! 

We are planning for the users to be licensed as GC1 and up.  Access to digital channels (SMS and email) will be based on GC license level as it is today for other interactions.

The current setup includes a single "Direct Routing" queue users will be members of.  Membership will be based on the association of a new 'directrouting' tag to users' contact fields on their profile.  This association can be done via SCIM, API, or bulk user import and will add users to the correct queue and add the specific contact info/field (voice, SMS, or email) to the appropriate routes. 

We may adjust this approach depending on feedback but that is the current plan!  Stay tuned, and happy to answer any more questions you have.

Thanks!

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

This makes sense, thank you.

Will Direct Routing via dialed extensions work, or only if the user has a full DID?

------------------------------
Brad Murlin
Zillow, Inc.
------------------------------


Original Message:
Sent: 05-15-2023 09:26
From: trey buck
Subject: Upcoming Beta - Direct Routing

The concern is that users can have multiple DIDs and email addresses, and the system needs to know which specific contact information to use for Direct Routing.  This requires some indication on the individual profile contact fields.  E.g. user could have:

Work Phone 1 = Direct Routing for voice
Work Phone 2 = internal only (not expected to track as ACD interactions)
Email 1 = Direct Routing
Email 2 = personal email (not expected to track as ACD interactions)

The channels available to a user via Direct Routing are also gated by the license type, e.g. Digital (SMS and email) interactions require GC2+ and/or Digital add-on.

Does that make sense?

------------------------------
Trey Buck
Genesys - Employees
Senior Product Manager


Original Message:
Sent: 05-13-2023 01:51
From: Brad Murlin
Subject: Upcoming Beta - Direct Routing

My two cents: a single permission, or one per media type, that triggers this direct routing is probably easier to manage and see as an admin than a contact field tag - and still easily manageable via SCIM or API.

------------------------------
Brad Murlin
Zillow, Inc.


Original Message:
Sent: 05-12-2023 09:32
From: trey buck
Subject: Upcoming Beta - Direct Routing

Hi Steven - yes, happy to share and thanks for asking! 

We are planning for the users to be licensed as GC1 and up.  Access to digital channels (SMS and email) will be based on GC license level as it is today for other interactions.

The current setup includes a single "Direct Routing" queue users will be members of.  Membership will be based on the association of a new 'directrouting' tag to users' contact fields on their profile.  This association can be done via SCIM, API, or bulk user import and will add users to the correct queue and add the specific contact info/field (voice, SMS, or email) to the appropriate routes. 

We may adjust this approach depending on feedback but that is the current plan!  Stay tuned, and happy to answer any more questions you have.

Thanks!

------------------------------
Trey Buck
Genesys - Employees
Staff Product Manager


Original Message:
Sent: 05-12-2023 09:01
From: Steven Alix
Subject: Upcoming Beta - Direct Routing

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

------------------------------
Steve Alix
EDCi

@trey buck & @David Farrell - I'm also interested in a response to @Brad Murlin's question regarding whether or not an agent's extension will work as opposed to personal DIDs. In our org we issue extensions with a dial by extension option on the main phone number, thus saving us the overhead associated with DIDs.

------------------------------
Brian T. Jones | Ascension | Senior Specialist - Technology
------------------------------


Original Message:
Sent: 05-15-2023 14:14
From: Brad Murlin
Subject: Upcoming Beta - Direct Routing

This makes sense, thank you.

Will Direct Routing via dialed extensions work, or only if the user has a full DID?

------------------------------
Brad Murlin
Zillow, Inc.


Original Message:
Sent: 05-15-2023 09:26
From: trey buck
Subject: Upcoming Beta - Direct Routing

The concern is that users can have multiple DIDs and email addresses, and the system needs to know which specific contact information to use for Direct Routing.  This requires some indication on the individual profile contact fields.  E.g. user could have:

Work Phone 1 = Direct Routing for voice
Work Phone 2 = internal only (not expected to track as ACD interactions)
Email 1 = Direct Routing
Email 2 = personal email (not expected to track as ACD interactions)

The channels available to a user via Direct Routing are also gated by the license type, e.g. Digital (SMS and email) interactions require GC2+ and/or Digital add-on.

Does that make sense?

------------------------------
Trey Buck
Genesys - Employees
Senior Product Manager


Original Message:
Sent: 05-13-2023 01:51
From: Brad Murlin
Subject: Upcoming Beta - Direct Routing

My two cents: a single permission, or one per media type, that triggers this direct routing is probably easier to manage and see as an admin than a contact field tag - and still easily manageable via SCIM or API.

------------------------------
Brad Murlin
Zillow, Inc.


Original Message:
Sent: 05-12-2023 09:32
From: trey buck
Subject: Upcoming Beta - Direct Routing

Hi Steven - yes, happy to share and thanks for asking! 

We are planning for the users to be licensed as GC1 and up.  Access to digital channels (SMS and email) will be based on GC license level as it is today for other interactions.

The current setup includes a single "Direct Routing" queue users will be members of.  Membership will be based on the association of a new 'directrouting' tag to users' contact fields on their profile.  This association can be done via SCIM, API, or bulk user import and will add users to the correct queue and add the specific contact info/field (voice, SMS, or email) to the appropriate routes. 

We may adjust this approach depending on feedback but that is the current plan!  Stay tuned, and happy to answer any more questions you have.

Thanks!

------------------------------
Trey Buck
Genesys - Employees
Staff Product Manager


Original Message:
Sent: 05-12-2023 09:01
From: Steven Alix
Subject: Upcoming Beta - Direct Routing

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

------------------------------
Steve Alix
EDCi

Hi Brian - yes it will be possible to support targeting users on their extension.  One question though: What are your requirements when dialling outbound?  Would your users use 'dial on behalf of queue'?  And consequently all calls would appear to be coming from the same number..?  I ask because one of the requirements we're building for is to allow dialling outbound from a queue, but using the user's DID rather than the number on the queue.

------------------------------
David Farrell
Genesys - Employees
------------------------------


Original Message:
Sent: 12-18-2023 09:40
From: Brian Jones
Subject: Upcoming Beta - Direct Routing

@trey buck & @David Farrell - I'm also interested in a response to @Brad Murlin's question regarding whether or not an agent's extension will work as opposed to personal DIDs. In our org we issue extensions with a dial by extension option on the main phone number, thus saving us the overhead associated with DIDs.

------------------------------
Brian T. Jones | Ascension | Senior Specialist - Technology


Original Message:
Sent: 05-15-2023 14:14
From: Brad Murlin
Subject: Upcoming Beta - Direct Routing

This makes sense, thank you.

Will Direct Routing via dialed extensions work, or only if the user has a full DID?

------------------------------
Brad Murlin
Zillow, Inc.


Original Message:
Sent: 05-15-2023 09:26
From: trey buck
Subject: Upcoming Beta - Direct Routing

The concern is that users can have multiple DIDs and email addresses, and the system needs to know which specific contact information to use for Direct Routing.  This requires some indication on the individual profile contact fields.  E.g. user could have:

Work Phone 1 = Direct Routing for voice
Work Phone 2 = internal only (not expected to track as ACD interactions)
Email 1 = Direct Routing
Email 2 = personal email (not expected to track as ACD interactions)

The channels available to a user via Direct Routing are also gated by the license type, e.g. Digital (SMS and email) interactions require GC2+ and/or Digital add-on.

Does that make sense?

------------------------------
Trey Buck
Genesys - Employees
Senior Product Manager


Original Message:
Sent: 05-13-2023 01:51
From: Brad Murlin
Subject: Upcoming Beta - Direct Routing

My two cents: a single permission, or one per media type, that triggers this direct routing is probably easier to manage and see as an admin than a contact field tag - and still easily manageable via SCIM or API.

------------------------------
Brad Murlin
Zillow, Inc.


Original Message:
Sent: 05-12-2023 09:32
From: trey buck
Subject: Upcoming Beta - Direct Routing

Hi Steven - yes, happy to share and thanks for asking! 

We are planning for the users to be licensed as GC1 and up.  Access to digital channels (SMS and email) will be based on GC license level as it is today for other interactions.

The current setup includes a single "Direct Routing" queue users will be members of.  Membership will be based on the association of a new 'directrouting' tag to users' contact fields on their profile.  This association can be done via SCIM, API, or bulk user import and will add users to the correct queue and add the specific contact info/field (voice, SMS, or email) to the appropriate routes. 

We may adjust this approach depending on feedback but that is the current plan!  Stay tuned, and happy to answer any more questions you have.

Thanks!

------------------------------
Trey Buck
Genesys - Employees
Staff Product Manager


Original Message:
Sent: 05-12-2023 09:01
From: Steven Alix
Subject: Upcoming Beta - Direct Routing

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

------------------------------
Steve Alix
EDCi

Hi Steven - yes, happy to share and thanks for asking! 

We are planning for the users to be licensed as GC1 and up.  Access to digital channels (SMS and email) will be based on GC license level as it is today for other interactions.

The current setup includes a single "Direct Routing" queue users will be members of.  Membership will be based on the association of a new 'directrouting' tag to users' contact fields on their profile.  This association can be done via SCIM, API, or bulk user import and will add users to the correct queue and add the specific contact info/field (voice, SMS, or email) to the appropriate routes. 

We may adjust this approach depending on feedback but that is the current plan!  Stay tuned, and happy to answer any more questions you have.

Thanks!

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

Having "a single 'Direct Routing' queue" may not have much of an impact today.  But in the future as this gets rolled out in GA form, I'm assuming this will be part of a "typical" queue setup.  

How is this going to impact WFM?  

Hi Steven - yes, happy to share and thanks for asking! 

We are planning for the users to be licensed as GC1 and up.  Access to digital channels (SMS and email) will be based on GC license level as it is today for other interactions.

The current setup includes a single "Direct Routing" queue users will be members of.  Membership will be based on the association of a new 'directrouting' tag to users' contact fields on their profile.  This association can be done via SCIM, API, or bulk user import and will add users to the correct queue and add the specific contact info/field (voice, SMS, or email) to the appropriate routes. 

We may adjust this approach depending on feedback but that is the current plan!  Stay tuned, and happy to answer any more questions you have.

Thanks!

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

Hi Trent - we are actively discussing how to support Direct Routing as a "feature" on multiple queues.  There are challenges but have some ideas on how to solve.  What are your thoughts on applying DR to multiple queues vs a single DR queue?

re: WFM - we are not currently planning to support WFM scheduling to start with, but may support in the future.  The rational is that most Genesys customers we have spoken with do not consider Direct Routing users as 'agents' but instead 'back office' and therefore work time/schedules are more flexible for these employees.  Also, WFM usually plays into expected wait times for end customers which are difficult to accurately predict when considering how long a customer might wait for a single individual.  E.g. I am on the phone with one customer for 30 minutes, the next for 5 minutes, etc.

Does that make sense?  Anything I might be missing from your perspective?

Having "a single 'Direct Routing' queue" may not have much of an impact today.  But in the future as this gets rolled out in GA form, I'm assuming this will be part of a "typical" queue setup.  

How is this going to impact WFM?  

Hi Steven - yes, happy to share and thanks for asking! 

We are planning for the users to be licensed as GC1 and up.  Access to digital channels (SMS and email) will be based on GC license level as it is today for other interactions.

The current setup includes a single "Direct Routing" queue users will be members of.  Membership will be based on the association of a new 'directrouting' tag to users' contact fields on their profile.  This association can be done via SCIM, API, or bulk user import and will add users to the correct queue and add the specific contact info/field (voice, SMS, or email) to the appropriate routes. 

We may adjust this approach depending on feedback but that is the current plan!  Stay tuned, and happy to answer any more questions you have.

Thanks!

Hi Trey,

This is great news. Do you have more information you can share about how the users or agents need to be licensed and setup? Are they added to a queue? 

Thanks 

Hi Trey,
This sounds interesting.  Will this new functionality allow for screen recording of the direct routed calls?  To achieve this today, we have to create, and maintain, separate "personal queues" for users to get screen recordings.

Thanks,
Chad

Hi Trey.

I've read your post; but I don't really understand the purpose of this new feature. If possible, could you please give us an example of how you would try to do it now, and the same example once the new feature is up and running?


Thanks.

------------------------------
Marcelino Santos
Open Bank SA
------------------------------

Hi, Trey.
This is a very welcome new feature! Can we assume that In-Queue flows will be supported?
Thanks!

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

Awesome to hear!  Yes, we are adding features for each of voice, SMS, and email which will send DR users' assigned contact info on outbound interactions.

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

If a user only has the "Direct Routing" queue assigned to them, will that queue be selected automatically when the user places an outbound call, or do they still need to manually choose the "Direct Routing" queue to place an outbound call on behalf of a queue?

Awesome to hear!  Yes, we are adding features for each of voice, SMS, and email which will send DR users' assigned contact info on outbound interactions.

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

If a user only has the "Direct Routing" queue assigned to them, will that queue be selected automatically when the user places an outbound call, or do they still need to manually choose the "Direct Routing" queue to place an outbound call on behalf of a queue?

Awesome to hear!  Yes, we are adding features for each of voice, SMS, and email which will send DR users' assigned contact info on outbound interactions.

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

Chad,

Unless I'm missing something here, you wouldn't want that anyway!

The point here is for DID calls to receive the same "treatment" as ACD calls (i.e. Reporting, In-Queue flows, etc.) The numbers will (I assume) still be assigned to the individual users, and not the Queue.

If it was to work the way you suggest, then whose DID would you assign to the Queue for outbound calls?

David's reply does, however, pose another question. If I have a user that is a member of 2 "Direct Routed" queues, both of which have an In-Queue flow assigned, how will you control which flow gets executed?

If a user only has the "Direct Routing" queue assigned to them, will that queue be selected automatically when the user places an outbound call, or do they still need to manually choose the "Direct Routing" queue to place an outbound call on behalf of a queue?

Awesome to hear!  Yes, we are adding features for each of voice, SMS, and email which will send DR users' assigned contact info on outbound interactions.

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

We were looking for a way to make it easier for users that primarily place outbound calls.  It seems that if a user is only a member of a single queue, it should default to that queue rather than requiring the user to select a queue for each outbound call.  It is an additional step the users don't have to do in our current system today.

Chad,

Unless I'm missing something here, you wouldn't want that anyway!

The point here is for DID calls to receive the same "treatment" as ACD calls (i.e. Reporting, In-Queue flows, etc.) The numbers will (I assume) still be assigned to the individual users, and not the Queue.

If it was to work the way you suggest, then whose DID would you assign to the Queue for outbound calls?

David's reply does, however, pose another question. If I have a user that is a member of 2 "Direct Routed" queues, both of which have an In-Queue flow assigned, how will you control which flow gets executed?

If a user only has the "Direct Routing" queue assigned to them, will that queue be selected automatically when the user places an outbound call, or do they still need to manually choose the "Direct Routing" queue to place an outbound call on behalf of a queue?

Awesome to hear!  Yes, we are adding features for each of voice, SMS, and email which will send DR users' assigned contact info on outbound interactions.

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

Gotcha!

That's a slightly different ask, not related to Direct Routing.

Not a 100% solution, but you can select the option to remember the queue that you are placing a call on behalf of. You still need to do it manually for the first call, but after that...

HTH

We were looking for a way to make it easier for users that primarily place outbound calls.  It seems that if a user is only a member of a single queue, it should default to that queue rather than requiring the user to select a queue for each outbound call.  It is an additional step the users don't have to do in our current system today.

Chad,

Unless I'm missing something here, you wouldn't want that anyway!

The point here is for DID calls to receive the same "treatment" as ACD calls (i.e. Reporting, In-Queue flows, etc.) The numbers will (I assume) still be assigned to the individual users, and not the Queue.

If it was to work the way you suggest, then whose DID would you assign to the Queue for outbound calls?

David's reply does, however, pose another question. If I have a user that is a member of 2 "Direct Routed" queues, both of which have an In-Queue flow assigned, how will you control which flow gets executed?

If a user only has the "Direct Routing" queue assigned to them, will that queue be selected automatically when the user places an outbound call, or do they still need to manually choose the "Direct Routing" queue to place an outbound call on behalf of a queue?

Awesome to hear!  Yes, we are adding features for each of voice, SMS, and email which will send DR users' assigned contact info on outbound interactions.

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

Hi Paul,

Thanks for the feedback.  I think I'm missing something.  I cannot see where I would choose to remember the queue I'm placing a call on behalf of.  That sounds like this would solve some concerns from out agents.

Thanks,

Chad

Gotcha!

That's a slightly different ask, not related to Direct Routing.

Not a 100% solution, but you can select the option to remember the queue that you are placing a call on behalf of. You still need to do it manually for the first call, but after that...

HTH

We were looking for a way to make it easier for users that primarily place outbound calls.  It seems that if a user is only a member of a single queue, it should default to that queue rather than requiring the user to select a queue for each outbound call.  It is an additional step the users don't have to do in our current system today.

Chad,

Unless I'm missing something here, you wouldn't want that anyway!

The point here is for DID calls to receive the same "treatment" as ACD calls (i.e. Reporting, In-Queue flows, etc.) The numbers will (I assume) still be assigned to the individual users, and not the Queue.

If it was to work the way you suggest, then whose DID would you assign to the Queue for outbound calls?

David's reply does, however, pose another question. If I have a user that is a member of 2 "Direct Routed" queues, both of which have an In-Queue flow assigned, how will you control which flow gets executed?

If a user only has the "Direct Routing" queue assigned to them, will that queue be selected automatically when the user places an outbound call, or do they still need to manually choose the "Direct Routing" queue to place an outbound call on behalf of a queue?

Awesome to hear!  Yes, we are adding features for each of voice, SMS, and email which will send DR users' assigned contact info on outbound interactions.

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

Hey Chad,

OK, so on the Interactions screen (where you initiate an outbound interaction on behalf of a queue) there is a "gear" (settings) icon:

This will open up a preferences dialog where you can turn this on:

HTH

Hi Paul,

Thanks for the feedback.  I think I'm missing something.  I cannot see where I would choose to remember the queue I'm placing a call on behalf of.  That sounds like this would solve some concerns from out agents.

Thanks,

Chad

Gotcha!

That's a slightly different ask, not related to Direct Routing.

Not a 100% solution, but you can select the option to remember the queue that you are placing a call on behalf of. You still need to do it manually for the first call, but after that...

HTH

We were looking for a way to make it easier for users that primarily place outbound calls.  It seems that if a user is only a member of a single queue, it should default to that queue rather than requiring the user to select a queue for each outbound call.  It is an additional step the users don't have to do in our current system today.

Chad,

Unless I'm missing something here, you wouldn't want that anyway!

The point here is for DID calls to receive the same "treatment" as ACD calls (i.e. Reporting, In-Queue flows, etc.) The numbers will (I assume) still be assigned to the individual users, and not the Queue.

If it was to work the way you suggest, then whose DID would you assign to the Queue for outbound calls?

David's reply does, however, pose another question. If I have a user that is a member of 2 "Direct Routed" queues, both of which have an In-Queue flow assigned, how will you control which flow gets executed?

If a user only has the "Direct Routing" queue assigned to them, will that queue be selected automatically when the user places an outbound call, or do they still need to manually choose the "Direct Routing" queue to place an outbound call on behalf of a queue?

Awesome to hear!  Yes, we are adding features for each of voice, SMS, and email which will send DR users' assigned contact info on outbound interactions.

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

Chad,

Unless I'm missing something here, you wouldn't want that anyway!

The point here is for DID calls to receive the same "treatment" as ACD calls (i.e. Reporting, In-Queue flows, etc.) The numbers will (I assume) still be assigned to the individual users, and not the Queue.

If it was to work the way you suggest, then whose DID would you assign to the Queue for outbound calls?

David's reply does, however, pose another question. If I have a user that is a member of 2 "Direct Routed" queues, both of which have an In-Queue flow assigned, how will you control which flow gets executed?

If a user only has the "Direct Routing" queue assigned to them, will that queue be selected automatically when the user places an outbound call, or do they still need to manually choose the "Direct Routing" queue to place an outbound call on behalf of a queue?

Awesome to hear!  Yes, we are adding features for each of voice, SMS, and email which will send DR users' assigned contact info on outbound interactions.

We have a few "Sales account managers" who I think could take advantage of this. However, will the agent be able to make an outbound call on behalf of the queue with their assigned phone number?

Thanks to everyone who has applied for the beta so far - great to see so much interest!  We have delayed the beta start for a number of weeks and will be in touch to those who have applied when we have more details.  Watch this space.

Thanks to everyone who has applied for the beta so far - great to see so much interest!  We have delayed the beta start for a number of weeks and will be in touch to those who have applied when we have more details.  Watch this space.

Hi all - thanks for your patience on this one.

Due to some adjustments based on feedback and competing priorities, the updated target date for this beta launch is 20^th September 2023.  As we had almost 50 organisations apply for the beta, we'll unfortunately not be able to accommodate all in the beta release.  We'll reach out to those candidates we can accommodate in the weeks before the beta start, and add them to the beta community.

More details to follow.

Thanks to everyone who has applied for the beta so far - great to see so much interest!  We have delayed the beta start for a number of weeks and will be in touch to those who have applied when we have more details.  Watch this space.

One of the features of Direct Routing will be the ability for a user to define backup options, in case they're not available.  The interaction (email, SMS or Callback) can be transferred to the backup immediately (on alerting timeout), or after some configurable period.  

We'd like to get your input on how you'd see this backup working.

At the moment we're considering two options:

Option 1

• User (or Admin) defines a single backup option
• Can be a Queue or another User
• If a User's backup is another User (say, User2), and User2 also isn't available, go to User2's backup option
• Constraint: A backup user's backup has to be a Queue
• This is to prevent never-ending chains of backup users

Option 2

• User (or Admin) defines a primary and secondary backup option
• Primary backup can be a Queue or another User
• If primary backup is a Queue – no secondary backup
• If primary backup is another User (say, User2), and User2 isn't available, go to first Users secondary backup
• Secondary backup is always a Queue

In both cases, there should be no more than two 'levels' of backup.

Any comments on these options are appreciated.

Hi all - thanks for your patience on this one.

Due to some adjustments based on feedback and competing priorities, the updated target date for this beta launch is 20^th September 2023.  As we had almost 50 organisations apply for the beta, we'll unfortunately not be able to accommodate all in the beta release.  We'll reach out to those candidates we can accommodate in the weeks before the beta start, and add them to the beta community.

More details to follow.

Thanks to everyone who has applied for the beta so far - great to see so much interest!  We have delayed the beta start for a number of weeks and will be in touch to those who have applied when we have more details.  Watch this space.

One of the features of Direct Routing will be the ability for a user to define backup options, in case they're not available.  The interaction (email, SMS or Callback) can be transferred to the backup immediately (on alerting timeout), or after some configurable period.  

We'd like to get your input on how you'd see this backup working.

At the moment we're considering two options:

Option 1

• User (or Admin) defines a single backup option
• Can be a Queue or another User
• If a User's backup is another User (say, User2), and User2 also isn't available, go to User2's backup option
• Constraint: A backup user's backup has to be a Queue
• This is to prevent never-ending chains of backup users

Option 2

• User (or Admin) defines a primary and secondary backup option
• Primary backup can be a Queue or another User
• If primary backup is a Queue – no secondary backup
• If primary backup is another User (say, User2), and User2 isn't available, go to first Users secondary backup
• Secondary backup is always a Queue

In both cases, there should be no more than two 'levels' of backup.

Any comments on these options are appreciated.

Hi all - thanks for your patience on this one.

Due to some adjustments based on feedback and competing priorities, the updated target date for this beta launch is 20^th September 2023.  As we had almost 50 organisations apply for the beta, we'll unfortunately not be able to accommodate all in the beta release.  We'll reach out to those candidates we can accommodate in the weeks before the beta start, and add them to the beta community.

More details to follow.

Thanks to everyone who has applied for the beta so far - great to see so much interest!  We have delayed the beta start for a number of weeks and will be in touch to those who have applied when we have more details.  Watch this space.