Комментарий и дополнительные поля заказа: как не перегрузить оформление

Что магазин сделает с ответом покупателя?

Что произойдёт с заказом, если покупатель напишет «позвоните перед доставкой»? Кто прочитает это пожелание? С этих вопросов стоит начинать выбор дополнительных полей заказа: от ответа зависит, нужен магазину свободный комментарий, отдельный вариант выбора или разговор с покупателем уже после оформления.

Далее речь о магазине с доставкой, где дополнительные пожелания передают сотруднику до отправки заказа. Комментарий подходит для пояснения, которое он прочитает и оценит. Для заранее известных действий, например выбора упаковки, удобнее отдельное поле: склад получит понятный ответ и сможет выполнить нужную операцию без разбора свободного текста. Подробности, без которых магазин уже принимает заказ, можно уточнить позже. У каждого способа есть свой срок получения ответа. Поэтому формат вопроса выбирают вместе с сотрудником, который использует данные: он покажет, где увидит пожелание и что успеет изменить до отправки.

Дополнительное поле оправдано, когда оно меняет конкретное действие. Если никто не может объяснить, зачем ответ нужен до отправки заказа, требование заполнить его переносит внутреннюю неопределённость магазина на покупателя.

Три способа спросить об одном пожелании

Сначала выберите способ обработки. Если ответ читают и обсуждают, достаточно комментария. Если он запускает известное действие, полезнее отдельный выбор с понятным значением. Если сведения понадобятся позже, вопрос переносят в разговор после оформления.

Сохранения в заказе мало. При приёмке покупатель пишет просьбу позвонить перед доставкой, а исполнитель показывает её путь до того сотрудника, который подготовит передачу заказа курьеру, включая экран чтения и момент получения этих сведений. Далее магазин подтверждает, что просьба попадёт тому, кто звонит. Если пожелание остаётся лишь в карточке администратора, в задании указывают недостающий переход данных и получателя. Испытание проводят на тестовом заказе, с отключёнными реальными уведомлениями. Такой проход связывает интерфейс с действием команды и позволяет принять доработку по понятному результату.

Обязательные сведения для покупки выбирают по оплате, доставке и типу плательщика. Этот состав формы подробно объяснён в разборе свойств заказа Битрикс.

Свободный комментарий подходит для объяснения

Покупателю проще написать необычное пожелание своими словами. Ради редкого уточнения не нужно предлагать длинный список вариантов. Комментарий полезен там, где решение принимает сотрудник после чтения, а от формулировки не требуется автоматически менять цену, доставку или комплектность заказа.

Свободное пожелание требует чтения. Покупатель может написать «в пятницу», «после праздников» или добавить к дате просьбу позвонить заранее, поэтому сотруднику придётся уточнить и день, и действие, прежде чем передавать заказ в доставку. Один текст допускает несколько толкований. Если от точной даты зависит выполнение заказа, я выбираю отдельное поле и понятный способ подтверждения даты, а комментарий оставляю для пояснения.

Подпись объясняет пределы пожелания

У поля нужна постоянная подпись. В рекомендациях W3C для форм подсказка внутри пустой строки не заменяет подпись, поскольку исчезает после начала ввода. Назначение вопроса остаётся видимым и рядом с уже набранным ответом.

Рядом можно объяснить, какие пожелания магазин здесь принимает и что требует отдельного согласования. Это помогает избежать обещаний, которые форма фактически не исполняет: поле «Комментарий» не подтверждает выбранную покупателем дату или бесплатную дополнительную услугу, пока магазин отдельно не принял эти условия.

В подсказке достаточно назвать назначение поля и сотрудника, который уточнит нестандартный запрос. Длинное перечисление просьб заставляет покупателя искать свою ситуацию среди чужих, хотя свободный комментарий как раз оставляет выбор формулировки. Повторяющиеся просьбы — сигнал для изменения формы. Если сотрудник снова и снова выделяет из текста один параметр, отдельный выбор сократит эту работу и заранее покажет покупателю, какие варианты магазин принимает.

Во время приёмки сравнивают пустой комментарий и содержательный текст с переносами строк. После ошибки в другом поле введённое пояснение сохраняется, чтобы покупателю не пришлось набирать его заново. Если магазин ограничивает длину, доступный предел виден до отправки.

Отдельное свойство нужно для известного действия

Структурированное поле даёт сопоставимые ответы. В справке Битрикса перечислены типы свойства заказа: текст, число, «да/нет», перечисление, файл, дата и местоположение. Тип выбирают под действие сотрудника.

Для известных вариантов лучше перечисление, чем свободный текст: покупатель выбирает из списка, а сотрудник получает одно из значений, смысл которых магазин определил заранее. У выбора есть получатель. Если услуга относится к подготовке доставки, исполнитель показывает, где склад прочитает ответ до комплектации и как передаст его дальше, когда сам не выполняет выбранное действие. Для платной услуги отдельно демонстрируют пересчёт суммы и сохранение итоговой стоимости, поскольку добавление свойства ещё не связывает его с ценой. Эти переходы принимают в тестовом заказе: значение на сайте, запись в заказе и сведения у получателя описывают один выбор. Так выясняется, какой этап уже работает, а какой ещё требует доработки.

