Покупатель дошёл до последнего шага, заполнил корзину, ввёл телефон, нажал «Оформить заказ» — и получил красную надпись «Ошибка при сохранении заказа». Что сломалось? Какое поле? Что теперь делать? Он не знает. Через пару секунд он закрывает вкладку, и заказ, ради которого работала вся реклама и весь каталог, просто исчезает.
Сообщения об ошибках в форме заказа — это микрокопирайтинг, от которого напрямую зависит выручка. Эта статья о том, как переписать их по-человечески на 1С-Битрикс: как устроено хорошее сообщение, каким тоном писать, как привязать ошибку к полю и что делать с техническими ответами, которые приходят из учётной системы при автоматизации продаж и склада на 1С.
Коротко
- Форма заказа — последний шаг воронки; непонятная ошибка здесь обнуляет всю работу по привлечению.
- Хорошее сообщение говорит, что сломалось, где именно и что сделать — без обвинений и технического жаргона.
- Каждую ошибку привязывайте к своему полю и показывайте все проблемы сразу, а не по одной.
- Технические ответы из 1С (нет на складе, изменилась цена) переводите в человеческий текст с понятным действием.
Почему тексты ошибок важны именно в форме заказа
В любую форму на сайте покупатель приходит с разной степенью мотивации, но в форму оформления заказа — с самой высокой. Он уже выбрал товар, согласился с ценой, потратил время. Это самый дорогой трафик на всём сайте: за ним стоит реклама, SEO, работа каталога и корзины. Потерять человека здесь — значит потерять его на пике готовности купить.
Именно поэтому сообщение об ошибке на этом шаге работает не так, как на форме подписки или обратной связи. Если человек не понял, что от него хотят, он не будет разбираться — он уйдёт к конкуренту, где форма «не ругается». Текст ошибки здесь — не косметика, а прямой инструмент удержания конверсии.
Что не так со стандартными сообщениями Битрикса
Штатный модуль «Интернет-магазин» и компонент оформления заказа отдают сообщения, написанные с точки зрения системы, а не покупателя. Они технически корректны, но бесполезны для человека. Типичные проблемы:
- Абстрактность. «Не заполнены обязательные поля» — а какие именно? Покупатель ищет их глазами по всей форме.
- Технический язык. «Ошибка при сохранении заказа (ERROR)» ничего не говорит о причине и о действии.
- Оторванность от поля. Сообщение висит одним блоком сверху, а проблемное поле никак не выделено.
- Обвиняющий тон. «Вы ввели некорректные данные» звучит как упрёк, а не как помощь.
Это не вина платформы: стандартные тексты — универсальная заготовка. Задача разработчика и редактора — заменить их на формулировки под конкретный магазин и конкретные поля. Хорошая новость в том, что это делается один раз и работает на каждый заказ.
Анатомия хорошего сообщения об ошибке
Полезное сообщение об ошибке отвечает на три вопроса покупателя за одну короткую фразу: что случилось, где и что делать.
| Элемент | Задача | Пример |
|---|---|---|
| Что сломалось | Назвать проблему конкретно | «Не хватает номера телефона» |
| Где | Привязать к полю визуально | Подсветка поля «Телефон» |
| Что делать | Подсказать действие/формат | «Введите 11 цифр, например 79001234567» |
| Тон | Помочь, а не обвинить | Нейтральный, дружелюбный |
Не нужно раздувать текст. Одна ясная фраза лучше абзаца объяснений. Если формат сложный (например, ИНН или номер карты), добавьте короткий пример прямо в подсказку — это снимает большинство вопросов.
Тон и слова: пишем без обвинений
Самая частая ошибка в текстах ошибок — обвиняющая интонация. Слова «вы», «неверно», «недопустимо» превращают подсказку в упрёк. Покупатель и так расстроен, что заказ не прошёл, — не стоит усиливать негатив.
Ещё несколько принципов тона: не шутите про деньги и оплату (это раздражает), не используйте капслок и восклицательные знаки, не пишите «Внимание!» и «Ошибка!» крупными буквами. Спокойный, короткий, по делу текст воспринимается как помощь, а не как сбой.
Привязка ошибки к полю, а не к форме
Даже идеально написанное сообщение бесполезно, если покупатель не понимает, к какому полю оно относится. Поэтому ошибку нужно показывать в двух местах одновременно: коротким сводным списком сверху формы (чтобы человек видел общую картину) и подписью под каждым проблемным полем с его подсветкой.
Важные детали привязки:
- Показывайте все ошибки разом. Не заставляйте отправлять форму по кругу, чтобы узнавать про каждое поле по очереди.
- Прокручивайте к первой ошибке. После отправки автоматически подведите экран к первому проблемному полю, особенно на мобильном.
- Снимайте ошибку при исправлении. Как только поле заполнено верно, подсветка и текст должны исчезнуть — это даёт ощущение прогресса.
- Не теряйте введённое. При ошибке значения всех остальных полей должны сохраниться, иначе покупатель заполнит всё заново и уйдёт.
Как переписать типовые ошибки: примеры
Проще всего понять принцип на конкретных заменах. Слева — как обычно, справа — как по-человечески.
| Было | Стало |
|---|---|
| Не заполнено обязательное поле | Укажите имя — так курьер поймёт, кому передать заказ |
| Вы ввели неверный телефон | Проверьте номер: нужны 11 цифр, например 79001234567 |
| Некорректный email | Похоже, в адресе опечатка — проверьте символ @ и домен |
| Ошибка при сохранении заказа | Не удалось оформить заказ. Попробуйте ещё раз или позвоните нам — поможем |
| Недопустимый индекс | Индекс состоит из 6 цифр — проверьте, пожалуйста |
Заметьте: правые формулировки не длиннее левых, но каждая называет поле, объясняет формат и оставляет покупателю понятный следующий шаг. Именно эта конкретика превращает «стену» в диалог.
Ошибки, приходящие из 1С
Отдельная категория — ошибки, которые возникают не из-за покупателя, а из-за состояния данных: товара не осталось на складе, цена изменилась после синхронизации, доставка в регион недоступна. Эти ответы приходят на сайт при обмене с учётной системой, и показывать их дословно нельзя — они написаны для системы, а не для человека.
Такие ситуации перехватывают и переводят в понятный сценарий с действием: «Одной позиции, к сожалению, не осталось в наличии — убрать её из заказа?» или «Цена товара изменилась, актуальная — столько-то. Продолжить оформление?». Чтобы это работало корректно, наличие и цены должны стабильно приходить из 1С — это часть автоматизации на 1С. Техническую сторону обмена и защиту точек интеграции мы разбираем в статье про REST, вебхуки и безопасность в Битрикс.
Момент показа: на лету или при отправке
Когда именно показывать ошибку — вопрос не менее важный, чем её текст. Слишком ранняя валидация раздражает, слишком поздняя — заставляет проходить форму заново.
- Формат — на лету или при уходе из поля. Телефон и email удобно проверять, когда человек закончил вводить поле, чтобы подсказка появилась сразу.
- Обязательность — при отправке. Не подсвечивайте поле как «пустое», пока покупатель до него не дошёл, иначе форма кажется недружелюбной с самого начала.
- Серверные проверки — после отправки. Наличие, цену и доступность доставки проверяет сервер, но результат всё равно показывают человеческим текстом.
Хороший баланс: мягкая проверка формата по ходу заполнения плюс полная проверка при попытке оформить, со сводкой всех проблем сразу.
Где в 1С-Битрикс менять эти тексты
Технически тексты сообщений живут в нескольких местах, и важно не править ядро, чтобы изменения пережили обновления платформы.
- Языковые файлы компонента. Тексты компонента оформления заказа (sale.order.ajax или заказного) выносятся в языковые файлы шаблона, а не правятся в исходниках модуля.
- Настройки свойств заказа. Названия и обязательность полей задаются в свойствах заказа модуля «Интернет-магазин»; понятные названия — половина хорошего сообщения.
- Обработчики событий модуля sale. Кастомную валидацию и человеческие тексты удобно вешать на события оформления через D7-подход, не трогая ядро.
- Шаблон формы. Привязку ошибки к полю, подсветку и сводный список реализуют в шаблоне компонента и его JS.
Такой подход к кастомизации без правки ядра — общая практика для устойчивых проектов на Битрикс. О том, как строить логику на современном ядре, мы пишем в материале про D7 и ORM в Битрикс, а как безопасно выкатывать такие изменения — в статье про CI/CD и деплой Битрикс.
Мобильная версия и доступность
Больше половины заказов оформляется с телефона, и на маленьком экране требования к сообщениям об ошибках жёстче. Длинный текст переносится на несколько строк и ломает вёрстку, а проблемное поле легко теряется за клавиатурой.
- Короткие формулировки. На мобильном каждая лишняя строка стоит дорого — режьте текст до сути.
- Автопрокрутка к ошибке. После отправки экран должен сам подвести к первому проблемному полю.
- Правильные типы клавиатур. Для телефона — цифровая, для email — с символом @; это снижает число ошибок ввода в принципе.
- Доступность. Ошибку связывают с полем через aria-атрибуты, чтобы её озвучивал скринридер, а цвет подсветки дублируют иконкой или текстом — не все различают красный.
Частые ошибки
- Технический текст покупателю. Коды ошибок и ответы системы вместо человеческой фразы — верный способ потерять заказ.
- Одно сообщение на всю форму. «Заполните обязательные поля» без указания, какие именно, заставляет искать проблему глазами.
- Ошибки по одной. Форма отдаёт по одной проблеме за отправку, и покупатель ходит по кругу.
- Обвиняющий тон. «Вы ввели неверно» вместо «проверьте, пожалуйста».
- Потеря введённых данных. После ошибки форма очищается, и всё приходится вводить заново.
- Ранняя валидация обязательности. Поля «ругаются» пустыми ещё до того, как покупатель до них дошёл.
- Игнорирование мобильных. Длинные тексты и отсутствие автопрокрутки на телефоне.
Чек-лист внедрения
- Собрали все ошибки формы. Прошли оформление со всеми типами проблем и выписали каждое сообщение, которое видит покупатель.
- Переписали тексты. Каждое сообщение называет поле, объясняет формат и подсказывает действие спокойным тоном.
- Привязали к полям. Ошибка показывается и в сводке сверху, и подписью под подсвеченным полем.
- Настроили момент показа. Формат — на лету, обязательность — при отправке, серверные проверки — с человеческим текстом.
- Обработали ответы 1С. Наличие, цены и доступность доставки переведены в понятные сценарии с действием.
- Сохранили введённое. При любой ошибке значения полей не теряются.
- Проверили мобильную версию. Короткие тексты, автопрокрутка, правильные клавиатуры, доступность.
- Вынесли изменения из ядра. Тексты и валидация живут в шаблоне и обработчиках, а не в исходниках модуля.
Вывод
Сообщения об ошибках в форме заказа — это не мелочь для верстальщика, а инструмент удержания самой ценной части воронки. Покупатель на шаге оформления уже готов купить, и единственное, что может его остановить, — непонимание, что пошло не так. Понятный текст, привязанный к полю и написанный без обвинений, снимает это препятствие.
Начните с простого: пройдите свою форму со всеми типовыми ошибками, выпишите то, что видит покупатель, и перепишите каждую фразу под человека. Отдельно разберитесь с ответами, которые приходят из 1С, — переведите их в понятные сценарии. Эта разовая работа окупается на каждом заказе, который иначе был бы брошен на последнем шаге.
