Genesys Cloud - Main

 View Only

Discussion Thread View
Back to discussions
Expand all | Collapse all

Customer first Callback pacing modifier calculation is not clear

  • 1.  Customer first Callback pacing modifier calculation is not clear

    Posted 02-02-2025 06:00

    Hello friends.

    According to the Documentation of Customer first Callback, it's not clear enough what is the pace of dialing per Agents:

    Customer first callbacks overview - Genesys Cloud Resource Center

    It says:

    "The pacing modifier does not consider the status of the agent, for example, idle or interacting. If an agent is in available status in the queue, then Genesys Cloud multiplies the calculated coefficient by the online agent count."

    1st interpretation:

    It can be interpreted in few ways, I can say "Genesys Cloud multiplies the calculated coefficient by the online agent count.",

    It means that any Online Agent that is a member of this queue is in the calculation, even if the Agent is not in OnQueue status,

    2nd interpretation:

    Alternatively, it can be interpreted as follow: "The pacing modifier does not consider the status of the agent; for example, idle or interacting"

    The system doesn't care if the Agent is in Idle or Interacting as long as the Agent is OnQueue,

    And with this interpretation the Agent must be in OnQueue status in order to be part of the calculation (even if he is not Idle).

    Reality:

    In reality, it's behaved exactly like regular queue routing!:

    In reality, when i did a check, the system only dial for Idle Agents

    I've set the Pacing Modifier to 10 = 1 call per Agent.

    When I was in Interacting\Communicating Status, the system didn't dial, at the moment I changed to Idle, the system Dial instantly.

    So, what is it?, how does the pacing is calculated exactly?, does anybody knows?

    Thanks in advance 🙏


    #Implementation
    #Outbound
    #PlatformAdministration
    #Routing(ACD/IVR)
    #SystemAdministration

    ------------------------------
    Shahar Leonard
    Genesys Cloud Professional Certified
    ------------------------------


  • 2.  RE: Customer first Callback pacing modifier calculation is not clear

    Posted 02-02-2025 14:59

    I have found the documentation for this one to be less helpful as well, for me this line "If you set the pacing modifier to the maximum of 10, then Genesys Cloud dispatches one callback per agent. If you set the pacing to the minimum of one, you must have 50 agents on-queue for Genesys Cloud to dispatch a callback."

    So a queue with 49 agents and this set to 1 will never get a call, why 50? If is set it to 2, do I need 25 agents minimum, 40, or just 1? Just give me the formulae or a table or something so I can make an informed decision on the value I'm selecting.



    ------------------------------
    Anton Vroon
    ------------------------------

    Original Message


  • 3.  RE: Customer first Callback pacing modifier calculation is not clear

    Posted 02-02-2025 15:51

    Hey Anton.

    My understanding is that yes, if you set the Pacing Modifier to 1 and you have 49 Agents available, so not even one callback will dial.

    By the way, i let ChatGPT to run the calculations and this is the exact Calls per Agent in each point, from 1 to 10:

    https://chatgpt.com/share/67054972-6b0c-8005-ae7d-b476fc5f2c38

    Best regards,



    ------------------------------
    Shahar Leonard
    Genesys Cloud Professional Certified
    ------------------------------

    Original Message


  • 4.  RE: Customer first Callback pacing modifier calculation is not clear

    Posted 02-02-2025 15:58
    Edited by Anton Vroon 02-02-2025 16:00

    Thanks Shahar, your link however doesn't work for me:

    Not sure how you are getting any AI to run the calculations without knowing what to calculate, I haven't seen a formulae shared anywhere for how it is calculated.

    Unless you are running hundreds of tests at each setting with different amounts of agents logged in to the queue and then feeding that in to the AI?

    EDIT: Took some doing, got the link working. I mean this is a good guestimate figuring out based on 2 data points, but maybe it isn't linear, we just don't know, which is more my point, documentation really needs to be better for something like this.



    ------------------------------
    Anton Vroon
    ------------------------------

    Original Message


  • 5.  RE: Customer first Callback pacing modifier calculation is not clear

    Posted 02-03-2025 05:23

    Hi,
    I have seen the pace values to translate to approx.:

    1. Min. ~50 agents,
    2. Min. 35-40 agents,
    3. Min. 20-25 agents,
    4. Min. 10-15 agents,
    5. - 6. Min. 5-10 agents,

          7. - 9. Min 2-5 agents,
          10. - Min 1 agent

    I assume we don´t publish it yet in the docs bc we have just recently released the feature and these values are subject to slight adjustments based on the feedback we get. But maybe @Rini Rajan can share more.



    ------------------------------
    Georgy Rudnev
    Technical Account Manager
    ------------------------------

    Original Message


  • 6.  RE: Customer first Callback pacing modifier calculation is not clear

    Posted 02-03-2025 12:33
    Edited by Shahar Leonard 02-03-2025 12:45

    After more thoughts and tests, I think I understand the exact behavior now.

    And it's as follow:

    There is two processes.
     
    Dialing process - Its a dumb process that dials for every Idle Agent
    Pacing Modifier - this process is enforcing extra regulation and constrains on the dumb Dialing Process
     
    When the the Documentation says "The pacing modifier does not consider the status of the agent", 
    It means that the Pacing Modifier doesn't care if the Agent is in a call or not,
    But the Dialing process definitely consider if the Agent is in call or not
    The number of Agents in Onqueue status is in the consideration only of the Pacing Modifier, and the number of Idle Agent is only in the Considerations of the Dialing Process

    It doesn't matter if there is 1000 Agent in OnQueue Status, as long as these 1000 Agents are not Idle, not even one Callback will be dialed.

    In any case, the system will not dial more than the number of Idle Agents in the respective Queue.

    Generally, the system dialing as per as the number of Idle Agents in the respective Queue, but only within the constrains forced by the Pacing Modifier, 

    Scenarios:

    If the Pacing Modifier is set to 1 (most restrictive), and there is 55 Onqueue Agents, and 50 of the 55 Agents are Idle, 

    There is 50 Idle Agents, so the system wants to dial 50 Callbacks, but the Pacing Modifier acting as Party Destroyer that stops the system from dialing.

    The system will dial only one Callback, because of the Pacing Modifier Constrains, that allows only one call per 50 OnQueue Agents.

    On the other hand, if the scenario is the same, but the Pacing Modifier is set to 10 (most permissive), so, the constrains of Pacing Modifier are much less restrictive.

    There is 50 Idle Agents, so the system wants to dial 50 Callbacks, and the Pacing Modifier acting as an Observer that watch the situation.

    In this scenario, there is not restrictions at all, as long as the Agent is Idle (of course he is OnQueue) the system will dial for him.

    To summaries:

    The System always dials as per as Idle Agents in queue, and the Pacing Modifier acting as a Party Destroyer, in range of 1 to 10

    When 1 is the worst kind Party Destroyer, and 10 is the Observer who couldn't care less.

    That's my understanding according to the tests I did,

    The documentation in this specific regard acts as an Enigma that can be unlock only by testing.

    Please correct me if I misunderstood.

    Best regards,



    ------------------------------
    Shahar Leonard
    Genesys Cloud Professional Certified
    ------------------------------

    Original Message


  • 7.  RE: Customer first Callback pacing modifier calculation is not clear

    Posted 02-03-2025 15:28

    Interesting,

    What happens if agent's are not idle. Eg you have 50 callbacks in queue, 1000 agents on queue, but there is a constant stream of inbound calls resulting in no agent being idle.

    When agent goes available and gets the next call will it still in that brief window dial the customer, assuming the callback is the next longest waiting interaction?



    ------------------------------
    Anton Vroon
    ------------------------------

    Original Message


  • 8.  RE: Customer first Callback pacing modifier calculation is not clear

    Posted 02-04-2025 02:34

    My understanding that the Callback treated like the inbound calls exactly, if the callback has the highest priority in the current waiting calls, it will be dial.

    The priority is combination of priority set in the Architect in the flow, and the time that the Interaction is waiting on the queue.

    Shortly, it's just like inbound call, its waiting on the queue, just without the customer on the line

    Best regards, Shahar.



    ------------------------------
    Shahar Leonard
    Genesys Cloud Professional Certified
    ------------------------------

    Original Message


  • 9.  RE: Customer first Callback pacing modifier calculation is not clear

    Posted 02-03-2025 15:30

    After more thoughts and tests, I think I understand the exact behavior now.

    And it's as follow:

    1st, it doesn't matter if there is 1000 Agent in OnQueue Status, as long as these 1000 Agents are not Idle, not even one Callback will be dialed.

    In any case, the system will not dial more than the number of Idle Agents in the respective Queue.

    Generally, the system dialing as per as the number of Idle Agents in the respective Queue, but only within the constrains forced by the Pacing Modifier, 

    What do i mean by that?

    If the Pacing Modifier is set to 1 (most restrictive), and there is 55 Onqueue Agents, and 50 of the 55 Agents are Idle, 

    There is 50 Idle Agents, so the system wants to dial 50 Callbacks, but the Pacing Modifier acting as Party Pooper that stops the system from dialing.

    The system will dial only one Callback, because of the Pacing Modifier Constrains, that allows only one call per 50 OnQueue Agents.

    On the other hand, if the scenario is the same, but the Pacing Modifier is set to 10 (most permissive), so, the constrains of Pacing Modifier are much less restrictive.

    There is 50 Idle Agents, so the system wants to dial 50 Callbacks, and the Pacing Modifier acting as an Observer that watch the situation.

    In this scenario, there is not restrictions at all, as long as the Agent is Idle (of course he is OnQueue) the system will dial for him.

    To summaries:

    The System always dials as per as Idle Agents in queue, and the Pacing Modifier acting as a Party Pooper, in range of 1 to 10

    When 1 is the worst kind Party Pooper, and 10 is the Observer who couldn't care less.

    That's my understanding according to the tests I did,

    The documentation in this specific regard acts as an Enigma that can be unlock only by testing.

    Please correct me if I misunderstood.

    Best regards,



    ------------------------------
    Shahar Leonard
    Genesys Cloud Professional Certified
    ------------------------------

    Original Message


  • 10.  RE: Customer first Callback pacing modifier calculation is not clear

    Posted 02-13-2025 21:41

    Can I apply the concepts discussed in this thread to a practical example of a busy queue.  If my understanding is incorrect, hopefully someone with CFCB experience or someone from Genesys will correct me.

    I am assuming that the Dialing process is triggered by a change of agent state or queue state, when an agent on the queue becomes idle, this seems to be our experience in testing.  So, in a busy queue where there are waiting calls, there is only ever likely to be one idle agent when the Dialing process is triggered.

    First, some made up definitions
    real waiting calls - non-CB calls waiting in the queue
    callback calls - callback calls in the queue that have not been called yet
    real callback calls - callback calls that have been called and are now in the queue with high priority

    So example 1.
    40 agents on queue
    20 real waiting calls
    20 callback calls
    0 real callback calls
    pacing modifier = 10

    The first two callback calls have been waiting longer than any real waiting calls. There are no idle agents.  An agent finishes a call and becomes idle. How many callbacks are launched ?
    From the previous discussion it seems the answer would be one, since there is only one idle agent at that time.  Presumably the idle agent would immediately be allocated a real waiting call, since there are no real callback calls.  The launched callback would then eventually become a real callback call, and would then be the next call answered.

    So example 2.
    40 agents on queue
    20 real waiting calls
    20 callback calls
    0 real callback calls
    pacing modifier = 4

    The first two callback calls have been waiting longer than any real calls. There are no idle agents.  An agent finishes a call and becomes idle. How many callbacks are launched ?
    From the previous discussion it seems the answer would still be one, since there is only one idle agent.  Again the idle agent would immediately be allocated a real waiting call, since there are no real callback calls.  The launched callback would then eventually become a real callback call, and would then be the next call answered.

    So example 3.
    40 agents on queue
    20 real waiting calls
    20 callback calls
    0 real callback calls
    pacing modifier = 1

    The first two callback calls have been waiting longer than any real calls. There are no idle agents.  An agent finishes a call and becomes idle. How many callbacks are launched ?
    From the previous discussion it seems the answer would be none, in fact callbacks would never be launched because there is not enough agents on queue. So there is a big risk that callbacks are left uncalled if the number of on-queue agents drop at the end of a shift.

    Some observations, assuming my assumptions are correct.  
    There doesn't seem to be much difference between pacing modifier 10 and 4 for a busy queue, but going too low could be disastrous.
    Busy queues are what callbacks are useful for, and we find that when the wait time is long the majority of callers choose a callback, so the number of callback calls far exceeds the number of real waiting calls.  This leads to example 4

    40 agents on queue
    0 real waiting calls
    20 callback calls
    0 real callback calls
    pacing modifier = 10

    There are no idle agents.  An agent finishes a call and becomes idle. How many callbacks are launched ? From the previous discussion it seems the answer would still be one. Does the agent then wait for the callback call to be processed and get back into the queue?



    ------------------------------
    Murray Silvester
    Development consultant
    ------------------------------

    Original Message


  • 11.  RE: Customer first Callback pacing modifier calculation is not clear
    Best Answer

    Posted 5 days ago

    Hey everyone,

    Thank you for all your feedback and discussions on the Customer-First Callback Pacing Modifier. We understand that our previous documentation may not have been as clear as it should have been. To improve clarity, we've revamped the pacing modifier section here https://help.mypurecloud.com/articles/customer-first-callbacks-overview/, to make the calculation more straightforward.

    We appreciate your input and hope this update makes things clearer!



    ------------------------------
    Rini Rajan
    Staff Cloud Product Manager
    Genesys - Employees
    ------------------------------

    Original Message


Need Help finding something?

Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources