Владелец узнаёт о срыве срока в 8 утра, а не когда позвонил клиент

Контекст

Мебельная фабрика полного цикла — кухни, шкафы-купе, гардеробные, город-миллионник. ~60–115 заказов одновременно в производстве, CRM — Bitrix24.

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

Данные в CRM при этом были неполными и «шумными»: находка стартового аудита — плановый срок монтажа заполнен только у 13 карточек из 114, а на доске висели десятки брошенных и тестовых карточек, некоторые не двигались по 119–526 дней. Отличить реальный пожар от мусора глазами было практически невозможно. Отдельная боль — два конкурирующих поля с датой монтажа, одно из которых давно не поддерживалось: ориентация на него давала 50 «просрочек», из которых реальными были 3.

Ограничения

• Качество данных в источнике. Плановый срок заполнен у 11% карточек. Система должна была приносить пользу, не требуя предварительной чистки CRM — иначе внедрение никогда бы не стартовало
• Легаси-поля в CRM. Два конкурирующих поля даты монтажа, одно из которых давно не поддерживалось, плюс 12 стадий смарт-процесса с историческим мусором — вплоть до стадии «УДАЛИТЬ» и карточек с «ТЕСТ» в названии
• Блокировка Telegram в РФ. Российский дата-центр блокировал api.telegram.org — бот молчал с таймаутами, хотя Bitrix24 и Anthropic API были доступны. Обход через прокси на Cloudflare Workers провалился; итоговое решение — перенос сервера на площадку с доступностью всех внешних API
• Ноль внешних зависимостей. Требование: код работает на любой машине без pip install — только стандартная библиотека Python. Это исключило официальные SDK Anthropic и Telegram: все интеграции написаны на urllib
• Нетехнический оператор. Все операции внедрения — создание сервера, SSH, правка конфигов — выполнялись на стороне фабрики человеком без инженерного опыта. Каждое действие должно было сводиться к копированию одной команды

Решение

Что это даёт

Каждое утро в 8:00 в рабочий чат приходит сводка: что горит по срокам, что застряло, что готово к отгрузке, что превратилось в «завал». Читается с телефона за 20 секунд, сортировка — по серьёзности, сверху самый просроченный.

В любой момент можно задать боту обычный вопрос своими словами — «сколько заказов горит?», «что с заказом 1042?» — и получить ответ по актуальным данным из CRM за пару секунд. Пороги тревоги меняются прямо из чата: «подними порог „горит“ до 3 дней» — бот подтверждает и применяет.

Как устроено

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

Работа с грязными данными — часть продукта. Перед анализом идёт фильтр: скрываются карточки на служебной стадии, тестовые записи и «зомби» — всё, что не двигалось дольше 120 дней. При первом прогоне это отсеяло 49 карточек из 114. Заказы без живого планового срока не поднимают ложную тревогу, но и не теряются: если такой заказ стоит на месте больше 30 дней, он попадает в отдельный блок «Завалы» — это не пожар, а backlog на разбор. Так система приносит пользу на неидеальных данных и попутно подсвечивает, где CRM нужно дозаполнить.

Калибровка — на живых данных, а не на предположениях. Изначальные пороги из ТЗ («застрял» = 3 дня) на реальной доске давали 90 срабатываний из 114 — чистый шум; порог подняли до 14 дней. Аналогично с датой: сравнение двух полей на реальной выборке показало, что устаревшее поле генерирует 47 ложных просрочек против 3 настоящих — от него отказались полностью.

Инфраструктура: бот живёт на VPS как systemd-сервис с автоперезапуском и держит постоянное соединение с Telegram (long-polling) — ответы приходят за 1–2 секунды. Он же по расписанию отправляет утреннюю сводку, только по будням. Вся «инструкция» агента — роль, пороги, логика классификации, формат отчёта — вынесена в отдельный документ из 9 автономных блоков: можно править один блок, не задевая остальных и не меняя код.

Результат

Сводка и диалог работают 24/7 при выключенном компьютере владельца; ботом пользуются четверо — владелец и три сотрудника. Полная выгрузка из CRM занимает 3,2 секунды. Стоимость эксплуатации — около 600 ₽ в месяц за сервер плюс 2–10 центов за вопрос к модели.

Отдельная находка аудита, которую вскрыл инструмент: плановый срок монтажа заполнен лишь у 13 заказов из 114 — автоматизация отчётности подсветила, что дозаполнять в CRM.

Что бы сделал иначе

• Начинать не с ТЗ, а с разведки данных. Пороги в ТЗ («застрял» = 3 дня) звучали разумно, но на живой доске дали 90 срабатываний из 114 — отчёт был бы бесполезен с первого дня. Любой порог должен назначаться после того, как посмотрел распределение реальных данных, а не до
• Не доверять названию поля. «Дата монтажа» звучит как то самое поле — оно давало 47 ложных просрочек. Правильное называлось «Ожидаемая дата монтажа». Прогнать оба поля на реальной выборке заняло 10 минут и спасло проект от полной недостоверности
• GitHub Actions — не платформа для интерактивного бота. Cron раз в 5 минут на практике давал задержки 15–40 минут и пропуски. Для отчёта раз в сутки годится, для диалога — нет. Надо было сразу брать VPS
• Проверять сетевую доступность площадки до развёртывания. Всё развернулось на российском VPS — и только там выяснилось, что дата-центр блокирует api.telegram.org. Потерян день на попытку обхода и переезд. Проверка заняла бы 15 секунд: curl к api.telegram.org
• Инструмент вскрывает проблемы процесса, а не только автоматизирует его. Главная находка проекта — не код, а то, что срок монтажа заполнен у 11% заказов, и часть карточек стоит «Готов к отгрузке» с просрочкой 40+ дней. Автоматизация отчётности бесполезна, если данные в источнике не ведут — это стоило проговорить с командой на старте

Стек

Что это в деньгах

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

Куда дальше

Смотрят вместе с этим

Заказы тоже зависают между этапами молча?