Проектирование Омниканального контакт-центра

О заказчике:

Telescop corp, которая разрабатывала для авиакомпании AirAstana омниканальный контакт-центр. 
Я выступал в качестве проектировщика интерфейса. 

 

О проекте:

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

Технического задания на старте не было. Срок ставился в 6 дней.
Заказчик предоставил наброски прототипов уже существующего решения для понимания сути сервиса (ниже часть прототипов)

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

После того как было составлено Техническое Задание по которому уже можно было приступить к работе, срок проекта согласовали в 1 календарный месяц и 80 тыс. руб с оплатой понедельно.

Я решил что на данном этапе хватит подобного ТЗ и так как сервис очень большой получается, лучше переходя от раздела к разделу детально уточнять ТЗ этого раздела. Эта хороший способ быстро приступить к реализации и не парить мозг заказчику, но важно заранее заложить дополнительный срок на реализацию 20-50% от первоначального. 

Я этого не сделал, в итоге работал больше месяца по ставке в 1,5 раза ниже обычной чтобы выполнить свои обязательства. Поэтому все следующие проекты я буду начинать только с детально прописанного ТЗ по каждому разделу, функции, ограничению для каждой “роли” (админ/клиент/сотрудник)

Цели и задачи:

Ключевая проблема авиакомпании AirAstana которую нужно было решить – это неэффективность службы поддержки, которая компенсируется большим числом менеджеров (повышенными расходами)

У авиакомпании AirAstana миллионы клиентов по всему миру и все они обращаются в контакт центр разными способами: звонят, пишут через онлайн-чат на сайте, мобильное приложение, через социальные сети вконтакте, facebook, мессенеджеры telegram, whatsapp, viber.

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

Основная цель бизнеса проектирования омниканального контакт-центра – сократить расходы на штат службы поддержки 

 
Как этого добиться:
 
1. Повысить эффективность сотрудников, сократив ненужные рутинные действия 
Добиться этого за счет омниканальности (когда все сообщения клиентов приходят в одно единственное окошко менеджеру) и системы шаблонных быстрых ответов
 
2. Перенести на чат-ботов все повторные вопросы и сценарии разговоров
Для того нужен конструктор чат-ботов с функцией обучения сотрудникам. 
В идеале придти к тому что бы менеджерам занимались только уникальными нетипичными вопросами, и обучали чат-ботов.
 
3. Подробная статистика по работе каждого сотрудника и каналов
Для того чтобы не держать в штате тунеядцев, тех кто плохо обслуживает клиентов и оперативно реагировать на сбои каналов
 
4. Единая база клиентов, сотрудников
О которых можно все посмотреть – когда и с кем общались, через какие каналы. В любой момент связаться – написать по любому каналу или позвонить, заблокировать, сделать рассылку, отправить смс и тд.
 
5. Записи всех разговоров, истории переписок и хранилище данных
Чтобы быстро в любой момент времени найти нужный файл, забытую тему или какие-то важные данные из разговора с клиентом.

Этап 1. Погружение в тему омниканальности и бизнеса клиента

– Какую выгоду она дает бизнесу
– Какие есть решения на рынке
– Кто и как их разрабатывает
– Какие сложности с внедрением
– Кто уже внедрил и какой результат

– кем и когда основана
– цели, миссия, ценности компании
– какое место на рынке занимается, какую долю
– сколько сотрудников в компании, отзывы о работе в ней
– парк самолетов
– куда летают, какое обслуживание
– сильные и слабые стороны компании
– независимые отзывы о компании
– планы компании на будущее

Этап 2. Краткая проработка ролей пользователей в системе, их целей, задач

Основная проблема этого проекта – что у заказчика времени было на проектирование в 20 раз меньше чем требовалось и прорабатывать сценарии использования, контекст, цели, мотивацию и тд просто не было времени. 

Администратор

Роман Богдашкин

Основные задачи в сервисе:

1) Видеть насколько эффективно работает каждый сотрудник в компании чтобы найти и уволить бездельников

2) Иметь статистику по всем абонентам, эффективности работы сотрудников для отчетности 

3) Контролировать стабильность работы всех систем, настраивать взаимодействие

4) Понять на что больше всего уходит времени менеджеров и сократить это время за счет чат-ботов, тем самым снизив расходы на з/п менеджеров

Супервайзер

Бекнияз Ахметов

Основные задачи в сервисе:

1) Контролировать работу своей группы менеджеров

