PCCE Outbound Dialer — отчет о деталях вызовов

[ln33147]

Уважаемые коллеги!
Это касается среды PCCE, версия 12.6(2).
Мы успешно настроили исходящий дозвонщик, и он работает надлежащим образом. В
настоящее время мы работаем над отчетом для отображения сведений о вызовах исходящего дозвонщика, включая имя агента, внутренний номер, номер вызываемого абонента и продолжительность вызова.
Мы основали наш запрос ниже на таблице Dialer_Detail; однако возвращаемые значения продолжительности вызова неточны по сравнению с продолжительностью в системе записи вызовов, которая содержит точные данные. SELECT
D.DateTime,
CONCAT(P.FirstName, ' ', P.LastName) AS AgentName,
D.CallDuration,
D.PreviewTime,
D.PickupTime,
D.ReservationCallDuration,
P.LoginName AS HRMS,
D.Phone AS CalledNumber,
D.CallResult,
D.AgentPeripheralNumber AS Extension
FROM
Dialer_Detail D WITH (NOLOCK),
test_awdb.dbo.Agent A WITH (NOLOCK),
test_awdb.dbo.Person P WITH (NOLOCK)
WHERE
D.AgentPeripheralNumber = A.PeripheralNumber
AND P.PersonID = A.PersonID
AND A.SkillTargetID IN (:agent_list)
AND D.DateTime BETWEEN :start_date AND :end_date Мы также попробовали удалить «ReservationCallDuration» и «PreviewTime», но данные по-прежнему были неточными. Есть какие-нибудь советы? Заранее спасибо.

[ln33147]

Привет, Билл, Я не смог выяснить причину несоответствия. Время звонка отсутствует, так как клиент использует функцию автоответа. Я также попробовал вычесть PreviewTime и AgentReservationTime, но данные по-прежнему не совпадали с данными системы записи.
Однако, когда я использовал поле Duration из таблицы TCD, все данные совпали идеально.
Я привел ниже запрос на случай, если кто-то еще столкнется с подобной проблемой в будущем. SELECT CONVERT(VARCHAR, DATEADD(SECOND, T.TalkTime, 0), 108) AS TalkTime, D.DateTime, CONCAT(P.FirstName, ' ', P.LastName) AS AgentName, P.LoginName AS HRMS, D.Phone AS CalledNumber, D.Номер периферийного устройства агента AS Дополнительный номер FROM Dialer_Detail D WITH (NOLOCK), test_awdb.dbo.Agent A WITH (NOLOCK), test_awdb.dbo.Person P WITH (NOLOCK), Termination_Call_Detail T WITH (NOLOCK) WHERE D.AgentPeripheralNumber = A.PeripheralNumber AND P.PersonID = A.PersonID AND A.SkillTargetID IN (:agent_list) И D.ДатаВремя МЕЖДУ :дата_начала И :дата_окончания И D.RouterCallKeyDay = T.RouterCallKeyDay И D.Ключ вызова маршрутизатора = T.Ключ вызова маршрутизатора

[bill.king1]

Я предполагаю, что вы используете кампанию на основе агентов, верно?
Когда вы говорите, что время не совпадает, можете ли вы пояснить, что вы имеете в виду? Например, система записи звонков показывает большее время по сравнению с UCCE или наоборот? Возможно ли, что время, указанное в деталях набора номера, включает время, необходимое для фактического набора номера клиента? Вы
пробовали проверить, остается ли это поведение неизменным при переходе на другой тип кампании на основе агентов (например, прогрессивная против предварительного просмотра и т. д.)?

[ln33147]

Привет, Билл,
да, это предварительная кампания на основе агентов.
Мы заметили, что продолжительность звонков в Cisco больше, чем то, что мы видим в системе записи.
Мы уже вычли PreviewTime и AgentReservationTime из значения CallDuration, но полученная продолжительность все равно больше и не совпадает с данными системы записи.
Мы еще не тестировали это с другими режимами набора номера, но можем попробовать. Я просто хотел подтвердить, что эта таблица должна отражать точную продолжительность разговора между агентом и клиентом.

[bill.king1]

Это происходит постоянно?
Например, что происходит, если вы делаете это с тестовым пользователем, всегда ли это занимает одинаковое количество времени (например, всегда на 10 секунд больше)?
Может ли это быть, например, время набора номера/звонка агентом?

[ln33147]

Привет, Билл, Это не одно и то же время. Я смог решить эту проблему, используя TalkTime из таблицы Termination_Call_Detail, и теперь она совпадает с системой записи.

[bill.king1]

Если вы измеряли время вручную, смогли ли вы определить, в чем заключалась проблема (например, время звонка клиенту и т. д.)?
Рад, что вам удалось решить эту проблему.