Название для покупателя и код для интеграции

В справке по свойствам заказа название служит подписью, а мнемонический код — отдельным идентификатором. Если команде нужно переименовать вопрос «Позвонить перед доставкой», сначала меняют понятную покупателю подпись, а возможность сохранить код обсуждают с исполнителем: так он отдельно проверит, что уже настроенная передача пожелания продолжает работать после правки текста на форме.

У свойства настраиваются обязательность, множественность и значение по умолчанию. Для заранее выбранного варианта в задании называют основание: правило магазина или явный выбор покупателя. Случайный первый пункт списка плох тем, что создаёт заказ с услугой, которую человек мог даже не заметить. Иногда полезнее дать ответ «не требуется» или «уточню с менеджером», чем принуждать к неподходящему варианту. Тогда и сотрудник понимает, что предстоит обсудить.

Опция «Доступно в фильтре по заказам» позволяет использовать свойство для отбора. В документации указано: свойство типа «Дата» (DATE) и множественные значения недоступны для такого отбора. Поэтому до выбора типа спросите сотрудника, какой список заказов ему понадобится получать: например, отбор с определённой дополнительной услугой. Во время приёмки он показывает этот список и открывает контрольный заказ из результатов.

Ответ поступает до нужной операции. Для склада это момент комплектации, для менеджера — подготовка разговора с покупателем. Такой срок в задании полезнее обещания, что данные будут «видны где-то в системе».

Что спрашивать после заказа и что сохранять в профиль

Не каждое уточнение нужно до покупки. Если магазин способен принять заказ без подробностей, а сотрудник всё равно связывается с покупателем для согласования, часть редких вопросов можно оставить этому разговору, сохранив в форме только сведения, необходимые для самого оформления.

Уточнение после покупки входит в работу сотрудника магазина. Он связывается с покупателем до операции, для которой нужен ответ. Если менеджер связывается с покупателем лишь после комплектации, перенос вопроса о составе заказа создаст другую проблему. Сначала руководитель называет ответственного и момент разговора, затем определяет, какие действия ждут уточнения, а какие сотрудник выполняет сразу. Покупателю объясняют, что уже принято и о чём с ним ещё договорятся. В приёмке менеджер показывает заказ с нерешённым вопросом и способ заметить его до передачи на следующий этап. После этого редкое уточнение можно убрать из оформления без потери задачи.

Повторная покупка не должна повторять разовую просьбу

В Битриксе опция «Входит в профиль» сохраняет данные для следующих заказов. Документация рекомендует включать в профиль устойчивые сведения и не хранить там разовую комплектацию. Это различие относится и к дополнительным пожеланиям.

Просьба доставить конкретную покупку другому получателю или временное уточнение доступа относятся к одному заказу. Я не включал бы такие значения в постоянный профиль: покупатель может не заметить старую просьбу при повторном оформлении, а сотрудник доставки примет её за актуальный ответ и передаст новый заказ по указанию из прежней покупки.

У свойства есть опция «Служебное». Такое поле видно в административной части и скрыто от клиента. Сотрудник магазина может хранить здесь внутреннюю пометку, но она решает другую задачу, чем комментарий покупателя. Если менеджер меняет значение перед передачей заказа, в протоколе приёмки записывают, какой ответ получит следующий сотрудник.

Повторный заказ проверяют с другим пожеланием. По нему видно, осталась ли просьба в старой покупке или появилась снова там, где человек её не вводил.

Один вопрос — один понятный следующий шаг

У дополнительного вопроса есть своя работа: комментарий читают, значение отдельного свойства используют для известного действия, а подробности после оформления уточняет назначенный сотрудник. Смешение этих способов оставляет покупателя с лишним вопросом, а магазин — с ответом, который непонятно как выполнить.

Когда поле должно появляться

Свойства Битрикса привязаны к типу плательщика. Для дополнительного поля с привязкой к оплате или доставке официальный курс описывает показ при совпадении хотя бы одного выбранного критерия, а не обязательном одновременном совпадении двух списков. Исключение — местоположение, которое используется для расчёта доставки.

Показ поля проверяют по выбранным условиям. Покупатель меняет оплату и доставку, возвращается к прежнему варианту, а маркетолог смотрит, какие дополнительные вопросы появились и какой ответ сохранился. Скрытая строка не должна блокировать заказ. Старое пожелание также сверяют в сохранённой покупке после переключения, чтобы сотрудник не получил просьбу для уже отменённого способа доставки. У изменённого оформления принимают фактическое поведение на этих переходах.

W3C рекомендует явно обозначать обязательный или необязательный ответ и требуемый формат. Для редкого пожелания это снимает ещё один вопрос: человек видит, можно ли оставить строку пустой, а сотрудник знает, какие данные форма запросила у покупателя.

Доработку стоит начинать с одного пожелания и одного получателя. Опишите действие сотрудника, экран с ответом и нужный момент его передачи — по такому заданию команда ШТАБ ИТ поможет доработать оформление магазина.