Как логистическая компания утроила скорость обработки накладных с n8n + ИИ
- До внедрения
- 200/день
- ручной обработки на одного оператора
- После внедрения
- 600/день
- автоматически + ручная финальная сверка
- Ошибок ввода
- −80%
- автоматическая валидация структуры
- Срок внедрения
- 10 дней
- включая интеграцию с 1С
Контекст и вызов
Оператор клиента вручную переносил данные из 200-300 накладных и заявок в день в учётную систему. PDF, фотографии бумажных накладных от водителей, email от клиентов с разными форматами заявок. Каждый документ — 3-5 минут на ввод, регулярные ошибки из-за усталости, накапливающиеся пропуски. Найм второго оператора был неоптимальным — задача очевидно автоматизируемая.
Подход
Workflow в n8n из 6 нод:
- Триггер — Email IMAP / Telegram webhook / HTTP webhook (форма) — все нормализуются в стандартный JSON
- OCR-этап — для изображений Tesseract, для PDF pdftotext, для текста pass-through
- Извлечение полей — HTTP-вызов к Claude API с function-calling схемой (Pydantic JSON-schema на стороне n8n)
- Валидация — Postgres query на дубликаты + бизнес-правила (например, дата не в прошлом месяце, сумма в разумных пределах)
- Запись — REST-вызов к 1С с retry-логикой (если 1С отвечает ошибкой, agent пробует 3 раза с экспоненциальным backoff)
- Уведомление — Telegram оператору сводка («обработано 47 документов за час, 3 требуют проверки»)
Что было сложно
Сложность 1 — разнообразие форматов. В первую неделю собрали выборку из 200 реальных накладных. Оказалось, что у разных контрагентов 12 разных шаблонов. Решили через few-shot prompting — даём Claude примеры извлечения для каждого шаблона. Точность скакнула с 67% до 94%.
Сложность 2 — рукописные накладные водителей. Бумажные накладные с рукописными правками — проблема для OCR. Решили через Claude vision как fallback — если Tesseract возвращает confidence < 70%, переключаемся на vision-режим Claude. Стоимость выше, но точность тоже.
Сложность 3 — интеграция с 1С 8.3. REST-обёртка работает, но 1С может «зависать» на 20-30 секунд на тяжёлых документах. Добавили асинхронную очередь — n8n кладёт документ в Redis, отдельный worker подбирает и пишет в 1С. Это убрало таймауты в основном flow.
Эффект на бизнес
Через 2 месяца после запуска:
- Документов в день: 200 → 600 (×3)
- Ошибок ввода: −80% (структурированная валидация на этапе записи)
- Финальная сверка операторами: 20% документов (остальное в системе сразу)
- Оператор переключился на отчётность и сложные случаи — задачи, на которые раньше не было времени
"Заявки и накладные теперь обрабатываются сами. Оператор перешёл на разбор сложных случаев и подготовку отчётности."
Что использовали
Частые вопросы по кейсу
- Что делать с фотографиями накладных от водителей?
- Telegram-бот принимает фото, прогоняет через OCR (Tesseract для печатного текста, Claude vision для рукописного), а Claude в текстовом режиме структурирует данные. Точность извлечения на типовых накладных — 94%, остальные 6% уходят в очередь ручной проверки оператору.
- А если в накладной ошибка или дублирование?
- Перед записью в 1С агент проверяет — есть ли уже накладная с таким номером + датой + контрагентом. Если есть — помечает как duplicate и не создаёт, оператор смотрит. Если данные не сходятся (например, маршрут A→B, а машина уже шла B→A) — флаг для ручной проверки.
- Интеграция с 1С — сложно ли?
- 1С имеет REST-обёртку (1С Web-сервисы), к ней мы подключились через n8n HTTP-ноды. На стороне 1С — стандартные процедуры записи документов. Заняло 2 дня на разработку и тестирование маппинга полей.
- А что с конфиденциальностью данных клиентов?
- На аудите обсудили — для логистики критично, что данные грузов остаются внутри. n8n развёрнут на VPS клиента, в Claude API уходят только обезличенные структурированные данные документа (без названий грузополучателей и сумм). Полная история операций — в локальной Postgres с шифрованием at rest.
Хотите такой же результат?
Бесплатный 2-дневный аудит. За полчаса поймём, есть ли смысл двигаться дальше.