Спор push против SMS часто отвлекает от главного: какое действие должен совершить человек и что случится, если он не увидит сообщение. Для операционного проекта канал выбирают по срочности, доступности и необходимости подтверждения, а не по моде.
Как задать политику уведомлений
В OCC/WAY базой служат in-app и WebSocket-обновления; web push доступен при активной подписке, а email и Telegram используются по правилам срочности и подключения. Не обещайте доставку через канал, на который пользователь не подписан: у критичного события должны быть запасной маршрут и эскалация.
Матрица для команды
- Низкий приоритет: собрать в дайджест или показать в интерфейсе.
- Рабочий статус: in-app и мгновенное обновление интерфейса.
- Срочное действие: персональное уведомление с понятным сроком и кнопкой перехода.
- Нет реакции: напомнить и передать выше по цепочке ответственности.
- После запуска анализировать не открытия, а время до результата и долю закрытых задач.
Как не превратить уведомления в шум
Каждое сообщение должно отвечать на три вопроса: что произошло, к какому объекту относится, что и до какого времени нужно сделать. Дубли по каналам оправданы для критичных личных событий, но не для каждого изменения в ленте.
Что зафиксировать до следующего шага
- У каждого типа события есть владелец и ожидаемое действие.
- Срочность определена правилами, а не субъективным нажатием кнопки.
- Есть резервный маршрут и эскалация при молчании.
- Метрика показывает реакцию и результат, а не количество отправок.
Частые вопросы
- SMS всегда надёжнее push?
- Канал сам по себе не гарантирует действие. Оцените доступность пользователя, стоимость, согласие на коммуникацию, необходимость подтверждения и сценарий при отсутствии реакции.
- Что отправлять заказчику?
- Только события его объекта и уровня доступа: готовность этапа, запрос решения, приёмка, важное замечание. Внутренние финансовые и кадровые детали не должны попадать в его канал.
