Automated Call Blending

Agents who are logged into an Outbound campaign, and are also members of one or more queues for one or more Inbound campaigns, will be automatically assigned to an Outbound or Inbound campaign based on inbound demand. The message flow for blended agent movement is the same as agent movement for Campaign Chaining.

Blending is achieved by Softdial CallGem™ making decisions on whether and when to move agents between outbound and Inbound campaigns.

Group membership provides the basis to determine which agents are candidates for moving between outbound and inbound. The Group Membership [GM] message can and should be sent for agents whenever they log on to any Outbound campaign. The campaign an agent logs on to is determined as their 'home' campaign. If an agent is moved to another campaign to service workload, they will be moved back to their home campaign as demand permits.

In a multiple inbound queue blending scenario, the priority of servicing queues is based on the following values set in the Queue Configuration dialogue (see Queues):

• from V10.2 - Service Level Agreement (SLA)
• pre-V10.2 - Queue priority relative to other queues in the campaign

In a queue shortage situation, the agent that is selected to be moved from Outbound to Inbound for blend is not made with any regard to fairness or quotas and nor should it be. Agent selection for blend has to be on the basis of which is the agent that is most likely to be released the most quickly without major impact on outbound pacing. Compromising this will lead to a blending solution with sub-optimum performance which is why there are no configuration options to modify these rules.

The rules for prioritising blend agent selection are as follows:

Each agent on an Outbound campaign that may be moved to service inbound demand will be in a specific state (e.g. waiting, talking, wrapping up) and will have been in that state for a period of time.

This information is used to determine which agent should be selected for move, and results in the following priorities:

Priority	Agent state	If there are multiple agents in this state...
1	Waiting, without reservation (i.e. not on a callback or abandon retry, reserved for blend or going unavailable)	Select the agent who has been in a waiting state for the shortest amount of time. The rationale behind this is that Predictive queues are generally FIFO. An agent waiting for a long time will be the first to be offered a connected predictive call. By selecting an agent waiting for the shortest time, we give the best chance of predictive pacing not becoming unbalanced.
2	Wrapping without callbacks queued for that agent (and is not reserved for blend or going unavailable)	Select the agent who has been in a wrapping state for the shortest amount of time. An agent that has been in wrap for a short amount of time is statistically more likely to finish the transaction quickly than an agent who has been in wrap for 20 seconds or so. Agents on long wraps are likely to be documenting a call resolution (e.g. a sale or a customer service action that requires documenting). An agent 2 seconds into wrap is far more likely to be marking a call as answer machine or unable to engage respondent.
3	In any other ACD state, where the agent has no callbacks queued (and is not reserved for blend or going unavailable)	Select the agent who has been in this state for the shortest amount of time. An agent that has been in talking for a long time on outbound is processing a sale call, commitment, research survey and is likely to be on the call for longer than somebody talking for a short time, or previewing a call, or waiting reserved for a callback to answer. Again, best performance is served by delivering the agent talking or reserved for the shortest amount of time.
4	Wrapping with callbacks queued(but is not reserved for blend or going unavailable)	Select the agent who has been in a wrapping state for the shortest amount of time. Reasoning is as no. 2, but statistically, there is no value in picking one over another. By the time we get to 4th choices, the best hope is that another agent cycles through one of the first 3 choice states.
5	In any other ACD state, with callbacks queued (but is not reserved for blend or going unavailable)	Select the agent who has been in this state for the shortest amount of time. Reasoning is as no. 3, but statistically, there is no value in picking one over another. By the time we get to 5th choices, the best hope is that another agent cycles through one of the first 4 choice states.

In the event that an agent moves into a waiting state (1st choice) and there are other agents with active reservations, the reservation is switched to the newly-waiting agent and the original agent reserved for blend carries on processing outbound transactions.

The registry key DetailBlendLogging (type REG_DWORD) has been added to provide detailed logging of the blend decision.

Possible values are:

• 0 - off (default if not set)
• 1 - on

From V10.6.547 - blending now has higher precedence than callbacks by default. In addition, if there is a choice of agents to select for blend, the system will select an agent without callbacks in preference to one with callbacks. In the event that an agent with callbacks is subject to blend, the callbacks are returned planned not made (CA32 by default).

The registry option CallbackTrumpsBlend (type REG_DWORD) (which is static and system-wide) allows users to set callbacks to have a higher precedence than blending. This will result in the system favouring selection of agents without callbacks.

Possible values are:

• 0 - off (default if not set)
• Any non-zero value - on