Оптовая база строительных материалов в Екатеринбурге. 14 менеджеров, 4 кладовщика, 2300 позиций в номенклатуре. Каждый день — звонки, мессенджеры, Excel-таблицы, распечатанные накладные и неизбежные ошибки. Когда директор компании Алексей Вернов позвонил мне в феврале этого года, он сказал коротко: «Мы теряем деньги на хаосе». За семь недель мы превратили этот хаос в систему. Вот как именно.
Что происходило до автоматизации: анатомия потерь
Прежде чем строить решение, мы провели три дня аудита. Результаты оказались хуже, чем предполагал сам клиент.
Менеджеры принимали заказы в восьми разных каналах одновременно: телефон, WhatsApp, Telegram, email, сайт, личные визиты, 1С-портал и даже SMS от постоянных клиентов. Ни одного единого окна. Информация вносилась в CRM вручную — в среднем через 40 минут после получения заказа. За это время клиент уже мог позвонить повторно, уточнить, изменить позиции.
Складской учёт держался на двух кладовщиках, которые вели бумажные журналы и дублировали их в Excel раз в сутки. Расхождение между фактическим остатком и данными в 1С составляло в среднем 12–18% по ключевым позициям. Это означало: менеджер обещал клиенту товар, которого физически не было, или наоборот — говорил «нет в наличии», когда склад был полон.
Потери считались просто: 3–4 срыва отгрузки в неделю, средний чек — 180 000 рублей, репутационные потери не считали вообще. Только прямые потери на возвратах и компенсациях составляли около 280 000 рублей в месяц.
Архитектура решения: что именно мы строили
Я не сторонник продавать клиенту «ИИ ради ИИ». Поэтому мы начали с простого вопроса: где человек делает то, что машина сделает точнее и быстрее? Таких точек нашлось четыре.
Первая точка — унификация каналов приёма заказов. Мы развернули омниканальный хаб на базе собственного оркестратора: все входящие сообщения из WhatsApp Business API, Telegram Bot API, email и веб-формы сайта стекались в единую очередь. Языковая модель (мы использовали GPT-4o с тонко настроенным системным промптом) разбирала текст заказа, извлекала: наименование товара, артикул, количество, единицу измерения, адрес доставки, желаемую дату. Если данных не хватало — бот уточнял. Если клиент писал «200 кирпичей красных» — модель матчила это к конкретной номенклатуре через векторный поиск по базе SKU.
Вторая точка — валидация остатков в реальном времени. Мы подключили 1С через REST API с кешированием остатков каждые 90 секунд. При поступлении заказа система автоматически проверяла доступность позиций и резервировала их на 15 минут — время для подтверждения клиентом. Если товара не хватало, бот предлагал альтернативу из той же категории или ставил заказ в лист ожидания.
Третья точка — автоматическое создание документов. Подтверждённый заказ без участия человека уходил в 1С, где формировался счёт, накладная и задание на сборку для склада. Менеджер получал уведомление уже о готовом заказе — ему оставалось только проверить и отправить клиенту подтверждение.
Четвёртая точка — складской учёт с ML-прогнозированием. Это самая интересная часть. Мы обучили модель на двухлетней истории продаж, сезонности, данных о поставщиках и внешних факторах (погода, строительный сезон). Модель ежедневно формировала прогноз потребности на 14 дней вперёд и автоматически создавала черновики заявок поставщикам, когда остаток опускался ниже рассчитанного порога.
Семь недель внедрения: что шло не по плану
Честный кейс невозможен без разбора проблем. У нас их было три.
Проблема первая — качество номенклатуры. База SKU из 2300 позиций оказалась в катастрофическом состоянии: дубли, опечатки, разные единицы измерения для одного товара, устаревшие артикулы. Векторный поиск работал с точностью 61% — неприемлемо. Мы потратили полторы недели только на чистку справочника. После нормализации точность матчинга выросла до 94%.
Проблема вторая — сопротивление менеджеров. Классика. Люди боялись, что их заменят. Мы провели три встречи с командой и объяснили: система берёт рутину, вы занимаетесь сложными переговорами, работой с ключевыми клиентами, развитием отношений. Переломный момент наступил на третьей неделе, когда менеджер Сергей за один день обработал на 40% больше запросов, чем обычно — просто потому что не тратил время на ввод данных.
Проблема третья — интеграция с 1С. Версия у клиента была старая, документация неполная, API работало нестабильно. Пришлось написать промежуточный адаптер и добавить систему retry с экспоненциальной задержкой. Это съело ещё неделю.
Итого реальный срок вместо пяти недель — семь. Но система заработала.
Результаты через 60 дней после запуска
Цифры — лучший аргумент. Вот что мы зафиксировали через два месяца после полного запуска.
Скорость обработки заказа сократилась с 40 минут до 3,5 минут в среднем. Для стандартных заказов от постоянных клиентов — до 90 секунд.
Расхождение складских остатков упало с 15% до 2,1%. Это фактически устранило категорию ошибок «обещали — не отгрузили».
Количество срывов отгрузки снизилось с 3–4 в неделю до 1 за первые два месяца — и та одна была связана с форс-мажором у поставщика, а не с внутренними процессами.
Нагрузка на менеджеров: 14 человек теперь справляются с объёмом, который раньше требовал бы 18–19 сотрудников при росте числа заказов на 23%.
Экономический эффект: прямая экономия на ошибках — около 240 000 рублей в месяц, дополнительная выручка от обработки ранее «упущенных» заказов — ещё порядка 180 000. Стоимость внедрения окупилась за 11 недель.
Что важно понять, если вы хотите повторить этот кейс
Три вещи, которые я говорю каждому клиенту перед стартом подобного проекта.
Первое: ИИ не работает на грязных данных. Если ваша номенклатура, история заказов или остатки хранятся в беспорядке — начните с аудита данных, а не с выбора модели. Это неприятная правда, но она сэкономит вам месяцы.
Второе: интеграция — самая дорогая часть. В нашем кейсе 40% бюджета ушло на интеграцию с 1С и подготовку данных. Только 25% — на саму языковую модель и логику бота. Планируйте бюджет честно.
Третье: изменения внедряются через людей, а не через технологии. Самый продуманный алгоритм провалится, если команда будет саботировать систему. Работайте с людьми параллельно с технической частью — это не мягкий навык, это жёсткое требование к проекту.
Автоматизация торговли — не про то, чтобы убрать людей. Она про то, чтобы люди занимались тем, в чём машина никогда не сравняется: отношениями, переговорами, нестандартными решениями. Когда это понимают все участники проекта — система работает.
Если вы хотите разобрать архитектуру подобного решения под вашу компанию или обсудить, с чего начать аудит процессов — подписывайтесь на канал. Раз в неделю публикую разборы реальных внедрений без воды и маркетинга.