Предположим, в очереди стоят три вызова от трех разных кате­горий клиентов: № 1, № 2 и № 3. Первый вызов ждет в очереди 20 секунд, второй — 25 секунд и третий — 10 секунд. Освобождает­ся оператор. Какой вызов ему поступит?

Без использования логики «Адвоката», конечно же, в первую очередь будет обслужен вызов N° 2. Причина: вызов № 2 наиболее долгое время провел в очереди в ожидании обслуживания.

Теперь давайте посмотрим, что произойдет с вызовами, если мы используем маршрутизацию на основе прогнозируемого времени ожидания.

Предположим, что если освободившийся оператор не возь­мет данный вызов, то клиент № 1 прождет еще 40 секунд, № 2 — 5 секунд и jq 3 — 35 секунд. Таким образом, для первого вызова PWT составит 20 + 40 = 60 секунд, для второго 25 + 5 = 30 секунд и для третьего 10 + 35 = 45 секунд.

Понятно, что в этом случае к оператору поступит вызов № 1, поскольку у него наибольшее прогнозируемое время ожидания, то есть он будет ждать дольше всех, если освободившийся опе­ратор на него не ответит.

А теперь давайте назначим для каждого вызова желаемое вре­мя ответа и в каждом случае определим коэффициент отклоне­ния прогнозируемого времени ожидания от желаемого времени ответа. Для вызова № 1 Service Objective составит 60 : 35 = 1,71, для вызова № 2 — 30 : 20 = 1,5 и для вызова № 3 — 45 : 25 = 1,8.

В результате выбирается вызов (№ 3) с наибольшим отклоне­нием прогнозируемого времени ожидания от желаемого времени ответа. То есть, несмотря на то, что текущее время ожидания у вы­бранного вызова № 3 самое маленькое (10 секунд), этот вызов бу­дет обслужен в первую очередь. Никогда бы не пришло в голову, правда?

Видите, как разные подходы к маршрутизации изменяют саму логику обслуживания вызовов?