Система деградирует не потому, что изнашивается код, а потому, что меняется мир вокруг неё. Прайс, срок поставки, регламент возврата, состав ассортимента, формулировки, которыми клиенты описывают свою проблему, версия API смежного сервиса, люди, которые знали, как всё устроено, — за полгода меняется всё перечисленное, а система продолжает работать по состоянию на день запуска. Ничего не падает. Просто ответы всё чаще расходятся с правдой.
Это худший из возможных видов отказа, потому что он не подаёт сигнала. Авария заметна за минуту: линия молчит, документы не грузятся, кто-то идёт к директору. Деградация обнаруживается через месяцы и, как правило, снаружи — клиентом, который приехал за заказом в обещанный срок, а заказ ещё не собран.
Ниже — шесть источников дрейфа, числа, по которым он виден заранее, расчёт ущерба от одного неисправленного факта, порядок квартального техосмотра на два часа и порядок восстановления, если расхождение уже случилось.
Шесть источников дрейфа
Дрейф не бывает беспричинным: у него всегда есть событие в бизнесе или снаружи, о котором системе не сказали. Источников ровно шесть, и полезно держать их списком, потому что каждый требует своего маршрута до базы знаний и своей частоты проверки.
| Источник | Как проявляется в ответах | Через сколько замечают сами | Что должно запускать обновление |
|---|---|---|---|
| Изменился прайс или условия скидок | Названа отменённая цена, клиент требует её соблюдения | 1–3 недели, обычно через конфликт с менеджером | Утверждение нового прайса — правка источника цен в тот же день |
| Изменился регламент: сроки, возврат, доставка, оплата | Обещан старый срок или старое условие возврата | 2–5 месяцев, потому что жалуются не все | Приказ или распоряжение по компании — правка в течение 2 рабочих дней |
| Обновился ассортимент | Новые позиции получают ответ «не знаю», снятые предлагаются как доступные | 3–8 недель, по росту доли отказов | Заведение или архивация карточки товара — еженедельная сверка справочника |
| Изменились формулировки клиентов | Понятный человеку вопрос уходит не в тот сценарий или к оператору | почти никогда без разбора выборки | Ежемесячный разбор 40 диалогов с накоплением новых формулировок |
| Поменялся API смежной системы | Часть данных перестала обновляться, ответы построены на старом слепке | от суток до месяца, если нет проверки свежести данных | Оповещение об ошибках обмена плюс контроль возраста данных |
| Сменились люди | Некому подтвердить, почему система отвечает именно так; правки прекращаются | 6–12 месяцев, по накопленному расхождению | Передача роли администратора системы с описанием обязанностей |
Четвёртый источник — самый недооценённый. Люди меняют язык быстрее, чем компания меняет прайс: появляется новое название у товара, входит в обиход слово из рекламы конкурента, клиенты начинают спрашивать «а есть рассрочка» вместо «а можно частями». Система, обученная на прошлогодних формулировках, просто перестаёт узнавать половину вопросов и честно передаёт их человеку. Формально она не врёт — но экономика решения падает вдвое.
Как деградация выглядит в числах
Хорошая новость в том, что дрейф считается. Он проявляется в трёх показателях за 4–8 недель до того, как о нём скажет первый клиент, и все три берутся из журналов самой системы, без опросов и без дополнительных инструментов.
- Доля обращений, переданных человеку. Главный индикатор. В модельном примере она держалась на 12 % на третьем месяце и выросла до 30 % к девятому. Тревога — не абсолютное значение, а рост на треть за месяц: система начала не узнавать то, что раньше узнавала.
- Доля ответов «не знаю» и отказов. Выросла с 4 % до 11 % за тот же период. Этот показатель растёт быстрее всего при обновлении ассортимента: новые позиции в базе знаний просто отсутствуют.
- Повторные обращения по тому же вопросу в течение 7 дней. Поднялись с 9 % до 19 %. Означает, что первый ответ клиента не устроил — либо он неверный, либо неполный. Самый честный из трёх, потому что его нельзя списать на «клиенты стали сложнее».
Важная тонкость: смотреть надо на динамику, а не на абсолютные значения. Норма для доли эскалаций — 10–20 %, и система, которая всю жизнь работала на 18 %, здоровее той, которая за два месяца прошла путь с 11 % до 17 %. Первая просто такая, вторая на глазах теряет качество. Поэтому базовые значения фиксируются на стабильном месяце сразу после запуска — этот пункт входит в чек-лист передачи системы в эксплуатацию.
Модельный случай: склад переехал, а система не узнала
Оптовая компания на 60 человек, ассистент отвечает на 3 000 обращений в месяц. 14 марта склад переехал из Подольска в Домодедово, и срок доставки по Москве изменился с «на следующий день» на «через день». Приказ по компании вышел, менеджеров предупредили на планёрке, прайс поправили. О базе знаний ассистента не подумал никто: она не была ничьей.
Ассистент продолжил обещать доставку на следующий день. Вопросы о сроках — это 22 % потока, то есть 660 обращений в месяц, из них по Москве примерно 40 % — 264 обращения. Расхождение обнаружили в августе, когда руководитель отдела продаж разбирал третью подряд претензию и решил проверить, что именно отвечает бот.
Соотношение 180 825 ₽ против 317 ₽ — не риторический приём, а точная стоимость отсутствия маршрута. Работа, которая должна была занять двадцать минут, не была сделана не потому, что дорого или сложно, а потому, что в приказе о переезде склада не было строки «внести изменение в базу знаний ассистента, ответственный — такой-то, срок — два рабочих дня».
Двадцать тысяч рублей времени менеджеров растворяются в фонде оплаты труда, семьдесят две тысячи компенсаций проходят как скидки, а два ушедших клиента вообще нигде не отражаются — они просто перестали писать. Поэтому деградацию не видно в финансовом отчёте, и решение «не покупать сопровождение» выглядит экономией ровно до тех пор, пока кто-нибудь не сложит эти три строки вместе.
Квартальный техосмотр за два часа
Полноценный аудит системы — дорогая процедура, и раз в квартал она не нужна. Нужен техосмотр: короткая проверка по фиксированному списку, которая занимает два часа и даёт отчёт на одну страницу. Порядок ниже отработан на контурах вроде модельного и не требует ничего, кроме доступа к журналам.
- 1Выборка 40 диалогов, 40 минут
Берутся не случайные, а по правилу: 15 обращений, закрытых системой, 15 переданных человеку, 10 с повторным обращением в течение недели. Читаются целиком. Ищется не «плохой тон», а фактические расхождения и вопросы, которых система не поняла.
- 2Сверка десяти фактов, 30 минут
Заранее составленный список из десяти проверяемых утверждений: цена трёх ходовых позиций, срок доставки в два региона, условие возврата, минимальная партия, срок действия акции, реквизиты, режим работы. Каждый факт спрашивается у системы так, как спросил бы клиент, и сверяется с источником правды.
- 3Проверка внешних связей, 20 минут
По каждой из внешних зависимостей — когда последний раз проходил успешный обмен, каков возраст самых свежих данных, не истекает ли ключ в ближайшие 60 дней. Именно здесь ловятся молчаливые остановки обмена, когда ошибок нет, потому что запросы просто перестали уходить.
- 4Три числа и отчёт, 30 минут
Доля эскалаций, доля ответов «не знаю», доля повторных обращений — за квартал и в сравнении с базовыми значениями. Отчёт на одну страницу: что нашли, что правим сразу, что выносим в план развития, каких маршрутов обновления не хватает.
Два часа работы инженера — это 6 000 ₽ в квартал по канонической ставке 3 000 ₽/час, или 24 000 ₽ в год. Сравните с 180 825 ₽ ущерба от одного пропущенного факта, и вопрос о целесообразности закрывается. На тарифах сопровождения такой техосмотр обычно входит во включённые часы и отдельно не оплачивается.
Маршрут изменения: кто и в какой срок доносит новость до системы
Техосмотр находит расхождения, но не предотвращает их. Предотвращает организационный маршрут: правило, по которому каждое изменение в бизнесе доходит до базы знаний системы так же обязательно, как до прайса и до менеджеров. Маршрут описывается одной таблицей и вешается на владельца процесса.
| Событие в бизнесе | Кто сообщает | Срок | Что меняется в системе |
|---|---|---|---|
| Утверждён новый прайс или условия скидок | Коммерческий директор | В день вступления в силу | Источник цен и правила расчёта скидки |
| Изменились сроки, доставка, возврат, оплата | Автор приказа или распоряжения | 2 рабочих дня | Статьи базы знаний и шаблоны ответов |
| Заведена или снята позиция ассортимента | Категорийный менеджер | Еженедельная сверка справочника | Каталог и правила ответа по наличию |
| Запущена или закончилась акция | Маркетинг | За 1 день до старта и в день окончания | Стоп-темы, шаблоны, срок действия условий |
| Сменился ответственный за направление | Руководитель отдела | В день перевода | Маршруты эскалации и контакты в ответах |
| Подрядчик уведомил об изменении API | Администратор системы | В день получения уведомления | План работ по обмену, при необходимости — заявка |
Дальше нужен один человек, который эту таблицу держит в рабочем состоянии и физически вносит правки. Кто именно им становится, сколько часов в месяц это занимает и как считается стоимость ведения базы знаний, мы разбирали отдельно — там же приведены нормативы по объёму и структуре статей. Здесь важно другое: без имени в столбце «кто сообщает» таблица не работает, потому что ответственность «отдела» всегда означает ничью.
Если расхождение уже случилось
Обнаружив дрейф, первое желание — срочно всё переписать. Это ошибка: пока непонятен масштаб, правки делают картину хуже. Рабочий порядок другой.
- 1Ограничить ущерб за час. Темы, по которым система отвечает неверно, переводятся на человека до выяснения: одно правило, пять минут работы. Лучше очередь к менеджеру, чем ещё двести неверных ответов.
- 2Определить границы. По журналу найти дату, с которой ответы разошлись с правдой, и посчитать, сколько обращений попало в этот период. В модельном примере это 14 марта и 1 320 ответов.
- 3Составить список пострадавших. Не всех, а тех, кто получил неверный ответ по действующей сделке. Обычно это единицы процентов от общего числа — и именно им надо написать первыми, до того как они напишут вам.
- 4Исправить источник, а не ответ. Меняется не формулировка в диалоге, а тот справочник или статья, откуда система берёт факт. Иначе через месяц ошибка вернётся другим путём.
- 5Проверить остальные девять фактов. Если разошёлся один, почти всегда разошлись ещё два: события в компании происходят пачками. Это как раз процедура сверки из техосмотра.
- 6Достроить недостающий маршрут. Разбор заканчивается не исправлением, а строкой в таблице маршрутов: кто в следующий раз сообщит об этом событии и в какой срок.
Оценка ущерба нужна не для того, чтобы кого-то наказать, а чтобы получить основание для регулярной процедуры. Разговор «давайте раз в квартал тратить два часа» проигрывает любому срочному делу; разговор «прошлый пропущенный факт стоил 180 825 ₽, техосмотр стоит 6 000 ₽» закрывается за минуту.
Систему убивает не ошибка в коде, а изменение в бизнесе, о котором ей не сказали. Ошибку найдут за час, изменение — за полгода.
Когда квартальный техосмотр не нужен
Регулярная проверка оправдана не везде, и навязывать её всем — тот же самый продающий приём, против которого написана эта статья. Есть три случая, когда достаточно годовой сверки или не нужно и её.
- Система не разговаривает с клиентами и не оперирует изменчивыми фактами. Внутренний классификатор писем, поиск по архиву договоров, распознавание входящих счетов — у них нет прайса и сроков, которые могут устареть. Достаточно контроля ошибок обмена и годовой сверки.
- Бизнес-правила действительно стабильны. Если за два года не менялись ни ассортимент, ни условия, ни регламенты, квартальная сверка десяти фактов девять раз подряд покажет одно и то же. Переходите на полугодовую и вернитесь к квартальной, когда что-то изменится.
- Поток слишком мал для статистики. При 50–100 обращениях в месяц доля эскалаций скачет от случайных причин, и по ней ничего не видно. Здесь работает не мониторинг чисел, а прямое чтение всех диалогов раз в месяц — на таком объёме это полчаса.
И честная оговорка про верхнюю границу: если система за год потребовала трёх крупных переделок и всё равно расходится с процессом, дело не в дрейфе знаний. Дело в том, что процесс изменился сильнее, чем система способна вместить, и вопрос надо ставить иначе — дорабатывать или переписывать. Это уже другая развилка, со своими критериями и своим расчётом.
