Как масштабировать знания, а не нагрузку

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

С этим столкнулась команда клиентского сервиса ITSM 365. Кира, бизнес-аналитик клиентского сервиса и куратор командной базы знаний, рассказала, как команда постепенно выстроила систему, которая помогает не искать одни и те же решения снова и снова.

База знаний сама по себе проблему не решает

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

• Актуальность — обновляем материалы и следим, чтобы они не дублировались.
• Доступность — встраиваем статьи в рабочий процесс.
• Признание — публично отмечаем всех, кто участвовал в подготовке материалов.
• Ответственность — поддерживаем базу всей командой. 

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

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

Нужные инструкции должны быть под рукой

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

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

Иногда достаточно простого решения

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

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

ИИ там, где он действительно экономит время

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

Раньше на такую работу могло уйти около получаса, сейчас — в среднем 3–5 минут.

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

Что изменилось в работе

Раньше на вопрос «Как добавить новую колонку в список заявок?» специалист в среднем тратил около 25 минут, а стажер — почти час. Сейчас открываем готовую статью и обычно закрываем такой вопрос примерно за минуту. 

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

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