Мы знаем, какие проблемы есть в вашем контакт-центре. Их всего две, но они заставляют вас по-настоящему страдать 😈

Первая — это непосредственно управление КЦ. Высокая текучесть персонала, необходимость постоянно нанимать-обучать новых сотрудников отнимает много времени. А время — это сами знаете что. Причем в 90% случаев причина кроется в куче приложений, с которыми надо работать оператору. Для клиента звонок — это просто звонок. А вот для оператора контакт-центра он превращается в работу с разными приложениями,где содержится информация о человеке “на том конце провода”: статус его заказа, товары в корзине, остатки, счета. 

И вишенка на этом торте: у каждого такого сервиса — своя инструкция. Их десятки — где нажимать и что смотреть. Написанные на бумажках, в иксельках и других отдельных документах. Нет четкого алгоритма работы, есть только раздражающие бумажки и приложения.

haos

Вторая проблема — это необходимость дать клиенту максимально полный сервис за максимально короткое время.  Клиент хочет как можно быстрее решить свой вопрос, а не слушать полчаса заезженную мелодию Баха.

Хотя кажется, какое там время — секунды, иногда доли секунд. Но давайте  посчитаем — мы же за data driven business как-никак. Пусть у вас небольшой контактный центр, где работают 50 операторов. На каждом клике мы теряем доли секунды. А теперь перемножим наше количество операторов, количество обращений, количество кликов. Мы получим несколько человеко-дней, которые были потрачены на поиск информации, на ожидание ответа системы! Несколько человеко-дней, за которые мы могли оказать услуги десяткам и сотням клиентов! Поэтому количество кликов должно быть минимальным, а скорость реакции — максимальной. 

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

Три основных блока, которые нужно рассмотреть в рамках проекта единого сервис-деска:

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

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

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

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

Screenshot_1

Смотрите, сколько всего задействовано:

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

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

Что мы делаем:

  1. Собираем все юзер-кейсы, которые есть у оператора, что конкретно он делает в той или иной ситуации.
  2. Составляем потоки данных: смотрим, как эти юзер-кейсы реализуются разными системами — что куда и откуда передается.
  3. На основании потоков данных создаем архитектуру приложений — как разные системы взаимодействуют между собой, какая интеграция между ними необходима. В этой ситуации надо понимать, что все приложения интегрируется с телефонией и чатами. И это взаимодействие не может быть синхронным, так как многие большие системы — “медленные”, они будут обрабатывать запрос какое-то время. А оператору надо дать ответ здесь и сейчас. Поэтому большой вызов в создании архитектуры заключается в том, что максимальное количество данных собрать за то время, пока идет соединение абонента и оператора. 

Дальше весь этот “конструктор” надо собрать и получить то самое единое рабочее место для оператора. Туда еще могут быть добавлены элементы скриптов, что-то наподобие чек-листа диалога и пр.

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

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

Screenshot_2

Юзабилити критически важный фактор в работе сервис-десков контакт-центра. Должно быть минимум кнопок и максимум результата на каждое действие. А интерфейс – интуитивно понятен. Как достичь удобства пользования? Прорабатываем каждый отдельный пользовательский кейс. Вот пришел звонок по отмене заказа, что дальше делает оператор? Что он видит, что должен нажать, какие его действия. При этом помним, что действий должно быть минимально. Прорабатываем каждый возможный пользовательский кейс и каждый шаг оператора в этом кейсе.

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

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

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

Screenshot_4

Если сжато, то основное требование безопасников — запретить хранение важной информации в фронтовых системах, к которым имеет конечный доступ оператор. Мало того, что живой посторонний человек видит эти данные, так он еще и удаленно работает и кто знает, что он там сделает с этими данными: перепишет или заскриншотит и в каких целях использует.

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

Это, кстати, вечная война между безопасниками и клиентским отделом: можно показывать оператору имя или нет? Сразу скажем, мы принимаем сторону победившего, с технической точки зрения нам нет разницы. Процесс сбора информации должен занимать секунды. Мы руководствуемся золотым стандартом: 80/20: 80% звонков должны быть отвечены за 20 секунд. 

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

Саммари

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

Хотите получать полезный контент и быть в курсе последних событий

Подписывайтесь 😉

Recommended Posts