Что публиковать в базе знаний, а что оставить внутри команды

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

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

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

Публичная статья отвечает на вопрос клиента, а не показывает кухню поддержки

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

Хорошая публичная статья похожа на короткий ответ оператора, только без привязки к конкретному обращению. Например: «Как изменить email в аккаунте», «Как получить закрывающие документы», «Что делать, если не пришло письмо для входа».

В неё стоит выносить то, что клиент может сделать сам или понять без участия команды:

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

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

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

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

Внутренняя статья нужна там, где начинается решение оператора

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

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

Это не дублирование. Это две разные задачи.

Во внутреннюю базу стоит уносить:

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

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

Лучше написать грубее, но проверяемо: «Если клиент обратился в течение трёх дней после списания и ранее не получал компенсацию по этой причине, оператор может продлить доступ на семь дней без согласования». Если правило спорное, это уже видно. Его можно обсудить и поправить.

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

Один вопрос часто требует двух статей

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

Так удобно в день написания. Через месяц неудобно всем.

Клиенту мешают внутренние слова: «создать тикет», «передать во вторую линию», «проверить в CRM». Оператору мешают клиентские объяснения, потому что ему нужен короткий порядок действий. Редактор боится править: непонятно, какая часть видна наружу.

Лучше разделять пару сразу.

Публичная статья: «Как запросить возврат».
Внутренняя статья: «Возврат: проверка, исключения и эскалация».

Публичная статья: «Не получается войти в аккаунт».
Внутренняя статья: «Доступ: как проверять владельца аккаунта».

Публичная статья: «Как получить документы для бухгалтерии».
Внутренняя статья: «Закрывающие документы: где проверить реквизиты и кому передать запрос».

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

Если вы используете базу как источник для ИИ-ответов, это разделение становится ещё важнее. Ассистенту не всё равно, какие тексты лежат в базе: клиентская статья должна быть безопасной для ответа наружу, а регламент — полезным для подсказки оператору. Мы отдельно разбирали, почему регламенты для сотрудников и статьи для клиентов — разные тексты.

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

Риск раскрыть лишнее — не только про пароли и персональные данные

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

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

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

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

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

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

Разделение должно быть видно в структуре, а не только в голове

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

Нужны простые признаки.

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

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

Перед публикацией полезно прогнать статью через четыре вопроса:

1. Кто читатель: клиент или оператор?
2. Что он должен сделать после чтения?
3. Есть ли в тексте то, что нельзя показывать наружу?
4. Если другой сотрудник выполнит статью дословно, результат будет таким же?

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

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