Как мы в 11 раз сократили время реакции техподдержки Kaiten
А еще в 7 раз ускорили решение запросов. Рассказываем про трансформацию нашей техподдержки

В 2020 году основатель и СТО Kaiten лично отвечал на каждый запрос клиентов. Продукт рос, поэтому к 2024 году только двух специалистов не хватало. Сложные задачи зависали, разбор идей по улучшению продукта стоял, отчетность просто копилась в Excel. Стало ясно — без кардинальных перемен отдел ждал коллапс.
Это кейс о том, как мы перестроили все: от команды и процессов до аналитики, расширили отдел, научились в 11 раз быстрее реагировать на обращения и в 7 раз быстрее их закрывать. Никита Крицкий, менеджер продукта, и Дмитрий Кирюхин, руководитель службы поддержки Kaiten, рассказали, с какими трудностями столкнулись, какие уроки извлекли и чего удалось достичь.
Исходная точка: как все было устроено
История техподдержки Kaiten началась с прямого вовлечения основателей. В 2020 году за все клиентские обращения отвечал сам Вячеслав Цырульник, сооснователь и технический директор Kaiten. Он был тем человеком, кто лично общался с клиентами, вникал в их проблемы и отвечал на вопросы.
По мере роста продукта Вячеслав понял: нужны отдельные специалисты. Так в 2022 году в команде появился первый сотрудник поддержки Лиза, а через год к ней присоединился Дин. Вместе они работали с основным объемом поступающих заявок. В 2023-2025 годах вместе с ними отдел развивал Никита Крицкий, менеджер продукта.
Техподдержка Kaiten уже тогда была квалифицированной и контактной, с сотрудниками было легко общаться и получать ответы на любые вопросы.
Никита Крицкий, менеджер продукта
Большинство заявок поступали через собственный модуль Kaiten Service Desk, остальные — по электронной почте. Кнопка-ссылка на портал поддержки уже тогда была интегрирована прямо в интерфейс сервиса.

Отчетность и аналитику вели отдельно в Excel. Сотрудники каждый день вручную записывали, сколько обращений и на какие темы они обработали, а также сколько времени на это ушло. В среднем они обрабатывали 1000-1200 заявок в месяц, а среднее время ответа было 20 минут.
По мере роста клиентской базы и количества обращений стали зарождаться проблемы, с которыми нужно было разбираться:
- Нет руководителя. У команды не было выделенного лидера, который мог бы системно развивать и координировать проект.
- Нет распределения заявок. Все тикеты брали на себя сотрудники поддержки. Если требовались более глубокие знания, запросы вручную перенаправляли в отделы продаж и разработки. Нужно было, чтобы система автоматически распределяла сложные заявки на L2-L3 или в отдел разработки на основе тематики заявок.
- Нет планов по масштабированию. Количество компаний-клиентов и лицензий постоянно росло, функциональность продукта усложнялась, параллельно росло количество обращений. Никто не думал о том, как развивать отдел поддержки.
- Нет отчетности. Некому было заниматься глубокой аналитикой — сотрудники не отслеживали время ответа, категории запросов или удовлетворенность клиентов. Таблица в Ecxel не показывала реальную картину нагрузки и эффективности отдела.
Это был период, когда команда справлялась с количеством заявок, но внутренняя организация работы требовала серьезных изменений, чтобы справиться с ростом компании.
Накопившиеся проблемы и триггеры изменений
Функционал Kaiten активно расширялся, росло количество лицензий и клиентов с разными тарифами. К концу 2023 года стало очевидно: Лиза и Дин пока справлялись с нагрузкой, но уже работали на пределе.
В начале 2024 года наняли нового сотрудника — Андрея Харитонова, но все равно команда с трудом закрывала обращения,
Никита Крицкий построил тренд развития и понял, что уже через полгода нагрузка вырастет в 1,5 раза, с чем команда уже не справится.

