Бот молчал про остатки в 1С: семь пакетов в плане, один в коде

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

бот третий день подряд отвечает «уточню у менеджера»

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

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

план на семь пакетов и один HTTP-клиент в реальности

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

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

Когда бот «сломался» и директор попросил технического специалиста посмотреть не презентацию, а код, в списке зависимостей проекта нашёлся один пакет — обёртка над обычным HTTP-запросом. Ни OData-клиента, ни векторного индекса, ни модуля распознавания намерений в проекте не оказалось. Функция, которая должна была обращаться к 1С за остатками, называлась getStockFromERP() и всегда возвращала пустое значение — заглушку, которую никто не заменил на рабочий код. Все «умные» ответы бота свелись к десятку захардкоженных фраз в условной конструкции, а на всё остальное бот выдавал одну и ту же дежурную реплику.

Клиенты не получали данные из 1С не потому, что упала сеть или менялся остаток на складе, а потому что самого запроса к 1С в коде не существовало.

во что обошлось молчание бота: заявки, время и деньги

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

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

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

как проверить план разработки против того, что реально в коде

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

что смотреть в репозитории

• ✓Просить доступ к репозиторию хотя бы на чтение и сверять package.json или requirements.txt с планом: если в плане заявлен «модуль распознавания намерений на библиотеке X», а такой библиотеки в зависимостях нет, вопрос к подрядчику не риторический, а прямой.
• ✓Запускать бота в тестовой среде и лично задавать вопрос про товар, которого точно нет в наличии, и про товар, который точно есть в достатке — одинаковый ответ на оба случая означает, что обращения к базе нет вообще.
• ✓Смотреть логи в момент вопроса: если в них не появляется исходящий запрос к серверу 1С, бот ничего не проверяет, а просто выдерживает паузу для вида.
• ✓Смотреть историю коммитов: если план описывает семь блоков, а коммитов по факту три и все они правят один файл с текстами ответов, остальные блоки существуют только в документе.

что смотреть на стороне 1С

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

три варианта, что делать с ботом-имитатором

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

что сделали в итоге и как теперь принимают доработки

Заказчик выбрал третий вариант. Аудит показал: из семи заявленных блоков реально требовались два — запрос к 1С по OData за остатками и статусами заказов и простое логирование диалогов для разбора спорных случаев. Векторный поиск, распознавание намерений и оркестратор сценариев для магазина с ограниченным набором типовых вопросов оказались лишней сложностью, которая не окупалась объёмом реальных обращений. Прежде чем подключать бота к 1С:Управление торговлей через штатный сервис данных, пришлось сначала обновить платформу — прежняя версия не поддерживала нужный протокол обмена. Если задачи бота со временем усложнятся — например, появится автоматическое резервирование партии под клиента или расчёт скидки по его условиям, — под это может понадобиться уже доработка на уровне 1С:ERP, а не только правка кода самого бота.

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

❓ Частые вопросы

Как понять, что чат-бот для сайта реально подключён к 1С, а не выдаёт заготовленные ответы?

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

Сколько стоит доработка чат-бота, если разработчик не выполнил план по интеграции с 1С?

Стоимость зависит от объёма недоделанного и от того, сколько из заявленных блоков реально нужно восстановить. Аудит кода и последующая доработка ведутся по ставке для 1С от 3800 ₽ в час, итоговая сумма фиксируется после диагностики, а не оценивается на глаз ещё до просмотра репозитория.

Можно ли проверить план разработки бота до оплаты, не имея своего программиста?

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

Почему бот вообще не выдал ошибку, если не мог получить данные из 1С?

Потому что в коде не было даже попытки обращения к 1С — функция всегда возвращала один и тот же заранее заданный ответ, независимо от товара и склада. Ошибка обычно появляется, когда система пытается что-то сделать и не может; здесь система изначально ничего не пыталась делать.

Что делать, если у бизнеса вообще нет 1С:Управление торговлей, а бот всё равно нужен для остатков и заказов?

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