Telegram-бот для проверки комплектации заказа по накладной и фото товаров

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

Бизнес-задача была сформулирована прямо: автоматизировать проверку корректности комплектации до отправки заказа. Для этого сотрудник фотографировал накладную и товары на столе (с видимыми артикулами), а система автоматически сравнивала, совпадает ли фактическая комплектация с документом.

Что было важно для бизнеса

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

Ключевая идея: вместо ручной сверки «глазами» использовалась автоматическая верификация. OpenAI отдельно разбирал накладную и отдельно распознавал товары/бирки на фото, после чего формировал структурированный вывод о корректности комплектации.

Если у вас похожая задача (контроль комплектации, фото товаров и накладных, проверка перед отправкой) и нужно снизить операционные потери, можно прислать задачу в бриф.

Отправить бриф

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

• Собран workflow, который принимает пачку фотографий: накладная + товары с видимыми артикулами.
• Настроен анализ через OpenAI с прикладным промптом под задачу сверки комплектации.
• Реализован раздельный разбор: отдельно накладная, отдельно фактические товары на фото.
• Сформирован структурированный JSON-ответ с заключением: корректная комплектация или нет.
• Собран Telegram-бот, который возвращает по каждой фотографии понятный статус проверки.
• Проработаны сценарии ошибок: плохое качество фото, нечитабельные артикулы, неполный комплект изображений.

Результат на практике

В рабочем потоке контроль комплектации стал выполняться быстрее и более единообразно: сотрудник отправлял фото, а бот возвращал заключение по результату сверки.

• Проверка заказа перед отправкой перестала зависеть только от ручной внимательности конкретного сотрудника.
• Появился единый формат решения: «комплектация корректна / некорректна» с деталями в структурированном виде.
• Снизился риск пропуска ошибок, которые приводят к возвратам и дополнительной логистике.
• Команда получила инструмент, который встраивается в привычный Telegram-процесс без отдельного интерфейса.

По рабочей статистике около 90% проверок возвращали заключение «комплектация верна». Оставшиеся 10% в большинстве случаев тоже оказывались корректными, но требовали внимания из-за ошибок распознавания или отсутствия читаемых артикулов на фото. В результате внимание сотрудников было перефокусировано с тотальной перепроверки всех заказов на целевую перепроверку только этих 10%.

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

Экономика проверки через OpenAI

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

Рисунок 2. Тестовый расход OpenAI: 92 запроса, $0.51. На этой базе была рассчитана ориентировочная стоимость обработки одной фотографии до запуска в продакшн.

Почему решение делали через Telegram

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

Технические детали

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

1. Порядок реализации: сначала n8n, затем Telegram-бот

• На первом этапе workflow был собран и оттестирован в n8n как отдельный контур.
• После подтверждения качества распознавания и логики сверки решение было упаковано в Telegram-бота.
• Такой подход позволил быстрее валидировать бизнес-гипотезу и не усложнять ранний этап разработкой интерфейса бота.

Рисунок 3. Тестовый стенд в n8n, на котором отрабатывалась логика до упаковки в Telegram-бота.

2. Поток обработки

1. Сотрудник отправляет в бота пачку фото: накладная и товары на столе, где видны артикулы.
2. Изображения передаются в OpenAI с промптом на задачу верификации комплектации.
3. Модель отдельно извлекает данные накладной и отдельно распознаёт фактические товары/бирки.
4. Выполняется сверка «документ vs факт» по артикулам и позициям.
5. На выходе формируется структурированный JSON с заключением по корректности комплектации.
6. Telegram-бот возвращает сотруднику статус проверки по каждой фотографии/заказу.

3. Что валидировалось отдельно

• Читаемость накладной и наличие достаточных данных для извлечения позиций.
• Читаемость артикулов на фото товаров (бирки, маркировка, угол съёмки).
• Полнота комплекта фото для конкретного заказа.
• Пустые или низкоуверенные распознавания с переводом в ручную проверку.

4. Роли пользователей и доступ через Telegram-команды

• Была реализована модель доступа на основе белых списков пользователей.
• Для администраторов было доступно управление белыми списками (добавление/удаление/актуализация доступа).
• Для администраторов была реализована статистика по работе бота, доступная через команды со слэшем в Telegram.
• Для обычных сотрудников административные команды и статистика были недоступны.
• Команда /help работала с разным выводом для разных ролей: администраторы видели полный набор команд, сотрудники — только рабочие команды своего контура.

5. Два контура бота: тестовый и продакшн

• Были реализованы одновременно два Telegram-бота: тестовый и продакшн.
• Каждый бот работал в своём environment с раздельными настройками и токенами.
• Изменения сначала вносились в тестового бота и проходили проверку с заказчиком.
• После подтверждения корректности тот же код деплоился в продакшн-контур.

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

6. Практические нюансы OCR и визуальной сверки

• В этом кейсе качество входного фото влияло меньше, чем ожидалось; критичным оказался другой фактор — текст не должен быть повёрнут на 90/180 градусов.
• Для корректной сверки важно, чтобы на фото товаров артикулы были видны отдельно и без перекрытий.
• Лучший эффект дал гибрид: автоматическая проверка + ручная перепроверка спорных случаев.

7. Отдельный челлендж: обработка галереи фото в Telegram

Существенная сложность возникла на этапе обработки галерей: у Telegram нет надёжного механизма заранее узнать, сколько фотографий будет в конкретной галерее, и нет явного сигнала «галерея полностью завершена» в момент приёма каждого отдельного изображения.

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

8. Эксперимент с двухпроходной схемой (через n8n)

Отдельно тестировалась двухэтапная логика в n8n: сначала запускался чистый OCR с формированием JSON по накладной и товарам, а затем отдельным шагом выполнялся анализ этого JSON на корректность комплектации.

Этот вариант показал более слабый результат. На практике модель, которая сразу видела исходные фото, получала больше контекста для принятия решения и давала более точное заключение в один проход. Поэтому в рабочем контуре был зафиксирован однопроходный сценарий «фото -> анализ -> заключение».

9. Что важно при переносе такого решения в другой проект

• Сначала зафиксировать стандарт фотосъёмки для сотрудников (ракурс, свет, видимость артикулов).
• Отдельно проектировать обработку ошибок и повторной отправки, а не только «счастливый путь».
• Собирать метрики с первого дня: доля ошибок комплектации, доля ручных перепроверок, время проверки заказа.

Если нужно, на следующем шаге можно добавить в этот кейс скриншоты интерфейса бота, пример структуры выходных данных и зафиксированные метрики до/после в формате «бизнес-кейс для откликов».