2) Если менеджер не может ответить на вопрос клиента, то помочь ему подключившись к разговору/чату

3) Общение в групповом чате с командой менеджеров

4) Оптимизация работы менеджеров за счет быстрых ответов и чат-ботов

Менеджер

Маргарита Михалевич

Основные задачи в сервисе:

1) За минимальное количество времени дать полноценный ответ клиенту, решив его вопрос

2) Обслужить как можно больше клиентов

3) Общение в групповом чате с командой менеджеров

4) Обучение чат-ботов

Сотрудник

Елена Никитина

Основные задачи в сервисе:

1) Общение с командой

Этап 3. Анализ конкурентов, подборка лучших интерфейсных решений. 

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

Сложность этого этапа заключалась в том, что в одном сервисе, который я проектировал объединено несколько сервисов (рассылки/чат-боты/онлайн-чаты/хранилище данных и тд) и по каждому такому сервису есть 10-15 конкурентов. 
То есть пришлось анализировать интерфейсы порядка 120-150 сервисов как на российском рынке, так и на западном. 
Это заняло довольно много времени, которого и так не хватало. 

Этап 4. Информационная архитектура сервиса 

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

Меню по умолчанию – свернутое
1) Так как ширину экрана определили небольшой в 992px, то по умолчанию меню делаем свернутым чтобы на экране умещалось максимум данных. При необходимости меню можно развернуть. Контент при этом сжимается.
2) Вторая причина – это то, что сотрудники будут работать в веб-сервисе ежедневно и быстро запомнят иконки. А по ним быстрее найти нужный раздел, чем раскрывать меню и искать по тексту.

 

Фильтры без кнопок “Применить”

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

Раздел “Статистика”

Раздел статистики дает полную прозрачность работы каждого сотрудника, канала. Это позволяет находить самых неэффективных сотрудников (уволить при необходимости и сократить расходы). Либо выявить причины почему долго обслуживается тот или иной канал.

Раздел разрабатывался исходя из потребностей администраторов и супервайзеров, выгод для бизнеса.

Для удобства весь раздел разбит на 4 составляющих (табы):
– каналы
– супервайзеры
– менеджеры
– клиенты

Раздел “Клиенты”

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

Раздел “Команда”

Основная цель – быстро найти сотрудника и связаться с ним

Раздел “Чаты”

Главное требование – чтобы все чаты, как клиентские, так и командные были в одном окне. 
При этом необходимо, чтобы все функции по переписке (добавление файлов, записи голосовых сообщений, быстрые ответы), созвоны (аудио, видео), информации о пользователе, история обращений и действиях (отправить смс, заблокировать), поиск по чатам и внутри переписки были в одном единственном окне. 

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

Это окно переделывалось и дорабатывалось несколько раз практически с нуля. Итоговый вариант вы видите ниже

Раздел “Записи звонков”

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

Раздел “Каналы”

Этот раздел необходим только администраторам для отслеживания работоспособности каналов, настройки.
 

Раздел “Автоуведомления”

Этот раздел необходим для повышения сервиса и заботы о клиентах в зависимости от их местанахождения.

Например если клиент подъезжает к аэропорту и у него сегодня рейс – приходит смс с номером стойки регистрации его рейса. 

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

Раздел “Чат-боты”

Этот раздел поможет сильно разгрузить менеджеров сняв с них всю рутинную работу с повторяющимися вопросами и сценариями. 

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

Еще один важным требованием было сделать возможность обучения чат-ботов сотрудниками как в отдельном окне, так прямо из интерфейса окна чата с клиентом.

Раздел “Центр уведомлений”

Данный раздел необходим только администраторам для отслеживания работоспособности всех систем и оперативного реагирования на возникающие проблемы

В системе администратор указывает при каких сбоях, какие сообщения, кому и когда отправляются.

Раздел “Хранилище данных”

В этом разделе можно найти любой файл который загрузил клиент или коллега. При большом потоке клиентов хранить и находить все у себя на компьютере сложно. А здесь с помощью фильтра это можно сделать за пару кликов

Раздел “Рассылки”

Рассылки позволяют сократить рутинные действия на отправку писем, смс и сделать все быстрее, красивее и проще. 

Основная задача была – сделать простой удобный пошаговый способ сборки и отправления писем, где минимизируется риск отправить письма не тем людям, не то письмо.

В итоге разработано 350+ макетов только для роли “администратор”