Были и другие сложности, которые становились более явными:
- Усложнение запросов. Kaiten привлекал все больше корпоративных клиентов, чьи вопросы требовали глубокого технического погружения, а также много времени на решение. Доля сложных и специфических запросов значительно возросла.
- Отсутствие L2/L3 поддержки. У команды не было четко выделенных второй и третьей линий поддержки. Любые относительно сложные технические вопросы автоматически перенаправляли разработчикам. Это не только отвлекало инженеров от основных задач, но и затягивало время ответа клиентам.
- On-prem специфика. Уже тогда часть обращений была от клиентов с собственными серверами и локальными сетями. С каждым таким запросом тоже нужно было обращаться к разработчикам.
- Слепота в данных. Отчетность по-прежнему вели в Excel, поэтому руководство не понимало, какие типы запросов приходят чаще, какая реальная нагрузка у сотрудников, почему возникают задержки.
А еще существовал бэклог на 2 000 обращений из неразобранных пожеланий и запросов, многие из которых со временем становились неактуальными. Команда просто не успевала ими заниматься.

Основным триггером для изменений стал кадровый кризис стали необходимость в руководителе и изменения в кадровом составе. На тот момент у некоторых сотрудников появились новые роли в компании, а другие не были готовы взять руководящую должность.
Преодоление сопротивления
Помимо перечисленных выше триггеров были и 2 других — руководство и разработчики неверно оценивали потребности отдела и не давали нужные ресурсы для работы. В чем была сложность?
Обоснование найма новых сотрудников. Технический директор считал, что логичнее сделать больше автоматизаций, чем нанимать новых людей.
Чтобы доказать обратное, Никита и Дмитрий собрали детальную статистику по росту клиентской базы и обращений. Они объяснили руководству, что при текущих темпах роста никакая автоматизация не сможет полностью заменить дефицит кадров.
Собранные отчеты продвигали через разные каналы внутри компании с вовлечением HR-отдела и других директоров. Постепенно руководство согласилось с необходимостью расширения.
Получение доступов. Отдел разработки опасался выдавать поддержке расширенный доступ в административную панель. Это вынуждало специалистов поддержки постоянно обращаться к разработчикам, что создавало «бутылочное горлышко» и значительно увеличивало время решения заявки пользователя.
Для преодоления этого сопротивления Никита систематически собирал кейсы и фиксировал:
- сколько обращений за месяц передавали разработчикам;
- сколько времени ждали ответа;
- какие задержки это вызывало.
Наглядная статистика показала, что отсутствие доступа у поддержки не только неэффективно, но и вредит клиентскому сервису, отвлекая ценные ресурсы разработки.
Стало понятно, что нужно проводить глубокую трансформацию отдела, чтобы сделать его управляемым, масштабируемым и эффективным
Никита Крицкий, менеджер продукта
Трансформация: появление нового лидера и перестройка системы
Никита взял на себя координацию и проведение планерок, но у него не было ресурсов полностью посвятить себя развитию отдела. Поиск руководителя продолжили, но теперь шире определили его роль. Ждали, что новый сотрудник возьмет на себя:
- оперативное руководство небольшой командой;
- постоянное улучшение процессов;
- отстаивание интересов отдела перед высшим руководством;
- преобразование хаоса в гибкую и масштабируемую систему.
Обновление команды
Одновременно с поиском лидера шло формирование новой структуры команды, чтобы закрыть критические пробелы:
- Усиление экспертизы L2/L3. Андрей Харитонов получил доступ к административной панели и занялся решением наиболее сложных и технических запросов, в том числе от клиентов серверной версии. Так сняли лишнюю нагрузку с разработчиков и освободили первую линию для быстрых ответов.
- Восполнение и расширение штата. Привлекли 3 новых сотрудников на место опытных Лизы и Дина. Это позволило не только заменить уходящих, но и расширить команду, чтобы справляться с растущей нагрузкой.

