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