Всем привет, я Роман Басалыко. Последние двадцать лет работаю с командами продуктовой технической поддержки. Эта статья — попытка честно описать, почему одни команды масштабируются без потери качества, а другие нанимают людей и всё равно не справляются.
По данным индустриальных исследований, одна заявка, решенная без участия инженера техподдержки — экономит в среднем $15–20. При потоке в тысячи заявок в месяц это уже существенные цифры.
Есть три признака того, что в техподдержке что‑то системно сломано:
Первый — лучшие инженеры заняты самыми простыми вопросами: клиент привык связываться с конкретным человеком.
Второй — каждый новый сотрудник учится полгода‑год, прежде чем его можно отпустить в самостоятельную работу со сложными заявками.
Третий — SLA формально соблюдается, но нагрузка все равно растет, CSAT падает, команда выгорает в режиме аврала, уровень стресса зашкаливает, спешка влечет за собой ошибки и ситуация ухудшается.
Если хотя бы два пункта про вас — у вас есть проблема, и это проблема со знаниями.
Техподдержка работает, как пожарная команда. Работа хорошая, но как пожар, так хоть увольняйся.
Но у нас же ITSM‑подход и ITIL‑процессы
Скажите вы.
ITIL хорошо решает операционные задачи: маршрутизацию, SLA, эскалации, отчётность. В том числе методика декларирует, что нужно выстраивать систему управления знаниями, получать знания из обращений, применять их на практике.
Но в данном случае ITIL как сова в анекдоте про мышей, которым она рекомендует стать ежиками, чтобы их не съели.
А как это применить на тактическом поле? В результате компания выстраивает всё более сложные процессы поверх фундаментального дефекта: знания живут в головах конкретных инженеров, а не в системе.
Это незаметно на старте, но становится критичным при масштабировании. Нанимаете второго инженера — нагрузка на первого не падает, потому что новый учится у него полгода. Нанимаете пятого — та же история. Линейный рост команды не даёт линейного роста производительности.
Есть метрика, которая это показывает наглядно: время до полной самостоятельности нового сотрудника. В среднем по рынку — 6–12 месяцев для сложной продуктовой поддержки. Это не проблема найма. Это симптом того, что знания не задокументированы в форме, с которой можно работать.
Что такое KCS и почему это не очередной фреймворк ради фреймворка. И не замена ITSM/ITIL
KCS (Knowledge‑Centered Service) — методологии уже больше 30 лет, но в России она пока мало распространена. Подход можно внедрить на любой ITSM‑платформе, но на практике это требует серьёзных доработок — классический хэлпдеск не задумывался под работу со знаниями в потоке. Поэтому всё чаще появляются системы, где KCS «зашит» в архитектуру с самого начала — например, Swarmica строится вокруг этой методологии, а не как надстройка над ней. Суть простая: знания создаются не отдельным отделом технических писателей, а прямо в процессе решения заявок. Инженер решил проблему — зафиксировал решение в базе знаний. Следующий, кто встретит похожую проблему, не тратит время на поиск с нуля.
Разница с традиционным подходом принципиальная. В классической модели база знаний — артефакт: ее создают технические писатели постфактум, она быстро устаревает и плохо отражает реальные паттерны обращений. В KCS база знаний — живой инструмент, который обновляется каждый раз, когда кто‑то с ней работает.
Важный момент для 2026 года: KCS — это «RAG» фундамент, который делает ии‑ассистентов полезными. ИИ в техподдержке работает ровно настолько хорошо, насколько хороша база знаний, которую он использует. Без структурированных актуальных знаний генеративная модель будет давать уверенные, но общие ответы вместо конкретных решений под ваш продукт. Давайте посмотрим, как это работает на конкретном примере — команды, которая прошла этот путь джедая от начала до конца.
Задача: Поднять CSAT хотя бы до 90
Дано: Команда поддержки продуктовой IT‑компании в области ИБ, 45 человек, сложный технологический стек, высокие требования к безопасности данных и блокеры внедрения в виде команды безопасников и юристов.
Хэлпдеск‑система настроена, но не масштабируется с ростом числа клиентов. Онбординг нового инженера занимает 3 месяца теории и ещё 9 месяцев до хорошего уровня. Среднее время решения заявки — 7 дней. База знаний есть, обновляется, но управляется командой технических писателей отдельно от техподдержки и потока заявок. Быстро устаревает и иногда статьи не соответствуют запросам, потому что строятся на семантическом ядре поисковой выдачи, а не на реальных кейсах.
После внедрения методологии KCS:
Метрика | До | После |
Онбординг нового инженера | ~12 мес. | ~3 мес. |
Среднее время решения заявки | 7 дней | 4 дня |
Время первого ответа | ~1 час | 15 минут |
Входящий объем обращений | — | −21% |
CSAT | ниже целевого | 97% |
CSAT 97% — не результат найма более вежливых инженеров. Контекст клиента — история обращений, особенности инсталляции, ограничения — виден в любой системе. Разница в том, что на основе этого контекста агент (человек или ИИ) сразу получает готовые варианты решения: применить напрямую или уточнить пару деталей. Это работает только потому, что за ними стоит живая база знаний — актуальная, проверенная на реальных кейсах. Один из новых сотрудников решил заявку за 20 минут в первые месяцы работы, воспользовавшись базой знаний.
Как устроена система изнутри
Статьи в базе знаний имеют два слоя. Внешний — публикуется на портале самообслуживания и индексируется в поисковиках и внешних ИИ‑системах. Статьи в базе знаний имеют два слоя. Внешний — публикуется на портале самообслуживания и индексируется в поисковиках и внешних ИИ‑системах. Популярные решения расходятся: их находят в Google, цитирует Яндекс GPT, на них ссылаются в профессиональных сообществах. Существующие клиенты получают ответ, не открывая заявку. Но эти же материалы видят и те, кто еще не клиент, — и приходят, потому что увидели экспертный контент именно по своей теме. «Правильная» база знаний работает одновременно как инструмент поддержки и как канал лидогенерации. Клиент может найти ответ до того, как создаст заявку. Внутренний — виден только инженерам: диагностические шаги, черновики, данные, которые нельзя показывать публично.
Из 45 человек в команде 15 — инженеры‑редакторы. Это не отдельный отдел документации — те же люди, которые решают заявки. Сейчас в базе около 1000 опубликованных статей, ещё 2000 в разных стадиях готовности. Каждая пятая заявка закрывается еще до обращения к инженеру.
Подводные камни, о которых не предупреждают
Сопротивление на старте — это нормально. Особенно если у команды уже есть работающее решение: самописная система, сильно кастомизированный хэлпдеск или просто привычный инструмент. В таких случаях смена системы воспринимается как риск — сложно, дорого, долго, и непонятно, станет ли лучше.
Но здесь важно честно оценить, с чем именно сравнивать. Самописная система на старте — это хорошо: точно под процессы, быстро, гибко. Проблемы появятся позже. С ростом продукта и команды система начинает обрастать исключениями и костылями, зависеть от решений, которые никто не документировал, и требовать все больше ресурсов на поддержку. В какой‑то момент происходит инверсия: вы уже не управляете системой — система управляет вами. Бизнес адаптируется под ограничения инструмента вместо того, чтобы инструмент работал на бизнес.
Три признака, что это уже происходит:
Никто не знает систему целиком — знания распределены по людям и частично «в головах»;
Любое изменение требует мини‑рефакторинга из‑за накопленных зависимостей;
На запросы к разработчику очередь на несколько месяцев.
Самописная система в этой точке — не актив, а накопленный риск. Просто привычный.
Второй типичный страх — сам переход. «Это займет год», «сломаем поддержку», «слишком много зависимостей». Страх обоснован, если переход делается неправильно: старую систему выключают, новую включают, команда разбирается на ходу. Рабочая альтернатива — параллельный запуск: новая система настраивается и тестируется, пока старая продолжает работать. Переключение происходит в один момент, без даунтайма, после того как команда уже освоилась. Именно так прошёл переход в упомянутом выше кейсе ИБ‑компании: внедрение заняло 2 месяца вместо ожидаемого года, поддержка не останавливалась ни на день.
Условия, без которых KCS не работает:
Не внедрять приказом сверху — найти группу энтузиастов на первые месяцы
KCS имеет смысл при команде от 10 человек — раньше накладные расходы перевешивают пользу
В первые три месяца часть команды скептически относилась к новому подходу: база ещё не была наполнена, польза не была очевидна. Через полгода скептиков практически не осталось — система начала экономить время тех же людей, которые раньше сомневались.
Что в итоге
Если команда поддержки выгорает, новички учатся год, а метрики не растут — проблема почти всегда не в процессах. Процессы можно докрутить за месяц, а систематизировать работу со знаниями — нет. Стандартные процессы отвечают за маршрутизацию и SLA, но не за то, как команда накапливает и использует опыт. Эта дыра не закрывается сама и не закроется новым наймом сотрудников — каждый новый человек просто удлиняет очередь на обучение у того единственного инженера, который «всё знает».
KCS — это не про документацию. Это про то, чтобы сделать знания рабочим активом команды, и органично встроить в ITIL‑процессы: каждое решение в заявке становится ресурсом для следующего запроса, нового сотрудника и в перспективе — ИИ‑ассистента. Без такого фундамента ИИ в поддержке будет давать уверенные, но бесполезные ответы; с ним — реально снимать нагрузку с инженеров.
Кейс ИБ‑компании показывает масштаб эффекта: онбординг сократился с года до трех месяцев, CSAT вырос до 97%, каждая пятая заявка закрывается до обращения к инженеру. Это не результат ребрендинга или волшебной системы — это результат того, что знания вынули из голов и положили туда, где с ними может работать вся команда.
Начинать стоит не с выбора инструмента, а с честного ответа на один вопрос: если завтра уволятся три ключевых инженера, что останется в компании — работающая поддержка или паника? Если второе — пора менять не процессы. Пора менять подход к знаниям!
