Русский
Русский
English
Статистика
Реклама

Call-центр

Как продолжительность смены и число одновременно обслуживаемых проектов влияют на время обработки контакта?

16.11.2020 22:16:56 | Автор: admin

Если вы задавались вопросами производительности труда операторов и управления средним временем обработки контакта (Average Handling Time, AHT), то материал, который вы сейчас читаете, точно для вас.

Сразу оговоримся, что эта статья не является полноценным исследованием и не охватывает все причины, которые могут повлиять на скорость обработки звонков (например, за рамками остался любимый вопрос автора о Speech Transmission Index (STI), индексе отвлекающих факторов в операторском зале). Она фиксирует зависимости, знание которых поможет вам выжать еще несколько килограммов эффективности при планировании ресурсов КЦ.

Мы выдвинули 2 гипотезы относительно среднего времени AHT:

  • 1. При условно-постоянной нагрузке на операторов AHT должно увеличиваться в течение смены из-за накапливающейся усталости сотрудников.

  • 2. Если подключать операторам несколько проектов (линии с разными тематиками), AHT тоже будет расти из-за того, что переключения между задачами требуют дополнительных усилий, а значит дополнительного отдыха. Возможно, по сравнению с ситуацией, когда операторы обслуживают монопроекты, разговоры затянутся за счет условно-незаметных пауз и меньшей скорости их работы в инфосистеме КЦ.

Чтобы проверить гипотезы, мы решили провести натурный эксперимент. Главной сложностью было найти контакт-центр с относительно стабильными параметрами:

  • Операторский состав не меняется

  • Маркетинговых активностей нет

  • Изменения в сценарии разговоров и интерфейсы автоматизированного рабочего места оператора не вносятся

  • Нагрузка на контакт-центр (Workload) в пределах запланированной

Оказалось, что найти КЦ, в котором эти условия соблюдаются одновременно, довольно сложно. Тем не менее, это удалось сделать. Нам любезно предоставили площадку и операторский пул.

Условия для для проверки гипотезы 1:

Проверка длилась 3 рабочих дня. Мы отобрали 13 операторов с минимальным разбросом AHT по конкретной темтике и подключили им единственный проект. На время эксперимента мы попросили операторов минимизировать время перерывов или постараться перенести их на конец дня (ни один сотрудник не пострадал, неудобства всем компенсировали). Если в течение смены требовались дополнительные операторы для обслуживания пиковой нагрузки, то они приходили на работу в нужное время (то есть были свеженькими). А после того, как необходимость в них отпадала, переводились на другие проекты и не возвращались обратно.

Количество поступивших к операторам звонков (по науке называется Volume):

Мы построили график AHT (черная линия) и время обработки по каждму оператору (тонкие синие кривые). 19 мая картина получилась такой:

Не важно, когда начинается смена, AHT растет примерно одинаково. Красные графики время обработки контакта операторами, которые начинали работу позже 8 утра:

На всякий случай мы посмотрели как выглядит динамика коэффициента загрузки операторов Occupancy:

В оставшиеся два дня эксперимента 20 и 21 мая ситуация практически не менялась. Итоги:

  1. Гипотеза о том, что AHT растет в течение смены, подтвердилась. Распространять этот вывод на все проекты в любых контакт-центрах неверно, при этом на него можно опираться в дальнейших исследованиях.

  2. Прирост AHT может быть больше 15-16%, зависит от конкретных условий, типа и содержания проекта, а также от индивидуальных особенностей операторов. На самом деле, бывает и 40%+.

  3. Динамику AHT в течение смены следует учитывать при планировании ресурсов. Если рассчитывать потребность в операторах по среднему, есть риск, что к концу смены персонала не хватит.

  4. Вероятно, пока Occupancy не относительно высок (<=75%) загрузка операторов не влияет на производительность и труда.

  5. Каждый оператор устает по-своему, с разной скоростью.

  6. Если не все операторы подключаются к обслуживанию проекта сразу в начале смены, это влияет на AHT.

  7. Интересно изучать динмику AHT по интервалам времени, когда в линии одинаковое количество людей:

