База знаний обновляется не по расписанию, а по трём разным календарям сразу: прайс и наличие — в день изменения, регламенты и условия — раз в месяц сплошной сверкой, частые вопросы — по журналу переданных оператору диалогов. Попытка свести всё к одному ритму («ревизия раз в квартал») заканчивается одинаково: цены протухают на второй неделе, а половина новых вопросов не попадает в базу вообще.
Причина в том, что база знаний — единственная часть ИИ-решения, которая обязана меняться постоянно. Код после приёмки стоит на месте, интеграции меняются несколько раз в год, а содержание ответов расходится с реальностью каждую неделю: поменялся прайс, переехал склад, отдел продаж придумал новое условие для оптовиков. Модель при этом продолжает отвечать уверенно и вежливо — тем, что в неё положили полгода назад.
Дальше — разбор по разделам с их сроками годности, правило назначения владельцев, три календаря обновления, требования к версиям и расчёт трудозатрат. Модельный пример небольшой: компания на 25 человек, один ассистент в клиентском канале, 900 обращений в месяц, база из 60 статей. Если у вас поток в несколько тысяч обращений и отдельная служба поддержки, экономика другая — она разобрана в соседнем материале про ведение базы знаний поддержки.
Что лежит в базе и у чего какой срок годности
Первое, что стоит сделать, — разложить содержимое базы на разделы и подписать каждому срок годности. Дальше расписание вырастет из таблицы само, а разговор о том, кто виноват в устаревшем ответе, станет коротким.
| Раздел | Что внутри | Срок годности | Что происходит, если протухло |
|---|---|---|---|
| Прайс и наличие | Цены, минимальная партия, скидочные ступени, что есть на складе | До первого изменения — обновляется в день приказа | Клиент получает цену, по которой вы не продадите; спор и отказ от заказа |
| Сроки и условия доставки | Сроки по регионам, стоимость доставки, самовывоз, график отгрузок | 2–4 недели или сразу после переезда склада | Обещание, которое не выполняется; повторные обращения и возвраты |
| Регламенты и правила | Порядок оплаты, возврат, гарантия, работа с юрлицами, документы | Раз в месяц сплошной сверкой | Бот ссылается на отменённое правило — риск спора и репутации |
| Шаблоны ответов | Формулировки для типовых ситуаций, тон, подписи, ссылки | Раз в квартал | Ответы звучат чужеродно, но вреда мало — это косметика |
| Частые вопросы | Ответы на то, что реально спрашивают клиенты | Еженедельно по журналу эскалаций | Бот отвечает «не знаю» и передаёт человеку то, что мог закрыть сам |
Обратите внимание на асимметрию: самое дорогое протухание — в первых двух строках, а самая частая работа — в последней. Поэтому раздел «прайс и наличие» ведётся событийно и с подтверждением, а «частые вопросы» — потоком и без согласований. Смешивать эти два режима в одном регламенте нельзя: либо цены будут ждать еженедельной планёрки, либо каждая формулировка пойдёт через утверждение у директора.
Владелец раздела — это имя, а не отдел
Формулировка «за актуальность отвечает отдел маркетинга» не работает по простой причине: у отдела нет календаря, отпуска и телефона. Работает другая — у каждой строки таблицы выше стоит имя конкретного человека, его заместитель на время отсутствия и срок, в который он обязан донести изменение до базы. Это не бюрократия, а единственный способ сделать обновление обязанностью, а не доброй волей.
- Прайс и наличие — тот, кто утверждает цены, обычно руководитель отдела продаж. Правило: то же письмо, которым цены рассылаются менеджерам, уходит редактору базы.
- Сроки и условия доставки — логист или тот, кто общается с перевозчиком. Переезд склада, смена транспортной компании и новогодний график — его три обязательных повода.
- Регламенты и правила — тот, кто их пишет: юрист, бухгалтер или руководитель сервиса. Обновление регламента без обновления базы считается незавершённой работой.
- Частые вопросы и шаблоны — редактор базы. В компании до 50 человек это чаще всего старший оператор или администратор системы на 2–4 часа в месяц.
- Заместитель у каждого владельца. Отпуск владельца прайса на две недели не должен означать двух недель неверных цен в ответах бота.
Самая дешёвая защита от расхождений — процедурная, а не техническая: изменение цены, срока или правила закрывается только после подтверждения, что база знаний обновлена. Один пункт в чек-листе приказа, одна строка в задаче. Без него новость доходит до системы последней, а иногда не доходит вовсе — и через полгода выясняется, что ассистент называет срок поставки, отменённый весной. Мы разбирали отдельно, как это выглядит в числах и во что обходится.
Три календаря обновления
Обновления идут в трёх режимах, и путать их не стоит: один запускается событием, второй — датой, третий — данными из журнала работы самой системы.
- 1По событию: в день изменения
Прайс, наличие, сроки, любое условие, которое клиент слышит от менеджера. Правило простое: изменение доходит до базы в тот же рабочий день, что и до сотрудников. Одна правка — 10–20 минут, проверка считается отдельно.
- 2По расписанию: раз в месяц
Сплошная сверка регламентов и правил по списку разделов: открыть, прочитать, подтвердить актуальность или поправить. В модельном примере это шесть разделов по 10 минут — час в месяц. Даже если ничего не изменилось, запись «проверено такого-то числа» стоит этого часа.
- 3По данным: еженедельно
Разбор журнала: какие диалоги ушли оператору, где бот ответил «не знаю», по каким вопросам клиенты возвращались повторно. Пять однотипных эскалаций за неделю — это заявка на новую статью. Так база растёт по реальному спросу, а не по представлениям о нём.
- 4После каждой правки — проверка
Пять контрольных вопросов ассистенту той же формулировкой, какой спрашивают клиенты. Занимает 10 минут и ловит главную ошибку редактирования: статья поправлена, а модель по-прежнему находит старую версию в соседнем разделе.
Схема из трёх горизонтальных дорожек, сходящихся справа в один блок «база знаний ассистента». Дорожка 1 «по событию»: приказ о цене, переезд склада, новое условие → подпись «в тот же день, 10–20 минут». Дорожка 2 «по расписанию»: 6 разделов регламентов → подпись «раз в месяц, 60 минут». Дорожка 3 «по данным»: журнал эскалаций, ответы «не знаю», повторные обращения → подпись «еженедельно, правило: 5 однотипных эскалаций = новая статья». После общего блока — маленький блок «проверка: 5 контрольных вопросов, 10 минут». Чертёжный стиль, подписи по-русски.
Версии и откат за три минуты
База знаний правится людьми, а люди ошибаются. Типичный случай: редактор уточнил формулировку про предоплату, убрал слово «для новых клиентов» — и ассистент двое суток обещал отсрочку всем подряд. Ошибка обнаруживается по жалобе менеджера, и дальше всё зависит от того, есть ли у базы история версий.
Сохранённая редакция с тремя обязательными полями: кто изменил, когда и что именно. Хранить достаточно 90 дней — этого хватает, чтобы найти и откатить любую неудачную правку. Откат должен быть кнопкой, а не задачей подрядчику: с кнопкой возврат занимает 3 минуты, без неё редактор восстанавливает текст по памяти около 2 часов и всё равно пишет не то, что было.
Второе требование к версиям — предпросмотр до публикации. Правка проверяется на тех же пяти контрольных вопросах и только потом становится видна клиентам. В маленькой компании это звучит избыточно ровно до первого случая, когда опечатка в цифре превращает 5 000 ₽ в 500 ₽, а бот честно повторяет это тремстам собеседникам. Версии, предпросмотр и поиск по разделам — часть самого хранилища, а не отдельная функция бота: в каталоге это корпоративная база знаний, из которой одинаково читают и ассистент, и живые сотрудники.
Нарисованный абстрактный экран карточки раздела базы знаний с подписанными полями: «Раздел: сроки и условия доставки», «Владелец: имя», «Заместитель: имя», «Срок годности: 2–4 недели», «Проверено: дата», «Версия: 14», «Изменил: имя, дата, что именно». Внизу две кнопки: «предпросмотр» и «откатить к версии 13». Сбоку пометка «история 90 дней». Чертёжный стиль без реального интерфейса, подписи по-русски.
Сколько это часов и денег в месяц
Разложим ведение базы на конкретные действия. Модельный пример прежний: 60 статей, 900 обращений в месяц, один ассистент, полная стоимость часа сотрудника 950 ₽ — с налогами и накладными, а не оклад, поделённый на часы.
Эти 4 часа 20 минут — время вашего сотрудника, а не подрядчика. Правка текста в базе знаний не требует инженера и не должна оплачиваться по инженерной ставке: у подрядчика в договоре сопровождения обновление базы обычно входит во включённые часы, но передавать туда еженедельную работу с формулировками бессмысленно — он всё равно пойдёт спрашивать у ваших людей, что теперь правда.
Теперь цена бездействия, на том же примере. Компания переехала на другой склад, срок доставки по региону вырос с двух дней до четырёх, строку в базе не поправили. Вопросов про сроки — 22 % от потока, это 198 обращений в месяц, и все получают неверный ответ. Даже при мягкой оценке в 6 % отказов от заказа из-за расхождения обещания с фактом это 12 заказов, а при средней марже 3 360 ₽ — 40 320 ₽ в месяц. Одна строка, двадцать минут работы, десятикратная разница.
Два столбика для сравнения масштаба. Левый низкий: «ведение базы 4 117 ₽/мес» с разбивкой по работам в минутах — 40, 20, 60, 100, 40, итого 260 минут. Правый высокий: «потери от одной устаревшей строки про срок доставки 40 320 ₽/мес» с подписью «198 обращений про сроки, 12 отказов, маржа 3 360 ₽». Между столбиками пометка «×10». Ось Y — рубли в месяц, подписи по-русски.
Когда отдельный регламент базы знаний не нужен
Не всякой компании нужна описанная конструкция целиком. Есть три ситуации, в которых она даёт больше работы, чем пользы.
- База меньше 15 статей и один автор. Владельцы разделов, версии и календари здесь избыточны: хватит одного документа, одного ответственного и правила «поправил — проверь пятью вопросами».
- Содержание почти не меняется. Справочная информация об услугах, которая живёт годами: сверка раз в полгода закроет вопрос, ежемесячная сплошная проверка будет тратой часа впустую.
- Ассистент отвечает только по данным из учётной системы. Если бот берёт цену, остаток и статус заказа напрямую из 1С, отдельная база под эти факты не нужна и вредна — она станет вторым источником правды и рано или поздно разойдётся с первым.
И граница, о которой стоит сказать прямо: обновление базы знаний не лечит плохо поставленный процесс. Если условия меняются каждую неделю и сами сотрудники не знают актуальных, ассистент будет отражать этот беспорядок с точностью зеркала. Сначала — источник правды на стороне бизнеса, потом — база знаний для системы, которая из него питается.
Ассистент не устаревает сам. Устаревает то, что мы в него положили и забыли подписать сроком годности.
