Оптовые заказы через Telegram: приём в 1С без ручного переноса менеджером

О клиенте

Оптовый поставщик продуктов питания: 300+ постоянных B2B-клиентов — магазины, кафе, небольшие сети. Учёт — в 1С:УНФ. Заказы приходили через WhatsApp, Telegram, звонки и почту; менеджеры вручную переносили их в 1С.

Классическая для оптовой торговли ситуация: клиентов много, заказы повторяются, но каждый проходит через руки менеджера.

Проблема

Как шёл заказ

Клиент писал менеджеру в мессенджер свободным текстом: «привезите как обычно, плюс два ящика воды». Дальше:

• Менеджер вспоминал, что значит «как обычно», уточнял позиции, проверял наличие в 1С, называл цену.
• Вручную заводил заказ в 1С:УНФ.
• Отправлял счёт — иногда с задержкой в несколько часов, если был занят.

На 300+ клиентов и 4 менеджера это давало очередь: в пик заказ обрабатывался по 20–40 минут, часть заявок терялась в переписке, клиенты звонили уточнять статус.

В деньгах

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

Почему не веб-кабинет

Сначала обсуждали B2B-портал. Но у портала есть проблема: клиентов пришлось бы заставлять им пользоваться — ещё один сайт, пароль, вкладка. Половина клиентов продолжила бы писать в мессенджер. Клиенты уже жили в Telegram, поэтому решили закрыть 80% сценариев ботом за долю стоимости портала, а к идее кабинета вернуться позже, если упрёмся в потолок.

Подход

Discovery

За несколько дней разобрали реальные диалоги заказов и структуру 1С:УНФ. Ключевой вывод: 70% заказов — это повтор или небольшая вариация прошлого. Значит, главный сценарий бота — не «выбор из каталога с нуля», а «повторить прошлый заказ и подправить».

Ключевые решения

aiogram + интеграционный слой к 1С. Бот на webhook-ах, отдельный сервис на FastAPI как прослойка к 1С:УНФ через HTTP-сервисы. Вся сложность — в интеграционном слое, а не в «умности» бота.

Валидация остатков в реальном времени. Прежде чем принять позицию, бот проверяет наличие через HTTP-сервис 1С — клиент не заказывает то, чего нет.

Документы из 1С, а не из бота. Счёт и УПД формирует 1С (источник правды по ценам и реквизитам), бот отдаёт клиенту готовый PDF. Никакого дублирования логики ценообразования.

Решение в деталях

Сценарии бота

• Повторить прошлый заказ — бот показывает последний заказ, клиент правит количество и подтверждает.
• Заказ по каталогу — навигация по группам и поиск по названию/артикулу, с ценами клиента (оптовые уровни из 1С).
• Статусы — «где заказ», «когда доставка» — без участия менеджера.
• Документы — счёт и УПД по запросу, из 1С, в PDF.
• Эскалация — кнопка «позвать менеджера» с передачей контекста диалога, чтобы человек не переспрашивал заново.

Проводка в 1С

Подтверждённый заказ уходит в 1С:УНФ документом через HTTP-сервис: контрагент определяется по Telegram-аккаунту (сматчили при подключении клиентов), позиции — по артикулам, цены — по оптовому уровню клиента. Менеджер видит заказ уже в 1С и подключается только там, где нужно решение человека.

Наблюдаемость

Логирование каждого заказа и алерты по сбоям обмена с 1С в Telegram-канал команды. Если 1С недоступна, бот принимает заказ в очередь (Redis) и проводит его, как только связь восстановится, — клиент не упирается в ошибку.

Самое сложное

Сопоставление клиентов с контрагентами 1С

Проблема. Telegram-аккаунт клиента никак не связан с карточкой контрагента в 1С — а без этого нельзя ни подставить цены, ни провести заказ.

Что сделали. Сделали разовую процедуру привязки: при первом входе клиент подтверждает номер телефона, бот находит контрагента в 1С по телефону и связывает аккаунты. Спорные случаи (несколько юрлиц на один контакт) уходят менеджеру на ручное подтверждение.

«Как обычно» без магии

Проблема. Клиенты формулируют заказ неформально, ожидая, что бот поймёт «как обычно».

Что сделали. Не стали строить угадывание на модели — сделали явную и предсказуемую механику «повторить прошлый заказ» с возможностью правки. Это надёжнее и понятнее клиенту, чем ИИ, который иногда ошибается в количествах.

Результаты

Через 6 недель после запуска

• −72% время оформления заказа — с 20–40 минут до нескольких минут; повтор прошлого заказа занимает меньше минуты.
• Ноль ручных переносов заявок из мессенджера в 1С — заказы проводятся автоматически.
• Счёт сразу после заказа, а не через несколько часов.
• MVP за 3 недели, полный функционал со всеми сценариями — за 1.5 месяца.

Менеджеры переключились с механического приёма на допродажи и новых клиентов. К идее полноценного веб-кабинета пока не возвращались — бот закрыл основные сценарии.

Что меняется для каждой роли

Бот выигрывает у полноценного портала там, где клиенты уже живут в мессенджере. Что это даёт разным участникам процесса:

Постоянный клиент. Кнопка «повторить прошлый заказ» закрывает основной сценарий опта: поправить количество, подтвердить, получить счёт в PDF. Заказ поставщику занимает меньше минуты с телефона, и учиться ничему не нужно — интерфейс уже знаком. Наличие проверяется сразу, поэтому не возникает ситуации «заказали, а потом перезвонили, что товара нет», а цены показываются свои, по договору.

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

Специалист 1С. Интеграция идёт через HTTP-сервисы: проверка остатков в реальном времени, проводка заказа документом, счёт и УПД формирует сама 1С. Ценообразование в боте не дублируется — источник правды остаётся один, и расхождений между каналами не возникает.

IT-директор. Очередь на Redis решает главный сценарий отказа: если учётная система временно недоступна, бот принимает заказ и проводит его после восстановления связи. Клиент не упирается в ошибку и не уходит к конкуренту из-за чужой аварии.

Коммерческий директор. Бот закрывает большую часть сценариев B2B-портала за долю его стоимости. Это осознанный размен: там, где клиентская база уже сидит в Telegram, портал добавляет не столько функций, сколько барьер входа.

Стек

• Bot / backend: Python 3.12, aiogram, FastAPI, Redis, PostgreSQL, structlog
• 1С: 1С:УНФ, HTTP-сервисы для проводки заказов и выдачи документов
• Инфра: Docker Compose, алерты в Telegram

Когда такой подход подходит вашей компании

Подойдёт, если:

• Много повторяющихся B2B-заказов, которые сейчас идут через мессенджеры и звонки.
• Менеджеры вручную переносят заявки в 1С и теряют время на механику.
• Клиенты уже в Telegram, и заставлять их осваивать веб-портал — заведомо проигрышно.

Не подойдёт, если:

• Нужны сложные каталоги с конфигураторами, многоуровневые роли и брендированный интерфейс — тогда нужен полноценный B2B-портал.
• Заказы каждый раз уникальны и требуют инженерного подбора — бот не заменит менеджера.