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

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

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

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

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

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

image

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

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

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

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


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

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

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

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

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

Что делать?

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

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

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


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

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

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

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

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

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

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

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

image

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