Привет, это STILT
Мы занимаемся инцидентной технической поддержкой IT-проектов по методологии ITIL.
Даже ночью сигнализируем об ошибках в системах и поддерживаем их работоспособность, чтобы наши клиенты получали деньги без перебоев.
Сейчас помогаем крупнейшей фармкомпании в России продавать аптечную продукцию
на маркетплейсах.
В кейсе расскажем, что сделали за год, чтобы бизнес клиента работал как часы.
Ключевые цифры за год
среднее время решения
закрытых вопросов L1
задач в месяц передаём
в разработку
Компания запустила продажи на маркетплейсах
На рынке нашего клиента долгое время знали как дистрибьютора лекарств. Но в 2021 компания открыла собственные аптеки и запустила продажи онлайн.
А когда государство разрешило продавать лекарства на маркетплейсах, вышла и на них.
Мы познакомились с компанией в 2022 году — они искали техническую поддержку интернет-магазина для сайта и приложения. Оба продукта доверили нам и не прогадали — мы устранили 40+ исторически сложившихся ошибок на проекте и в 3,5 раза снизили нагрузку на менеджеров клиента. Когда речь зашла про поиск аутсорсеров для поддержки интеграций с маркетплейсами, клиент снова выбрал нас.
Зачем на этом проекте понадобилась техподдержка
Компания интегрируется с маркетплейсами двух типов — с вертикальными и горизонтальными:
- Вертикальные маркетплейсы продают товары одной категории, в случае клиента — это интернет-аптеки, такие как «ГОРЗДРАВ» и «Планета здоровья»
- Горизонтальные маркетплейсы продают товары разных категорий — это хорошо знакомые нам Wildberries, Ozon, «Мегамаркет», где есть не только лекарства
Всего интеграций 24
И со всеми в системе клиента нужно «общаться», то есть обмениваться данными о заказах. Как и в любом общении, здесь тоже возникают трудности — на техническом языке их называют инцидентами.
Инциденты — это любые события, которые нарушают нормальную работу системы: сбой оборудования, ошибки в передаче данных, проблемы с сетью.
Возникновение инцидентов приводит к простоям — из-за ошибок заказы не обрабатываются как надо, и клиент теряет в деньгах. Другими словами, если система застопорится даже на полчаса, клиент недополучит сотни тысяч рублей — как минимум. Мы должны отлавливать такие сбои раньше, чем они приведут к убыткам.
Техническая поддержка — это система быстрого реагирования. Мы как лейкоциты в крови. Если в организм попадает вирус, то они первыми узнают об опасности и включают SOS-систему — поднимают температуру, и организм начинает бороться
с болезнью. Так же и с IT-проектами — если где-то что-то сбоит, то мы узнаём об этом первыми и экипируем клиента на устранение проблемы.
Наша задача — обнаружить проблему на проекте, показать, где она и почему возникла, и не дать клиенту забыть про неё
Погрузились в бизнес-процессы
Первые две недели любого проекта мы посвящаем передаче знаний: от разработчиков и менеджеров клиента к нам.
Этот этап позволяет понять, как работает система клиента, какие у неё ключевые параметры, как и с какой периодичностью они передаются. В общем, смотрим, что под капотом.
Настроили систему оповещений
Чем больше инцидентов мы отследим, тем лучше.
За каждую пропущенную проблему перед клиентом мы отвечаем деньгами и репутацией.
Отследить всё вручную невозможно — для этого нужны специальные инструменты. Один из них — это система оповещений, или алертов.
Алерты — это уведомления об инцидентах, которые говорят, что в системе возникла ошибка или аномалия, требующая вмешательства человека
Как мы обвешиваем систему алертами
На стороне клиента много ключевых обменов и бизнес-процессов. Если видим, что для какого-то из них необходим алерт, мы ставим эту задачу команде аналитиков клиента. И обязательно аргументируем, почему без алерта не обойтись.
После того как алерт создали, прописываем алгоритмы реагирования, согласовываем их с клиентом и ждём, когда алерт сработает.
На что реагируют наши алерты
Неактуальные цены
С нынешней экономикой цены могут меняться каждый день. Нам нужно отслеживать, чтобы та стоимость, которую покупатель видит на онлайн-витрине, и та, которая посчитана в экономике клиента, совпадали. Ведь бывает так, что система передаёт на маркетплейс 12 тысяч новых ценников, а площадка принимает только 9. В итоге 3 тысячи позиций продаются по старой цене.
Заработок в фарме идёт на второй цифре после запятой. Если вчера Парацетамол стоил 100 рублей 15 копеек, а сегодня стоит 100 рублей 20 копеек, и система это не проиндексировала, то заказы будут уходить по вчерашней цене — на этом бизнес потеряет деньги.
Технические сбои
То, о чём мы сказали выше, — это бизнес-процессы клиента, в которые мы погружаемся с головой. Но помимо них есть и чисто технические инциденты, о которых мы тоже должны своевременно предупреждать клиента. Например, долгое ожидание ответа от сервера или слишком высокая нагрузка на него. С последним у нас был невесёлый пример.
Как-то раз мы отследили высокую нагрузку на базу данных и сообщили об этом клиенту. Решить вопрос нужно было срочно — иначе бы интеграция перестала работать. Администратор, который в этом разбирался, был занят, поэтому помочь попытался другой специалист. Но что-то пошло не так: не зная нюансов, он удалил важный файл, отвечающий за работу базы данных. Нагрузка на неё, конечно, снизилась, но и сама база перестала работать. Заказов не было, пока первый специалист не освободился и не вернул всё на место.
Неправильно посчитанные остатки
Чаще всего проблем с остатками две:
Эту проблему решаем так: проверяем, почему площадка недополучила необходимые страницы, затем передаем проблему команде разработки и в чат маркетплейса (иногда проблема на их стороне: идут технические работы или случаются аварии).
Когда возникает такая проблема, мы сразу делегируем её на маркетплейс. Служба поддержки связывается с покупателем напрямую — пишет в мессенджер или звонит по телефону, объясняет ситуацию и предлагает замену лекарства.
Для каждого из этих пунктов мы создали свои дашборды, или доски отслеживания. Они отображают текущие процессы и помогают отлавливать инциденты в реальном времени.
Создали карту эскалации
Окей, инциденты отследили, но что с ними делать дальше? Какие-то вещи мы можем обработать на своей стороне, но чаще — сигнализируем клиенту об ошибке, ведь большинство проблем решаются на его стороне. Для этого у него есть и нужные доступы, и технические специалисты.
Изначально на проекте не было понимания, кто за что отвечает: проблему могли кинуть в общий чат, и никто бы не среагировал на неё — не ясно, в чьей зоне ответственности она находится. И даже проджект-менеджеры, работавшие на проекте с самого начала, порой не знали, к кому идти за помощью.
Чтобы побороть это, мы создали карту эскалации — документ, который описывает процесс перехода инцидента на следующий уровень технической поддержки программного обеспечения: с L1 (мы) на L2 (клиент). В карте прописали, какие типы инцидентов бывают, и кто со стороны клиента ответственен за их обработку.
Карта эскалации
Полностью решить проблему с дискоммьюникейтом удалось за три месяца. Теперь инцидент отправляется напрямую к тем специалистам клиента, которые за него в ответе. Это ускоряет реагирование на проблему.
Отслеживаем разночтения в статусах заказа
Статусы заказа — это этапы, через которые проходит заказ во время обработки, и помогают пользователю отследить, что происходит с заказом после покупки. Также статусы помогают специалистам понять, что заказ корректно проходит все этапы.
Все мы видим плашки «Готовится к упаковке», «Отправлен», «Доставлено», когда оформляем заказы.
Для пользователя статус лишь уведомление в личном кабинете.
А вот со стороны маркетплейсов статусы — это отображение бизнес-процессов, которые в каждой компании строятся по-своему. Поэтому и статусы у них тоже разные. И, по факту, любому екому нужна техническая поддержка в этом вопросе.
Чтобы соотнести статусы разных площадок друг с другом, клиент проводит маппинг — подбирает аналоги. Если на 100% идентичного статуса нет, то подбирается похожий, по сути, и они приравниваются друг к другу.
Статусные модели маркетплейсов
К системе клиента, как мы уже говорили выше, подключено 24 маркетплейса. У каждого свои бизнес-процессы.
Мы следим за тем, чтобы статусы корректно отображались как в личном кабинете покупателя, так и у нас в системе. Чтобы ситуаций, когда у человека заказ еще в сборке, а у нас уже в доставке, не возникало.
Взяли на себя коммуникацию
с представителями площадок
С каждой из подключенных площадок у клиента есть как минимум один чат.
В них проджект-менеджеры клиента задают площадкам вопросы, если где-то на маркетплейсе застревает заказ или возникает другая проблема.
Нам показалось, что логичнее взять коммуникацию с площадками на себя.
Если мы, например, видим, что от Яндекс.Маркета заказы не идут уже полчаса, а на нашей стороне всё “окей”, то нам нужно понять, что у Яндекса не так.
Глупо играть с ним в глухой телефон, отправляя на переговоры клиента. Быстрее и проще — спросить самим.
Сейчас мы состоим в 10 чатах по интеграциям. Ведём всю коммуникацию и транслируем бизнесу ход решения проблемы со стороны маркетплейса. Бизнес получает почасовой отчёт и сам определяет, вмешиваться в ситуацию или нет.
Таким образом, мы:
а) сокращаем временной промежуток между возникновением инцидента и реакцией на него;
б) высвобождаем время проджект-менеджеров со стороны клиента — эта коммуникация больше не ложится к ним на плечи, и они могут заняться более важными делами.
Заменили клиенту штатный отдел поддержки уровня L1
Когда-то у клиента была штатная поддержка двух уровней: L1 и L2. Но команде L1 не всегда удавалось решать проблемы оперативно, так как на ней лежала часть других задач.
Сейчас всю первую линию поддержки заменили мы, а технические специалисты клиента этого уровня смогли переключиться на более важные задачи: кто-то перешёл в другой отдел, а кто-то возглавил новое направление.
За год работы нам удалось:
- Ускорить реакцию на инциденты до 12,5 минут;
- Закрыть 7 294 вопросов уровня L1.
Какой ещё профит получил клиент от того, что у него появились мы?
Отдых для сотрудников по праздникам и выходным. Мы взяли на себя часть ответственности проектных менеджеров, поэтому теперь они могут уходить в отпуск не боясь, что резкое ночное «У нас всё упало!» помешает им отдыхать. Ведь для круглосуточной технической поддержки у нас выстроены все необходимые процессы.
Нам нравится делать свою работу хорошо
Мы продолжаем проводить системную техническую поддержку на проекте клиента: отлавливать ошибки и улучшать процессы.
На проекте ведём строгую отчётность, чтобы у клиента перед глазами была полная картина того, как работают интеграции — где какое происшествие случается и как решается.
Отзывы
Главным преимуществом ООО «СТИЛТ-ИТИЛ» считаем внимательность к деталям, оперативность реакции, соблюдение SLA и регулярную аналитическую отчетность по всем проектам.
ООО «Комплицерте Тех» рекомендует ООО «СТИЛТ-ИТИЛ», как организацию, оказывающую качественные и профессиональные услуги в сфере технической поддержки сложных IT-проектов.»
Кейсы
Услуги
Наша техническая поддержка снимет нагрузку с ваших плеч, позволяя вам сосредоточиться на стратегически важных бизнес-процессах.
Мы поможем вам защитить себя от текущих и потенциальных проблем.
Оказание услуг технической поддержки — наша работа.
Если вам тоже нужна поддержка, — заполняйте форму ниже.
Перезвоним, выслушаем и расскажем, чем сможем помочь.