Трансформация отчетности
В отделе также отказались от ручной отчетности в Excel и перешли к системному сбору данных и аналитике в Kaiten. Стали строить наглядные дашборды и отслеживать основные метрики:
- Нагрузка на сотрудника — визуализировали, кто сколько задач взял в работу и какая у каждого сотрудника нагрузка.
- Количество обращений — отслеживали число заявок на одну платящую компанию или лицензию, что позволяло прогнозировать будущий рост и планировать ресурсы.
- Типы и категории запросов — определяли самые частые запросы и «узких мест» в продукте.
Мы постоянно собирали разную информацию и статистику. После внедрения дашбордов по категориям тикетов и времени решения стало видно, куда направлять внимание в первую очередь.
Дмитрий Кирюхин, руководитель службы поддержки Kaiten
Оптимизация процессов взаимодействия
Kaiten стал системой для управления всеми процессами службы поддержки. В модуль Service Desk добавили новые типы, классификации и категории для более точной работы с обращениями.

Продумали, как оптимизировать некоторые процессы:
- Внедрили чат-ботов в чаты с клиентами — они автоматически передавали заявки из групповых чатов в Service Desk Kaiten.
- Создали канбан-доску для развития отдела — на ней команда создавала карточки с идеями улучшений процессов, автоматизации и расширения функционала продукта.
- Отказались от групповых чатов с клиентами в Telegram. В чаты добавляли саппорт, разработчиков, менеджеров продаж и других специалистов — всех, кто на разных этапах мог потребоваться для работы с клиентом. В переписках было легко потерять важную информацию по проблемам клиента. Это перегружало и рассеивало внимание специалистов. А клиенты обращались за помощью только через чаты.
Чем больше человек в чате, тем сложнее было разобраться. Например, когда в одном чате добавляли по 20 человек, каждый из них что-то писал и обсуждал. В итоге саппорту приходилось отслеживать все сообщения, чтобы увидеть проблему клиента и помочь ему.
Никита Крицкий, менеджер продукта
Никита и Дмитрий совместно выстроили систему эскалации проблем. Если вопрос не получалось решить на уровне специалиста, он передавался руководителю, а в критических случаях — техническому или коммерческому директору.

Выстраивание онбординга через базу знаний и видео
Мы хотели, чтобы сотрудники быстрее погружались в продукт, и с этим помогла база знаний. Каждая новая фича или изменения в интерфейсе всегда после завершения разработки проходили через публикацию в базу знаний. Для статьи в базу описывали возможности фичи, на что она влияет и как работает.
Сотрудники саппорта тоже могли редактировать материалы в базе знаний. Например, вносить правки, когда видели в тексте неактуальную информацию.
Если нужно было писать с нуля, кто-то из команды маркетинга шел к разработчикам и задавал все вопросы, а потом составлял материал.
Никита Крицкий, менеджер продукта
Оставалось выстроить детальный процесс онбординга, которому не хватало детализации. Первым сотрудникам и руководителям пришлось самостоятельно разбираться в продукте и особенностях работы. Например, когда появился Дмитрий, он сам изучал продукт, а потом составил для себя план задач на испытательный срок. С руководителем, который был до него, Никита созванивался каждый день и объяснял нюансы работы продукта и его инструменты.
Позже для новых сотрудников разработали план онбординга, куда включили изучение базы знаний и просмотр обучающих видео.

