CRM система – обращения от клиентов

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

Проблемы

1. Идентификация клиента
2. Верификация клиента
3. Постоянное перенаправление обращения между отделами
4. Нарушение сроков реализации обращения
5. Ошибки в ответе по обращению или отсутствие ответа
6. Контроль руководителей ответственных по обращению
7. Отсутствие контроля качества

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

Систематизация

Первым шагам мы провели общий анализ 100 000 обращений за 3 месяца, а также подробный выборочный анализ 500 обращений. С первого взгляда показалось, что почти все обращения уникальны и придумать решение этих проблем явно будет не из простых. Но по прошествии небольшого времени мы смогли выявить зависимость.

В компании оказывались как платные услуги, так и бесплатные, которые должны были выполнятся согласно заключенному ранее договору с клиентом. Мы решили разделить все обращения на 15 типов, которые в свою очередь подразделялись на несколько категорий и 2 направления. Наименование данных типов и категории не так существенно для понимания этой статьи. А вот направления важны. Это и есть признак платности.

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

• Новое
• Регистрация
• Формирование заказа (В случае платной заявки)
• Оплата заказа (В случае платной заявки)
• В работе или На доработке
• Приемка выполнения работ
• Подготовка ответа
• Выполнено или Отменено

Тут необходимо остановится на каждой стадии подробнее.

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

Регистрация – этап для регистрации клиента. Происходит автоматический выбор сотрудников ответственных по данному обращению, наблюдателей, контролеров по сроку и редакторов.

В работе или На доработке – обращение на данном этапе переходит в работу к первому, главному, ответственному лицу.

Приемка выполнения работ – ответственное лицо 1 проверяет реализацию обращения и согласовывает завершение работы по обращению.

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

Выполнено или Отменено – финальный статус обращения.

Кроме стадий были также определены разные роли, которые уже были упомянуты выше. Роли нужны были для универсальной работы со всеми обращениями. Например, в обращениях по выполнению перерасчетов участвует руководитель расчетно-абонентского отдела, а в обращениях по предоставлению скидки – руководитель отдела по работе с клиентами. Разные должности, разное время и объем работы – сложно анализировать и автоматизировать. Но что, если мы обозначим их по-другому – ответственное лицо. Теперь понимать гораздо легче – 2 обращения – 2 ответственных лица. Уже не важно какие должности они занимают для отчетности и аналитики.

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

Автоматизация

Вернемся к списку наших проблем. Первые две проблемы – это идентификация и верификация клиента. Для правильного решения необходимо вести стандартизированную базу клиентов с привязкой к уникальному идентификатору. Именно таким идентификатором мы выбрали номер телефона. Теперь при создании нового обращения мы могли получить всю информацию о клиенте, потому что телефон клиента – это уникальный обязательный реквизит, на основе которого в обращение автоматически подгружается вся информация. Но как понять, что клиент именно тот, за кого себя выдает? Тут и появляется необходимость в верификации. Мы ввели не одну характеристику, а несколько и основной при поиске клиента стал «подтвержденный» номер телефона. О том как мы собирали базу и выбирали ответственных лиц, которым позволено подтверждать телефон – расскажем в одной из следующих статей. Сейчас скажем просто, что для верификации мы использовали именно это поле – подтвержденный телефон.

После решения данной проблемы переходим к следующей – постоянное перенаправление клиента между отделами. Такое может происходить по разным причинами: банальное непонимание процесса ответственным лицом, отсутствие времени или желания в реализации обращения и так далее. Важны не причины, а следствие. Данный пинг-понг грозит зависанием обращения и клиент просто не получит обратной связи. На основе анализа предыдущих обращений мы выявили, что 70% обращений решаются в рамках одного отдела, 25% в рамках двух отделов и только 5% обращений требуют взаимодействия 3 и более отделов.

Как вы уже, наверное, поняли – мы ввели роли. Основными ролями по обращению стали:

• Ответственное лицо 1
• Исполнитель 1
• Ответственное лицо 2
• Исполнитель 2
• Ответственное лицо 3
• Исполнитель 3

Ответственное лицо и Исполнитель – это участники процесса в рамках одного отдела. Система автоматически назначает Ответственное лицо 1 и Исполнителя 1 согласно заранее определенной матрице маршрутов, о которой написано выше. Именно Ответственное лицо 1 будет нести ответственность за выполнение обращения. В свою очередь мы дали возможность выбирать дополнительный отдел для уточнения информации или запроса каких-либо данных, которые требуют больших прав или полномочий. Эти люди записывались системой в роли Ответственное лицо 2, Исполнитель 2, Ответственное лицо 3 и Исполнитель 3. Таким образом мы смогли минимизировать перенаправление обращения между отделами, так как ответственный по обращению никогда не меняется и полностью отвечает за реализацию.

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

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

