Восемь модулей в проде — и тихий баг, который нашёлся только на аудите

Контекст

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

Заходили в работу вдвоём с отраслевым бизнес-консультантом: он отвечал за вопрос «что» — провёл аудит онлайн-процессов продаж, я за вопрос «как» — за техническое задание и инженерную реализацию. Это разделение оказалось важнее, чем выглядело на старте: аудит дал не мои гипотезы, а картину, которую компания признаёт своей.

Что болело

Контроль качества звонков делался руками. Один человек слушал те самые тридцать звонков в день и проставлял оценки по чек-листу из двадцати пяти пунктов. Это не масштабируется в принципе и уже на текущем объёме давало дырявое покрытие: часть разговоров не попадала под проверку вовсе, а оценки тех, что попадали, нигде не накапливались. Отсюда следствие, которое и есть настоящая проблема: работать с качеством на уровне процесса было не с чем. Чек-лист существовал, а сводной картины — какие его шаги системно выпадают и какие из них стоит поддержать подсказкой, скриптом или напоминанием — не было ни у кого.

Квалификация лидов была субъективной: признак «целевой или нет» проставлялся вручную и по личному суждению, без общих критериев. Это значит, что данным о качестве потока нельзя доверять как таковым — не потому, что кто-то недобросовестен, а потому, что одна и та же заявка у разных людей и в разные дни получала разную отметку.

Follow-up не существовал как процесс: следующий шаг нигде не фиксировался и ничем не напоминался — ни в CRM, ни в телефонии не было механизма, который бы его требовал, ставил в очередь и отслеживал. Нерабочее время не покрывалось ничем. Знания о товаре были размазаны по учётной системе, сайту и Excel-прайсам, и менеджер собирал ответ из трёх источников на ходу. Аналитики по коммуникациям не было вовсе.

Как подходил

Первое решение было не про технологию, а про порядок. Восемь модулей разбили на три фазы, и порядок определялся не технической готовностью, а сопротивлением команды. Фаза первая — «контроль и прозрачность»: автоанализ звонков по чек-листу, скрытая от менеджеров квалификация лидов, дневная сводка руководителю. Ключевое свойство этой фазы — она невидима для менеджеров: они не меняют свою работу, и им нечему сопротивляться, пока система набирает данные. Фаза вторая — «рост конверсии»: цепочка из пяти касаний, чат-бот на сайте вместо старого виджета, ночные автоответы. Фаза третья — «оптимизация»: подсказки в переписке, еженедельный свободный анализ коммуникаций, рекомендация следующего действия.

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

Третье — от чего отказались осознанно. Подсказки менеджеру в реальном времени прямо во время разговора мы не делали. По опыту такие подсказки сбивают человека, особенно на звонке в три с половиной минуты, где нет паузы, чтобы читать экран. Это записано в материалы отдельным пунктом: не всё, что можно построить, стоит включать.

Инженерно система собрана на Node.js с PostgreSQL и векторным расширением, очередями и Redis, в контейнерах на выделенном сервере, с деплоем через CI. Первый полный прогон загрузки знаний дал около трёх с половиной тысяч сущностей и столько же фрагментов с эмбеддингами за две с половиной минуты; сопоставление каталога с остатками из учётной системы сошлось на 86 % строк.

Что мешало и что не получилось

Технический риск, который мы предвидели, сбылся. В техническом задании была формальная оговорка про ограничения CRM-платформы; в конце мая её поддержка подтвердила, что нужный доступ к переписке через родное API недоступен. Пришлось перестраивать архитектуру виджета подсказок на перехват сообщений из интеграций-посредников. Здесь связка сработала как задумано: предупредили — сбылось — отработали по оговорке, без спора о вине. Отдельно несколько дней живых экспериментов съело двадцатичетырёхчасовое окно бизнес-мессенджера: правила рассылок пришлось выяснять эмпирически.

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

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

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

Провалилась и первая версия материалов по кейсу для заказчика. Обратная связь от отраслевого консультанта была прямой: недостаточно проработано, «было → стало» жило на одном слайде, три слайда подряд рассказывали про механику вместо денег и рисков для собственника, ни одного скриншота, цифры про объём работ вместо эффекта. Переделку поставили — финальной версии в материалах не нашлось.

Что стало

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

Клиентских цифр у нас нет, и здесь это не умолчание, а зафиксированная позиция: цифры конверсии принадлежат заказчику и нам не передавались. Целевые метрики успеха — точность автоматического чек-листа выше 90 % совпадения с ручной проверкой, выявление больше 80 % некорректных отказов, охват follow-up выше 95 %, принятие подсказок выше 60 % — так и остались целевыми: это критерии приёмки из аудита, а не достигнутый результат.

Качественно подтверждено одно: менеджеры пользуются подсказками. Учитывая историю с тихим багом, эту фразу я теперь читаю осторожнее, чем читал в момент, когда её услышал.