Первый же расчёт вскрыл 18 должников и 143 позиции, которых не хватало на складе. Раньше этого не видел никто

Контекст

Оптовый дистрибьютор мебельной фурнитуры в Уфе: около шестисот активных клиентов, пять менеджеров, восьмизначный месячный план продаж. Бизнес живой и прибыльный — и полностью держащийся на памяти конкретных людей.

Клиент переставал заказывать, и это замечали через месяцы, когда он уже работал с конкурентом. Дебиторку никто не собирал системно: в учёте валовый долг выглядел одной суммой, реальную картину по клиентам не видел никто. Заказы поставщику делались на глаз, поэтому по части ассортимента на складе было пусто, а по части — запас на годы вперёд.

Руководство при этом не имело ежедневного план-факта. Отчёты из 1С собирались вручную и расходились с реальностью, потому что разные люди считали по разной методике. Спорить о цифрах приходилось раньше, чем о решениях.

Задача формулировалась просто: сделать так, чтобы система сама находила проблемы в базе и превращала их в конкретные задачи конкретным менеджерам. Не дашборд, на который никто не смотрит, а сделки в CRM, которые нельзя не заметить.

Ограничения

• В 1С — никаких записей. Никогда. Требование собственника, не подлежащее обсуждению. Учётная система — источник правды для бухгалтерии, и любая запись извне ставит её под сомнение
• В CRM — только по белому списку. Девять разрешённых операций записи, всё остальное отклоняется. LLM-агент физически не может писать в Bitrix24, даже если очень захочет
• Живая база со своей историей. Идентификатор основного склада в техзадании оказался ошибочным и указывал на склад-витрину. Документа «Счёт на оплату» в базе не существовало вовсе. Регистр оплат по заказам оказался пустым. Поле «Менеджер» в документах в основном заполнено техническим «Администратором» — то есть штатным способом узнать, чей это клиент, было нельзя
• Роботы портала конфликтовали с ботом, перетирая ответственного и служебные поля только что созданных сделок
• Дневной бюджет на модель — 15 долларов, при исчерпании система обязана деградировать до шаблонных справок, а не останавливаться
• Техзадание менялось на ходу. Формула складской программы пересматривалась трижды за один день, состав аналитических контуров — дважды за неделю

Решение

Что это даёт

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

Менеджеру не нужно ничего искать. Не нужно вспоминать, кто давно не звонил. Не нужно открывать 1С и сводить отчёты. Работа приходит к нему сама, по одной задаче за раз.

Руководитель вечером получает итоги дня: план-факт по компании и по каждому менеджеру, средний чек по категориям клиентов, результативность каждого направления — сколько выдано, сколько обработано, сколько отгружено после выдачи.

Как устроено

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

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

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

Отдельная часть работы, которую обычно не показывают, — контроль сходимости. Выручка, посчитанная ботом, сверялась с эталоном учёта: расхождение 0,2%. План-факт сошёлся с файлом заказчика копейка в копейку. Свободный остаток проверялся владельцем руками на конкретном артикуле, и цифры совпали. Без этой процедуры любая автоматическая аналитика — просто ещё один источник спорных чисел.

Поверх всего — диалоговый режим. Сотрудник из белого списка задаёт вопрос в свободной форме: «сделай анализ перемещений на склад производства», «кто нам должен денег». Агент сам строит запросы к учётной системе, считает и отвечает цифрами со сверкой. Тяжёлые разборы уходят в аналитическую песочницу с SQL и выдачей в Excel.

Попробуйте сами

Утро AI-сотрудника — за 30 секунд

Ниже — уменьшенная копия системы на вымышленных данных. Слева то, что агент видит в 1С и Bitrix24, справа — его лента. Запустите прогон и смотрите: каждая находка подсвечивает свои данные, каждой проблеме ставится задача с готовой справкой, а в конце складывается тот самый утренний отчёт руководителю.

Архитектура

Read-only контур к 1С — двойной барьер. В клиенте физически нет методов записи, плюс перехватчик отклоняет любой не-GET-запрос до отправки. Ночной синк складывает данные в локальный кэш: около девятнадцати тысяч отгрузок за тринадцать месяцев, строки документов, остатки, цены, справочники. Вся аналитика работает по кэшу — учётная система не нагружается вообще.

Белый список операций в CRM как код. Девять операций записи, каждая — отдельный типизированный метод с валидацией до сетевого вызова. Общий вызов API и LLM-агент могут только читать. Это оказалось главным аргументом в разговоре с заказчиком: не обещание «бот ничего не сломает», а архитектурная невозможность.

Паспорта обеих систем. Бот сам разведал структуру учётной системы (791 объект) и портала (62 сущности, 2356 полей, 108 стадий), еженедельно сверяет изменения и докладывает расхождения. Семантика стадий сделок берётся из паспорта, а не зашита в код — поэтому изменения в CRM не ломают отчёты.

Каскадная атрибуция менеджеров. Раз поле в документах бесполезно, реальный менеджер клиента восстанавливается по закреплению и истории отгрузок. Покрытие — 89,8%.

Идемпотентность везде. Журнал сделок пишется до вызова API, поэтому перезапуск не создаёт дублей. У отчётов есть ключи отправки. Повторный прогон любой задачи безопасен.

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

Стек

Результат

От старта до боевого автономного режима — около двух недель.

Первый прогон дебиторки выявил 18 должников и создал девять сделок без единой ошибки. Первая автоматическая сверка склада показала, что по 143 позициям из 301 свободный остаток меньше месячного расхода, — при том что по другим товар был заморожен на годы вперёд, вплоть до запаса на триста месяцев. Отчёт о возврате вскрыл избыточный остаток на четверть миллиона рублей и позицию к возврату поставщику.

Попутно вычистилось то, о чём никто не подозревал: 148 ошибочных привязок клиентов к чужим карточкам CRM и 42 клиента-призрака в аналитике.

Сейчас система создаёт до двадцати сделок в день и работает без участия человека. В первый же день контура обзвона менеджеры отработали семь выданных клиентов.

Отдельный результат — тиражируемость. Паспорт проекта оценивает развёртывание копии под нового клиента в три-четыре дня разработки плюс три-четыре дня конфигурации.

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

• Формула из техзадания дала обратный результат — спасла проверка на живых данных. Правило отбора в складской программе, написанное по букве ТЗ, включало в заказ затоваренные позиции и пропускало товары с нулевым остатком. Поймали до запуска только потому, что каждый расчёт прогонялся на реальных остатках и сверялся глазами. Любую бизнес-формулу нужно проверять на крайних случаях до продакшена, а не после
• «Остаток» — это три разных числа. Начали с «в наличии», а заказчик оперирует свободным остатком за вычетом резерва. Разница на одном артикуле — 148 штук против 45. Складские термины нужно сверять с заказчиком на конкретном примере, а не в переписке
• Деплой убил вечернюю рассылку. Пересборка контейнера попала ровно на минуту запуска планировщика. Расписание живёт в памяти процесса, запуск потерялся, отчёты не вышли. Теперь есть окна деплоя и обязательная проверка журнала отправок после каждой пересборки
• Матчер компаний связывал людей по отчеству. 148 ошибочных привязок, сделка уходила не тому клиенту. Переписали правила для физических лиц — только полное ФИО с фамилией — и добавили пост-проверку совместимости названий
• Первый разовый отчёт ушёл не в том виде: включил все товары с остатком вместо только непроданных, 1153 позиции вместо 105. У разовых отчётов нужно сверять не только цифры, но и сам отбор — с образцом заказчика
• Техзадание живёт своей жизнью. Формула складской программы менялась трижды за день. Проект это пережил только потому, что все пороги и правила вынесены в конфигурацию — большинство правок делались без единой строки кода

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

Первый расчёт вскрыл 18 должников и 143 позиции дефицита — это деньги, которые уже лежали в вашей 1С. Не верьте на слово — подвигайте ползунки под свой бизнес:

Дальше работает только абонентская плата — дешевле одного менеджера.

Куда дальше

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

Похожая ситуация — данные в 1С есть, а решения принимаются по памяти?