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:
Sent: 02-03-2025 12:27
From: Shahar Leonard
Subject: Customer first Callback pacing modifier calculation is not clear
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
------------------------------