Отлично, сроки соблюдены, обращение выполнено и все довольны. Как бы не так. Обязательной задачей стояло, что по каждому обращению должно быть уведомление клиенту о выполнении или отклонении. И тут все кажется очень просто – вот обращение выполнено – отправим Email и все. Но можем ли мы быть уверены, что Email дойдет до клиента? Или дойдет именно туда, куда должен дойти? Тут опять нужна верификация. Да, та самая верификация, которая помогла нам определить клиента. Также как и с номером телефона – у нас появился подтвержденный Email на который мы отправляем результаты реализации обращения. А дальше автоматически проверяем ушло ли письмо от нас и принял ли почтовый сервер клиента данное письмо. Если нет – отправляем повторно, пока не добьемся успеха. На данном этапе у нас возникла роль – Редактор. Это человек, который вычитывает все комментарии участников реализации обращения и формирует официальный ответ, который будет отправлен клиенту всеми доступными способами. О способах отличных от Email письма я расскажу дальше. Изначально мы думали о том, чтобы также типизировать по матрице и ответы, но индивидуальность обращений была настолько велика, что пока эту идею было принято отложить.

Ну, теперь то уж точно все? Почти. Обращение завершено, клиент получил ответ, но как нам понять удовлетворен ли он ответом? Понадобилась еще одна роль – Контролер по качеству. И в этой роли у нас могут быть тысячи, если не десятки тысяч человек. Потому что в данной роли выступает сам клиент. Нам показалось это наиболее правильным решением, ведь никто не знает так точно о нюансах обращения, как сам инициатор этого обращения. На подтвержденный Email вместе с официальным ответом мы приложили ссылку. Перейдя по данной ссылке клиент попадал на специальную веб-форму, на которой он оценивал качество выполнения обращения по 5-бальной шкале, плюс мог написать комментарий относительно выставленной оценки. Далее мы прикладываем оценку и комментарий к обращению и проводим автоматическую аналитику. Если оценка ниже 3-ех, то автоматически создается новое обращение, которое имеет такую же силу, как и любое другое и повторно направляется ответственному лицу. Таким образом каждая негативная оценка обрабатывается и повышается лояльность клиентов к сервису и компании в целом.

Регистратор

Я не зря вынес данную роль в отдельную тему. Эта роль очень важна и о ней стоит рассказывать когда вы уже познакомились с остальной структурой системы. Здесь нужно вернуться к самому началу – инициации обращений. Самая лояльная компания та, которая способна принять обращение любыми каналами связи. Если в вашей компании работает 10 или даже 50 человек – вам не сложно будет обучить всех регистрировать обращения. Но если у вас 100, 200, 500 или даже 1000 сотрудников? И все они взаимодействуют с клиентами, и все могут принять обращения. А что если у вас дополнительно есть контакт-центр, мессенджеры, сотни внутренних Email адресов офисы-филиалы, личный кабинет, мобильные приложения и т.д. Как не запутаться в таком огромном потоке информации и не пропустить не единого обращения? Правильный ответ на данный вопрос – единая точка входа. Мы просто обрезали полномочия на регистрацию обращения всем сотрудникам и перевели все на контакт-центр, а места, которые можно было автоматизировать – автоматизировали. Например, личный кабинет, мобильное приложение и даже Email письмо – теперь регистрируются автоматически, благодаря умной системе определения типа. А благодаря матрице – зная тип обращения мы можем легко определить участников реализации и запустить процесс в работу. Все оффлайн обращения лично или по звонку были переведены на сотрудников контакт-центра, а для них мы максимально упростили функционал регистрации обращения. Для создания нового обращения им требуется заполнить всего 4 поля: выбрать клиента из базы, выбрать тип обращения, заполнить описание обращения и добавить файлы по обращению при наличии. И все, дальше система все сделает сама.

Это, кстати, в продолжении об альтернативных способах ответа клиенту. Точка входа – одна, но способов оповещения клиента о выполненном обращении - несколько. Когда клиент идентифицирован – мы точно знаем какими каналами он пользуется (Email, личный кабинет, мобильное приложение и тд.) и оповещаем его по всем указанными каналам.

Заключение

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

• Анализ текущей ситуации
• Описание вариантов решения
• Адаптация наиболее подходящего варианта
• Реализация
• Тестирование
• Обучение

Категория WEB