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