Круглосуточная инцидентная техническая поддержка интернет-магазина и мобильного приложения

Клиент крупнейший дистрибьютор игрушек в РФ

1. Обеспечение бесперебойной работы интернет-магазина и мобильного приложения.

2. Обогащение базы знаний по типичным инцидентам для обеспечения прозрачности взаимоотношений между СТП и Заказчиком.

3. Снижение нагрузки на проектных менеджеров и разработчиков проекта, за счет решения типичных кейсов.

Погрузились в бизнес-процессы

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

Настроили систему оповещений

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

Как мы регулируем систему алертов

На стороне клиента много ключевых обменов и бизнес-процессов. Если видим, что для какого-то из них необходим алерт, мы ставим эту задачу аналитикам. И обязательно аргументируем, почему без алерта не обойтись. После того, как его создали, прописываем алгоритмы реагирования, согласовываем их с клиентом и ждём, когда алерт сработает.

Задача не только заметить угрозы, но и оценить их значимость, чтобы команда техпода не подрывалась зря. Поэтому мы выводим адекватные пороговые значения и регулируем «чувствительность» системы к ним.

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

 1. Создать карту эскалации. 

Изначально на проекте не было понимания, кто за что отвечает: проблему могли кинуть в общий чат, и никто бы не среагировал на неё — не ясно, в чьей зоне ответственности она находится. И даже проджект-менеджеры, работавшие на проекте с самого начала, порой не знали, к кому идти за помощью. Наш подход дает выявить горячие точки, не устраивая переполох во всей компании. Каждая ошибка находится в зоне ответственности конкретного сотрудника, а если он в данный момент занят, то сигнал получает другой человек в соответствии с внутренней иерархией. Для этого мы создали карту эскалации — документ, который описывает процесс перехода инцидента на следующий уровень технической поддержки программного обеспечения: с L1 (мы) на L2 (клиент). В карте прописали, какие типы инцидентов бывают и кто со стороны клиента ответственен за их обработку.

 2. Отслеживать разночтения в статусах заказа.

Для пользователя статус лишь уведомление в личном кабинете. А вот со стороны маркетплейсов статусы — это отображение бизнес-процессов, которые в каждой компании строятся по-своему. Поэтому и статусы у них тоже разные. И, по факту, любому екому нужна техническая поддержка в этом вопросе.

3. Взяли на себя коммуникацию с представителями площадок.

С каждой из подключенных площадок у клиента есть как минимум один чат. В них проджект-менеджеры клиента задают площадкам вопросы, если где-то на стороне маркетплейса застревает заказ или возникает другая проблема. Нам показалось, что логичнее взять коммуникацию с площадками на себя. Если мы, например, видим, что от Яндекс.Маркета заказы не идут уже полчаса, а на нашей стороне всё окей, то нам нужно понять, что у Яндекса не так. Глупо играть с ним в глухой телефон, отправляя на переговоры клиента. Быстрее и проще — спросить самим: 

— Коллеги, уже 1,5 часа не получаем от вас заказы — при норме один заказ в полчаса. Что случилось и можем ли мы как-то помочь?

Сейчас мы состоим в 10 чатах по интеграциям. Ведём всю коммуникацию и транслируем бизнесу ход решения проблемы со стороны маркетплейса. Бизнес получает почасовой отчёт и сам определяет, вмешиваться в ситуацию или нет.

Таким образом мы: а) сокращаем временной промежуток между возникновением инцидента и реакцией на него; б) высвобождаем время проджект-менеджеров со стороны клиента — эта коммуникация больше не ложится к ним на плечи, и они могут заняться более важными делами.

4. Заменить клиенту штатный отдел поддержки уровня L1.

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

За первые 6 месяцев удалось достичь:

1. Снижение нагрузки на команду проектных менеджеров и разработку клиента в 3,5 раза.

2. По результатам собранной нами статистики, командой было устранено 50+ дефектов в обменах систем.

3. Среднее время обработки заявки (от инцидента до решения) сократилось в 4 раза, с 30 минут до 7,5 минут.

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