В 2022 году мы впервые рассказали, как организовали службу поддержки в Кайтене. Тогда главной победой стало то, что все обращения удалось собрать в одном месте и перестать терять заявки. Для того этапа это был серьезный шаг вперед. Но настоящая трансформация началась позже.
За последние четыре года количество обращений выросло почти втрое — примерно с 500 до 1500 заявок в месяц. Обычно такой рост приводит к усложнению процессов: скорость реакции снижается, команда начинает работать в режиме постоянного аврала, а качество сервиса становится все сложнее поддерживать на прежнем уровне.
Но в Кайтене ситуация развивалась по другому сценарию.
💡 Несмотря на трехкратный рост нагрузки, среднее время ответа в чате не увеличилось, а наоборот сократилось — с 20 до 5 минут.
Разбираемся, как нам удалось этого добиться, вместе с Дмитрием Кирюхиным, руководителем службы поддержки Кайтена.
Как все начиналось: один человек и никаких процессов
На старте отдельной службы поддержки в Кайтене не было. Всеми обращениями занимался один сотрудник: отвечал на вопросы, разбирался в проблемах, искал решения и тут же переходил к следующему запросу.
Пока пользователей было немного, такой подход работал. Однако вместе с ростом продукта появились и новые сложности:
- становилось все труднее удерживать в памяти контекст обращений;
- возрастал риск потерять запрос;
- поддерживать одинаковую скорость реакции на все заявки было все сложнее.
Кроме того, вся система фактически зависела от одного человека. А значит, масштабировать ее без серьезных изменений было невозможно.
Рост команды не решил всех проблем
Когда обращений стало больше, к работе поддержки начали подключаться новые сотрудники. Это помогло распределить нагрузку, но не сделало процесс прозрачнее и управляемее.
Заявки продолжали поступать из разных источников — электронной почты, мессенджеров и сторонних сервисов. Единой точки учета не существовало, поэтому регулярно возникали типичные проблемы:
- часть обращений терялась;
- ответы задерживались из-за необходимости уточнять детали;
- при передаче задачи другому специалисту контекст приходилось восстанавливать заново.
Команда не видела общей картины: было сложно оценить текущую загрузку, понять статус конкретного обращения и вовремя заметить возникающие узкие места.
Единый процесс внутри Кайтена
Следующим этапом стало внедрение модуля «Служба поддержки» прямо внутри Кайтена.
После этого обращения из всех каналов начали автоматически превращаться в карточки на единой канбан-доске. Каждая заявка стала проходить через стандартный набор этапов обработки, а вся работа по обращению — от переписки с клиентом до внутреннего обсуждения и фиксации причины проблемы — сосредоточилась внутри одной карточки.
Это позволило значительно упорядочить работу команды и сохранить весь контекст в одном месте.
Однако даже после этого оставалось много ручных операций:
- сотрудники самостоятельно перемещали карточки между этапами;
- дополнительную информацию приходилось запрашивать отдельно;
- статусы контролировались без единых правил и автоматизации.
Формально система поддержки уже существовала, но ей по-прежнему не хватало управляемости. Команда не видела ключевых метрик, не контролировала соблюдение SLA и не могла быстро находить узкие места в процессе.
Когда стало понятно: проблему нужно решать системно
Раньше рабочий день поддержки часто начинался с вопроса: кто сегодня будет разбирать очередь обращений? Со временем мы поняли, что гораздо важнее разобраться в другом — почему эта очередь вообще возникает.
Вместо того чтобы воспринимать поддержку как набор отдельных заявок, мы начали смотреть на процесс целиком. Где появляются узкие места? На каких этапах скапливаются обращения? Что именно замедляет работу команды?
Чтобы ответить на эти вопросы, потребовалось перестроить процесс так, чтобы его можно было измерять, анализировать и улучшать на основе данных.
Что изменилось
Сначала научились видеть картину целиком
Именно тогда в работе поддержки появились SLA и системная работа с метриками.
Отчеты перестали быть просто набором цифр и превратились в инструмент управления. Благодаря им стало видно:
- какие типы обращений регулярно выходят за рамки целевого времени;
- как меняется нагрузка в пиковые периоды;
- на каких этапах чаще всего возникают задержки;
- где внутри команды формируются точки перегрузки.
В модуле «Служба поддержки» доступен набор отчетов, которые позволяют анализировать эффективность работы команды и находить проблемные зоны.
Затем избавились от рутины
Анализ процессов показал интересную закономерность: значительная часть времени инженеров уходила не на решение клиентских проблем, а на сопутствующие действия.
Собрать контекст, определить клиента, распределить обращение, проконтролировать сроки, уточнить статус — каждая операция занимала всего пару минут. Но в масштабе недели это превращалось в 10–20 часов командного времени.
Мы решили передать эти задачи системе.
Автоматическая идентификация клиента
Раньше работа с новым обращением начиналась с базовой проверки: кто пишет, какой у клиента тариф, были ли предыдущие обращения.
Теперь система собирает эту информацию автоматически. При создании карточки данные о клиенте подтягиваются сразу, а инженер получает весь необходимый контекст без дополнительных действий.
В карточке обращения собрана вся ключевая информация, необходимая для быстрого ответа клиенту.
Автоматическая маршрутизация заявок
Часть обращений распределяется автоматически — в зависимости от типа запроса и канала поступления.
Это позволило сократить объем ручной обработки входящего потока и сделать работу поддержки более предсказуемой.
Контроль SLA без ручного отслеживания
Раньше инженерам приходилось самостоятельно следить за сроками ответа и решения обращений.
Сегодня это делает система. SLA-таймеры работают автоматически, а если появляется риск нарушения сроков, обращение эскалируется без участия сотрудников.
Таймеры SLA отображаются прямо внутри карточек и помогают контролировать сроки в реальном времени.
Единый процесс между поддержкой и разработкой
Одним из самых заметных изменений стала интеграция поддержки и разработки.
Несколько лет назад взаимодействие строилось через Slack: разработчики обсуждали проблему в одном месте, а поддержка ждала обновлений в другом. В результате информация быстро расходилась, а актуальный статус приходилось уточнять вручную.
Сейчас тикет поддержки напрямую связан с задачей разработки внутри Кайтена.
Поверх этой связки работают автоматизации, которые самостоятельно перемещают карточки между пространствами и колонками в зависимости от событий: когда задача берется в работу, закрывается или выходит в релиз.
Благодаря этому инженерам поддержки больше не нужно вручную отслеживать изменения или уточнять статус у разработчиков.
Переписка с клиентом, история обращения, внутренние комментарии и связанная задача разработки находятся в одной карточке. При этом клиент видит только свою коммуникацию с поддержкой.
Построили команду, которая не зависит от отдельных людей
Параллельно мы пересмотрели подход к распределению экспертизы внутри команды.
Раньше специалисты были жестко привязаны к своим направлениям: один занимался интеграциями, другой — биллингом, третий — настройкой продукта.
На первый взгляд это удобно. Но на практике такая модель создает серьезные риски. Отпуск, больничный или увольнение сотрудника автоматически превращают его область ответственности в потенциальную точку отказа.
Поэтому мы отказались от узкой специализации.
Сегодня заявки обрабатываются всей командой, а для работы с багами действует еженедельная ротация. Каждые семь дней назначается инженер, который отвечает за это направление: воспроизводит ошибки, взаимодействует с разработкой и контролирует движение задач. Затем роль переходит следующему специалисту.
Так каждый инженер регулярно работает с разными типами кейсов и накапливает знания не в одной области, а по всей системе.
Этот подход помог решить сразу несколько задач:
- снизить риск профессионального выгорания;
- убрать зависимость от отдельных сотрудников;
- сохранить устойчивость команды при росте нагрузки;
- создать условия для долгосрочного развития специалистов.
Матрица компетенций как инструмент развития
Когда данных о работе поддержки стало достаточно, мы сформировали матрицу компетенций — карту навыков, которая показывает текущий уровень каждого инженера и помогает планировать дальнейшее развитие.
В основу легли четыре направления экспертизы:
- работа с инструментами;
- знание продукта;
- техническая диагностика;
- работа с информацией.
Каждое направление было разбито на конкретные проверяемые навыки. Всего в матрице около 115 компетенций, распределенных по трем уровням:
Junior — уверенно работает по типовым сценариям и использует поддержку коллег в сложных ситуациях.
Middle — самостоятельно ведет большинство обращений и эффективно справляется со стандартными кейсами.
Senior — берет на себя самые сложные запросы, видит системные проблемы и помогает устранять их причины.
Матрица одновременно решает две важные задачи.
Во-первых, делает профессиональный рост прозрачным и измеримым. Повышение уровня теперь основано не на субъективной оценке, а на освоении конкретных навыков. По этой модели уже два инженера выросли до уровня Senior.
Во-вторых, помогает управлять взаимозаменяемостью внутри команды. Мы видим, где возникает риск концентрации экспертизы у одного человека, какие компетенции необходимо развивать и какие зоны ответственности стоит распределять между сотрудниками заранее.
По сути, матрица позволяет превращать накопленный опыт команды в понятную систему развития и передачи знаний.
Результаты заметны уже сегодня. Все больше сложных обращений решается без эскалации, Senior-инженеры самостоятельно ведут Enterprise-клиентов и сложные интеграционные кейсы, а параллельно помогают коллегам быстрее расти через наставничество и обмен опытом.
Что изменилось в цифрах
В 2022 году нашей целью было отвечать клиентам в течение 20 минут после поступления обращения. Сегодня среднее время ответа в чате составляет около 5 минут.
Для обращений через портал мы используем другую метрику — время до типизации и приоритизации заявки. Она показывает, сколько времени проходит с момента поступления обращения до того, как становится понятно, что именно произошло и насколько срочно нужно реагировать.
Сейчас этот показатель составляет в среднем около 10 минут.
Однако средние значения не всегда отражают реальную картину, поэтому мы анализируем и процентили. Они позволяют понять, как распределяется скорость обработки заявок по всему потоку.
Например, 15-й процентиль по времени типизации составляет менее одной минуты. Это означает, что 15% обращений попадают в работу практически мгновенно.
Полное время решения заявки в среднем занимает около 10 часов. При этом каждая седьмая заявка закрывается менее чем за час — это также отражает значение 15-го процентиля.
Важно учитывать, что в эту метрику входит весь жизненный цикл обращения: от первого сообщения клиента до окончательного закрытия заявки, включая ожидание ответа со стороны пользователя и, при необходимости, участие команды разработки.
Для сравнения: в среднем по рынку B2B SaaS полный цикл решения обращения обычно занимает от 11 до 24 часов.
Неожиданные эффекты изменений
Некоторые результаты оказались для нас не менее ценными, чем рост скорости и эффективности поддержки.
Служба поддержки стала инструментом для всей компании
Изначально модуль «Служба поддержки» создавался исключительно для работы с клиентскими обращениями.
Но со временем оказалось, что такой подход отлично подходит и для внутренних сервисных процессов.
Сегодня через этот же модуль проходят:
- HR-запросы;
- административные задачи;
- бухгалтерские обращения;
- внутренние сервисные запросы сотрудников.
По сути, решение, созданное для клиентской поддержки, постепенно превратилось в универсальную систему обслуживания внутри всей компании.
Модуль «Служба поддержки» используется не только для работы с клиентами, но и для внутренних процессов компании.
Появилась коллективная память команды
Еще одним важным результатом стала накопленная база знаний.
Каждая карточка хранит не только описание проблемы, но и полный контекст работы с ней: запрос клиента, ход обсуждения, принятое решение и дальнейшие действия.
В результате история обращений превратилась в полноценный рабочий инструмент.
Сегодня новый инженер может:
- изучить типовые кейсы по своему направлению;
- быстро найти похожую ситуацию среди ранее решенных обращений;
- увидеть весь контекст коммуникации и логику принятия решений.
Если раньше полноценное погружение в работу занимало почти месяц, то сейчас на адаптацию обычно требуется около недели.
Старые кейсы помогают быстрее решать новые задачи, а знания команды перестают зависеть от конкретных сотрудников.
Поддержка стала источником продуктовых инсайтов
Раньше многие решения принимались на основе ощущений.
Например: «кажется, пользователи часто спрашивают об этой функции» или «похоже, здесь возникает много проблем».
Теперь любые гипотезы можно проверить данными.
Мы видим:
- сколько пользователей столкнулись с конкретной проблемой;
- в каком контексте она возникает;
- как меняется ее частота со временем;
- какие сложности действительно влияют на клиентский опыт.
Поддержка перестала быть только каналом коммуникации с пользователями и стала полноценным источником данных для развития продукта.
Что дальше
Следующий этап развития — автоматизация типовых обращений с помощью искусственного интеллекта.
Наша цель — автоматизировать до 50% заявок без участия инженеров поддержки.
Речь идет о нескольких уровнях автоматизации:
- генерации черновиков ответов;
- автоматической классификации обращений;
- интеллектуальной маршрутизации заявок;
- сценариях, которые ИИ сможет полностью закрывать самостоятельно.
Сейчас проект находится на стадии проектирования архитектуры, но именно это направление мы рассматриваем как следующий шаг в развитии поддержки.
Поддержка развивается вместе с продуктом
За несколько лет служба поддержки Кайтена прошла путь от простой канбан-доски до полноценной экосистемы с аналитикой, автоматизацией и прозрачными процессами.
За это время количество обращений выросло почти в три раза, а команда увеличилась всего на 20%. При этом нам удалось не только сохранить показатели качества, но и существенно ускорить работу с клиентами.
Поддержка перестала быть местом, куда пользователи приходят сообщить о проблеме.
Сегодня это один из главных источников сигналов для развития продукта. Именно здесь становится видно, что вызывает сложности у клиентов, какие процессы требуют улучшения и какие изменения принесут наибольшую пользу пользователям.
Главный вывод
С ростом количества обращений масштабировать нужно не команду, а систему.
Когда процессы прозрачны, измеримы и автоматизированы, поддержка перестает работать в режиме постоянного реагирования и становится инструментом развития продукта и бизнеса.
Смотрите также: