Регистрация
Обновлено:
10 min read
Оценить

Как мы в 11 раз сократили время реакции техподдержки Kaiten

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

Как мы в 11 раз сократили время реакции техподдержки Kaiten
Содержание
Kaiten
Управляйте задачами, проектами и командой в одном месте
Попробовать бесплатно
Kaiten
Покажет, чем занята команда и где застревают проекты
Попробовать бесплатно

В 2020 году основатель и СТО Kaiten лично отвечал на каждый запрос клиентов. Продукт рос, поэтому к 2024 году только двух специалистов не хватало. Сложные задачи зависали, разбор идей по улучшению продукта стоял, отчетность просто копилась в Excel. Стало ясно — без кардинальных перемен отдел ждал коллапс. 

Это кейс о том, как мы перестроили все: от команды и процессов до аналитики, расширили отдел, научились в 11 раз быстрее реагировать на обращения и в 7 раз быстрее их закрывать. Никита Крицкий, менеджер продукта, и Дмитрий Кирюхин, руководитель службы поддержки Kaiten, рассказали, с какими трудностями столкнулись, какие уроки извлекли и чего удалось достичь. 

Kaiten — российский сервис для совместной работы. Все процессы компании в одном месте: проекты, задачи, цели, сотрудники, документы, переписки, отчеты, заявки.
Попробовать бесплатно

Исходная точка: как все было устроено

История техподдержки Kaiten началась с прямого вовлечения основателей. В 2020 году за все клиентские обращения отвечал сам Вячеслав Цырульник, сооснователь и технический директор Kaiten. Он был тем человеком, кто лично общался с клиентами, вникал в их проблемы и отвечал на вопросы.

По мере роста продукта Вячеслав понял: нужны отдельные специалисты. Так в 2022 году в команде появился первый сотрудник поддержки Лиза, а через год к ней присоединился Дин. Вместе они работали с основным объемом поступающих заявок. В 2023-2025 годах вместе с ними отдел развивал Никита Крицкий, менеджер продукта.

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

Никита Крицкий, менеджер продукта

Большинство заявок поступали через собственный модуль Kaiten Service Desk, остальные — по электронной почте. Кнопка-ссылка на портал поддержки уже тогда была интегрирована прямо в интерфейс сервиса. 

Так выглядел интерфейс службы поддержки, где пользователи оставляли заявки

Отчетность и аналитику вели отдельно в Excel. Сотрудники каждый день вручную записывали, сколько обращений и на какие темы они обработали, а также сколько времени на это ушло. В среднем они обрабатывали 1000-1200 заявок в месяц, а среднее время ответа было 20 минут.

По мере роста клиентской базы и количества обращений стали зарождаться проблемы, с которыми нужно было разбираться:

  • Нет руководителя. У команды не было выделенного лидера, который мог бы системно развивать и координировать проект. 
  • Нет распределения заявок. Все тикеты брали на себя сотрудники поддержки. Если требовались более глубокие знания, запросы вручную перенаправляли в отделы продаж и разработки. Нужно было, чтобы система автоматически распределяла сложные заявки на L2-L3 или в отдел разработки на основе тематики заявок.
  • Нет планов по масштабированию. Количество компаний-клиентов и лицензий постоянно росло, функциональность продукта усложнялась, параллельно росло количество обращений. Никто не думал о том, как развивать отдел поддержки.
  • Нет отчетности. Некому было заниматься глубокой аналитикой — сотрудники не отслеживали время ответа, категории запросов или удовлетворенность клиентов. Таблица в Ecxel не показывала реальную картину нагрузки и эффективности отдела.

Это был период, когда команда справлялась с количеством заявок, но внутренняя организация работы требовала серьезных изменений, чтобы справиться с ростом компании.

👉
Подробнее об этом этапе работы службы поддержки Kaiten рассказывала сама Лиза в статье «Опыт Kaiten: как организовать поддержку пользователей в модуле Service desk»

Накопившиеся проблемы и триггеры изменений

Функционал Kaiten активно расширялся, росло количество лицензий и клиентов с разными тарифами. К концу 2023 года стало очевидно: Лиза и Дин пока справлялись с нагрузкой, но уже работали на пределе. 

В начале 2024 года наняли нового сотрудника — Андрея Харитонова, но все равно команда с трудом закрывала обращения, 

Никита Крицкий построил тренд развития и понял, что уже через полгода нагрузка вырастет в 1,5 раза, с чем команда уже не справится.

Чем выше кривая, тем сложнее справляться с задачами тем же маленьким коллективом

Были и другие сложности, которые становились более явными:

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

А еще существовал бэклог на 2 000 обращений из неразобранных пожеланий и запросов, многие из которых со временем становились неактуальными. Команда просто не успевала ими заниматься. 

Так выглядел бэклог пожеланий и предложений расширения функционала от клиентов

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

Преодоление сопротивления

Помимо перечисленных выше триггеров были и 2 других — руководство и разработчики неверно оценивали потребности отдела и не давали нужные ресурсы для работы. В чем была сложность? 

Обоснование найма новых сотрудников. Технический директор считал, что логичнее сделать больше автоматизаций, чем нанимать новых людей.

Чтобы доказать обратное, Никита и Дмитрий собрали детальную статистику по росту клиентской базы и обращений. Они объяснили руководству, что при текущих темпах роста никакая автоматизация не сможет полностью заменить дефицит кадров.

Собранные отчеты продвигали через разные каналы внутри компании с вовлечением HR-отдела и других директоров. Постепенно руководство согласилось с необходимостью расширения.

Получение доступов. Отдел разработки опасался выдавать поддержке расширенный доступ в административную панель. Это вынуждало специалистов поддержки постоянно обращаться к разработчикам, что создавало «бутылочное горлышко» и значительно увеличивало время решения заявки пользователя.

Для преодоления этого сопротивления Никита систематически собирал кейсы и фиксировал: 

  • сколько обращений за месяц передавали разработчикам; 
  • сколько времени ждали ответа;
  • какие задержки это вызывало. 

Наглядная статистика показала, что отсутствие доступа у поддержки не только неэффективно, но и вредит клиентскому сервису, отвлекая ценные ресурсы разработки.

Стало понятно, что нужно проводить глубокую трансформацию отдела, чтобы сделать его управляемым, масштабируемым и эффективным

Никита Крицкий, менеджер продукта

Трансформация: появление нового лидера и перестройка системы

Никита взял на себя координацию и проведение планерок, но у него не было ресурсов полностью посвятить себя развитию отдела. Поиск руководителя продолжили, но теперь шире определили его роль. Ждали, что новый сотрудник возьмет на себя:

  • оперативное руководство небольшой командой; 
  • постоянное улучшение процессов; 
  • отстаивание интересов отдела перед высшим руководством;
  • преобразование хаоса в гибкую и масштабируемую систему.

Обновление команды

Одновременно с поиском лидера шло формирование новой структуры команды, чтобы закрыть критические пробелы:

  • Усиление экспертизы L2/L3. Андрей Харитонов получил доступ к административной панели и занялся решением наиболее сложных и технических запросов, в том числе от клиентов серверной версии. Так сняли лишнюю нагрузку с разработчиков и освободили первую линию для быстрых ответов.
  • Восполнение и расширение штата. Привлекли 3 новых сотрудников на место опытных Лизы и Дина. Это позволило не только заменить уходящих, но и расширить команду, чтобы справляться с растущей нагрузкой.
Так стала выглядеть доска, когда сложные заявки выделили в линию поддержки L2

Трансформация отчетности

В отделе также отказались от ручной отчетности в Excel и перешли к системному сбору данных и аналитике в Kaiten. Стали строить наглядные дашборды и отслеживать основные метрики:

  • Нагрузка на сотрудника — визуализировали, кто сколько задач взял в работу и какая у каждого сотрудника нагрузка.
  • Количество обращений — отслеживали число заявок на одну платящую компанию или лицензию, что позволяло прогнозировать будущий рост и планировать ресурсы.
  • Типы и категории запросов — определяли самые частые запросы и «узких мест» в продукте.
Мы постоянно собирали разную информацию и статистику. После внедрения дашбордов по категориям тикетов и времени решения стало видно, куда направлять внимание в первую очередь.

Дмитрий Кирюхин, руководитель службы поддержки Kaiten

Оптимизация процессов взаимодействия

Kaiten стал системой для управления всеми процессами службы поддержки. В модуль Service Desk добавили новые типы, классификации и категории для более точной работы с обращениями.  

У каждой задачи на доске есть свои сроки, на фасаде указаны причина обращения и тег

Продумали, как оптимизировать некоторые процессы:

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

