Интерфейс обработки заказов - это рабочий экран оператора, где принимаются решения по каждому заказу: подтвердить, передать на сборку, оформить возврат, связаться с клиентом. Если для этого нужно параллельно держать открытыми CRM, личный кабинет банка и трекер СДЭК, оператор тратит на заказ в два-три раза больше времени, чем должен, и рано или поздно путает статусы или копирует не тот номер телефона. Я собирал такие панели и для интернет-магазинов на Tilda с кастомными скриптами, и для отдельных веб-сервисов на React, и в этой статье разберу, какие блоки данных обязаны быть на одном экране, как выстроить статусы заказа и сколько это стоит в реальных проектах.
Зачем сводить всё на один экран, а не в пять вкладок
На практике узкое место почти никогда не в скорости сервера, а в количестве переключений между окнами. Оператор открывает заказ в CRM, идёт в личный кабинет эквайринга проверить, прошла ли оплата, потом в кабинет СДЭК за трек-номером, потом возвращается и вручную вписывает его в карточку. На каждый заказ уходит лишняя минута-полторы. При потоке в 150 заказов за смену это два с половиной часа чистого времени, которое можно было потратить на звонки клиентам или сборку.
Второй эффект хуже: при ручном переносе данных между системами растёт число ошибок. Неправильно скопированный трек-номер, не тот статус оплаты, забытый комментарий клиента про доставку до третьего этажа без лифта. Каждая такая мелочь оборачивается звонком в поддержку или испорченным заказом, а на масштабе в сотни заказов в месяц это уже заметные деньги и потерянные клиенты.
Какие блоки обязаны быть в карточке заказа
Через любую панель обработки заказов, которую я делал, независимо от платформы, проходит один и тот же набор блоков. Если хотя бы одного из них нет на экране, оператор всё равно откроет вторую вкладку.
- Блок клиента. Имя, телефон, email, история предыдущих заказов и пометки вроде «просил перезвонить после 19:00» или «постоянный клиент, давать скидку».
- Состав заказа. Список товаров с количеством, ценой, применёнными скидками и итоговой суммой без пересчёта в уме.
- Статус и способ оплаты. Оплачено, ожидает оплаты, частичная предоплата, с прямой ссылкой на транзакцию в T‑Bank или другом эквайринге, а не отдельным окном личного кабинета банка.
- Доставка. Способ (курьер, самовывоз, ТК), адрес, стоимость, трек-номер СДЭК или другой службы, подтянутый автоматически, а не вбитый руками.
- История статусов. Кто и когда перевёл заказ из «нового» в «подтверждённый», сколько времени заказ провисел на каждом этапе.
- Комментарии и теги оператора. Свободное поле для заметок плюс быстрые теги вроде «срочно», «проблемный», «повторный клиент».
Если заказы приходят с нескольких источников, например часть с сайта на WooCommerce, часть из Tilda-форм и часть через Telegram-бота, все эти блоки должны выглядеть одинаково независимо от источника. Оператору не должно быть важно, откуда пришёл заказ, важно только его текущее состояние.
Статусы заказа: как выстроить переходы, а не свалку
Частая ошибка - завести статусы вроде «в работе», «уточняется», «проблема», которые ничего не говорят о том, какое действие нужно от оператора дальше. Рабочая схема обычно линейная, с редкими боковыми ветками на отмену и возврат.
| Статус | Что делает оператор | Куда уходит уведомление |
|---|---|---|
| Новый | Проверяет наличие товара, подтверждает заказ звонком или в чате | Оператору в панель, иногда дублируется в Telegram-бота |
| Подтверждён | Ждёт поступления оплаты или переводит в сборку при оплате при получении | Клиенту через SMS или бота на подтверждение |
| Оплачен | Передаёт заказ на сборку и упаковку | На склад, статус в CRM обновляется автоматически из T‑Bank или ЮKassa |
| Передан в доставку | Прикрепляет трек-номер, фиксирует дату отгрузки | Клиенту с трек-номером СДЭК или другой ТК |
| Доставлен / отменён | Закрывает заказ или оформляет возврат | В отчёт по конверсии, без лишних уведомлений |
Ключевое требование к такой схеме - каждый переход должен быть доступен одной кнопкой прямо с экрана заказа, без перехода в отдельный раздел настроек статусов. И у каждого статуса должен быть понятный «хозяин»: кто отвечает за то, чтобы заказ не завис на этом этапе дольше суток.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Интеграции, без которых экран оператора бесполезен
Сам по себе красивый интерфейс не решает задачу, если данные в него приходится вбивать руками. На практике для панели обработки заказов нужны минимум три интеграции.
Оплата
Статус транзакции должен подтягиваться автоматически через вебхук T‑Bank, ЮKassa или другого эквайринга. Как только оплата прошла, заказ сам переходит в статус «оплачен», без ручной сверки по выпискам.
Доставка
Трек-номер и статус движения посылки СДЭК или другой транспортной компании должны появляться в карточке заказа через API, а не копироваться из личного кабинета службы доставки.
Уведомления и автоматизация
Смену статуса удобно транслировать клиенту через Telegram-бота на aiogram, а саму синхронизацию между CRM, эквайрингом и складом собирать на n8n: одна цепочка сценариев вместо десятка ручных действий у оператора. Если у вас уже есть магазин на Tilda и заказов немного, часто хватает точечного скрипта, который подтягивает статус оплаты и трек-номер прямо в стандартную админку Tilda. Когда поток заказов переваливает за сотню в день и процессов становится больше, чем может унести один скрипт, отдельная панель обработки заказов под конкретный процесс окупается быстрее, чем кажется на старте.
Частые ошибки в интерфейсе оператора обработки заказов
Смотрю на однотипные проблемы почти в каждом проекте, который достаётся мне на доработку после чужой разработки.
- Слишком много всплывающих окон: чтобы посмотреть состав заказа, нужно открыть отдельный попап поверх другого попапа.
- Нет истории изменений статуса, поэтому невозможно понять, кто и когда перевёл заказ в «отменён».
- Трек-номер и статус оплаты вписываются руками, хотя оба значения давно доступны через API.
- Нет быстрых фильтров по срочности, способу оплаты или региону доставки, оператор ищет нужный заказ глазами по всему списку.
- Отсутствуют горячие клавиши для типовых действий: подтвердить, отменить, поставить пометку.
Каждая из этих мелочей по отдельности кажется незначительной, но вместе они превращают смену оператора в постоянное переключение контекста, а не в работу с заказами.
Сколько стоит разработать интерфейс обработки заказов
Стоимость зависит от того, дорабатываете вы существующую платформу или собираете отдельную панель с нуля. Ниже цены на мои услуги, актуальные на сегодня.
| Задача | Стоимость |
|---|---|
| Кастомный скрипт для Tilda (статус оплаты, трек-номер СДЭК) | от 3 000 ₽ |
| Комплексная интеграция для Tilda (CRM, эквайринг, доставка) | от 40 000 ₽ |
| Автоматизация в n8n | от 25 000 ₽ |
| Telegram-бот с уведомлениями по заказам | от 30 000 ₽ |
| CRM/админ-панель на React | от 100 000 ₽ |
| Отдельный веб-сервис под обработку заказов | от 300 000 ₽ |
На рынке аналогичные CRM-панели у студий и фрилансеров часто оцениваются в диапазоне 150 000-400 000 ₽ в зависимости от глубины интеграций, так что разброс цен между разными исполнителями обычно связан именно с количеством подключаемых систем, а не с дизайном экрана. Срок разработки отдельного веб-сервиса под обработку заказов у меня начинается от 8 недель, точечная интеграция для Tilda обычно занимает 3-5 дней.
Частые вопросы
Сколько блоков должно быть на экране заказа?
Обычно хватает шести: клиент, состав заказа, оплата, доставка, статус с историей и комментарии оператора. Если блоков больше, экран стоит разбивать на вкладки внутри одной карточки заказа, а не выносить данные в отдельные разделы сайта.
Нужна ли отдельная CRM, если заказы приходят с Tilda?
Не всегда. При потоке до пары десятков заказов в день часто достаточно кастомного скрипта, который подтягивает статус оплаты и трек-номер прямо в стандартную админку Tilda. Отдельная панель нужна, когда заказов становится много и появляются процессы, которые Tilda в принципе не умеет обрабатывать: сложная логика скидок, склад, несколько источников заказов одновременно.
Как ускорить работу оператора при большом потоке заказов
Убрать ручной ввод везде, где данные можно получить по API: статус оплаты из T‑Bank, трек-номер из СДЭК, уведомления клиенту через бота на aiogram. Плюс горячие клавиши для типовых переходов между статусами и фильтры по срочности прямо в списке заказов.
Что делать, если операторы путают статусы заказа
Обычно причина в размытых названиях статусов и в том, что переход между ними требует нескольких кликов в разных местах интерфейса. Решение - линейная схема статусов с понятным действием на каждом шаге и кнопкой перехода прямо в карточке заказа, без блужданий по меню.