Карточка заказа — главный рабочий экран оператора RetailCRM. В ней собрана вся информация по сделке: клиент, товары, деньги и логистика, а также инструменты для смены статуса, коммуникаций и печати документов. Разберём, как устроена карточка и за что отвечает каждый блок и поле.
Общая структура карточки
Карточка заказа открывается по клику на номер заказа из раздела Заказы и построена по принципу единого экрана: слева — основное «тело» заказа, справа — панель коммуникаций и активности. Такая компоновка позволяет менеджеру видеть и содержание сделки, и переписку с клиентом одновременно.
Верхняя часть карточки — это «шапка»: номер заказа, текущий статус, ответственный менеджер, дата создания и сумма. Ниже идут функциональные блоки, каждый из которых отвечает за свою предметную область.
- Клиент — контактные данные, тип клиента, привязка к корпоративному аккаунту.
- Состав заказа — товарные позиции, количество, цены и скидки.
- Оплата — суммы, типы и статусы оплат.
- Доставка — способ, адрес, дата и стоимость.
- Параметры — тип заказа, способ оформления, источник, менеджер.
- Коммуникации — переписка, звонки, комментарии и история.
Блок клиента и контактов
Блок клиента связывает заказ с профилем покупателя в общей клиентской базе. Здесь отображаются имя, телефон, e-mail и признак типа клиента — физическое лицо или представитель компании. При работе в корпоративном режиме к заказу дополнительно привязываются компания и контактное лицо.
RetailCRM автоматически ищет клиента по телефону и e-mail при создании заказа: если совпадение найдено, система подтягивает существующий профиль и всю историю покупок, а не плодит дубли. Из блока клиента доступен переход в карточку покупателя, где виден сегмент, LTV и предыдущие заказы.
- Контактное лицо — тот, с кем реально общается менеджер.
- Компания — юрлицо для B2B-заказов и выставления документов.
- Персональные данные — телефоны и e-mail с возможностью указать несколько значений.
Состав заказа: товары и суммы
Табличный блок с товарными позициями — ядро карточки. Каждая строка содержит наименование, артикул, количество, цену за единицу, скидку и итоговую сумму по позиции. Товары добавляются из каталога с подсказкой по остаткам на складах, поэтому менеджер сразу видит, что реально есть в наличии.
| Поле позиции | Назначение |
|---|---|
| Товар / артикул | Ссылка на номенклатуру из каталога |
| Количество | Число единиц, с учётом остатка на складе |
| Цена | Базовая цена из каталога или ручная |
| Скидка | В рублях или процентах, на позицию или весь заказ |
| Сумма | Итог по строке после скидки |
Внизу блока сводятся итоги: сумма товаров, общая скидка, стоимость доставки и итог к оплате. Скидку можно задать как на отдельную позицию, так и на весь заказ — общая скидка распределяется по позициям пропорционально.
Оплата и доставка
Блок оплаты хранит финансовую часть сделки. Одному заказу может соответствовать несколько оплат — например, предоплата и остаток при получении. Для каждой оплаты указываются тип (наличные, карта, онлайн-платёж, безнал), сумма и статус: не оплачено, оплачено частично или оплачено.
Блок доставки отвечает за логистику: способ доставки (курьер, самовывоз, служба доставки), адрес, желаемые дата и время, а также стоимость. При подключённых интеграциях со службами доставки здесь же считается тариф, выбирается ПВЗ и формируется отправление с трек-номером.
- Способ доставки определяет доступный набор полей адреса и расчёт стоимости.
- Адрес разбит на компоненты: город, улица, дом, квартира, индекс.
- Дата доставки и временной интервал попадают в отгрузочные документы.
Системные параметры и статусы
Блок параметров описывает служебные характеристики заказа. Ключевое поле — статус, который отражает стадию обработки и группируется в группы статусов (новый, согласование, комплектация, доставка, выполнен, отменён). Смена статуса нередко запускает триггеры: постановку задач, уведомления клиенту, автозаполнение полей.
| Поле | Что задаёт |
|---|---|
| Статус | Текущую стадию обработки заказа |
| Тип заказа | Категорию (розница, опт, маркетплейс) |
| Способ оформления | Канал создания: сайт, телефон, вручную |
| Источник | Рекламный канал (UTM, кампания) |
| Ответственный менеджер | Оператора, ведущего заказ |
Отдельно стоит отметить теги — свободные метки, которыми удобно помечать заказы для последующей фильтрации (например, «vip», «претензия», «повтор»). Теги не влияют на логику, но сильно упрощают выборки и сегментацию.
Пользовательские поля
Стандартного набора полей хватает не всем процессам, поэтому RetailCRM позволяет добавлять пользовательские (кастомные) поля в разделе Администрирование → Пользовательские поля. Их можно создать для сущностей «Заказ», «Клиент» и «Компания», и в карточке заказа они выводятся отдельным блоком.
Каждое поле имеет символьный код, по которому к нему обращаются в API, триггерах и шаблонах документов. Поддерживаются разные типы данных:
- Строка и текст — произвольные значения (например, «код в 1С»).
- Число — вес, количество коробок, баллы.
- Дата — плановая отгрузка, срок гарантии.
- Флажок — да/нет (например, «нужен подарочный пакет»).
- Список — выбор из заранее заданных значений.
customFields — например, customFields.vip_client. Продумывайте коды заранее: переименовать поле легко, а вот менять код после запуска интеграций рискованно.Коммуникации и история изменений
Правая панель карточки — центр коммуникаций. Здесь в единой ленте собираются переписка из мессенджеров и e-mail, записи звонков, задачи и внутренние комментарии. Менеджеру не нужно переключаться между каналами: весь диалог с клиентом виден рядом с составом заказа.
Отдельно ведётся история изменений — системный журнал, который фиксирует, кто и когда менял поля заказа: статус, суммы, состав, ответственного. Это незаменимый инструмент для разбора спорных ситуаций и контроля работы операторов.
- Комментарий менеджера — внутренняя заметка, клиент её не видит.
- Комментарий клиента — пожелание покупателя, переносится в документы.
- История — хронология изменений с указанием автора и времени.
Итог
Карточка заказа RetailCRM — это единый экран, где сходятся клиент, товары, деньги и логистика, а также коммуникации и журнал изменений. Понимание её структуры и назначения каждого поля напрямую влияет на скорость обработки и на то, насколько корректно данные пойдут в документы, интеграции и аналитику.
Грамотно настроенный состав блоков, продуманные пользовательские поля и правила автоподстановки убирают ручную рутину и ошибки операторов. Если нужно настроить поля карточки под ваш процесс, связать их с 1С и маркетплейсами или выстроить статусную модель — мы поможем внедрить и донастроить RetailCRM под ваши задачи, от аудита процессов до обучения менеджеров.
Частые вопросы
Можно ли изменить набор полей в карточке заказа?
Да. Администратор скрывает или показывает блоки и создаёт пользовательские поля в разделе администрирования, адаптируя карточку под конкретный процесс продаж.
Что такое пользовательские поля и зачем они нужны?
Это дополнительные поля для данных, которых нет в стандартной карточке: код в 1С, вес, плановая отгрузка. Они добавляются для заказов, клиентов и компаний и доступны в API, триггерах и документах.
Может ли у одного заказа быть несколько оплат?
Да, к заказу можно привязать несколько оплат разных типов, например предоплату картой и остаток наличными при получении. Каждая имеет свою сумму и статус.
Как в карточке связаны заказ и клиент?
Заказ привязывается к профилю клиента по телефону и e-mail. При совпадении RetailCRM подтягивает существующего покупателя с историей покупок, не создавая дубль.
Где посмотреть, кто менял заказ?
В карточке ведётся история изменений — журнал, фиксирующий автора, время и суть каждого изменения полей, включая статус, суммы и состав заказа.
Чем комментарий менеджера отличается от комментария клиента?
Комментарий менеджера — внутренняя заметка, невидимая покупателю. Комментарий клиента отражает пожелания покупателя и может переноситься в отгрузочные документы.
Для чего нужны теги в заказе?
Теги — свободные метки для быстрой фильтрации и сегментации заказов, например vip или претензия. На бизнес-логику они не влияют, но упрощают выборки.
Как обратиться к пользовательскому полю через API?
По его символьному коду внутри объекта customFields, например customFields.vip_client. Поэтому код поля стоит продумывать до запуска интеграций.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.