Genesys Cloud - Main

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

Hi Chris,

Follow-up question, I have callback-blueprint and did not see anything mentioned on scheduled callback. Is scheduled callback possible with callback-blueprint?

https://developer.genesys.cloud/blueprints/automated-callback-blueprint/

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

Vincent - are you asking if there is an option for the customer to select a specific date and time to recieve the callback or if we offer the ability for agents to schedule callbacks to customers?

The former, I think, can be addressed by crafting a flow to grab the information but I don't honestly know (I'll check around).  The latter is part of the agent UI.

I'll follow-up but let me know the specifics of what you are referring to.

Thanks,
Chris

Hi Chris,

Follow-up question, I have callback-blueprint and did not see anything mentioned on scheduled callback. Is scheduled callback possible with callback-blueprint?

https://developer.genesys.cloud/blueprints/automated-callback-blueprint/

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.

Hi Chris,

Is there a way for supervisors to identify agents who are "camped out" after responding to a callback but before clicking "end callback"? We are trying to minimize this behavior, but in the views I can see, it looks like the agent is actually on a call.

Thanks!

1. Genesys offers 'in-queue' callbacks -meaning callers may be offered the opportunity to receive a callback and not lose their place in queue if configured in the IVR.  These callbacks are reported as a distinct media type as Jeff points out above.
2. As the next agent becomes available, Genesys Cloud will push a callback interaction to the agent for them to accept or decline.  Assuming they accept it - the next thing the agent will need to do is click a button to launch the outbound call to the customer. 
   1. This can have some unintended consequences however.  Agents can use the time to just camp out and not take any other interactions before they launch the callback - this is something supervisors should be aware of to ensure agent productivity.
   2. After the callback has ended, the agent then needs to hit the 'end callback' button - this again is a place where they can sit and do nothing (either intentionally or unintentionally!)  Again, something for supervisors to be aware of.
3. Overall, these in-queue callbacks really force the agent to make the call at the appropriate time to deliver the best customer experience to the customer.  
4. We've also recently published a 'callbacks blueprint' which works a bit differently than our in-queue callbacks.  We still offer the caller the ability to recieve a callback, but we use some flow techniques to create an OUTBOUND dialer record that uses the current estimated wait time value to automatically launch a call back to the customer at the appropriate time.  
   1. In this instance, the customer receives an automated message asking them if they are ready for their callback or if they need to reschedule.
   2. If they choose to accept the callback, Genesys pushes an INBOUND call back into the queue with a high priority to push it to the top of the queue to be answered next.
5. In this blueprint - we no longer track the callback separately and reporting is a bit easier (in my opinion) but requires some filtering (typically on queue name and outbound campaign name) to identify vs. all other calls.