База знаний становится полезной, когда человек находит ответ на свой вопрос и может выполнить действие без дополнительной переписки. Большой архив ответов операторов этому условию не соответствует: внутри встречаются устаревшие правила, частные исключения и сообщения, понятные только участникам диалога. ИИ удобно использовать для разбора такого архива и черновиков статей, если источники правил проверяются отдельно.
Гайд подготовлен для Tarasov Code — проекта Ильи Тарасова и TarasovWeb.
Отделите утверждённые правила от переписки
Соберите действующие инструкции, условия обслуживания, описание интерфейса и обезличенные обращения. Пометьте тип каждого источника. Ответ оператора может подсказать пользовательскую формулировку, но не должен автоматически становиться общим правилом. Например, разовая ручная компенсация не означает, что компенсация положена каждому обратившемуся.
Создайте реестр: документ, владелец, дата проверки, версия продукта, область действия. Документы с неизвестной актуальностью отправьте на уточнение. Если два источника противоречат друг другу, не просите модель выбрать более уверенно написанный. Решение должен дать ответственный сотрудник, иначе база знаний просто закрепит случайную ошибку.
Проектируйте статьи вокруг задач
Попросите ИИ сгруппировать обращения по намерению пользователя: изменить адрес доставки, восстановить доступ, скачать закрывающие документы. Не используйте внутренние названия отделов в качестве основной навигации. Клиент редко знает, что его вопрос относится к «операционному сопровождению второго уровня».
Для каждой темы задайте единую карточку: кому подходит инструкция, какие условия нужны, последовательность действий, ожидаемый результат, частые ошибки и путь эскалации. Часть «когда инструкция не подходит» особенно важна. Она останавливает пользователя до того, как он выполнит неверное действие для другого тарифа, роли или версии интерфейса.
Учебный пример: изменение адреса
Предположим, в 120 обращениях за месяц 28 касаются смены адреса. В действующих правилах есть три состояния заказа: принят, собран, передан перевозчику. Для первого разрешено редактирование в кабинете, для второго нужен оператор, для третьего действует отдельный порядок перевозчика. Одна короткая фраза «измените адрес в настройках» будет неверна в двух случаях из трёх.
Черновик статьи должен начинаться с проверки статуса заказа. Затем идут три самостоятельные ветки с конкретным результатом. Если источник не содержит срок обработки обращения оператором, нельзя добавлять обещание «в течение часа». Вместо этого укажите способ отслеживания ответа, если он подтверждён документацией, либо вынесите вопрос о сроке владельцу процесса.
Подготовь статью поддержки по теме «Изменить адрес доставки».
Используй утверждённые правила как источник фактов.
Обращения используй только для понимания вопросов и словаря клиентов.
Структура: кому подходит, проверка статуса, действия по состояниям,
ожидаемый результат, ограничения, обращение к поддержке.
Для каждого правила укажи ID источника в рабочей версии.
Не придумывай кнопки, сроки, компенсации и возможности продукта.
Отдельно перечисли пробелы и противоречия исходных документов.
Правила: [текст]. Обращения: [обезличенные примеры].Проверьте статью на вопросах, которые она должна закрыть
Возьмите несколько обращений, не использованных при подготовке. Дайте сотруднику только статью и попросите ответить клиенту. Если требуется знание, которого в документе нет, исправьте пробел. Если ответ найден, но долго, пересмотрите заголовки, порядок блоков и поисковые синонимы. Название «Редактирование реквизитов доставки» может проигрывать простому «Как изменить адрес заказа».
Для автоматического помощника дополнительно проверяйте, возвращает ли поиск нужную статью и правильную ветку. Ошибка поиска отличается от ошибки текста: переписывание инструкции не всегда исправляет плохую выдачу. Храните тестовые вопросы, ожидаемые источники и допустимые варианты ответа. При изменении правил повторяйте именно затронутые проверки.
Добавьте к статье поисковые формулировки, которыми пользуются клиенты, включая распространённые бытовые названия. При этом не вставляйте длинный список синонимов в основной ответ: они могут храниться в метаданных или настройках поиска. Различайте публичную инструкцию и внутреннюю памятку оператора. Внутренняя памятка может содержать порядок проверки обращения, тогда как клиенту нужен только доступный ему маршрут. Если один материал используется в обоих местах, проверьте, не раскрывает ли он служебные действия и не предлагает ли пользователю недоступный шаг.
Что проверить перед публикацией
- У каждого обязательного правила есть актуальный источник.
- Пошаговые действия воспроизводятся в указанной версии интерфейса.
- Исключения не спрятаны после основного обещания.
- Контакты и маршрут эскалации существуют.
- Назначены владелец статьи и дата следующей проверки.
Частые вопросы
Можно ли сразу обработать весь архив?
Лучше начать с одной частой темы и проверить схему. Массовое создание статей до согласования правил увеличивает количество материалов, требующих переделки.
Нужна ли отдельная статья на каждую формулировку?
Нет. Разные формулировки одного намерения можно объединить через понятный заголовок, синонимы и ссылки. Разделять стоит различные действия и условия.
В качестве справочника по написанию последовательных действий используйте рекомендации Google по процедурам. Они помогают редактуре, но не заменяют ваши утверждённые правила обслуживания.