Когда пора обновлять статью

Статья справки редко устаревает в один день. Вчера она ещё спасала смену, сегодня оператор открывает её перед ответом и зависает: «Так, подождите, у нас же кнопка теперь в другом месте».

Формально текст есть. Ссылка в базе есть. Клиенту её можно отправить.

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

Вопрос вернулся в поддержку, хотя статья уже есть

Самый простой сигнал: клиент спрашивает то, что вроде бы закрыто статьёй.

Не один раз, а снова и снова. У вас есть инструкция «Как вернуть товар», но в чат всё равно приходят: «А если упаковку вскрыли?», «А деньги на карту или бонусами?», «А курьер заберёт или самому нести?»

Это не значит, что клиенты ленятся читать. Часто статья отвечает на главный вопрос, но пропускает развилки, из-за которых человек не может принять решение.

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

Если вопрос вернулся, не нужно сразу писать новую статью. Сначала посмотрите, чего не хватает в старой:

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

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

Оператор отвечает иначе, чем написано в тексте

Второй сигнал видно не клиенту, а внутри команды.

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

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

Причины бывают нормальные. Правило изменили, но забыли обновить справку. Команда нашла более точную формулировку в переписке. Появилось исключение, которое раньше встречалось редко.

Плохо не то, что оператор отступил от статьи. Плохо, если это отступление живёт только в его голове или в одном удачном ответе в чате.

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

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

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

Интерфейс поменялся, а слова остались прежними

Третий сигнал кажется мелким, пока клиент не упрётся в него лбом.

В статье написано: «Нажмите “Профиль” в правом верхнем углу». После редизайна там аватар без подписи. Или кнопка «Оплатить» стала «Перейти к оплате». Или раздел «Доставка» переехал в «Заказы».

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

Такие правки проще всего пропустить, потому что они не выглядят как изменение правил. Никто не отменял возвраты, не менял тарифы, не переписывал договор. Просто в интерфейсе стало иначе.

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

После изменений в продукте стоит проверять не всю базу знаний, а статьи, где есть:

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

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

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

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