Проверка гипотезы 2.При подключении операторам дополнительных проектов, время обработки контакта должно увеливаться быстрее, чем если бы они обслуживали только один проект.

В проверке гипотезы 1участвовала только одна группа операторов. Ребята знали несколько проектов, поэтому мы решили подключить им второй проект и посмотреть, что получится. Операторы, которые в рамках эксперимента сначала обслуживали только второй проект, тоже вошли в объединенную группу:

В следующий вторник (26.05) после первого эксперимента мы замеряли время среднее время обработки контактов на двух проектах по отдельности. А еще через неделю (02.06) объединили группы и посмотрели, что получится. При этом на обоих проектах мы выставили целевой Service Level одинаковым 80% вызовов должны были быть приняты за 15 сек (на втором проекте цель изначально была чуть мягче 80\20).

Итоги:

  1. Гипотеза 2 подтвердилась. AHT при объединении групп операторов в течение смены растет еще быстрее, чем в каждой группе по отдельности.

  2. Партнерский контакт-центр не предоставил нам возможности провести исследование для подключения операторам более чем двух проектов. Это потребовало бы существенного перепланирования графиков работы операторов. Однако у нас есть основания предполагать, что чем больше проектов одновременно обслуживает один человек, тем быстрее растет уже не AHT, аскорость ростаAHT.

  3. Эффект от объединения групп тоже нужно учитывать при планировании ресурсов.

  4. При подключении операторам нескольких проектов в потенциале может возникнуть ситуация, когда из-за роста AHT объединение групп не позволит сократить число сотрудников на линии.

Дмитрий Галкин, независимый консультант по вопросам создания и управления контакт-центрами Специально для Omniline.

Подробнее..

Главное хвост о порочности усредненных значений

25.11.2020 12:06:49 | Автор: admin

Если голова в крематории, а ноги в морге, то информация о средней температуре по больнице не информативна. Аналогично, если олигарх ест мясо, а тракторист капусту, это не значит, что в среднем они едят голубцы. Практика управления контакт-центром по средним значениям показателей не очень хороша.

Пусть контакт-центр обслуживает входящие звонки, которые поступают на номер 8-800. Руководитель отслеживает среднюю скорость ответа (Average Speed of Answer, ASA).

В первом и втором случае звонки поступают в очередь ожидания, но характер наполнения очереди разный: неравномерный и равномерный:

Если смотреть только на среднее, то можно не заметить рост длины очереди, понести необоснованные расходы на 8-800 и/или потерять часть клиентов, не готовых ждать долго. При этом значения ASA вполне могут оказаться в пределах целевого коридора, как в примере.

Кстати, в e-commerce, где время перезвона по клиентской заявке часто критично для конверсии, руководители контакт-центров не уделяют этому вниманияи не смотрят одновременно на ASA и суммарное время ожидания. А клиенты переключаются на конкурентные предложения и количество чеков за период становится меньше.

Есть разные способы отловить ситуацию. Вариант 1 рассмотрели:

Вариант 2, с помощью часто используемого индикатора Service Level. Я не очень люблю им пользоваться, но это вопрос личных предпочтений.

Мне больше нравится вариант 3, учитывающий хвост Service Level, т.н. SL Tail. Хотя показатель редкий и в стандартах его нет.

Удобство в том, что можно измерять одновременно несколько хвостов для разных предельно допустимых времен ожидания. Тогда можно на гистограмму распределения вызовов по Waiting Time не смотреть: несколько чисел сразу показывают, какие доли от общего объема контактов ждут больше 1,2,3.минут. Соответственно, место на мониторе освобождается от громоздкого графика. Выглядит он, кстати, примерно так:

