Личный кабинет покупателя магазина: сценарии, проверка и приёмка

Личный кабинет покупателя магазина — это раздел сайта для просмотра заказов, статусов, документов, адресов и управления подписками. Задача раздела — дать покупателю понятный маршрут после оплаты и снизить нагрузку на поддержку. Ниже — карта сценариев, критерии выбора, учебный пример и чек-лист приёмки, по которому работу можно принять у подрядчика.

Зачем магазину личный кабинет покупателя и где его границы

Личный кабинет нужен там, где покупка не заканчивается одним заказом: покупатель возвращается, отслеживает доставку, хранит несколько адресов, оформляет повторно. Раздел решает три практические задачи. Покупатель сам находит ответы про свой заказ. Магазин получает актуальные данные для доставки и связи. Поддержка перестаёт отвечать на однотипные вопросы про статус и состав заказа.

Границы стоит зафиксировать до начала работ, иначе объём расползётся. Кабинет не заменяет учётную систему и CRM: он показывает то, что уже есть в заказах и профиле покупателя. Он не хранит данные банковской карты — оплата проходит на стороне платёжного сервиса. Он не решает задачи оптовых продаж с индивидуальными ценами и остатками: это отдельный класс решений, который разбирается в материале про B2B-портал для оптовых продаж: личный кабинет, остатки и цены под клиента. И он не подменяет оферту и правила возврата — это документы, а не интерфейс.

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

Ответственные. Со стороны заказчика нужен владелец продукта, который принимает решения по сценариям, и сотрудник поддержки, который знает реальные обращения. Со стороны подрядчика — аналитик, разработчик и тестировщик. Если роли не назначены, спорные места решает тот, кто громче, и это первая причина переделок.

Карта сценариев кабинета: как её собрать до начала работ

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

Что входит в карту

Соберите карту так. Выпишите обращения поддержки за месяц, сгруппируйте их по смыслу, опишите действия покупателя и менеджера, затем определите состав страниц.

Фиксируйте пять полей: исполнитель, входные данные, шаги, результат, способ проверки. Если результат нельзя проверить, сценарий неполный.

Как приоритизировать сценарии

Полезно сразу отметить, какие сценарии обязательны для запуска, а какие можно добавить позже. Обязательные — те, что закрывают частые обращения. Дополнительные — те, что улучшают опыт, но не мешают оформить заказ. Такой порядок защищает от соблазна сделать сразу всё и не успеть к запуску.

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

Вход, регистрация и связка гостевого заказа

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

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

Восстановление доступа. Продумайте, что видит покупатель, если забыл пароль или потерял доступ к почте. Сценарий восстановления должен быть описан в карте, а не оставлен на усмотрение разработчика. Здесь же решают, какие данные нужны для подтверждения личности, и сверяют это с требованиями к персональным данным.

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

История заказов, статусы и документы

Это ядро кабинета. Покупатель приходит сюда с одним вопросом: что с моим заказом. Значит, список заказов должен открываться быстро, а статус — читаться без расшифровки.

Что показывать в списке и карточке

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

Как называть статусы

Называйте статусы понятно для покупателя: «Собирается», «Передан в доставку». Внутренние коды скрывайте. Если статусов много, объединяйте их. Связь внутреннего статуса и пользовательского описывайте в карте сценариев.

Документы и печатные формы

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

Действия после оплаты: изменение заказа, отмена и возврат

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

Изменение состава заказа

При сборке или отгрузке свободное редактирование опасно. Используйте запрос на изменение: покупатель отправляет заявку, менеджер подтверждает. Статус заявки виден в кабинете.

Частичные оплаты и отгрузки

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

Отмена и возврат

Отмена — это смена статуса и, возможно, возврат денег. Возврат — отдельная процедура со своими правилами и сроками, которые определяются офертой и законом. Кабинет может принять заявку на возврат и показать её статус, но не должен обещать конкретный срок зачисления денег: это зависит от политики платёжного сервиса и банка. Формулировки в интерфейсе согласуют с профильным специалистом.

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

Персональные данные, адреса и профили покупателя

В кабинете покупатель поддерживает свои данные в актуальном виде. Это выгодно магазину: адрес доставки и телефон не устаревают.

Адреса и профили

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

Смена контактов

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

Удаление профиля

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

Подписки, накопительные скидки и карты

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

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

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

Если в магазине есть группы покупателей с особыми условиями, логика цен выносится отдельно и не смешивается с обычным кабинетом — см. Цены для групп покупателей. Смешение двух логик в одном разделе — частая причина путаницы и в ценах, и в правах доступа.

Учебный пример: кабинет для магазина с тремя сценариями

Учебный пример. Данные условные и приведены только для разбора логики.

Входные условия

Условный магазин «Городской сад» продаёт садовый инвентарь. Заказы оформляют и с регистрацией, и без неё. Доставка — курьером и в пункт выдачи. Оплата — онлайн и при получении. Поддержка получает много вопросов про статус заказа и про возможность поменять адрес после оформления. Программа лояльности не ведётся.

Что решили сделать

Владелец продукта и поддержка собрали карту из трёх обязательных сценариев: посмотреть заказ и статус, поменять адрес до отгрузки, повторить покупку. Блоки со скидками и картами лояльности в первую версию не включали — программы нет, показывать нечего.

Действия

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

Наблюдаемый результат

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

Проверка

Тестировщик проверил каждый сценарий на тестовых заказах: с оплатой онлайн и при получении, с доставкой курьером и в пункт выдачи, для зарегистрированного покупателя и для гостя. Отдельно проверили, что чужой заказ в кабинете не открывается и что после смены статуса в учётной системе покупатель видит обновление. Результат зафиксировали в карте сценариев.

Ограничения примера

Это учебный пример. Состав страниц и поддержка частичных оплат зависят от платформы, что подтверждается документацией и тестами.

Как проверить результат и принять работу

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

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

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

Типичные ошибки и ограничения

Первая ошибка — показывать в кабинете всё, что умеет платформа. Лишние страницы путают покупателя и увеличивают объём поддержки. Вторая — прятать статус за внутренними названиями, которые понятны только менеджеру. Третья — разрешать свободное редактирование заказа, который уже собирается: это расходится с учётом.

Отдельно стоит сказать про данные. Кабинет работает с персональными данными, поэтому вопросы их хранения, удаления и подтверждения личности выходят за рамки интерфейса и решаются вместе с профильным специалистом. Не стоит закрывать их только техническими средствами.

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

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

Какие исходные данные подготовить для оценки

Чтобы оценить работу по кабинету, подрядчику нужны конкретные входные данные. Чем точнее они собраны, тем меньше допущений в оценке.

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

Если кабинет проектируется вместе с запуском нового сайта, полезно заранее посмотреть, как устроена разработка интернет-магазина в целом: тогда кабинет встраивается в общую логику, а не пристраивается к ней позже.

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