Запуск мастер-групп
Стали регулярно проводить мастер-группы — созвоны, на которых команда обсуждала и разбирала сложные или проблемные кейсы. Это позволилоиспользовать разнообразный опыт и бэкграунд каждого члена команды (от технического до клиентского), выработать совместные решения и учиться на уже закрытых обращениях.
Регулярно анализировали закрытые тикеты и определяли, где можно действовать эффективнее или решить проблему иным способом. Такой анализ помогал постоянно повышать качество ответов и не допускать новых ошибок.
Взаимопомощь и гибкость
В команде всегда поощряли взаимопомощь. Не было жестких рамок, запрещающих обращаться к коллегам за советом или помощью по сложному тикету.
Действовал простой алгоритм: сначала попробуй решить сам, затем, если не разобрался и не нашел ответа в Базе знаний, обращайся к коллегам, в том числе с сотрудниками других отделов и руководителем. Это создавало атмосферу поддержки и ускоряло обучение.
Результаты и текущее состояние
В октябре 2025 года команда состояла из 5 специалистов по облачным и серверным версиям под руководством Дмитрия Кирюхина.
Чтобы эффективность отдела была максимальной, внутри команды четко распределили роли:
- Андрей Харитонов, как самый опытный сотрудник, работает на линии L2-L3, отвечает за помощь пользователям серверной версии Kaiten, требующей глубоких технических знаний и специфического подхода.
- Юля, Максим, Лиза и Полина сфокусированы на поддержке пользователей облачной версии продукта.
Как проходит рабочий день. Рабочий день команды поддержки теперь четко структурирован:
- утренние и вечерние планерки для синхронизации;
- мониторинг очереди;
- распределение проектных задач;
- регулярные синхронизации со смежными отделами разработки и Customer Success.

Команда встречается на регулярных созвонах, в остальном работает в асинхронном режиме или собирается в виртуальных коворкингах для совместной работы в реальном времени.
Результаты:
Также отдел адаптировался к будущему росту компании и постепенному увеличению количества заявок от пользователей.

Компания перешла от интуитивных решений к принятию решений, основанных на данных. Теперь вместо того, чтобы просто реагировать на проблемы, команда может заранее их предотвращать, опираясь на метрики.
В дальнейшем также планируем смотреть, изучать и искать узкие места, которые могут негативно повлиять на пользовательский опыт и устранять их.
Дмитрий Кирюхин, руководитель службы поддержки Kaiten
Что мы поняли в процессе трансформации
За время изменений команда поддержки Kaiten усвоила несколько уроков:
- Руководитель нужен раньше, чем кажется. Даже если команда состоит из опытных специалистов, им нужен человек, который будет развивать отдел, отстаивать его интересы и обеспечивать ресурсы. Не стоит откладывать найм руководителя поддержки до тех пор, пока проблемы не станут критическими и неуправляемыми. Лучше всего растить сотрудников внутри штата, даже если не все хотят руководить.
- L3 — must-have для сложного продукта и on-prem. Если компания предлагает сложный многофункциональный продукт или работает с серверными решениями, то важно готовить выделенных специалистов с глубокими техническими знаниями (L2/L3). Отсутствие таких специалистов перегружает разработчиков и замедляет решение клиентских запросов.
- Telegram-чаты (групповые) убивают фокус. Они отвлекают сотрудников, усложняют отслеживание запросов и фиксацию решений. Переход на системный прием заявок через Service Desk (даже если из чатов их регистрирует бот) значительно повышает продуктивность.
- Нельзя вводить KPI без учета сложности и линии поддержки. Не стоит оценивать всех сотрудников по единым метрикам без учета сложности запросов и линии поддержки. Например, только по количеству закрытых тикетов. Это искажает результаты и может демотивировать. Важно, чтобы KPI отражали реальную ценность работы каждого специалиста.
- Автоматизация не заменяет людей при кратном росте. Без нее не обойтись, но нельзя отказаться от найма в пользу автоматизации, когда сотрудники уже перегружены. Это ведет к демотивации и выгоранию команды. Автоматизация может занять несколько месяцев, за это время проблема усугубится, сотрудники еще больше устанут, а результата может не появиться.
Kaiten выстроил все процессы службы поддержки через модуль Service desk (SD). Каждая компания, которой нужен SD, тоже может подключить модуль, настроить его и принимать заявки от внутренних и внешних пользователей. Это значительно упростит работу техподдержки и повысит лояльность клиентов.