Растем умом, а не числом
В новой статье рассказываем, как команда клиентского сервиса ITSM 365 выстроила систему обмена знаниями, чтобы не решать типовые вопросы заново и не зависеть от знаний отдельных специалистов.
Кира, бизнес-аналитик ITSM 365 и куратор командной базы знаний, собрала подходы и инструменты, которые помогают сохранять накопленный опыт внутри команды, быстрее обучать новичков и справляться с растущим количеством обращений без потери качества.
Проблема: больше людей — больше хаоса
Кажется, что с ростом количества клиентов проблему можно решить самым очевидным способом — расширить команду. Но на самом деле все оказывается сложнее.
Чем больше людей подключается к работе с обращениями клиентов, тем больше времени начинает уходить на передачу знаний и согласование действий.
Почему так происходит?
- нужно погрузиться в контекст обращения;
- одну и ту же работу иногда выполняют несколько человек;
- при передаче заявки между линиями поддержки часть информации может потеряться;
- качество ответа начинает зависеть от опыта конкретного сотрудника;
- команда снова и снова тратит время на поиск решений для вопросов, с которыми уже сталкивалась раньше.
Иногда работа начинает напоминать квест‑комнату: один уже нашел решение, второй параллельно ищет его заново, а третий еще только пытается разобраться, что вообще произошло.
Первая идея в такой ситуации кажется очевидной: «Давайте просто выделим каждому клиенту отдельного специалиста».
Но вместе с новыми людьми начинает расти и объем знаний, который нужно передавать. Новичкам не хватает технической экспертизы и понимания контекста работы с клиентами, опытные сотрудники все чаще отвлекаются на помощь коллегам, а качество ответов становится слишком зависимым от того, кто именно взял заявку.
Именно тогда мы пришли к выводу, что масштабировать нужно не количество людей, а знания внутри команды.
На чем строится культура обмена знаниями
Мы довольно быстро поняли, что решить проблему одной базой знаний не получится. Даже самая подробная документация бесполезна, если ей неудобно пользоваться, она устаревает или сотрудники вспоминают о ней в последнюю очередь.
Со временем в нашей команде сформировались четыре принципа, которые помогают не просто хранить знания, а постоянно использовать и развивать их.
Актуальность
Сначала нам казалось, что достаточно просто начать писать статьи, но сама база знаний тоже требует постоянной поддержки. Когда мы начали переносить накопленный опыт из заявок в базу знаний, столкнулись с новой проблемой: по одному и тому же вопросу появлялось несколько статей с похожим содержанием. Каждая из них могла быть правильной, но найти актуальную становилось все сложнее.
Так в команде появилась роль куратора базы знаний. Его задача — не только проверять новые материалы, но и следить за тем, чтобы база знаний развивалась как единая система:
- проверяет, существует ли статья по этой теме;
- помогает определить, действительно ли нужен новый материал;
- сопровождает автора во время подготовки статьи;
- следит за соблюдением редполитики;
- помогает сделать текст понятнее для клиентов.
Со временем появились и процессы вокруг этой роли. Мы вместе со смежными командами регулярно пересматриваем существующие статьи, автоматизируем рутинные проверки и сейчас тестируем ИИ, который помогает искать нарушения редполитики и предлагать правки по оформлению.
При этом мы не пополняем базу знаний «ради количества». Новые статьи появляются тогда, когда мы видим повторяющийся запрос от клиентов или удачное решение, которое может пригодиться другим. Интересные вопросы и сильные ответы мы сразу отмечаем как кандидатов для новых материалов.
Доступность
Мы стараемся сделать так, чтобы поиск информации занимал меньше времени, чем ожидание ответа от другого специалиста.
В нашем случае статьи доступны прямо в портале поддержки. Например, при выборе категории заявки сотрудник сразу получает подборку подходящих материалов. Если клиент обращается по вопросам интеграции с мессенджерами, система предлагает статьи именно по этой теме и с учетом используемого продукта.
Признание
Мы рассказываем о каждой новой статье в отдельном канале и обязательно отмечаем всех, кто участвовал в ее подготовке.
На первый взгляд кажется, что такая практика должна увеличить количество новых материалов. Но, скажу честно, этого почти не произошло — и я считаю, что это совершенно нормально.
Гораздо важнее оказался другой эффект. Люди перестали воспринимать работу со статьями как дополнительную обязанность. Новички быстрее начинают предлагать изменения и не боятся редактировать существующие материалы, а опытные сотрудники охотнее делятся своими знаниями вместо того, чтобы хранить их только у себя.
Публичное признание не заменяет мотивацию, но помогает показать, что вклад в базу знаний — такая же важная часть работы, как решение клиентских задач.
Ответственность
Сегодня в базе знаний около 500 статей. Проверять каждую самостоятельно уже невозможно. Поэтому ответственность за актуальность материалов постепенно стала общей задачей команды.
Если коллеги замечают устаревший скриншот, неработающую ссылку или неточное описание, они сообщают об этом мне. В зависимости от объема изменений я обновляю материал сама или передаю его одному из авторов.
Сейчас у нас 15 активных авторов, заместитель куратора базы знаний, а статьи обновляются по мере необходимости: в среднем по две-три в неделю.
Что помогает нам переиспользовать знания
Большинство инструментов, о которых пойдет речь дальше, появились не потому, что мы заранее придумали идеальную систему. Почти все они выросли из конкретных проблем: что‑то предложили инженеры, что‑то — специалисты поддержки, а что‑то вообще задумывалось как временное решение, но осталось с нами на годы.
Многие из этих решений довольно простые. Именно поэтому они и работают: сотрудникам не нужно менять привычный процесс или помнить о каком‑то дополнительном инструменте — знания становятся частью ежедневной работы.
База знаний
Одна и та же статья в базе знаний не может быть одинаково полезной и сотруднику поддержки, и клиенту. Первому нужны технические детали, внутренние регламенты и возможные ограничения. Второму — понятная инструкция, которая поможет решить задачу самостоятельно.
Поэтому мы разделили базу знаний на две части:
- Закрытый раздел для сотрудников — внутренние инструкции, документацию по порталу поддержки, регламенты, скрипты, технические настройки.
- Открытый раздел для клиентов — инструкции по работе с продуктами, ответы на популярные вопросы, лучшие практики.
Кроме разделения на открытую и закрытую части, система учитывает, какие продукты использует клиент. Благодаря этому пользователь видит только релевантные статьи.
Сотрудник и клиент работают с одной системой знаний, но каждый получает информацию на своем уровне детализации. Это позволяет избежать дублирования материалов и значительно упрощает их поддержку в актуальном состоянии.
А еще когда готовим новую статью для клиентов, стараемся показать ее человеку, который еще не погружен в тему: стажеру или коллеге из другой команды. Если текст понятен ему, скорее всего, он будет понятен и большинству клиентов.
Шаблоны комментариев
Если клиент регистрировал заявку с высоким приоритетом, мы, не задумываясь, подключали инженеров. Но позже выяснилось, что значительную часть таких обращений специалисты поддержки могли закрыть самостоятельно. Инженеры снова и снова повторяли одни и те же рекомендации, отвлекаясь от действительно сложных задач.
Так появились шаблоны комментариев. Они помогают уже в первые 10–15 минут дать клиенту подробный ответ, проверить базовые сценарии и собрать необходимую информацию до подключения инженеров.
Со временем шаблоны появились и для других типов обращений. В результате специалисты быстрее отвечают клиентам, а инженеры подключаются только там, где это действительно необходимо.
ML
Сегодня ML встроен сразу в несколько процессов. Но если убрать красивые слова про искусственный интеллект, мы используем его в первую очередь там, где он действительно экономит время специалистам.
- Анализ эмоционального фона
ML анализирует комментарии в заявке и определяет общий эмоциональный фон общения — позитивный, нейтральный или негативный.
Если система видит потенциально конфликтную ситуацию, отдел Customer Success может подключиться к работе раньше и помочь не доводить разговор до эскалации.
Как и любая модель, она иногда ошибается. Например, до сих пор плохо распознает иронию и может принять шутку клиента за негативную реакцию.
- Краткое содержание обсуждений
Еще один сценарий — подготовка краткого содержания длинных обсуждений.
Для этого в карточке заявки есть отдельная кнопка: специалист может обратиться к ИИ‑ассистенту, выбрать готовый промт и получить результат прямо в заявке. Раньше на это могло уходить около получаса. Сейчас — в среднем 3–5 минут.
Последний сценарий — поиск по заявкам, задачам и базе знаний. В отличие от обычного поиска по ключевым словам, ML учитывает смысл запроса и помогает находить похожие кейсы даже тогда, когда формулировки отличаются.
Это особенно полезно, когда специалист не знает, как именно похожую проблему описывали раньше.
Кроме базы знаний у нас есть еще один простой, но очень полезный инструмент — внутренние комментарии по клиенту. Они отображаются прямо в карточке заявки, поэтому специалист видит важный контекст во время общения.
Иногда в ходе работы мы что‑то обещаем: рассказать о новой функции, вернуться после релиза, уточнить информацию или предупредить о важных изменениях. В потоке заявок такие договоренности легко забываются, поэтому мы фиксируем их в общей заметке по клиенту. Так любой специалист, который подключается к обращению, сразу понимает, о чем мы договаривались раньше и что важно учесть в коммуникации.
Что интересно, этот инструмент появился как временное решение еще семь лет назад. Но мы до сих пор не нашли ничего удобнее — обычное текстовое поле продолжает работать лучше многих более сложных вариантов.
Мы стараемся, чтобы специалисту вообще не приходилось задумываться, существует ли статья по нужной теме. При выборе категории заявки портал автоматически предлагает подходящие материалы.
Эта же логика работает и для клиентов. Например, если пользователь хочет зарегистрировать заявку с высоким приоритетом, система сначала предлагает статьи, которые могут помочь восстановить работоспособность приложения самостоятельно.
Какую пользу мы в итоге получили
За несколько лет отдельные практики и инструменты сложились в единую систему работы со знаниями. Она не избавила нас от сложных задач, зато значительно сократила количество повторяющейся работы и сделала знания менее зависимыми от конкретных людей.
Быстрее решаем типовые вопросы
Раньше на вопрос вроде «Как добавить новую колонку в список заявок?» специалист в среднем тратил около 25 минут, а стажер — почти час. Причем значительная часть времени уходила не на решение самой задачи.
Сейчас достаточно открыть готовую статью из базы знаний — и такой вопрос обычно закрывается примерно за минуту.
Клиенты чаще находят ответы самостоятельно
Благодаря открытой базе знаний и системе рекомендаций часть типовых вопросов вообще перестала доходить до специалистов поддержки. Это экономит время не только команде, но и самим клиентам — многие задачи они могут решить сразу, не дожидаясь ответа специалиста.
Удается сохранять качество поддержки
Количество обращений продолжает расти, но средняя оценка работы с клиентами остается на уровне 4,9+.
Конечно, это результат не только базы знаний, но именно единый подход к работе с информацией помогает сохранять качество сервиса по мере роста команды.
Новички быстрее начинают работать самостоятельно
Мы стараемся подключать стажеров к реальным задачам как можно раньше. Если раньше новичок сначала долго изучал материалы, а уже потом приступал к практике, то сейчас база знаний становится частью самого процесса обучения. Например, мы включили работу с базой знаний в программу стажировок: в конце обучения новички проходят небольшой квиз, где им нужно быстрее остальных найти нужную статью.
Это помогает быстрее оценить прогресс сотрудника, а ему самому — научиться искать ответы самостоятельно, а не ждать помощи коллег.
Вместо заключения
За эти годы мы поняли простую вещь: знания сами по себе не работают. Недостаточно написать хорошую статью или собрать большую базу знаний. Культура обмена знаниями начинает работать тогда, когда найти нужную информацию самостоятельно проще, чем ждать ответа коллеги.
Необязательно сразу строить сложную систему. Иногда достаточно совсем небольшого решения: общего текстового поля, шаблона комментария или внутреннего канала, где сотрудники делятся опытом.
Главное — сделать так, чтобы знания не оставались в голове одного человека. Со временем даже небольшие решения начинают складываться в единую систему. Именно так произошло и у нас.
