Поскольку предыдущие размышления на тему телекома получился несколько затянутыми и обо всех проблемах сразу, для любителей конкретики выделил один из наиболее критичных моментов.
Введение
Наша компания является давним клиентом «Билайн-бизнес» и потребляет практически все коммуникационные сервисы, предлагаемые этим конвергентным оператором: фиксированную и мобильную телефонную связь, Интернет, FMTN, SMS сервис, 8-800. В целом, качество предоставляемых услуг находится на достаточно высоком уровне. Проблемы случаются, но у кого их нет. Далее по тексту некоторые кейсы будут из практики общения с этим оператором, не безупречным, но работающем на достаточно высоком уровне.
По работе мне приходится взаимодействовать с западными и отечественными компаниями по различным вопросам, поэтому опыт в «шкуре» клиента немалый. Отдельные компании (к сожалению, по большей части западные) в плане организации работы с клиентами ушли далеко вперед, по сравнению с остальными. Контактируя с компаниями, которые находятся на начальном уровне организации такой работы невольно задаешься вопросом: «Почему у них всё на столь допотопном уровне?». Ну не могут большинство компаний предложить того пресловутого WoW эффекта о котором писал Тони Шей.
Существует масса технологий как улучшить жизнь клиента, но большинство предпочитает их старательно избегать, видимо, полагая, что минимизируют расходы на поддержку. Хотя, возможно, просто взгляд «замылился», а «размылить» некому. Подходы (инструменты) относительно несложные, но способны вызвать тот самый WoW эффект, который повышает лояльность потребителя компании/бренду.
Бизнес-процесс «as is». Типичный вариант.
Как клиент общается с продавцом сейчас? На 100% не знаю, но предполагаю, судя по результатам. Поскольку мы потребляем много операторских сервисов, периодически по ним возникают вопросы. Чаще всего они появляются, когда поступает интересное конкурентное предложение (ниже цена, выше качество сервиса, другой уровень сервиса, сокращение наших операционных расходов на сопровождение и т.д.), либо возникают проблемы по эксплуатации действующих сервисов (биллинг, финансовые документы, переезды офисов и т.п.).
Менеджеру и сервис-менеджеру отправляется e-mail с запросом. В одном письме может быть несколько запросов, что несколько осложняет жизнь участникам процесса, поскольку кому-то придется не раз прочитать не относящуюся непосредственно к нему информацию. Если менеджер/сервис-менеджер не в состоянии самостоятельно решить вопрос, то на основании письма клиента рассылает e-mail коллегам.
Возможно, в компании имеется некоторая внутренняя система для подачи формализованных запросов, но поскольку немало вопросов остаются без ответа, есть ощущение, что чаще всего используется обычный e-mail. Это достаточно типичный вариант организации внутреннего документооборота, не гарантирующий результат. Лишь слабый уровень конкуренции сохраняет подходы неизменными продолжительное время. Основная проблема — после отправки e-mail коллегам (по сути, не формализованная иерархическая или функциональная эскалация) крайне тяжело ГАРАНТИРОВАТЬ собираемость ответов.
Если же менеджер при получении сообщения сбросил флаг прочтения, а в большинстве почтовых программ это происходит по-умолчанию автоматически, достаточно выделить письмо, то шансов, что он вспомнит о просьбе немного. Если у него десяток клиентов — ещё можно держать в памяти долги, а если их несколько десятков, то шансов упомнить всё немного. Особенно если большую часть рабочего дня он проводит в машине, а почту читает со смартфона на бегу. Продавцы с феноменальной памятью мне пока что не встречались, хотя были те, кто компенсировали этот недостаток продуктивно используя функционал напоминаний в Outlook.
При организации обмена информацией в компании по e-mail руководитель подразделения (любого участвующего в процессе решения задачи клиента) по сути глух и слеп. У него есть лишь иллюзия, что его сотрудники 100% четко отрабатывают запросы клиентов. Он свято верит в это, поскольку клиенты с жалобами напрямую на него не выходили. Проверить действительно ли в подразделении всё так хорошо, как кажется, при такой организации можно одним лишь способом — провести опрос удовлетворенности клиентов. Хотя, даже положительные отзывы не могут выступать гарантией качественной работы подразделения.
Мне не раз приходилось участвовать в подобных опросах. Электронные анкеты были дюже навороченные и наверняка составлялись известными маркетинговыми агентствами (только крупные компании рассылали подобные опросники). Проблема лишь в том, что они вообще не затрагивали проблемных моментов работы. О них просто забыли упомянуть в анкете, да и возможности высказаться в произвольной форме не была предусмотрена, т.к. все вопросы были закрытыми, т.е. только выбор из пунктов. Да даже если бы анкета была составлена верно, всегда ли клиент в состоянии идентифицировать проблему и ответить честно? Ну и что, что ему пришлось несколько раз напоминать менеджеру о своём существовании, ведь в других компаниях ровно такой-же подход к клиенту, а то и хуже.
Бизнес-процесс «to be». Ущербный вариант.
Более продвинутые менеджеры могут использовать в работе механизм поручений (в Outlook), чтобы попытаться гарантировать получение какого-то результата от коллег. Неплохой вариант, но почему-то мне редко приходилось встречать продавцов, готовых 100% все заявки от клиентов пропускать через процедуру назначения поручений (или хотя-бы создавать себе задачи или напоминания), хотя это и не намного сложнее, чем переслать письмо. Большинство людей по натуре ленивы, поэтому лень и выступает двигателем прогресса. Это как в случае с массовым спортом. 🙂 Принудить использовать механизм поручений ой как непросто. Сотрудники должны быть достаточно обучены, нужны регулярные тренинги и, главное, контроль.
Как реализовать контроль в случае с Outlook? Отчасти, это возможно, хотя и затратно. Например, для особо въедливых, как правило, VIP клиентов (вроде меня) заводится специальный почтовый ящик, скажем boring@nnov.beeline.ru, на который клиент отправляет запросы.
ВАЖНО! Отправлять он должен не в персональную почту менеджера, которую тяжело проконтролировать, а именно на этот специальный ящик, доступ к которому будет у нескольких человек.
Чтобы получить гарантированный ответ ему нужно придерживаться простого правила: одно письмо с уникальной темой — один вопрос. Это упрощает группировку писем по теме (например, используя механизм «беседа» в Outlook) и минимизирует сумятицу. Получается, что ещё и клиент должен быть дюже дисциплинированным.
Outlook настраивается на сортировку писем в некоторую папку и, например, задается автоматическое присвоение отметки «к исполнению в это время» и «поместить их в категорию …». Вновь пришедшим заявкам дается красная категория «В работе». Доступ к ящику предоставляется также руководителю менеджера, чтобы он мог контролировать исполнение заявок.
Продавец должен быть вымуштрован, чтобы после исполнения запроса в входящей папке назначать для него другую категорию (зеленую «отработано») или перекладывать в папку «Отработанные». Кроме того он должен быть кристально честным и предельно осторожным дабы намеренно или случайно не удалить пришедший запрос, а если удалил — тут-же вызволить из корзины обратно.
Руководитель тоже должен не ленится и периодически проверять сколько «красных» заявок по таким клиентам осталось у продавца. Если клиентов у продавца немало, руководитель большую часть времени будет только и заниматся, что контролем. Даже если это выборочно делать. Никаких средств группового контроля (получение отчетов) подобного рода Outlook, естественно, не предусматривает.
Продавец должен все запросы коллегам отправлять исключительно через механизм «поручений», дабы хоть как-то контролировать их исполнение. В крайнем случае ставить себе задачу или напоминание проверить на каком этапе застряла заявка.
Если клиент захотел узнать как движется работа по его заявке, он сообщает тему заявки и менеджер начинает выбирать из переписки с сопутствующими службами ответы, чтобы составить вразумительное послание клиенту.
Это процесс на вскидку. В реальности потребуется ещё что-нибудь навернуть, чтобы всё работало более или менее четко. В результате получится, что типовым функционалом Outlook не отделаешься и надо будет писать VB скрипты.
Трудозатраты продавца и его руководителя, да и клиента для организации вышеописанной процедуры лишь в некоторой степени гарантирующей получение клиентом ответа, немалые. Нагрузка возрастает, качество исполнительской дисциплины растет, клиент становится довольнее, но руководитель и продавец вскоре увольняются. 🙂
Бизнес-процесс «to be». Servicedesk.
Рассмотрим реализацию примерно той-же схемы работы, только в более современном (совершенном) варианте.
Достаточно намаявшись с Outlook попробуем воспользоваться Servicedesk системой. Подойдет любая, способная разбирать (парсить) письма приходящие на определенный адрес, раскладывать их по очередям, создавать инциденты, отправлять уведомления заявителю и пр. В общем, если нужно бесплатно и прилично — более чем приемлемый вариант — OpenSource система OTRS. Клиенты системы вполне крупные и уважаемые. Для её работы достаточно простого сервера практически под любой OS где может работать Perl. Систему имеет смысл интегрировать с ActiveDirectory для Single Sign On авторизации агентов.
Итак, для начала создадим очередь «Заявки клиентов» и подочередь «Boring». Предполагается, что в эту очередь будут падать все запросы от клиента Boring. Организовать очереди можно и по другому, например, одну общую для всех клиентов.
Настраиваем правило, согласно которому письма приходящие на e-mail boring@nnov.beeline.ru должны падать в подочередь Boring. На почтовом сервере оператора создается фиктивный e-mail пользователь boring. OTRS будет сам забирать, например, по IMAP/POP3, письма приходящие на этот ящик и укладывать в нужную очередь.
Клиент обрадованный открывшимися возможностями формализованно подавать запросы отправляет e-mail на ящик boring@nnov.beeline.ru. Даже в случае Servicedesk ему лучше следовать правилу: один вопрос — одно письмо. OTRS забирает сообщение, проверяет нет ли в теме номера уже существующей заявки и если он отсутствует, создает новую заявку, присваивает ей номер и вежливо уведомляет о её создании клиента, попутно заметив, что если он надумает что-то добавить к заявке или спросить о чем-то, то должен лишь ответить (replay) на пришедшее письмо, не изменяя его темы.
Менеджер получает уведомление на e-mail/SMS о том, что от его «любимого» 😈 клиента Boring поступила новая заявка и, конечно-же, со всех ног бросатся её исполнять. Прочитав текст вопроса он осознает, что в одиночку ему не справится и нужно привлечь специалистов из нескольких подразделений, скажем, технический департамент и отдел маркетинга. Понимая, что можно сократить время на получение ответа, распараллелив заявку, вместо того, чтобы эскалировать сначала на инженеров, потом на маркетологов, менеджер разделяет заявку на две (split) и назначает ответственных из подразделений инженеров и маркетологов. Менеджер может назначить конкретного сотрудника, либо просто скинуть на соответствующую очередь (группу), чтобы менеджер этой группы сам назначил ответственного за заявку. При разделении заявки он указывает, что будет клиентом для этих заявок, чтобы получать сообщение о закрытии и публичные ответы ответственных.
После разделения создаются две дочерние задачи. На них можно перейти из основной (родительской) задачи, а из дочерних задач можно попасть в родительскую.
Не смотря на то, что менеджер сделал функциональную эскалацию на другие подразделения компании — он продолжает оставаться ответственным за исходную заявку, а его руководитель остается владельцем (если его назначили). Соотвественно, менеджер контролирует исполнение заявки, дожидаясь пока не ответят сотрудники смежных подразделений. Руководитель менеджера контролирует самого менеджера и получает уведомление на e-mail, когда заявка закрывается.
Ответственные сотрудники по двум разделенным задачам отрабатывают свою часть работы. Их контролируют владельцы каждой из разделенных задач, например, руководители соответствующих подразделений. Менеджер клиента может при разделении исходной заявки прописать себя владельцем подзаявок, тогда он сам сможет в полной мере контролировать исполнителей из смежных подразделений. Главное, чтобы прав доступа хватило.
После закрытия дочерних задач ответственными, менеджер клиента получает соответствующее уведомление на e-mail. Ознакомившись с ответами он либо закрывает заявку с автоматическим уведомлением клиенту (текст может вписать свой), либо отправляет ему письмо для уточнения информации.
Сразу отмечу, что в процессе общения агентов они тоже могут обмениваться сообщениями внутри OTRS. По-умолчанию, доступ к ним есть только у агентов и владельца заявки. Если в процессе переписки нужно сделать какое-то сообщение видимым для клиента, при ответе нужно выбрать, что оно публичное.
Менеджер мог избрать и другой, менее контролируемый путь получения ответа. Например, он мог просто эскалировать заявку на более компетентного по заданному вопросу сотрудника, например, своего руководителя (если требуется одобрить что-то), либо инженеров и т.д. сменив ответственного на нужного человека. В этом случает новый ответственный может самостоятельно закрыть заявку и клиент получит соответствующее уведомление. Но в любом случае заявка клиента не «повиснет» у кого-то в e-mail.
Если клиента не устроило как была отработана заявка, он может при получении на e-mail ответа сделать replay и заявка вновь откроется. Руководителю отдела продаж полезно отслеживать количество повторно открытых заявок, поскольку это в некотором роде характеристика качества работы менеджера клиента.
При отработке заявки через Servicedesk бизнес-процесс уже задан. Если требуется более жесткая процедура, тогда нужно либо править бизнес-процесс (ряд систем позволяют это делать), либо использовать изначально некоторую систему документооборота и создавать бизнес-процесс с нуля. Последнее — весьма затратная и долгая процедура. В случае с Servicedesk «из коробки», например, OTRS, приемлемый бизнес-процесс уже имеется и настроить систему можно буквально за несколько дней.
Отчеты
Для контроля качества работы подразделения без отчетов обойтись не получится. В Outlook получить нужные отчеты без программирования на VB не получится. В ServiceDesk достаточно много возможностей для построения отчетов в различных разрезах. При этом не нужно владеть навыками программирования, чтобы разработать нечто пригодное для использования. Основное, что требуется контролировать руководителю — как много заявок клиентов «висит» на том или ином менеджере и как долго. Это позволяет оперативно оценить загрузку сотрудников и их результативность. В случае «оптимизации» персонала это достаточно объективная информация по загрузке сотрудников. Полезно продемонстрировать её руководству вместо голословного утверждения, что сокращать персонал нельзя.
Полезно также отслеживать повторные открытия заявок, т.к. это потенциально конфликтная ситуация с клиентом, особенно если заявка была переоткрыта более одного раза. В общем, для грамотного менеджера Servicedesk дает немало пищи для ума. Чтобы извлечь аналогичную информацию из Outlook потребуется масса усилий программистов.
Тестирование Servicedesk «Билайна»
Некоторое время назад случайно наткнулся на сайте Билайна на web форму «Задайте вопрос вице-президенту«. Не особо рассчитывая на успех, написал вкратце (форма для текста очень маленькая), что неплохо было бы как-то упорядочить обработку запросов от клиентов, например, внедрив ServiceDesk. После отправки текста на экране высветился номер заявки (ага, значит запрос ложится в нечто вроде внутреннего Servicedesk, т.е. «Билайну» достаточно разрешить доступ к нему внешним клиентам). Хотя, на указанный при заполнении формы e-mail письма об открытии заявки не пришло (собственно и в дальнейшем ничего не пришло, поэтому не понятно, закрыт кейс или до сих пор в работе), т.е. диалог пока Билайн поддерживать не хочет.
Судя по всему эта заявка распределяется кем-то из первой линии техподдержки или специалистов по контролю за качеством или автоматически (по имени контрагента и указанным номерам договоров, но это маловероятно и неправильно) на персонального менеджера. По крайней мере персональный менеджер мне позвонил, но на этом всё и закончилось.
Возможно, подобного рода запросы контролируются непосредственно отделом качества или даже, чем черт не шутит, вице-президеном «Биалайн». По крайней мере, доступ у него к подобного рода заявкам, вероятно, имеется.
И тут вопрос что делается дальше. Ну позвонил мне менеджер, чтобы узнать, что, собственно, не устраивает. Ну рассказал я в очередной раз о проблемах. Дальше след заявки пропадает. У клиента нет возможности посмотреть на ответ. Понятно, что менеджер скорее всего что-то отписал руководству в оправдание, но что именно? Правильно ли он интерпретировал слова клиента?
Вопрос, способен ли монстр в лице «Билайна», что-то оперативно изменить в своих процессах для совершенствования процесса взаимодействия с клиентом или будет дана стандартная отписка: «Благодарим за ваше предложение. Мы несомненно учтем его (ага щас) в нашей дальнейшей работе». Когда я встречают подобный ответ — с высокой вероятностью он свидетельствует о том, что решили ничего не делать, т.е. «забить».
Если процесс анализа предложений клиентов разработан верно, то должна прийти иная фраза. Что-то вроде: «Мы проанализировали Ваше предложение и для его проработки бизнес-аналитиками были открыты заявки #… По мере реализации решения нам, вероятно, потребуется с Вами проконсультироваться. По ходу работы над заявкой Вы можете получать ответы от соответствующих служб. Благодарим за участие в совершенствовании наших бизнес-процессов.»
Если при этом задача действительно будет решена, пусть на это потребуется немало времени или по крайней мере будет дан вразумительный ответ, почему её нельзя решить (сейчас), но при любом раскладе клиент будет адекватно проинформирован, вот тогда он поймет, что действительно ценен для этой компании. Это тот высший пилотаж в организации процессов, который надолго привязывает клиента. В дальнейшем, даже в случае некоторой разницы в цене конкурентных предложений, клиент сто раз подумает, а стоит ли менять компанию, которая так внимательно относится к его пожеланиям.
