Наша компания по роду деятельности обычно рассматривает работу контакт-центров со стороны организации телефонной связи. Однако даже более важный вопрос их работы — это требования к единой системе (сервис-деску), которая способна заменить сразу несколько приложений в работе оператора колл-центра.
Каждый контакт-центр (КЦ) ежедневно сталкивается с двумя сложными задачами, вытекающими из самой деятельности этих подразделений.
Первая — это управление КЦ. При высокой «текучке» необходимость постоянно нанимать и обучать новых сотрудников отнимает очень много времени. И в 90% случаев причина проблемы кроется в большом количестве приложений, необходимых для работы оператора и содержащих информацию о клиенте (статус заказа, товары в корзине, счета и пр.). Как правило, каждое приложение имеет свой алгоритм работы (с инструкциями на бумажных распечатках и в методичках).
Вторая задача — необходимость дать клиенту максимально полный сервис за максимально короткое время. Хотя зачастую время ожидания невелико – от нескольких секунд до минуты — простой расчет показывает, что суммарные потери времени в пересчете на весь КЦ могут быть ощутимыми.
Рассмотрим небольшой КЦ (до 50 операторов). На каждом клике оператор теряет доли секунды. Перемножив количество операторов, количество обращений, количество кликов, получим несколько человеко-дней, которые были потрачены на поиск информации и на ожидание ответа системы. За это время КЦ мог бы оказать услуги десяткам и сотням клиентов. Именно поэтому количество кликов должно быть минимальным, а скорость реакции — максимальной.
Решение обеих проблем — использование единой системы, сервис-деска, вместо большого количества разных приложений.
![image](https://habrastorage.org/r/w780q1/webt/cx/qu/z4/cxquz44zrkyn6iyoignkosfk_wo.jpeg)
Как это сделать?
Единый сервис-деск должен обеспечивать три основных параметра:
Нужно определить, что именно и в каких приложениях делает оператор при работе с клиентом, затем собрать их в единую систему и выстроить функциональный дизайн.
Что это значит? Отменить заказ и изменить заказ — кардинально разные функции, которые могут задействовать разные приложения. Отмена заказа, изменение даты доставки — это работа со статусом заказа. А что делать, если нужно заменить товар в заказе? То есть нужно из системы, где заказы обрабатываются (а это может быть и несколько приложений, например, логистика, склад) получить данные о том, что вообще есть на складе и на что можно поменять уже зарезервированный товар.
В этом случае задействованы:
Если вся эта информация содержится в разных приложениях, переключение с одного на другое — это дополнительные клики и время.
Что делать?
Во-первых, собрать все юзер-кейсы, которые есть у оператора (что конкретно он делает в той или иной ситуации). Во-вторых, сопоставить потоки данных (как юзер-кейсы реализуются разными системами, что куда и откуда передается). Наконец, на основании потоков данных создать архитектуру приложений (как разные системы взаимодействуют между собой, какая интеграция между ними необходима). В этой ситуации надо понимать, что все приложения интегрируются с телефонией и чатами. И это взаимодействие не может быть синхронным, так как многие большие системы будут обрабатывать запрос какое-то время. Поэтому самый значимый вызов при создании архитектуры — сбор максимального количества данных за то время, пока идет соединение абонента и оператора.
Все полученные данные формируют единое рабочее место оператора. Оно может также содержать элементы скриптов, чек-лист диалога и пр.
Когда собран весь функционал и разработана архитектура интеграции систем, можно переходить к юзабилити и безопасности.
Юзабилити — это критически важный фактор в работе сервис-десков КЦ. Минимум кликов должен обеспечивать максимальный результат, а интерфейс должен быть интуитивно понятен.
Для этого нужно проработать каждый отдельный юзер-кейс. Сложность в том, что надо одновременно решить две противоположных задачи: с одной стороны, следует дать максимальный набор функций оператору, с другой стороны, если нагружать приложение кнопками, оно становится не юзабельным (что ведет к потере времени и снижению уровня сервиса).
Для проектирования оптимального решения существуют специальные инструменты, разделяющие весь интерфейс на модули, доступные из единой карточки клиента. Так можно добиться баланса между функциональностью и юзабилити.
Далее — безопасность. Вопрос безопасности возникает неизбежно, так как работа с персональными данными требует соблюдения законодательства.
Основное требование службы безопасности — запретить хранение важной информации в фронтовых системах, к которым оператор имеет конечный доступ.
Сервис-деск-платформы и CRM для контакт-центров могут быть самыми разными. Например, компания Omniline, которая помогла нам написать этот текст, предлагает решение Creatio, которое. Как только поступает звонок, система автоматически идентифицирует его по номеру и подтягивает в рабочий интерфейс оператора всю доступную на данный момент информацию об этом клиенте. Все происходит за секунды, и в момент соединения клиента с оператором у КЦ уже есть все необходимые данные.
Когда оператор заканчивает работу по обращению, в системе не остается никаких лишних данных, кроме информации о самом звонке, о типе обращения, о затраченном времени. Это позволяет компании собирать аналитические данные о работе КЦ для дальнейшей оптимизации бизнес-процессов.
![image](https://habrastorage.org/r/w1560/webt/hc/ed/bx/hcedbxdklxrdoqlpfobhpdqfqwa.png)
Перечисленные положения и требования к организации рабочих мест операторов справедливы для любых CRM-систем и сервис-деск-платформ, которые используются в КЦ. При этом со стороны организации телефонной связи может использоваться также любая платформа, отвечающая требованиям КЦ и имеющая возможности для интеграции с CRM. Например, мы — компания «АйПиМатика» — поставляем программную коммуникационную платформу 3СХ от кипрских разработчиков.
Каждый контакт-центр (КЦ) ежедневно сталкивается с двумя сложными задачами, вытекающими из самой деятельности этих подразделений.
Первая — это управление КЦ. При высокой «текучке» необходимость постоянно нанимать и обучать новых сотрудников отнимает очень много времени. И в 90% случаев причина проблемы кроется в большом количестве приложений, необходимых для работы оператора и содержащих информацию о клиенте (статус заказа, товары в корзине, счета и пр.). Как правило, каждое приложение имеет свой алгоритм работы (с инструкциями на бумажных распечатках и в методичках).
Вторая задача — необходимость дать клиенту максимально полный сервис за максимально короткое время. Хотя зачастую время ожидания невелико – от нескольких секунд до минуты — простой расчет показывает, что суммарные потери времени в пересчете на весь КЦ могут быть ощутимыми.
Рассмотрим небольшой КЦ (до 50 операторов). На каждом клике оператор теряет доли секунды. Перемножив количество операторов, количество обращений, количество кликов, получим несколько человеко-дней, которые были потрачены на поиск информации и на ожидание ответа системы. За это время КЦ мог бы оказать услуги десяткам и сотням клиентов. Именно поэтому количество кликов должно быть минимальным, а скорость реакции — максимальной.
Решение обеих проблем — использование единой системы, сервис-деска, вместо большого количества разных приложений.
![image](https://habrastorage.org/webt/cx/qu/z4/cxquz44zrkyn6iyoignkosfk_wo.jpeg)
Как это сделать?
Единый сервис-деск должен обеспечивать три основных параметра:
- функциональность;
- безопасность;
- юзабилити.
Функциональность
Нужно определить, что именно и в каких приложениях делает оператор при работе с клиентом, затем собрать их в единую систему и выстроить функциональный дизайн.
Что это значит? Отменить заказ и изменить заказ — кардинально разные функции, которые могут задействовать разные приложения. Отмена заказа, изменение даты доставки — это работа со статусом заказа. А что делать, если нужно заменить товар в заказе? То есть нужно из системы, где заказы обрабатываются (а это может быть и несколько приложений, например, логистика, склад) получить данные о том, что вообще есть на складе и на что можно поменять уже зарезервированный товар.
В этом случае задействованы:
- данные клиента;
- информация о статусе заказа;
- каталог.
Если вся эта информация содержится в разных приложениях, переключение с одного на другое — это дополнительные клики и время.
Что делать?
Во-первых, собрать все юзер-кейсы, которые есть у оператора (что конкретно он делает в той или иной ситуации). Во-вторых, сопоставить потоки данных (как юзер-кейсы реализуются разными системами, что куда и откуда передается). Наконец, на основании потоков данных создать архитектуру приложений (как разные системы взаимодействуют между собой, какая интеграция между ними необходима). В этой ситуации надо понимать, что все приложения интегрируются с телефонией и чатами. И это взаимодействие не может быть синхронным, так как многие большие системы будут обрабатывать запрос какое-то время. Поэтому самый значимый вызов при создании архитектуры — сбор максимального количества данных за то время, пока идет соединение абонента и оператора.
Все полученные данные формируют единое рабочее место оператора. Оно может также содержать элементы скриптов, чек-лист диалога и пр.
Юзабилити и безопасность
Когда собран весь функционал и разработана архитектура интеграции систем, можно переходить к юзабилити и безопасности.
Юзабилити — это критически важный фактор в работе сервис-десков КЦ. Минимум кликов должен обеспечивать максимальный результат, а интерфейс должен быть интуитивно понятен.
Для этого нужно проработать каждый отдельный юзер-кейс. Сложность в том, что надо одновременно решить две противоположных задачи: с одной стороны, следует дать максимальный набор функций оператору, с другой стороны, если нагружать приложение кнопками, оно становится не юзабельным (что ведет к потере времени и снижению уровня сервиса).
Для проектирования оптимального решения существуют специальные инструменты, разделяющие весь интерфейс на модули, доступные из единой карточки клиента. Так можно добиться баланса между функциональностью и юзабилити.
Далее — безопасность. Вопрос безопасности возникает неизбежно, так как работа с персональными данными требует соблюдения законодательства.
Основное требование службы безопасности — запретить хранение важной информации в фронтовых системах, к которым оператор имеет конечный доступ.
Сервис-деск-платформы и CRM для контакт-центров могут быть самыми разными. Например, компания Omniline, которая помогла нам написать этот текст, предлагает решение Creatio, которое. Как только поступает звонок, система автоматически идентифицирует его по номеру и подтягивает в рабочий интерфейс оператора всю доступную на данный момент информацию об этом клиенте. Все происходит за секунды, и в момент соединения клиента с оператором у КЦ уже есть все необходимые данные.
Когда оператор заканчивает работу по обращению, в системе не остается никаких лишних данных, кроме информации о самом звонке, о типе обращения, о затраченном времени. Это позволяет компании собирать аналитические данные о работе КЦ для дальнейшей оптимизации бизнес-процессов.
![image](https://habrastorage.org/webt/hc/ed/bx/hcedbxdklxrdoqlpfobhpdqfqwa.png)
Перечисленные положения и требования к организации рабочих мест операторов справедливы для любых CRM-систем и сервис-деск-платформ, которые используются в КЦ. При этом со стороны организации телефонной связи может использоваться также любая платформа, отвечающая требованиям КЦ и имеющая возможности для интеграции с CRM. Например, мы — компания «АйПиМатика» — поставляем программную коммуникационную платформу 3СХ от кипрских разработчиков.