Когда мини-приложению просить разрешение на сообщения?

Сначала запись, затем напоминание

Возьмём учебную ситуацию. Клиент записался на обслуживание 10 октября в 15:00. Запись уже подтверждена, на карточке видны услуга, дата, время, адрес и способ изменить договорённость. Теперь у предложения напомнить есть понятный предмет. Человек может решить, нужна ли ему помощь именно с этим визитом.

Рядом с карточкой можно написать: «Напомним один раз, 9 октября в 15:00, сообщением нашего бота. Время указано по месту обслуживания. Напоминание можно отключить; запись сохранится». Выбор назовём «Напомнить за сутки», отказ – «Без напоминания». Это пример текста для такой услуги, а не обязательные названия кнопок мессенджера.

Сутки здесь – 24 часа: 10 октября в 15:00 минус сутки даёт 9 октября в 15:00. Если у сервиса и клиента разные часовые пояса, на экране нужно прямо указать, чьё время показано. Обещание «завтра днём» выглядит проще, пока человек не пытается сопоставить его со своим календарём.

Окно мессенджера с просьбой дать боту доступ показываем после выбора «Напомнить за сутки», когда этот доступ ещё нужен. До него клиент должен увидеть, кто напишет и зачем. Общая фраза «Разрешите уведомления, чтобы быть в курсе» оставляет компании слишком много простора. В курсе чего именно, человек выяснит уже по первым сообщениям.

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

Можно предложить напоминание и на последнем шаге записи, если его выбор не мешает подтвердить услугу. Кнопка «Без напоминания» должна завершать тот же выбор времени. Если сотрудник ещё согласовывает визит, не обещайте сообщение о подтверждённой записи: сначала покажите, что заявка ждёт ответа.

Доступ бота и выбор клиента – разные решения

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

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

Мессенджер позволяет запросить право бота писать и получить результат просьбы. Но это разрешение не ограничивает бота ровно одним напоминанием. Обещание «один раз» должен соблюдать ваш сервис: хранить выбранную дату, не включать другие рассылки и не отправлять повторное сообщение после уже выполненного напоминания.

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

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

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

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

Отказ не должен отменять запись

Теперь клиент нажимает «Без напоминания» или не даёт боту доступ. Он отказался от одного способа напомнить, а обслуживание по-прежнему назначено. На экране остаётся спокойный итог: «Запись подтверждена: 10 октября, 15:00. Напоминание не включено».

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

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

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

Другой канал нельзя включать автоматически. Отказ от сообщений бота не означает «пришлите то же на почту». Даже если номер телефона или адрес уже есть у компании, клиент ещё не выбрал их для этого напоминания. Можно отдельно предложить другой способ с теми же понятными условиями. До нового выбора остаёмся без напоминания.

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

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

Проверка на трёх тестовых клиентах

Попросите разработчика подготовить три тестовых клиента с отдельными учебными записями на 10 октября в 15:00. В каждой карточке предложите одно сообщение за сутки, 9 октября в 15:00 по времени сервиса. Здесь проверяем ожидаемое поведение; реальным клиентам ничего не отправляем.

Нарисуйте три строки «выбрал напоминание → доступ бота → результат». Заполните их по примеру. Первый клиент уже разрешил сообщения: выбирает напоминание и видит дату отправки без повторного окна. Второй впервые разрешает сообщения и получает тот же итог. Третий отказывает, видит запись и остаётся без сообщения. Рядом с каждой строкой напишите, как снова открыть запись. Затем пройдите строки в тестовом приложении и отметьте, что произошло фактически.

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

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

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

Повторите проверку при переносе и отмене визита. После переноса в карточке и будущем сообщении должно быть актуальное время; при отмене старое напоминание убирается. Если отправка уже произошла до изменения, сервис не может сделать вид, что клиент никогда не получал старое сообщение. Покажите новое состояние записи и объясните, что изменилось.

Не ждите до 9 октября ради проверки. Разработчик может на отдельной тестовой записи назначить отправку через несколько минут и сохранить те же правила выбора и отмены. По переписке видно, сколько сообщений пришло; по плану отправки – осталось ли лишнее. Тестировать нужно оба результата, включая повторное открытие и повторное нажатие кнопки.

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

Когда просьба уместна

Я бы ставил просьбу там, где клиент уже может назвать пользу сообщения: «напомнить о моей записи завтра в три». Если доступ у бота есть, достаточно выбрать само напоминание. Если он ещё нужен, показываем объяснение, затем окно разрешения. Отказ оставляет клиенту запись и способ вернуться к её условиям.

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