Представьте руководителя поддержки, у которого на дашборде все в норме: SLA выполняется, обращения закрываются вовремя, CSAT держится на хорошем уровне. Он предлагает команде новую практику: каждый раз, решив обращение, добавлять готовое решение в базу знаний, чтобы в следующий раз подобный вопрос не пришлось разбирать с нуля. Реакция предсказуема: «Вы хотите, чтобы к каждому тикету мы добавляли еще одно действие? Тогда AHT* вырастет, а SLA* окажется под угрозой», - скажет команда.

Возражение звучит убедительно и у него есть основания. Ниже - детальный разбор процесса с метриками: сколько на самом деле стоит сохранение знаний, что компания получает взамен и как KCS ускоряет работу поддержки.

AHT - это среднее время обработки одного обращения, один из ключевых показателей нагрузки на команду техподдержки и SLA. Добавляем к работе над тикетом ещё один шаг - создание или привязку статьи. Логично, что время на обработку тикета растет. 

AHT - полезная метрика, но в одиночку она обманчива: ее легко «улучшить» во вред делу, закрывая обращения быстрее за счет качества и роста переоткрытий тикетов. 

Да, при решении обращения добавляется одно действие - зафиксировать решение в статье базы знаний. Но это действие измеряется секундами. 
Все, что следует за ним, работает на производительность агента: меньше повторной работы, быстрее поиск готового ответа, сокращение онбординга новичков, сохранение экспертизы в компании.

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

Внедрение методологии KCS правильнее рассматривать с точки зрения инвестиций. «Актив» здесь - база знаний, «вложение» — небольшая часть AHT, которую агент тратит на добавление статьи при решении обращения. Прибыль превышает вложение в разы: 

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

Больше от агента в этот момент ничего не требуется. Сколько времени занимают несколько кликов мышью? Статистически - меньше минуты. И это верхняя граница: при привязке уже существующей статьи времени уходит еще меньше.

Одна минута - это много или мало? Все зависит от поддерживаемого продукта и вашего текущего AHT.

Например, AHT равен 10 минутам. Тогда дополнительная минута - это +10% к времени обработки в моменте. Для SLA и для агента это ощутимо, спорить не будем. Но это вложение, а не потеря. Теперь посмотрим на возврат.
Даже если считать выгоду только по одному показателю — по AHT, — снижение времени работы над тикетом при внедренном KCS достигает 50–60%. 
Кейс: вложили +1 минуту (+10%), получили −50–60%. Итоговое снижение AHT с учетом инвестиции — порядка 40–50%. То есть тикет, который занимал 10 минут, со временем решается за 5–6.

А если AHT измеряется не минутами, а десятками минут, часами или даже днями (такие продукты тоже есть), то одна минута на черновик - это статистическая погрешность. В этом случае почти весь эффект уходит в чистую прибыль: расход незаметен, а результат тот же. Чем сложнее поддерживаемый продукт и дороже обращения, тем выгоднее для компании внедрение KCS.

Поясним на втором примере. Пусть продукт сложный и среднее обращение разбирается два часа. Минута на черновик - это меньше 1% AHT, на грани измеримости. А снижение на 50–60% означает, что в зрелом состоянии такое обращение решается за 50–70 минут вместо двух часов. Инвестиция почти невидима, а отдача — максимальна.

Откуда берётся снижение времени решения обращений на 50–60%? Изменения происходят из-за того, что меняется сам процесс работы:

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

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

• меньше повторной работы - одинаковые вопросы не решаются по второму, третьему, десятому разу. Требуется лишь проверить наличие подобного обращения, скопировать ответ и отправить клиенту;
• быстрее поиск - чтобы найти статью не нужно покидать хелпдеск - релевантная статья под рукой. Экономия времени на переключение между инструментами также экономит время. По статистике, 1-5 часов в день агенты тратят на поиск информации и переключаются между экранами для поиска;
• меньше зависимости от «носителей знаний» — знания перестают жить в голове ключевого агента, экспертиза команды накапливается и доступна всем;
• быстрый онбординг - новичку есть на что опереться: агент с 2-недельным стажем обладает той же экспертизой, что и агент с 2-летним стажем;
• снижение нагрузки на команду - полезная база знаний позволяет клиентам самостоятельно решать простые вопросы, не обращаясь к агентам.

AHT удобно измерять, поэтому вокруг него и строятся споры. Но производительность команды измеряется не только скоростью решения обращений.
Постоянная ручная работа без опоры на знания ведет к выгоранию и текучке кадров. А каждый ушедший агент уносит часть знаний с собой — и круг замыкается. 

KCS разрывает его: знание остаются в базе знаний, а не в голове агентов, поэтому уход человека не повлияет на качество поддержки. Снижается текучка — растет уровень экспертизы в команде, и это тоже производительность, просто в более длинном горизонте.

Есть и эффект для продукта. Статистика по тому, какие статьи и обращения встречаются чаще, показывает первопричины проблем. Их устранение снижает поток обращений еще до того, как они возникнут, — это самый дешевый способ повысить производительность: не обрабатывать обращение быстрее, а не получать его вовсе.

Инвестиция в KCS проваливается в одном предсказуемом сценарии — когда фиксация знаний оторвана от процессов. Несколько вещей держат расход маленьким, а отдачу — реальной:
•  Фиксировать знание в момент решения, а не «в конце дня».
Отложенная статья либо не пишется вовсе, либо пишется по памяти и теряет точность.
•  Не требовать «идеальных» статей.
Черновик из трех скопированных блоков полезнее гипотетической статьи, которая так и не была написана. Качество дорабатывается по мере переиспользования: востребованные статьи улучшаются, невостребованные отмирают.
•  Измерять переиспользование, а не количество статей.
Ценность создает не объем базы знаний, а то, как часто из нее берут готовые решения.
•  Встроить процесс в инструмент.
Если статья создается в одном окне с тикетом за несколько кликов — это ускоряет процесс и повышает мотивацию агентов. 

Вся эта арифметика работает при одном условии: фиксация знания должна стоить агенту секунды, а не минуты. Если для создания статьи нужно выйти из тикета, открыть отдельную систему и оформить материал «по правилам», инвестиция перестает быть маленькой — и сопротивление команды оправданно.

Поэтому внедрить KCS проще и быстрее, когда методология заложена в механику инструмента, а не существует обособленным модулем. Swarmica построена вокруг KCS: решая обращение, агент получает подсказку создать или дополнить статью прямо в окне работы — те самые несколько кликов. Одна база знаний из единого источника питает агентов, клиентский self-service и ИИ-ассистента.

Отдельно про ИИ: любой ИИ-ассистент настолько хорош, насколько хорош контент под ним. На хаотичной устаревшей базе знаний он лишь быстрее выдает неверные ответы. KCS — это и есть механизм, который держит базу знаний в форме, а значит, делает осмысленной и автоматизацию, и использование ИИ.