Цифровые продукты ·
Уведомление должно приходить ради следующего действия
Возможность отправить сообщение ещё не объясняет, зачем оно человеку. Push-уведомления для бизнеса стоит проектировать от события, после которого получателю нужно что-то сделать, и от времени, когда это действие ещё имеет смысл.
Начните с события, а не с рассылки
Запишите одну ситуацию: заказ готов к выдаче, документ ожидает согласования или встреча перенесена. Назовите получателя и действие, которое сообщение должно облегчить. Если после него человеку нечего делать и нечего уточнять, сначала разберитесь, зачем прерывать его внимание.
Разделите рабочие события и продвижение. Сообщение о готовности заказа помогает завершить уже начатую задачу. Предложение нового товара создаёт новую. Для этих сообщений нужны разные правила частоты, настройки и ожидания. Объединение их в общий поток затрудняет выбор полезных уведомлений и оценку результата.
Выберите канал для конкретной ситуации
Push подходит для короткого сигнала, который ведёт к действию в продукте. Письмо может быть удобнее для подробных условий и материалов, к которым вернутся позже. Сообщение внутри личного кабинета сохраняет контекст, но человек увидит его после входа. Иногда достаточно одного канала; иногда нужен согласованный резервный путь.
Не выбирайте приложение только ради уведомлений. Сначала проверьте, есть ли у аудитории повторяющаяся задача в нём. Если взаимодействие происходит редко и целиком помещается на сайте, оцените существующий маршрут. Вопрос формата уже разобран в статье [«Сайт или мобильное приложение»](/apocrypha/website-or-mobile-app); здесь решение касается конкретного события и канала.
У сообщения есть срок полезности
Уведомление «согласуйте документ сегодня» меняет смысл после закрытия задачи. Заказ может быть отменён раньше, чем человек откроет сообщение. Поэтому в задании нужны срок полезности, правило для изменившегося события и проверка актуального состояния после перехода.
Документация Firebase Cloud Messaging различает принятие сообщения к доставке и доставку устройству; задержки и срок хранения влияют на результат. Для бизнеса отсюда следует отдельная задача: устаревший сигнал не должен вести к действию, которое уже нельзя выполнить. Продукт должен объяснить текущее положение и предложить доступный следующий шаг.
Возможность отказа входит в проект
До реализации опишите категории уведомлений. Например, изменения своих заказов, задачи на согласование и новые предложения. Человеку должно быть понятно, что он выбирает, как изменить выбор и где найти сведения, если уведомления выключены. Не обещайте, что одно общее переключение решит все требования конкретной платформы: технический путь проверяется отдельно.
Продумайте общий экран устройства. Для сообщения о рабочем документе может быть достаточно нейтрального текста без фамилии клиента и содержания договора. Подробности открываются после перехода в продукт с его обычной проверкой доступа. Это решение о составе сообщения, которое следует принять до написания красивого текста рассылки.
Считайте завершённые действия
Перед пилотом запишите, что будет считаться пользой. Для согласования документа это может быть переход к нужной версии и завершение решения до установленного срока. Сам факт отправки не доказывает ни прочтение, ни действие. Даже открытие сообщения не объясняет, удалось ли человеку выполнить задачу.
Проверьте цепочку на тестовых событиях: кому предназначено сообщение, не отправляется ли оно повторно без причины, куда ведёт ссылка, что видно после закрытия задачи. Отдельно проверьте отключённые уведомления и недоступное устройство. Перечень дополняет [проверку приложения перед выпуском](/apocrypha/mobile-app-testing-before-release), но не заменяет её.
Закажите один законченный сценарий
Результатом первого этапа может быть короткий паспорт события: источник, получатель, текст, категории, срок полезности, переход, запасной канал и критерий успешного действия. По нему можно сравнить реализацию в готовой платформе с доработкой собственного продукта. Стоимость появится из конкретных связей и правил, а не из пожелания «добавить push».
Если событие ещё нельзя надёжно определить в системе, начните с его учёта. Если событие есть, но после сообщения человек теряется, исправьте страницу назначения. И только затем оценивайте дополнительные категории и частоту. Такой порядок позволяет расширять уведомления на основании работающего сценария.
Для [разработки приложения](/dialogue) полезно принести именно этот паспорт и описание текущего процесса. Тогда разговор о push-уведомлениях для бизнеса начинается с нужного действия и ограничений продукта, а первая версия получает проверяемую границу.
От сценария к приложению
Если вам нужно приложение, разберём ключевой сценарий, роли, первую версию и ограничения до начала разработки.