Аналогично с FCR долей вопросов, решенных с первого раза и его двоюродной сестрой FLR (долей вопросов, решенных на первой линии). У FCR тоже есть хвост вопросы, потребовавшие больше чем N обращений. В целом, у значимых для бизнес-процессов индикаторов очень желательно измерять хвосты, это переводит управляемость контакт-центра как системы на новый уровень, а для руководителя делает ситуацию более прозрачной.

Еще момент. Математически правильно вместо среднего арифметического использовать медиану, если результат процесса не подчиняется нормальному (гауссову) распределению, иначе получится ситуация с олигархом, трактористом и огурцами. Медиана простыми словами это число, которое занимает среднее положение в отсортированном списке (на картинке ниже медиана в первом случае равна 76, а во втором 90):

Здесь при одинаковых средних медианы разные, доступность контакт-центра различается. Во втором случае половина вызовов ждала больше 90 секунд и это бы легко понять, не залезая в детализацию звонков. Единственная проблема в том, что одной медианы недостаточно, чтобы аналитик мог увидеть разброс данных, а это характеристика качества менеджмента. Да требовать от среднестатистического супервайзера разбираться в медианах и дисперсиях кажется не очень хорошей идеей. Хвосты легко воспринимаются и понимаются даже слабо подготовленным руководителем.

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

Дмитрий Галкин, независимый консультант по вопросам создания и управления контакт-центрами Специально для Omniline.

Подробнее..

Новая версия 3CX v18 Alpha и дорожная карта развития 3CX на 2021 год

11.03.2021 16:14:30 | Автор: admin
Новая версия 3CX v18 Alpha выходит одновременно с дорожной картой развития этой коммуникационной платформы.



Стратегия 3CX создание и развитие коммуникационной системы для бизнеса будущего. 3CX эволюционирует в многофункциональную систему связи. Сейчас телефонный звонок уже не является приоритетным способом коммуникации с бизнесом. Клиенты задают вопросы в виджете чата на сайте, на странице компании в Facebook и через SMS. Использовать традиционные разрозненные способы связи неудобно ни клиентам, ни сотрудникам компании.

Оставаться на связи сразу по нескольким каналам довольно неудобно. А объединенная отчетность по коммуникациям с клиентом практически невозможна. Кроме того, компания должна приобретать различное ПО или оборудование для каждого канала коммуникаций.

С точки зрения клиента, разрозненные каналы коммуникаций неудобны, потому что он каждый раз общается с разными сотрудниками. Часто чат на сайте или в мессенджере нужно перевести в голосовой режим, чтобы уточнить подробности. Но перевод клиента в колл-центр, к другим операторам, часто сбивает с толку и уводит от покупки, или просто затягивает решение вопроса, не говоря уже о том, что при современной конкуренции бизнес должен бороться за качество обслуживания и лояльность каждого покупателя.

3CX v18 это коммуникационная система для бизнеса будущего, которая соединяет бизнес и клиентов через одно эффективное, простое и доступное решение. Связь внутри компании по-прежнему важна, но залог успеха сотрудников лояльные клиенты.

Расскажем о новинках в 3CX v18 Alpha.

Ядро 3CX v18


Разработчики 3CX значительно улучшили ядро системы: теперь платформа оптимизирована для новой ОС, которая войдет в ISO образ 3CX. Для этого сделано несколько важных доработок, касающихся совместимости и надежности:

  • 3CX ISO теперь основан на Debian 10 (Buster);
  • системы v16 будут беспрепятственно обновлены на Debian 10;
  • сервис 3CX Tunnel объединен с сервисом Media server: потребление памяти уменьшено примерно на 20%, улучшены качество связи, время и стабильность подключения (еще не протестировано в Alpha-версии и требует обновления приложений);
  • улучшено согласование SDP (Renegotiation): установлена лучшая совместимость с различными операторами, исправлены нечастые ситуации, приводящие к односторонней слышимости, повышена точность отчетов, появилась возможность записи только внутренних / внешних вызовов;
  • записи IPv6 DNS (AAAA);
  • различные исправления в отчетах о вызовах;
  • новый сервис Gateway Service, который будет отвечать за интеграцию со сторонними системами (и поддерживать REST API 3CX).

