Подписаться
Читать в телеграм
Возьмем вариант, когда мы обслуживаем в режиме 24/7 сразу несколько критичных бизнес-систем: «приклад» интернет-магазина, CRM, в том числе обеспечивающую работу бонусной программы, и комплекс ERP, закрывающий практически весь внутренний функционал компании. Первые 2 системы завязаны на работу с конечными пользователями – покупателями, третья подразумевает поддержку бизнес-пользователей. Понятно, что если какой-либо раздел интернет-магазина перестает работать даже на несколько минут, это приводит к падению продаж, то же самое можно сказать о перебоях в работе программы лояльности. На отчетность в ERP у ритейлера завязаны ключевые бизнес-процессы, в том числе формирование ежедневных планов продаж и отгрузок товара в магазины. При простое отчетной системы логистическая цепочка и продажи также «провиснут». В случае с интернет-магазином и CRM мы выступаем в качестве второй линии поддержки пользователей: от 1-й линии к нам поступают заявки на устранение инцидентов. Прямое общение с клиентами ритейлера происходит в ходе переписки при исполнении заявок. В то же время мы напрямую общаемся с владельцами и администраторами бизнес-приложений в компании, например, с мерчендайзерами, управляющими контентом на сайте. При проблемах в работе системы все они обращаются к нам.
Теперь, собственно, о принципах работы по заявкам и взаимодействия с пользователями. Они могут показаться простыми и понятными в теории, но, к сожалению, на практике их реализация может быть проблематичной. Первое, на что мы хотим обратить внимание, – это правильное определение критичности заявок. В различных ИТ-стандартах есть градация степеней критичности, например, самая высокая – это остановка всей системы, невозможность работы большой группы пользователей и т.д. Но при обслуживании интернет-магазинов есть нюансы. Так, если функционал заказа лишь одного, но очень востребованного в данный момент у покупателей товара дает сбой, с точки зрения стандартного подхода сформированная по инциденту заявка не будет критичной. Бизнес же при этом несет миллионные убытки, и решать проблему нужно максимально быстро, а не в общем потоке. В случае с приложением вроде бы простые заявки могут вылиться в критичные, чего не бывает при работе с железом, где сразу можно определить уровень влияния проблемы на бизнес. В итоге инженеры должны знать бизнес-специфику приложения, с которым работают, – что критично именно для него, а что нет.
Очень важно обращать внимание на вопрос коммуникаций, корректно выстраивать общение с пользователями – клиентами ритейлера. Например, приходит заявка «не могу посмотреть свои бонусные баллы на счете». Инженер может зайти, увидеть, что система работает корректно, закрыть заявку и отписать, что проблема не воспроизводится. Формально он по ней отработал. Но дело в том, что человек уже неоднократно пытался проверить состояние бонусного счета и просто забыл указать в обращении, что не может посмотреть баллы именно в Google Chrome. Всплыть эта история потом может на одном из форумов вместе с негативными комментариями пользователя в отношении компании и скринами переписки. Такие ситуации исключаются при неформальном, внимательном подходе к вопросу: инженер запрашивает у пользователя уточняющие детали о том, как воспроизвести проблему, и решает ее. Другой перекос – сообщение клиентам лишних подробностей о возникшей у них проблеме. Как правило, фразы инженера в переписке «этот раздел сайта уже час ни у кого не работает» не приводят ни к чему хорошему. Это еще один кандидат на появление поста в соцсетях или на форуме. Нужно учить инженеров минимизировать лишнюю информацию.
К коммуникационным вопросам относится и необходимость наличия у инженеров, обслуживающих приложение, дипломатических навыков. Бизнес-пользователь сообщает о проблеме в работе системы, например, о том, что отчет открывается не менее 15 секунд. Инженер проверяет описание параметров работы приложения: согласно спецификации отчет может открываться до 30 секунд, то есть этот факт не является инцидентом. Имеет смысл объяснить пользователю, почему ситуация является штатной, не ограничиваясь сообщением «проблемы не выявлено, инцидент закрыт».
При обработке заявок необходимо информировать о ходе работ их инициаторов. Пользователь отправляет заявку (оставляет сообщение на сайте, пишет e-mail), и для него она уходит в никуда, «в машину»: у человека нет канала коммуникации, по которому он может напрямую общаться с инженером. Специалист решает проблему в сроки, прописанные в SLA, но пользователь не знает о том, что работа идет. Это может вызвать негатив. Практика показывает: клиенты готовы ждать решения своей проблемы, но им обязательно нужно знать, что ею занимаются. Срочность для них часто даже не так важна, как информированность. В нашем случае мы настроили автоматические ответы на сайте ритейлера – заявка сформирована, на ее обработку нужно время. Помимо автореплая, наши инженеры также имеют возможность дополнительно информировать клиентов.
Таким образом, нашу коммуникацию с пользователями можно охарактеризовать русской пословицей «ни убавить, ни прибавить»: инженеры должны четко информировать пользователей о ходе работ по заявкам, не вдаваясь в излишние детали. В совокупности с глубокими техническими компетенциями и знанием бизнес-специфики работы приложений это ставит сложный процесс поддержки на обкатанные рельсы.
