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