Февраль 2024 года. Ко мне обратился Дмитрий — владелец оптовой компании по продаже строительных материалов в Екатеринбурге. Штат 23 человека, 4 менеджера по продажам, склад на 1800 позиций. Проблема звучала банально: «Мы тонем в заказах, но денег больше не становится». За этой фразой скрывалась классическая операционная ловушка — бизнес рос, а процессы оставались ручными.
Что происходило в реальности: менеджеры вручную переносили заявки из WhatsApp, почты и телефонных звонков в 1С. Кладовщик проверял остатки по Excel-таблице, которую обновляли раз в день. Заказы терялись, дублировались, уходили не в той комплектации. Показательная цифра: 17% заказов содержали ошибки при оформлении. Это не статистика из отчёта — это реальные деньги, которые уходили на переделки, возвраты и извинения перед клиентами.
За 7 недель мы выстроили систему на базе ИИ-инструментов, которая изменила картину радикально. Ниже — честный разбор того, что именно делали, какие грабли нашли и что получили на выходе.
Диагностика: почему «просто автоматизировать» не работает
Первая ошибка большинства внедрений — начать с инструмента, а не с процесса. Я провёл три дня в компании Дмитрия, буквально сидя рядом с менеджерами и наблюдая за их работой. Это дало картину, которую никакое ТЗ не передаёт.
Выяснилось, что основных каналов поступления заявок было пять: WhatsApp (личные номера менеджеров), корпоративная почта, звонки, Telegram-группа с ключевыми клиентами и — сюрприз — бумажные заявки от двух контрагентов, которые приезжали лично. Каждый канал жил своей жизнью. Единой точки сборки не существовало.
Параллельно вскрылась проблема складского учёта: в 1С числились одни остатки, в Excel кладовщика — другие, а по факту на полках нередко оказывалось третье. Расхождение достигало 12-15% по ряду позиций. Это означало, что менеджеры обещали клиентам товар, которого физически не было.
Диагноз: автоматизация нужна не для ускорения хаоса, а для создания единой управляемой системы. Без этого понимания любой ИИ превращается в дорогую игрушку.
Архитектура решения: что именно мы строили
Я намеренно отказался от попытки найти одну «волшебную» систему. Вместо этого выстроили слоистую архитектуру из нескольких специализированных инструментов, связанных между собой.
Слой 1. Единый входящий хаб. Все каналы коммуникации — WhatsApp Business API, почта, Telegram — подключили к платформе-агрегатору (использовали российское решение на базе открытого API). Теперь каждое входящее сообщение попадало в одну очередь с тегом источника.
Слой 2. ИИ-парсер заявок. Здесь использовали языковую модель с дообученным промптом под специфику строительных материалов. Модель умела извлекать из произвольного текста структурированные данные: наименование товара, количество, единицу измерения, желаемый срок доставки и контактное лицо. Важный момент: модель работала не как чёрный ящик — каждое распознавание сопровождалось оценкой уверенности в процентах. Заявки с уверенностью ниже 85% автоматически уходили на ручную проверку менеджеру.
Слой 3. Интеграция со складом. Распознанная заявка через API проверялась против актуальных остатков в 1С. Параллельно запустили ежечасную синхронизацию между 1С и физическим учётом через мобильное приложение для кладовщика — сканирование штрихкодов при каждом движении товара.
Слой 4. ИИ-ассистент для менеджеров. Не замена менеджера, а его усиление. Ассистент автоматически формировал черновик ответа клиенту с подтверждением наличия, ценой и сроком. Менеджер нажимал «отправить» или редактировал — весь цикл занимал 40-60 секунд вместо прежних 8-12 минут.
Что пошло не так: реальные проблемы внедрения
Без этого раздела статья была бы рекламным буклетом, а не честным кейсом.
Проблема первая: сопротивление персонала. Два менеджера из четырёх восприняли систему как угрозу своим рабочим местам. Один начал намеренно дублировать заявки вручную «на всякий случай», создавая ровно тот хаос, от которого мы уходили. Решение оказалось не техническим — мы провели встречу, на которой Дмитрий публично объявил, что сокращений не будет, а освободившееся время пойдёт на работу с крупными клиентами и развитие базы. Атмосфера изменилась за неделю.
Проблема вторая: качество исходных данных в 1С. Выяснилось, что около 200 позиций из 1800 имели задвоенные карточки с разными артикулами. ИИ-парсер честно путался, когда клиент заказывал «гипсокартон Кнауф 12,5» — таких карточек в базе было три. Пришлось остановить внедрение на полторы недели и провести чистку номенклатуры. Это была незапланированная работа, но без неё система давала бы системные ошибки.
Проблема третья: нетипичные запросы. Несколько клиентов писали заявки в настолько специфическом формате («дай как в прошлый раз, только побольше»), что модель не справлялась. Для таких случаев ввели отдельный тег «требует звонка» — менеджер видел флаг и сам связывался с клиентом. Попытка автоматизировать всё на 100% — ложная цель.
Цифры через 7 недель: что изменилось
Через 49 дней после старта мы провели замеры. Сравнивали с аналогичным периодом предыдущего года.
Скорость обработки заявки упала с 8-12 минут до 1,5-2 минут в среднем (с учётом заявок, уходящих на ручную проверку).
Доля ошибочно оформленных заказов снизилась с 17% до 3,2%. Три процента — это заявки с нетипичными формулировками, которые система честно маркировала как неопределённые. Их обрабатывали вручную, и там ошибок практически не было.
Расхождение складских остатков сократилось до 1,8% — с прежних 12-15%. Это прямой результат ежечасной синхронизации и сканирования при каждом движении.
Производительность менеджеров: каждый из четырёх стал обрабатывать в среднем на 34% больше заявок в день. При этом двое направили освободившееся время на холодные звонки — за 7 недель они привели трёх новых контрагентов.
Один конкретный финансовый результат: в марте компания впервые за полтора года не имела возвратов по причине «товара нет на складе, но менеджер подтвердил». Раньше такие ситуации случались 2-4 раза в месяц и каждая стоила в среднем 15-40 тысяч рублей репутационных потерь и логистических расходов.
Что важно понять, прежде чем внедрять ИИ в торговлю
Этот кейс не уникален по результатам — он типичен по проблемам. За последние два года я видел похожие ситуации в продуктовой дистрибуции, медицинских расходниках, запчастях для промышленного оборудования. Везде одни и те же паттерны.
Первое. ИИ не исправляет плохие данные — он их масштабирует. Если в вашей базе бардак, автоматизация сделает этот бардак быстрее и громче. Чистка данных — не опциональный этап, а обязательный.
Второе. Метрика «уверенности модели» — это не маркетинговая фича, а операционный инструмент. Любая система, которая не умеет говорить «я не знаю», опасна в production-среде.
Третье. Автоматизировать нужно не должности, а операции. Менеджер, освобождённый от рутинного переноса данных, становится дороже, а не лишним.
Четвёртое. Бюджет внедрения в случае Дмитрия составил около 380 тысяч рублей с учётом интеграционных работ, лицензий и трёх недель моей работы. Окупаемость по консервативной оценке — 4-5 месяцев. Это не венчурная история, это обычная операционная экономика.
Вывод
Автоматизация торговых процессов с помощью ИИ — это не про технологии. Это про готовность честно посмотреть на свои процессы, признать, где они сломаны, и методично выстроить систему, которая работает на вас, а не требует постоянного ручного управления.
Дмитрий сейчас думает о втором этапе: предиктивное управление запасами на основе исторических данных о заказах. Это уже другая история — и другой уровень зрелости процессов, которого они достигли за эти 7 недель.
Если вы хотите разобраться, какие процессы в вашем бизнесе можно автоматизировать с реальной отдачей — подписывайтесь на канал. Раз в неделю публикую разборы конкретных внедрений без воды и без маркетинга.