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