Когда техподдержку приходится запускать с нуля, важно быстро понять как устроена платформа, какие данные через неё проходят, какие внешние сервисы задействованы и где потенциально могут возникать сбои. Такой подход помогает не тратить силы на хаотичные попытки, а двигаться системно. Мы собрали практические шаги, которые позволяют стабилизировать поддержку даже при полном информационном вакууме.
1. Начните с понимания контекста
Наш проект — социальная платформа для Ямало-Ненецкого округа. Она помогает людям оформлять пособия, сертификаты и участки под строительство. Разработка уже была завершена другой компанией, а нам нужно было взять техподдержку и обеспечить её стабильность. На словах это звучало просто, но на деле оказалось тем ещё испытанием.
2. Примите хаос как отправную точку
Первые недели были похожи на блуждание в темноте. Код был чужим, документации не было, а тикеты приходили пачками. Из-за требований закона о персональных данных мы не могли локально развернуть систему и часто работали без доступа к реальной среде. Каждая заявка становилась расследованием: где ошибка, почему всё упало, кто виноват. Важно было не паниковать и фиксировать все находки. Они стали основой будущей базы знаний.
3. Выстраивайте систему, даже если кажется, что ещё рано
Первым шагом стала тикет-система. Мы выбрали Яндекс.Трекер и связали его с системой заказчика, чтобы обе стороны видели обращения и статусы в реальном времени. У заказчика задачи отображались по критичности, у нас — по внутренним срокам и ответственным. Это синхронизировало процессы без изменения привычных форматов работы. Затем настроили SLA — время реакции и время решения для каждой категории. Мы рекомендуем делать внутренние сроки чуть строже, чем по контракту. Это убережёт вас от штрафов и добавит спокойствия.
4. Разделите роли и зоны ответственности
Когда объём заявок растёт, важно, чтобы они не задерживались на любом из этапов. Мы ввели линии поддержки. L1 принимает обращения, собирает информацию и решает простые задачи. L2 — разработчики, которые работают с кодом и базой данных. Мы прописали чёткие правила передачи задач: что фиксировать, какие данные собирать, как описывать действия пользователя. Это сократило возвраты тикетов и ускорило обработку обращений.
5. Работайте не только с ошибками, но и с людьми
Самое сложное — чужой код и отсутствие прозрачности. Иногда мы не знали, где сбой: на нашей стороне или, например, у Росреестра. Но пользователю не важно, где проблема. Для него важно, чтобы всё заработало. Поэтому мы выработали правило: не спорить, а помогать. Иногда нужно объяснить, что ничего страшного не случилось, иногда — выслушать и успокоить, а иногда — просто всё починить. Эмпатия экономит нервы и заказчику, и команде.
6. Автоматизируйте повторяющееся
Через несколько месяцев стало ясно, какие задачи повторяются чаще всего. Мы описали их и частично автоматизировали. Около 40% тикетов теперь закрываются без участия разработчиков. По нашему опыту, если задача повторяется три раза — пора искать способ её автоматизировать.
И главное — не бойтесь хаоса. Любая система начинается именно с него. Важно фиксировать, анализировать и постепенно создавать свои правила работы.