Интернет-магазин обычно проектируют глазами покупателя: каталог, корзина, оформление и оплата
Но после запуска быстро выясняется, что есть ещё один важный пользователь — менеджер. Он принимает звонки и сообщения, создаёт заказы вручную, уточняет доставку, ищет клиента в CRM, отправляет ссылку на оплату и иногда работает с уже существующей сделкой
Если под него ничего не спроектировать, весь красивый интернет-магазин заканчивается набором вкладок браузера и копированием полей руками
Заказы приходят не только из checkout
В реальной компании заказ может начаться:
- на сайте
- из телефонного разговора
- из переписки
- из уже существующей сделки CRM
- после консультации оператора
Поэтому модель «есть только сайт и только checkout» слишком узкая
В РЕТОН появился отдельный внутренний сценарий, где менеджер может создать заказ сам и при этом оставить его в том же общем контуре, что и обычный заказ с сайта
Главное — не потерять происхождение клиента
Одна из неприятных ошибок ручных заказов — создание новой сделки там, где уже существует нужная
Это дробит историю общения, портит аналитику и может потерять источник клиента
Поэтому рабочее место менеджера умеет сначала искать кандидатов в CRM, а затем привязывать заказ к существующему контексту, когда это действительно нужно
Особенно важно при этом не перетирать атрибуцию: если сделка уже знает, откуда пришёл клиент, ручное создание заказа не должно превращать источник в «менеджер» только потому, что сотрудник нажал кнопку
Менеджеру не нужно знать устройство интеграции
Внутри процесс может затрагивать магазин, CRM, платёжную систему и 1С. Но интерфейс сотрудника должен говорить на языке задачи
Например:
найти клиента → выбрать товары → указать доставку → связать с CRM → подготовить оплату → отправить клиенту
Это гораздо лучше, чем инструкция «откройте CRM, скопируйте ID, потом откройте админку, потом создайте ссылку в другом сервисе»
Ссылка на оплату тоже часть рабочего процесса
Для менеджерского заказа важен отдельный платёжный сценарий
Система может подготовить страницу оплаты, а сотрудник — отправить её клиенту привычным каналом. При необходимости письмо или сообщение формируется из того же заказа, а не собирается вручную из кусочков
При этом платёж остаётся связан с конкретным внутренним заказом, поэтому после оплаты система понимает, что именно изменилось
Доставка должна жить рядом с заказом
Ещё один частый разрыв — когда доставка считается где-то отдельно
В рабочем месте менеджера полезнее сразу иметь поиск населённого пункта, доступные варианты и расчёт условий доставки. Тогда сотруднику не приходится пересобирать заказ после того, как выяснилось, что выбранный способ не подходит
Важный эффект — одинаковая модель для сайта и менеджера
Самое полезное здесь не в том, что появилась новая админ-страница
Полезно то, что заказ, созданный менеджером, дальше проходит через те же понятные состояния, что и заказ с сайта: CRM, оплата, учёт, сборка и исполнение
Так внутренний интерфейс не создаёт второй параллельный мир
Когда такой экран особенно нужен
Собственное рабочее место окупается, когда стандартная CRM-карточка уже не соответствует реальной последовательности действий сотрудника
Это не обязательно означает «CRM плохая». Просто CRM остаётся системой учёта и коммуникации, а поверх неё можно сделать маленький интерфейс, заточенный под конкретную операцию
Для меня это один из повторяющихся принципов в РЕТОН: не заставлять человека обслуживать архитектуру систем — подстроить интерфейс под работу человека