Автоматизация обработки заказов — контур от приёма заявки из любого канала до передачи проверенного черновика на подтверждение в учётную систему: поля нормализуются, остатки проверяются, дубли и ошибки адреса отсеиваются, спорные заказы уходят человеку. Разберём рабочий маршрут для компании, которая принимает заказы с сайта, маркетплейсов и по телефону, и границы, где автоматика уступает ручной проверке.
Что входит в обработку
Обработка заказов охватывает шаги до подтверждения: приём, нормализация полей, проверки и передача черновика в 1С или CRM на подтверждение. Учёт продаж после подтверждения — отдельный контур.
Заказ проходит четыре стадии. Приём: заявка приходит с сайта, маркетплейса, по телефону или в мессенджере. Нормализация: разные формы приводятся к единой карте полей — состав, количество, телефон, адрес, комментарий. Проверки: остатки, дубли, адрес, лимиты. Передача: проверенный черновик заказа уходит в учётную систему со статусом и владельцем для подтверждения. Стадии связаны одной очередью, и заказ виден в ней с момента поступления.
Каналы говорят на разных языках: на сайте — корзина, на маркетплейсе — строка выгрузки, по телефону — заметка оператора. Нормализация переводит всё это на один язык карты полей, и дальше маршрут работает с единой структурой.
Граница важна: цепочка учёта продаж начинается после подтверждения — сверка оплат, отгрузка, возвраты. Этот контур разобран в статье про учёт продаж: события, сверка и возвраты; здесь фокус на всём, что происходит до.
- Сайт и лендинг: форма заявки с составом и контактами
- Маркетплейсы: заказы из кабинетов продавца
- Телефон и мессенджеры: заявки менеджеров и операторов
- Электронная почта: заказы партнёров и оптовые заявки
Сравнивайте долю заказов без ручного вмешательства, время от заявки до подтверждения и длину очереди исключений. Добавьте число ошибочных остановок и время оператора на разбор. Эти показатели показывают, помогает ли маршрут команде и где правило требует пересмотра.
Маршрут заказа
Маршрут строится как конвейер с ручными точками: автоматика несёт типовое, человек — сомнительное. Связующим слоем служит таблица или очередь задач, где каждый заказ — строка со статусом. Один круг заказа выглядит так:
- Заявка падает в единую очередь из всех каналов.
- Скрипт нормализует поля: единые названия, форматы телефона и адреса.
- Скрипт сверяет позиции со справочником, а модель предлагает варианты разбора неоднозначных описаний для оператора.
- Система сверяет остатки в учётной системе и цены по прайсу.
- Поиск дублей сравнивает заказ с открытыми заявками.
- Проверенный черновик передаётся в 1С или CRM со статусом «к подтверждению»; ответственный подтверждает заказ по регламенту.
- Исключения уходят оператору в очередь ручной разборки.
Каналы подключаются по-разному: для маркетплейсов забор идёт выгрузкой из кабинета, для сайта — уведомлением формы, для телефона — формой оператора в той же таблице. Так любой заказ попадает в одну очередь вне зависимости от источника.
Для каждой стадии сохраняют в журнале время, результат и ответственного за решение. По журналу видно, где маршрут тормозит: канал с грязными формами, проверка с ложными срабатываниями, редкий кейс, который каждый раз тянет оператора внутрь. Такие места чинят первыми: быстрый эффект и меньше усталости команды.
Связку можно собрать через n8n, Make или API систем. Объём кода зависит от доступных коннекторов, версии 1С и правил каждого канала. До выбора платформы проверьте интерфейсы обмена и права доступа.
Проверки на входе
Проверки делятся на машинные и человеческие. Машинные считают и сравнивают, человеческие подтверждают сомнительное. Полная выгрузка заказов за день сверяется скриптом: суммы, количество строк, статусы — расхождения уходят в журнал с гипотезой причины. Цены берут из актуального прайса — справочника, который ведёт ответственный сотрудник.
| Проверка | Что ловит | Кто подтверждает |
|---|---|---|
| Нормализация полей | Пустые и кривые контакты, лишние пробелы, разные форматы | Скрипт, образец сверяет человек |
| Остатки и цены | Позиции сверх склада, устаревший прайс | Учётная система плюс оператор |
| Дубль заказа | Повтор от того же клиента в разных каналах | Скрипт сравнения, решение — человек |
| Адрес доставки | Опечатки, зоны вне обслуживания | Справочник зон плюс оператор |
| Лимиты и условия | Заказы сверх лимита, подозрительные контакты | Регламент и менеджер |
Каждая проверка имеет цену ложного срабатывания: слишком строгие правила заваливают операторов мусором, слишком мягкие пропускают брак. Баланс ищут на журнале — по доле исключений и доле ошибочных остановок. Правила уточняют после нескольких циклов наблюдения, сверяя пропуски и ложные остановки.
Языковая модель в этом контуре объясняет аномалии и предлагает гипотезы: почему заказ выглядит как дубль, где в адресе ошибка, какая позиция пропала из прайса. Оператор принимает решение по спорной заявке; сервер проверяет его права, а учётная система сохраняет подтверждённый статус.
Проверки отсеивают типовое, остальное — работа оператора.
Какой канал приносит вашей команде больше всего ручной работы?
Ручные исключения
Исключения — обычная часть обработки. Рост очереди служит сигналом: правила могут быть слишком строгими либо входные данные ухудшились. Цель контура — отдавать человеку короткую очередь с контекстом вместо потока сырых заявок. Оператор видит заказ, причину остановки и кнопки: подтвердить, уточнить, отклонить.
- Остаток сошёлся частично: что-то есть, чего-то ждём
- Похожий на дубль, но телефон иной: уточнить у клиента
- Адрес вне зоны доставки: предложить самовывоз или отказ
- Заказ сверх лимита для нового клиента: подтверждение менеджера
- Контакты подозрительные: звонок перед сборкой
Очередь разбирают по утверждённому регламенту: приоритет может учитывать срок доставки, статус клиента и стоимость заказа. При смене сезона владелец процесса пересматривает правила приоритета. Каждое решение возвращается в маршрут записью: причина, решение, кто решал. Раз в месяц журнал исключений читают целиком — повторяющиеся кейсы переводят в машинные проверки, и очередь становится короче без потери качества.
Новые сотрудники изучают очередь по сохранённым причинам остановки и подсказкам регламента. Опытных операторов подключают к разбору журнала — их интуиция о редких кейсах превращается в новые машинные проверки.
Признак устойчивого контура — повторяющиеся случаи проходят по правилам, а операторы разбирают исключения с полным контекстом.
Внедрение и пилот
Внедрение начинают с одного канала и одного типа заказа: меньше переменных, быстрее проверка. Состав работ: подключение канала, карта полей, проверки, очередь исключений, журнал. Регламент — часть внедрения: кто разбирает исключения, в какие сроки, кто владеет справочником цен и зон доставки. Без регламента контур живёт на личной памяти и ломается при увольнении. На трудоёмкость влияют число каналов, состояние учётной системы и требования к безопасности; смету считаем под задачу после короткого созвона.
Защита от сбоев строится заранее: если канал молчит дольше обычного, ответственный получает сигнал; если выгрузка пришла пустой, маршрут останавливается, а операторы работают по резервной форме. Эти правила записывают и проверяют до запуска. Проверка защиты — часть приёмки пилота: сценарий обрыва отрабатывают вживую.
Если команде нужен такой маршрут без разбора схемы, предлагаем пилот: берём один канал приёма, подключаем нормализацию и проверки, отдаём очередь исключений и журнал. Пилот покажет долю заказов без ручного разбора и случаи, где модель предложила неверную гипотезу. Подход и этапы — на странице про автоматизацию бизнес-процессов.
Отдельный разбор приёма заявок и передачи их между менеджерами — в статье про ИИ для обработки заявок.
Начните с одного канала: соберите заявки недели в таблицу, прогоните через нормализацию и проверки, посмотрите на очередь исключений. Этого хватает, чтобы понять, стоит ли подключать учётную систему.