Никита Крицкий, менеджер продукта

Никита и Дмитрий совместно выстроили систему эскалации проблем. Если вопрос не получалось решить на уровне специалиста, он передавался руководителю, а в критических случаях — техническому или коммерческому директору.

Выстраивание онбординга через базу знаний и видео

Мы хотели, чтобы сотрудники быстрее погружались в продукт, и с этим помогла база знаний. Каждая новая фича или изменения в интерфейсе всегда после завершения разработки проходили через публикацию в базу знаний. Для статьи в базу описывали возможности фичи, на что она влияет и как работает. 

Сотрудники саппорта тоже могли редактировать материалы в базе знаний. Например, вносить правки, когда видели в тексте неактуальную информацию.

Если нужно было писать с нуля, кто-то из команды маркетинга шел к разработчикам и задавал все вопросы, а потом составлял материал. 

Никита Крицкий, менеджер продукта

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

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

Запуск мастер-групп

Стали регулярно проводить мастер-группы — созвоны, на которых команда обсуждала и разбирала сложные или проблемные кейсы. Это позволилоиспользовать разнообразный опыт и бэкграунд каждого члена команды (от технического до клиентского), выработать совместные решения и учиться на уже закрытых обращениях.

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

Взаимопомощь и гибкость

В команде всегда поощряли взаимопомощь. Не было жестких рамок, запрещающих обращаться к коллегам за советом или помощью по сложному тикету.

Действовал простой алгоритм: сначала попробуй решить сам, затем, если не разобрался и не нашел ответа в Базе знаний, обращайся к коллегам, в том числе с сотрудниками других отделов и руководителем. Это создавало атмосферу поддержки и ускоряло обучение.

Результаты и текущее состояние

В октябре 2025 года команда состояла из 5 специалистов по облачным и серверным версиям под руководством Дмитрия Кирюхина.

Чтобы эффективность отдела была максимальной, внутри команды четко распределили роли:

  • Андрей Харитонов, как самый опытный сотрудник, работает на линии L2-L3, отвечает за помощь пользователям серверной версии Kaiten, требующей глубоких технических знаний и специфического подхода.
  • Юля, Максим, Лиза и Полина сфокусированы на поддержке пользователей облачной версии продукта.

Как проходит рабочий день. Рабочий день команды поддержки теперь четко структурирован:

  • утренние и вечерние планерки для синхронизации; 
  • мониторинг очереди; 
  • распределение проектных задач; 
  • регулярные синхронизации со смежными отделами разработки и Customer Success.

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

Результаты:

Параметр

До

После

Размер отдела

1 сотрудник

руководитель и 4 специалиста

L2/L3 поддержка

-

Полноценная линия L2/L3

Доля клиентских обращений, которые перенаправили обращений руководителям

35-40%

10-15%

Время реакции на обращение

Высокое

↓ в 11 раз 

Время решения заявки

Высокое

↓ в 7 раз

Ведение отчетности

Excel, без анализа

Kaiten, анализ и отчеты по результатам

Также отдел адаптировался к будущему росту компании и постепенному увеличению количества заявок от пользователей.

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

В дальнейшем также планируем смотреть, изучать и искать узкие места, которые могут негативно повлиять на пользовательский опыт и устранять их.

Дмитрий Кирюхин, руководитель службы поддержки Kaiten

Что мы поняли в процессе трансформации

За время изменений команда поддержки Kaiten усвоила несколько уроков:

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

Kaiten выстроил все процессы службы поддержки через модуль Service desk (SD). Каждая компания, которой нужен SD, тоже может подключить модуль, настроить его и принимать заявки от внутренних и внешних пользователей. Это значительно упростит работу техподдержки и повысит лояльность клиентов.

Kaiten упрощает управление компанией — вся работа видна на одном экране
Попробуйте сами или приходите на демо — покажем на примере вашей команды и ответим на вопросы.
Попробовать Kaiten

Оставить заявку

Менеджер свяжется с вами, чтобы уточнить детали и в формате видео показать возможности системы, ответить на вопросы и помочь с настройкой.
Сколько человек в команде?
Сколько сотрудников в компании?

Оставить заявку

Наш менеджер свяжется с вами, чтобы помочь.

Оставить заявку

Расскажите о своей компании, и мы отправим вам подходящую презентацию.
Сколько сотрудников в компании?