Установка и управление


SSO (Single Sign On) в веб-клиенте и интерфейсе управления 3CX.

Caller ID в формате E164 все Caller ID теперь могут быть преобразованы в единый формат E164.

Audit Log журналирование изменений в конфигурации системы (что, когда и кем).
Сервис DNS Helper устраняет необходимость отдельно указывать локальный и публичный IP-адреса. Это упрощает подключение к системе, поскольку не требует разной конфигурации веб-клиента и мобильных приложений для работы в локальной сети / удаленно. Одновременно этот сервис упрощает перенос системы в облако.

Удаленная установка IP-АТС или SBC на устройства Raspberry PI. Теперь можно отправить чистое устройство клиенту и инициализировать его удаленно. Также для настройки 3CX не нужны клавиатура и монитор.

Возможности колл-центра


В соответствии с тем, каким 3CX видит будущее бизнес-коммуникаций, компания прилагает много усилий, чтобы улучшить чат Live Chat для размещения на сайтах, а также интеграцию с мессенджерами.

Улучшенный виджет чата Live Chat: различные темы, оптимизация алгоритма сбора контактных данных клиента (имени и e-mail), различные режимы отображения на сайте, увеличение возможностей кастомизации виджета. Также реализована поддержка Google RCS (SMS 2.0).

Интегрированный портал Webmeeting


Портал видеоконференций Webmeeting будет объединен с системой 3CX:

  • вся информация о конференциях теперь хранится локально и полностью конфиденциальна;
  • унификация URL click2call и click2meet;
  • в дальнейшем можно будет использовать публичные или собственные MCU;
  • улучшен сервис голосового звонка в конференцию.

Встроенная техподдержка


3CX будет включать новый интерфейс техподдержки, который позволит быстро решать проблемы клиентов. Операторы смогут открывать запросы в техподдержку в процессе звонка или чата. Система может работать с e-mail службы поддержки партнера для эффективного отслеживания и решения запросов пользователей. Для обслуживания 3CX теперь не требуется отдельная хелпдеск-система партнер экономит на лицензиях и обучении.

image

Реализация пожеланий с Форума идей 3CX


Топ-10 пожеланий пользователей 3CX не остались без внимания!

Уже реализовано в 3CX Alpha:

  • возможность пропуска приветствия голосовой почты;
  • вызов сотрудника по имени или фамилии (ранее было только по фамилии);
  • импорт фото сотрудников из Office 365;
  • скрытие служебных номеров (IVR и пр.) из адресной книги 3CX.

Планируется в релизе или Update 1/2:

  • планирование повторяющихся аудиоконференций по расписанию;
  • отчет журнал количества одновременных вызовов в IP-АТС для планирования лицензии;
  • планирование конференций из плагина для Outlook;
  • индикация рабочих / нерабочих часов IP-АТС в приложении 3CX или расширении Chrome.

Обсуждаемые новые функции:

  • несколько адресных книг для разных отделов компании;
  • более детальное делегирование прав доступа к системе.

Подробный журнал изменений
Подробнее..

CRM в контакт-центре как создать единое окно для оператора

25.03.2021 18:04:40 | Автор: admin
Наша компания по роду деятельности обычно рассматривает работу контакт-центров со стороны организации телефонной связи. Однако даже более важный вопрос их работы это требования к единой системе (сервис-деску), которая способна заменить сразу несколько приложений в работе оператора колл-центра.

Каждый контакт-центр (КЦ) ежедневно сталкивается с двумя сложными задачами, вытекающими из самой деятельности этих подразделений.

Первая это управление КЦ. При высокой текучке необходимость постоянно нанимать и обучать новых сотрудников отнимает очень много времени. И в 90% случаев причина проблемы кроется в большом количестве приложений, необходимых для работы оператора и содержащих информацию о клиенте (статус заказа, товары в корзине, счета и пр.). Как правило, каждое приложение имеет свой алгоритм работы (с инструкциями на бумажных распечатках и в методичках).

