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

Но оператор всё равно пишет коллеге: «Клиент получил товар с повреждённой упаковкой. Возврат оформлять как обычно?» Коллега отвечает по памяти. Клиент ждёт на линии, поэтому открывать регламент некогда.

Возможно, с базой всё в порядке. Просто полный документ оказался слишком далеко в тот момент, когда нужно принять решение. Или формат не тот. Или… Когда этих «или» набирается целая кучка, в голову приходит неожиданный вывод.

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

Утверждённое правило может храниться в базе знаний, а необходимые для работы сведения — появляться в карточке заказа, интерфейсе или пошаговом сценарии. 

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

Почему сотрудники идут в чат или бегут к опытным

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

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

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

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

Одно правило — несколько точек применения

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

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

Значит, при изменении регламента команда должна проверить все зависимые элементы:

• Какие данные оператор видит в карточке заказа.

• Какие вопросы задаёт по скрипту.

• Какие поля обязан заполнить.

• Когда передаёт обращение на согласование.

• На какую редакцию правила ссылаются подсказки и материалы.

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

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

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

Полный регламент оставляем в базе знаний

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

Такие материалы полезны и при обучении новичков. Прежде чем следовать подсказкам в интерфейсе, человек должен понимать, почему процесс устроен именно так.

В Teamly можно хранить регламенты, инструкции и описания процессов в одном пространстве и искать материалы по смыслу запроса. База остаётся местом, где сотрудник может подробно разобраться в правиле, а не единственным экраном, который ему приходится открывать во время звонка.

Контекст заказа показываем в CRM

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

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

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

Обязательный шаг закрепляем в интерфейсе

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

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

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

Последовательность действий оформляем как скрипт

В разговоре с клиентом важен порядок вопросов. Сначала оператор находит заказ и уточняет обстоятельства. Затем проверяет условия стандартного возврата. Если случай подходит — оформляет обращение; если нет — передаёт его на согласование.

Скрипт показывает следующую развилку по мере разговора. Это полезнее, чем держать перед глазами все возможные варианты возврата одновременно.

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

В Teamly можно создавать скрипты для продаж, поддержки и сервиса. Как связать базу знаний операторов и сценарии работы, подробнее разбирается в статье «База знаний для операторов поддержки банка: создаём основу для скриптов».

Нестандартный случай сохраняем как кейс

Теперь представим, что упаковка повреждена, но товар исправен, а клиент просит не возврат денег, а замену. Стандартный сценарий не даёт однозначного ответа. Оператор передаёт обращение на согласование, команда принимает решение.

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

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

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

ИИ помогает найти ответ — если есть источник

Оператор не обязательно знает название нужного документа. Он может спросить: «Можно ли оформить замену, если упаковка повреждена, а товар работает?» ИИ-ассистент помогает найти связанные материалы по смыслу вопроса и сформулировать ответ со ссылками на них.

Один из подходов к такой задаче — RAG: система сначала находит подходящие фрагменты в корпоративных материалах, а затем модель использует их при подготовке ответа. Как устроен этот подход и какие требования он предъявляет к базе знаний, разобрано в статье «Как заставить AI-ассистента работать с базой знаний в enterprise-компании. RAG-модель в архитектуре».

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

ИИ-ассистент Teamly работает с корпоративными материалами и может давать ответы со ссылками на статьи и документы. Область поиска можно ограничивать всей базой, пространством или конкретной статьёй. А вопросы, для которых не нашлось надёжного источника, полезно учитывать при пополнении базы знаний.

С чего начать

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

Для процесса возврата достаточно разобрать несколько реальных обращений и пройти три шага:

• Найдите источник правила. Где хранится утверждённый порядок, кто владеет процессом и как фиксируются изменения?

• Проследите путь сотрудника. Какие данные он ищет во время обращения, что спрашивает у коллег и на каком шаге теряет время или ошибается?

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

После этого станет понятно, какие знания достаточно оставить в статье, а какие пора встроить в рабочий процесс.

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