Is the app ready for customers?Готово ли приложение к клиентам?
An installed icon and a working catalog do not establish readiness for customers. Verify the promise the customer sees against what the selected location can actually deliver. App acceptance reaches the point where the team can explain the outcome and handle an exception.Готовая иконка и открывающийся каталог не означают готовность клиентского канала. Проверяйте обещание, которое видит клиент, и работу, которую действительно может выполнить точка. Приёмка приложения заканчивается там, где команда умеет объяснить результат и исправить исключение.
Collect customer-facing promisesСобрать обещания клиенту
The channel owner selects the actions to enable at opening: ordering, booking, repeat purchase or support. For each, record the displayed promise, source of price and availability, confirming event and fulfillment team. Do not enable a section solely because it can appear in the menu.Владелец канала выбирает доступные при открытии действия: заказ, запись, повтор покупки или обращение. Для каждого сохраните экранное обещание, источник цены и наличия, подтверждающее событие и команду исполнения. Не включайте раздел только потому, что его можно показать в меню.
Prepare fictional customer records and scenarios without live charges or broadcasts. Specify location, language, device and connection conditions. If a live operation is necessary, agree its consequences, owner and reversal procedure separately. A test label alone does not isolate external actions.Подготовьте набор вымышленных клиентов и сценариев без реальных списаний и рассылок. Укажите выбранную точку, язык, устройство и условия связи. При необходимости проверки живой операции отдельно согласуйте последствия, ответственного и способ отмены; тестовая надпись сама по себе не изолирует внешние действия.
Align location, price and availabilityСверить точку, цену и доступность
Check a location change after adding an item. The basket must lead to a clear decision about price, availability and fulfillment. The business defines the required behavior and the configurator verifies it. Do not assume every location shares one assortment or that a saved basket fixes a price indefinitely.Проверьте смену точки после добавления товара: корзина должна приводить к понятному решению о цене, доступности и исполнении. Требуемое поведение задаёт бизнес и подтверждает настройщик. Не предполагайте, что все точки имеют одинаковый ассортимент или что сохранённая корзина фиксирует цену навсегда.
For a repeat order, use an item that has changed or disappeared since the previous purchase. The customer must understand the new contents being confirmed. Compare the app result with the worker’s record: an old name without the current variant can produce an apparently valid but unfulfillable order.Для повторного заказа используйте позицию, которая с прошлого раза изменилась или исчезла. Клиент должен понимать, какой новый состав подтверждает. Сравните итог в приложении и рабочую запись у исполнителя; старое название без актуального варианта способно создать внешне правильный, но невыполнимый заказ.
Test an uncertain submissionПроверить неясный результат
Consider a lost response after submitting an order. The customer cannot tell whether a record exists and tries again. The tester checks the actual outcome on both sides and records how the selected configuration behaves. An observed duplicate needs an owner; duplicate protection cannot be declared effective without evidence.Рассмотрите потерю ответа после отправки заказа. Покупатель не знает, создана ли запись, и нажимает ещё раз. Проверяющий ищет фактический результат на обеих сторонах и фиксирует поведение выбранной конфигурации. Обнаруженный повтор получает владельца; нельзя объявлять защиту от дублей работающей без проверки.
Separately revisit the app after an interruption: a changed booking, expired access and an unfinished payment. Support staff need an agreed identifier for finding the relevant history. Declining notifications should still leave a clear way to check a commitment that has already been accepted.Отдельно пройдите возвращение в приложение после паузы: изменённая запись, истёкший доступ и незавершённый платёж. Сотрудник поддержки должен найти нужную историю по согласованному идентификатору. Отказ в уведомлениях не должен лишать клиента понятного способа проверить уже принятое обязательство.
Assign message and support ownersНазначить владельцев сообщений
The service owner compares confirmation, rescheduling and cancellation wording with actual states. A “ready” message must not substitute for checking fulfillment. Assign an editor and reviewer for each language; translations must preserve timing, location and the action expected from the customer.Владелец обслуживания сверяет тексты подтверждений, переносов и отмен с фактическими состояниями. Сообщение «готово» не должно использоваться как замена проверки исполнения. Для каждого языка назначьте редактора и проверяющего; перевод должен сохранять срок, место и требуемое действие клиента.
Define who owns a request outside the usual shift and what customers see while waiting. Do not promise immediate help when it is unavailable. Test a handoff between staff with the original order and actions already taken, so a repeated request does not restart the investigation.Определите, кто отвечает на обращение вне обычной смены и что клиент видит во время ожидания. Если мгновенная помощь недоступна, не обещайте её. Проверьте передачу вопроса между сотрудниками с исходным заказом и уже выполненными действиями, чтобы повторное обращение не начинало разбор заново.
Open only verified journeysОткрыть только проверенные пути
The acceptance package records devices and versions, completed scenarios, known limitations and support owners. The channel owner decides which actions to expose. An unverified feature can be deferred if the remaining journey is complete and the wording does not promise the excluded capability.Приёмочный пакет содержит устройства и версии, выполненные сценарии, обнаруженные ограничения и ответственных за поддержку. Владелец канала решает, какие действия открывать клиентам. Непроверенную функцию можно отложить, если оставшийся путь полноценен и тексты не обещают исключённую возможность.
SABSUS describes an app covering catalogs, orders, bookings, loyalty and support. Confirm the contents of your version, its integrations and publication arrangements separately. Store-release readiness and the team’s ability to receive customer work need different evidence; neither establishes the other.SABSUS описывает приложение с каталогом, заказами, записями, лояльностью и поддержкой. Состав вашей версии, интеграции и публикацию подтвердите отдельно. Готовность магазина приложений и готовность команды принимать клиентскую работу проверяются разными доказательствами; одна не заменяет другую.
Quick answersКороткие ответы
Must every section open at once?Нужно ли открывать все разделы сразу?
No. Open agreed complete journeys and remove promises of deferred capabilities. Support needs an answer for excluded scenarios.Нет. Откройте согласованные полноценные пути и уберите обещания отложенных возможностей. У поддержки должен быть ответ для исключённых сценариев.
Is one phone enough for testing?Достаточно ли проверки на одном телефоне?
Choose coverage from supported devices, versions and usage patterns. Record what was tested and explicitly state its limits.Покрытие выбирают по поддерживаемым устройствам, версиям и способам использования. Сохраните проверенный набор и явно отметьте его ограничения.
Can a push message prove acceptance?Можно ли считать push подтверждением заказа?
Reconcile the accepted operational record and its state. Delivery of a notification alone proves neither order acceptance nor fulfillment.Сверяйте подтверждённую рабочую запись и её состояние. Доставка уведомления сама по себе не доказывает ни приём заказа, ни его исполнение.