Вторая задача необходимость дать клиенту максимально полный сервис за максимально короткое время. Хотя зачастую время ожидания невелико от нескольких секунд до минуты простой расчет показывает, что суммарные потери времени в пересчете на весь КЦ могут быть ощутимыми.

Рассмотрим небольшой КЦ (до 50 операторов). На каждом клике оператор теряет доли секунды. Перемножив количество операторов, количество обращений, количество кликов, получим несколько человеко-дней, которые были потрачены на поиск информации и на ожидание ответа системы. За это время КЦ мог бы оказать услуги десяткам и сотням клиентов. Именно поэтому количество кликов должно быть минимальным, а скорость реакции максимальной.

Решение обеих проблем использование единой системы, сервис-деска, вместо большого количества разных приложений.

image

Как это сделать?

Единый сервис-деск должен обеспечивать три основных параметра:

  • функциональность;
  • безопасность;
  • юзабилити.

Функциональность


Нужно определить, что именно и в каких приложениях делает оператор при работе с клиентом, затем собрать их в единую систему и выстроить функциональный дизайн.

Что это значит? Отменить заказ и изменить заказ кардинально разные функции, которые могут задействовать разные приложения. Отмена заказа, изменение даты доставки это работа со статусом заказа. А что делать, если нужно заменить товар в заказе? То есть нужно из системы, где заказы обрабатываются (а это может быть и несколько приложений, например, логистика, склад) получить данные о том, что вообще есть на складе и на что можно поменять уже зарезервированный товар.

В этом случае задействованы:

  • данные клиента;
  • информация о статусе заказа;
  • каталог.

Если вся эта информация содержится в разных приложениях, переключение с одного на другое это дополнительные клики и время.

Что делать?

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

Все полученные данные формируют единое рабочее место оператора. Оно может также содержать элементы скриптов, чек-лист диалога и пр.

Юзабилити и безопасность


Когда собран весь функционал и разработана архитектура интеграции систем, можно переходить к юзабилити и безопасности.

Юзабилити это критически важный фактор в работе сервис-десков КЦ. Минимум кликов должен обеспечивать максимальный результат, а интерфейс должен быть интуитивно понятен.

Для этого нужно проработать каждый отдельный юзер-кейс. Сложность в том, что надо одновременно решить две противоположных задачи: с одной стороны, следует дать максимальный набор функций оператору, с другой стороны, если нагружать приложение кнопками, оно становится не юзабельным (что ведет к потере времени и снижению уровня сервиса).

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

Далее безопасность. Вопрос безопасности возникает неизбежно, так как работа с персональными данными требует соблюдения законодательства.

Основное требование службы безопасности запретить хранение важной информации в фронтовых системах, к которым оператор имеет конечный доступ.

Сервис-деск-платформы и CRM для контакт-центров могут быть самыми разными. Например, компания Omniline, которая помогла нам написать этот текст, предлагает решение Creatio, которое. Как только поступает звонок, система автоматически идентифицирует его по номеру и подтягивает в рабочий интерфейс оператора всю доступную на данный момент информацию об этом клиенте. Все происходит за секунды, и в момент соединения клиента с оператором у КЦ уже есть все необходимые данные.

Когда оператор заканчивает работу по обращению, в системе не остается никаких лишних данных, кроме информации о самом звонке, о типе обращения, о затраченном времени. Это позволяет компании собирать аналитические данные о работе КЦ для дальнейшей оптимизации бизнес-процессов.

image

Перечисленные положения и требования к организации рабочих мест операторов справедливы для любых CRM-систем и сервис-деск-платформ, которые используются в КЦ. При этом со стороны организации телефонной связи может использоваться также любая платформа, отвечающая требованиям КЦ и имеющая возможности для интеграции с CRM. Например, мы компания АйПиМатика поставляем программную коммуникационную платформу 3СХ от кипрских разработчиков.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru