Выравнивание ожиданий клиентов при запуске ИТ-поддержки

Читая статьи в нашем блоге, может показаться, что мы работаем идеально. Конечно, это не совсем так, в нашем шкафу тоже есть скелеты. На этапе становления сервиса немало было набито шишек и выучено уроков.

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

Коммуникация

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

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

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

Первая ошибка

Таким образом, ошибка номер раз — мы эту потребность не выявили и не подстроились.

Вторая ошибка

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

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

Зоны ответственности

Следующее — зоны ответственности. Ни в коем случае не нужно предполагать, что ваше представление о том, какая сторона из трех (ИТ, бизнес, подрядчик) за что отвечает, совпадает с видением подрядчика. Даже в очень типовых процессах, таких как учет, каждая компания живет по-своему, и лучше перед началом работы проговаривать нюансы.

На второй месяц технической поддержки нового, очень перспективного для нас клиента, мы были буквально на волосок от гибели. Одной из функций поддержки у этого клиента было так называемое “восстановление последовательности” в 1С: перепроведение всех документов за месяц перед закрытием периода. Как обычно, документы вводятся “задним числом”, и перепроведение останавливается из-за отрицательных остатков. Нужно внимательно смотреть на даты и время документов и корректировать их, чтобы процедура могла продолжаться. В общем, “старожилы помнят” 🙂

У сотрудников нашей поддержки прошито в мозгах, что изменение документов в клиентской базе мы ни в коем случае не делаем, поскольку теряется аудиторский след.  А сотрудники бухгалтерии клиента привыкли, что раньше программисты 1С корректировали документы самостоятельно. Казалось бы, мелочь, которая выяснится при первом прогоне. Но первый прогон попал на новогодние праздники, и второго января, когда перепроведение остановилось, наш сотрудник написал письмо в бухгалтерию с описанием проблемы и просьбой скорректировать документы. Когда это письмо было прочитано? Пятого, когда по графику началось закрытие периода, и конечно же, оно было сорвано на два дня.

Третья ошибка

Могли мы это предусмотреть, и проговорить взаимные ожидания перед уходом на праздники? Конечно могли, но нет — пришлось “преодолевать” и выравнивать отношения, находясь “на карандаше” еще два-три месяца после инцидента.

Приоритеты

Наконец, приоритеты. Казалось бы, что здесь сложного — есть подписанный SLA, в котором все черным по белому расписано. Но есть SLA на бумаге, и есть SLA в голове ключевых экспертов. Пока они не выровнены — жди беды.

Новый, непривычный для нас в то время сервис — поддержка интеграционной шины для крупного корпоративного заказчика. Расписанный и согласованный с ИТ-заказчиком SLA. Второй месяц поддержки и первое закрытие. И здесь оказывается, что один из типов заявок, который обозначен, как средний приоритет (8 рабочих часов), в два последних дня финансового закрытия становится нулевым, а еще и расширяет время поддержки. Вместо графика 8*5 появляется график “ни шагу назад” — пока не решены все заявки этого типа, рабочий день не должен заканчиваться ни у нас, ни у клиента.

Четвертая ошибка

Конечно, это выяснилось около 21:00 при финальной попытке закрытия, когда специалисты заказчика обнаружили, что ИТ-поддержка ушла домой, не закрыв несколько последних заявок этого типа и не предупредив. И к рядовым специалистам нет вопросов, ведь они ориентировались на подписанный регламент. Вопросы были к ФТО в целом, и утром проблема была стремительно эскалирована на финансового директора и ИТ-директора.

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