Автоматизация push-уведомлений для SaaS: 5 шаблонов рабочих процессов

На графике показателя активации на понедельничном обзоре роста было 28%. Столько же, сколько в прошлом квартале. Столько же, сколько и в квартале до этого. Конверсия из пробной версии в платную составляет 14%. Ваш NRR двенадцать месяцев назад составлял 108%, а сейчас — 102%. Совет директоров спрашивает, что изменилось. Ничего не изменилось. В этом и проблема.

Стек жизненного цикла по-прежнему работает на тех же четырех автоматизированных push-уведомлениях, которые вы создали в прошлом году. Приветственное уведомление отправляется при регистрации. Уведомление о туре по продукту — через три дня. Уведомление об окончании пробной версии — на 12-й день. Уведомление о предупреждении о прекращении использования отправляется, когда DAU падает вдвое. Четыре триггера, каждый настроен в отдельном спринте отдельным владельцем кампании, каждый нацелен на один и тот же список подписчиков, ни один из них не осведомлен о других. Push-уведомление об активации отправляется людям, которые уже активировались. Push-уведомление об окончании пробной версии отправляется людям, которые уже обновились. Push-уведомление о предупреждении о прекращении использования отправляется людям, которые на самом деле не прекращают использование — они в отпуске.

Вот как выглядит автоматизация push-уведомлений для SaaS в большинстве среднерыночных PLG-команд: четыре-шесть несвязанных триггеров, замаскированных под автоматизацию, рассматриваемых как список кампаний, а не как граф рабочих процессов. За последнее десятилетие плейбук PLG стал хорош в работе по активации на стороне продукта, и большая часть легких достижений была связана с изменениями в продукте — редизайн онбординга, стартовые наборы с примерами данных, встроенные чек-листы. Следующие десять пунктов подъема активации и следующие пять пунктов NRR находятся не в продукте. Они находятся в слое автоматизации, которым должна была владеть команда по работе с жизненным циклом и которую так и не закончила строить.

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

Почему «автоматические push-уведомления» вашего SaaS замедляют NRR

Слово автоматизация выполняло ту же незаслуженную работу в SaaS, что и в электронной коммерции. Когда большинство команд по работе с жизненным циклом SaaS говорят «автоматические push-уведомления для SaaS», они имеют в виду триггерные push-уведомления: отдельные уведомления, которые срабатывают при возникновении события, без состояния, без ожидания, без ветвления, без условий выхода. Пользователь регистрируется, срабатывает приветственное push-уведомление. Пользователь достигает третьего дня, срабатывает push-уведомление с обзором продукта. Срок действия пробной версии пользователя приближается к концу, срабатывает push-уведомление об окончании пробного периода. Каждый триггер — это свой собственный конвейер, игнорирующий каждый другой триггер и не осведомленный о том, где пользователь на самом деле находится в своем жизненном цикле.

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

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

Для команды по работе с жизненным циклом SaaS среднего рынка это различие между NRR, который накапливается, и тем, который скользит вниз. Шесть триггеров, работающих параллельно, создают шесть каналов перекрестных помех. Пять рабочих процессов, работающих скоординированно, создают одно путешествие на подписчика на этап жизненного цикла, с ветвлением и ограничениями. Результаты поиска на первой странице по этому ключевому слову формулируют проблему как «какие push-уведомления отправлять» и отвечают списком инструментов или шаблонов. Это не тот вопрос, который менеджер по работе с жизненным циклом задает на понедельном обзоре роста. Вопрос в том, как составить путешествие.

Анатомия рабочего процесса push-уведомлений для SaaS

Перед чертежами — словарь. Рабочий процесс push-уведомлений SaaS строится из шести типов узлов. Как только вы узнаете, что делает каждый из них, каждый чертеж в этой статье будет читаться как схема, а не как описание.

СТАРТ. Точка входа. Узел СТАРТ определяет, как запускается рабочий процесс, либо событием подписчика (trial_signed_up, aha_moment_reached, usage_hit_80pct_of_plan_limit, dau_dropped_50pct), либо фильтром аудитории, который выбирает подписчиков, соответствующих определенным критериям в запланированное время. Рабочий процесс имеет ровно один узел СТАРТ.

ОЖИДАНИЕ. Задержка. Узел WAIT удерживает подписчика в этой точке на указанное время: часы для восстановления «момента озарения», дни для определения времени перехода от пробной версии к платной, недели для напоминаний о расширении. Или до определенного времени в календаре. Ожидания позволяют рабочему процессу не быть разовой рассылкой.

РЕШЕНИЕ. Двустороннее ответвление. Узел DECISION проверяет условие — повысил ли подписчик уровень, пригласил ли он товарища, достиг ли он события «момент озарения» за последние 24 часа, превышает ли его уровень MRR 99 долларов — и направляет его по пути ДА или по пути НЕТ. Решения позволяют рабочему процессу перестать относиться ко всем пользователям пробной версии одинаково.

РАЗДЕЛЕНИЕ_ПУТИ. Разветвление на основе процентов. Узлы SPLIT_PATH направляют подписчиков по нескольким путям на основе настроенных процентов: 50/50 для A/B-тестирования текста для перехода от пробной версии к платной, 33/33/34 для трехстороннего тестирования времени отправки напоминаний об активации. Как только у вас появится победитель, вы продвинете выигрышный путь до 100%, и рабочий процесс продолжит работу с проверенным вариантом.

ДЕЙСТВИЕ. Сама работа. Узлы ACTION отправляют push-уведомление, добавляют подписчика в сегмент, обновляют его пользовательские атрибуты, отправляют HTTP-запрос в вашу CRM, запускают другой рабочий процесс или останавливают его. PushEngage Workflows поддерживает одиннадцать типов действий. Наиболее распространенными в SaaS являются SendPushNotification, UpdateAttribute, HttpRequest (для CRM и эскалации в Slack) и Workflow.Start (для объединения стадий жизненного цикла).

КОНЕЦ / ВЫХОД. Терминал. Узлы END и EXIT завершают рабочий процесс и обновляют аналитику. END — это естественное завершение. EXIT обычно используется для досрочного завершения по пути НЕТ узла Decision, когда подписчик больше не соответствует требованиям, или для короткого замыкания, когда цель достигнута — подписка обновлена, DAU вернулся к базовому уровню, достигнут «момент озарения».

Каждый приведенный ниже шаблон состоит из этих шести частей.

Пять шаблонов рабочих процессов для SaaS

Это не «игры». Это рабочие шаблоны. Каждый из них перечисляет триггер, тип выполнения, последовательность узлов, критерии выхода и метрику удержания SaaS, которую он призван улучшить. Вы можете напрямую загрузить каждый из них в конструктор PushEngage Workflows и запустить первую версию менее чем за час. Для шаблонов текстов в каждом плане в старом каталоге примеров push-уведомлений для SaaS приведены конкретные формы сообщений; приведенные ниже шаблоны — это архитектуры пути, которые объединяют эти сообщения в последовательность.

Шаблон 1 — Серия активаций (автоматизация push-уведомлений для онбординга SaaS)

• Триггер (СТАРТ): Пользовательское событие trial_signed_up
• Тип выполнения: Одиночный (один путь активации на подписчика за 90-дневный период)
• Поток: Немедленное приветственное push-уведомление (ценностное предложение, а не перечисление функций) → ЖДАТЬ 1 час → push-уведомление с обзором продукта, сфокусированное на одной конкретной функции первого шага → ЖДАТЬ 24 часа → РЕШЕНИЕ: достиг ли подписчик события «момент озарения» (first_invoice_sent, first_dashboard_created, first_teammate_invited — в зависимости от того, что ваш продукт определяет как первую ценность)? → Путь ДА: push-уведомление с поздравлением и ненавязчивым предложением об обновлении, добавить в сегмент activated, КОНЕЦ → Путь НЕТ: ДЕЙСТВИЕ Workflow.Start, связывающееся с Блюпринтом 2 (восстановление момента озарения), КОНЕЦ
• Критерии выхода: Цель subscription_upgraded (после оплаты больше не отправлять сообщения об активации)
• Метрика SaaS: Коэффициент активации на 7-й день. 24-часовой контрольный пункт принятия решений — самый важный момент пробного периода. До этого момента пользователь исследует, после этого момента он либо принял решение, либо теряет интерес. Для текстов первых двух сообщений в шаблонах push-уведомлений для онбординга каталогизированы формы, которые стабильно работают.

Шаблон 2 — Восстановление "момента Ага"

• Триггер (СТАРТ): Workflow.Start из Блюпринта 1 ИЛИ фильтр аудитории trial_signed_up_more_than_24h_ago AND aha_moment_not_reached
• Тип выполнения: Одиночный
• Поток: Целевое push-уведомление с указанием конкретного шага, на котором застрял подписчик («Похоже, вы еще не создали свою первую панель управления — вот 60-секундный обзор») → ЖДАТЬ 12 часов → РЕШЕНИЕ: достигнут ли момент озарения? → Путь ДА: ДЕЙСТВИЕ Workflow.Start обратно в ветку поздравлений Блюпринта 1, КОНЕЦ → Путь НЕТ: отправить push-уведомление «Хотите пройти обучение?» со ссылкой на календарь → ЖДАТЬ 24 часа → РЕШЕНИЕ → если все еще нет, ДЕЙСТВИЕ HttpRequest в канал поддержки клиентов в Slack с пометкой пользователя для связи с человеком, КОНЕЦ
• Критерии выхода: Цель aha_moment_reached ИЛИ subscription_cancelled
• Метрика SaaS: Время до получения первой ценности. Для продуктов PLG время до получения первой ценности (TTFV) менее 7 дней является самым сильным предиктором конверсии из пробной версии в платную. Рабочий процесс восстановления момента озарения — это рычаг, который перемещает TTFV с «где бы пользователь ни оказался сам» на «где его может привести направленный толчок».

Шаблон 3 — Конверсия из пробной версии в платную (последовательность push-уведомлений от пробной до платной)

• Триггер (СТАРТ): Пользовательское событие trial_ends_in_3_days
• Тип выполнения: Одиночный
• Поток: Push-уведомление об окончании пробного периода (краткий обзор ценности, без скидки) → ЖДАТЬ 1 день → РЕШЕНИЕ: подписка обновлена? → Путь ДА: ВЫХОД → Путь НЕТ: push-уведомление об окончании пробного периода завтра со ссылкой на пример использования клиента → ЖДАТЬ 1 день → РЕШЕНИЕ → ДА: ВЫХОД → НЕТ: push-уведомление в последний день с ограниченной по времени скидкой на годовую подписку → КОНЕЦ
• Критерии выхода: Цель subscription_upgraded, соответствующая trial_id в триггерном событии. В тот момент, когда подписчик обновляет подписку — через 6 часов, 30 часов или 70 часов рабочего процесса — рабочий процесс для этого подписчика отменяется, и оставшиеся сообщения никогда не отправляются.
• Метрика SaaS: Коэффициент конверсии из пробной версии в платную. Это рабочий процесс с наиболее обоснованной статьей доходов. Расчеты приведены в разделе удержания ниже, но в качестве ориентира: каждый дополнительный 1% конверсии из пробной версии в платную по ежемесячному тарифу в 99 долларов США при 2000 пробных версиях в месяц составляет примерно 237 000 долларов США дополнительного годового регулярного дохода (ARR).

Шаблон 4 — Предложение расширения / обновления

• Триггер (НАЧАЛО): Пользовательское событие usage_hit_80pct_of_plan_limit (подписчики, места, вызовы API, проекты — в зависимости от того, что измеряется в вашем тарифе)
• Тип запуска: Несколько последовательных (один путь расширения за раз для каждой учетной записи; новый экземпляр запускается в следующем квартале, если порог будет достигнут снова)
• Поток: ЖДАТЬ 1 день (не запускать в момент срабатывания порога; дать пользователю закончить то, что он делал) → мягкое уведомление push с предварительным просмотром использования → ЖДАТЬ 5 дней → РЕШЕНИЕ: все еще 80%+? → Путь ДА: уведомление push с привязкой к ROI и кейсом клиента для следующего уровня → ЖДАТЬ 7 дней → РЕШЕНИЕ: подписка обновлена? → ДА: ВЫХОД → Путь НЕТ: ДЕЙСТВИЕ HttpRequest, создающее задачу в CRM для владельца учетной записи для связи со службой поддержки клиентов → КОНЕЦ
• Критерии выхода: Цель subscription_upgraded. Также выход при subscription_cancelled (что становится сигналом оттока, обрабатываемым в Блюпринте 5).
• Метрика SaaS: Вклад NRR. Доход от расширения — это метрика, определяющая оценку SaaS; рабочий процесс подталкивания к обновлению — это рычаг автоматизации, который преобразует сигналы использования по счетчику в доход от расширения ARR до того, как учетная запись будет вынуждена принять решение при продлении.

Шаблон 5 — Предотвращение оттока

• Триггер (НАЧАЛО): Фильтр аудитории dau_dropped_50pct_over_14d AND subscription_active
• Тип запуска: Одиночный (одна попытка предотвращения оттока на подписчика за 90-дневный период)
• Поток: Уведомление push для повторного вовлечения, показывающее функцию, которую подписчик никогда не использовал → ЖДАТЬ 5 дней → РЕШЕНИЕ: DAU вернулся к базовому уровню? → Путь ДА: добавить в сегмент re-engaged, ВЫХОД → Путь НЕТ: ДЕЙСТВИЕ HttpRequest для создания задачи в CRM для владельца CS + отправка push-уведомления с вопросом «что мы могли бы сделать лучше?» с одношаговым опросом → КОНЕЦ
• Критерии выхода: Условие аудитории dau_returned_to_baseline. Также выход при subscription_cancelled — в любом случае работа рабочего процесса завершена.
• Метрика SaaS: Коэффициент чистого оттока. Эскалация HttpRequest до CRM — это специфический для SaaS элемент: когда алгоритмическое восстановление терпит неудачу, рабочий процесс не сдается. Он передает учетную запись человеку из отдела по работе с клиентами с уже заполненным контекстом.

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

Сегментация по этапам жизненного цикла, A/B-тестирование и критерии выхода встроены в рабочий процесс

Доминирующая модель SaaS-маркетинга для этих трех концепций заключается в том, чтобы перечислять их как «лучшие практики» — общие пункты в конце статьи, оторванные от кампании, которая их использует. Это неправильный подход. Это не лучшие практики, которые находятся рядом с рабочим процессом. Это и есть рабочий процесс.

Концепция	Формулировка лучших практик (неправильно)	Формулировка узлов рабочего процесса (правильно)
Сегментация по этапам жизненного цикла	«Сегментировать по пробной версии / активированным / платящим / в группе риска»	Узел РЕШЕНИЕ, который проверяет lifecycle_stage (или вычисляет его из MRR + DAU + last-active) и направляет платящих пользователей на расширение, пользователей из группы риска на предотвращение оттока, а пользователей пробной версии на переход от пробной версии к платной.
A/B тестирование	«Всегда проводите A/B тестирование текста в конце пробного периода»	Узел РАЗДЕЛЕНИЕ_ПУТИ с распределением 50/50, балансировкой нагрузки подписчиков по каждому пути и полем winner_edge_id, которое продвигает победителя до 100%, как только тест достигнет значимости.
Тихие часы	«Не отправлять в 3 часа ночи»	Параметр на уровне рабочего процесса с start_at, end_at, timezone и настройкой fallback, которая либо skip (пропускает) отправку, либо reschedule (переносит) ее на одну минуту после окончания тихих часов — критически важно для глобальных B2B-команд, где финансовый директор находится в Лондоне, а руководитель разработки — в Сингапуре, и все они используют один и тот же план.
Критерии выхода	«Прекратить отправку тем, кто обновил подписку»	Правило на уровне рабочего процесса, которое проверяет подписчика по фильтру аудитории или по триггерной цели перед каждым узлом и отменяет рабочий процесс, если совпадение найдено.

Разница имеет значение, потому что лучшие практики легко принять к сведению, но трудно применить. Узлы рабочего процесса обеспечиваются самим движком. РЕШЕНИЕ выполняется каждый раз. РАЗДЕЛЕНИЕ_ПУТИ балансирует каждого подписчика. Отступление в тихие часы срабатывает без необходимости кому-либо помнить о времени. Правило выхода отменяет рабочий процесс независимо от того, обращает ли владелец кампании на это внимание.

Для приведенного выше чертежа перехода от пробной версии к платной это означает, что в тот момент, когда подписчик обновляет подписку — через 6 часов, 30 часов или 70 часов рабочего процесса — срабатывает правило выхода, рабочий процесс для этого подписчика отменяется, и оставшиеся касания никогда не отправляются. Никаких уведомлений «у вас остался один день до обновления» для тех, кто уже обновился вчера. Никаких сообщений в Slack от финансового директора с вопросом, прошла ли оплата.

Многоканальные push-уведомления для SaaS: веб-пуш, апп-пуш, внутри приложения, email и Slack/CRM

Вопрос о ширине канала по-разному решается для SaaS и для eCommerce. Каналы, важные для B2B PLG-команды, — это не только push и email. Это веб-пуши для веб-приложения, пуши в приложении для мобильных SaaS-приложений, внутриприложные сообщения для поверхности продукта, email как запасной вариант, когда push не подписан, и эскалация HTTP-запроса в Slack или HubSpot/Salesforce, когда вмешивается человек. Пять каналов эскалации, все они могут быть объединены в одном рабочем процессе, если движок рабочего процесса их поддерживает.

Сценарий восстановления "ага-момента" выглядит так:

• НАЧАЛО: событие trial_signed_up
• ПОДОЖДАТЬ 24 часа
• РЕШЕНИЕ: достиг ли подписчик события "ага-момента"?
  • ДА: ВЫХОД (активация прошла успешно, перейти к ветке поздравлений из Блюпринта 1)
  • НЕТ: продолжить
• РЕШЕНИЕ: вошел ли подписчик в веб-приложение в данный момент?
  • ДА: ДЕЙСТВИЕ — отправить внутриприложное сообщение (канал с наименьшим трением, эскалация пока не требуется)
  • НЕТ: продолжить
• РЕШЕНИЕ: подписан ли подписчик на веб-пуши?
  • ДА: ДЕЙСТВИЕ — отправить веб-пуш о пропущенном шаге
  • НЕТ: ДЕЙСТВИЕ — отправить email с тем же содержанием
• ПОДОЖДАТЬ 12 часов
• РЕШЕНИЕ: "ага-момент" достигнут сейчас?
  • ДА: ВЫХОД
  • НЕТ: ДЕЙСТВИЕ HttpRequest в Slack-канал Customer Success, назначить аккаунт представителю CS
• КОНЕЦ

Одна личность подписчика, один рабочий процесс, пять каналов эскалации. Сначала используется самый дешевый жизнеспособный канал: внутриприложное сообщение во время использования продукта, затем push, если подписан, затем email, если нет. Самый дорогой — время сотрудника CS — идет последним, только когда алгоритмическое восстановление явно не удалось. Для более глубокого рассмотрения компромиссов между каналами сравнение push vs in-app notifications подробно рассматривает математику затрат и персонализации для каждого.

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

Это дифференциатор, у которого нет аналога в результатах первой страницы по этому ключевому слову. Каждый из лучших результатов рассматривает push как один канал, а email — как сравнение. Ни один из них не описывает настоящий многоканальный рабочий процесс push-уведомлений для SaaS, где один триггер маршрутизируется через веб-пуш, внутриприложные сообщения, email и эскалацию до человека CS как единый путь с общими критериями выхода.

Математика NRR: доход по рабочему процессу, по каналу, по этапу жизненного цикла

Рабочий процесс, который не может быть защищен на следующем QBR, — это рабочий процесс, который будет прекращен. Задача менеджера жизненного цикла — показать в долларах или пунктах NRR, что произвела каждая автоматизация. Большинство статей об автоматических push-уведомлениях для SaaS останавливаются на уровне открытий. Этого недостаточно. Правильная метрика — это добавленный MRR на рабочий процесс, изменение NRR за квартал и снижение чистого оттока по когорте.

Рабочие процессы PushEngage отслеживают три показателя в каждом узле:

• Пользователи в очереди: подписчики, ожидающие в данный момент на этом узле (обычно это ожидание или перенос на часы тишины)
• Завершенные пользователи: подписчики, прошедшие через этот узел
• Выбывшие пользователи: подписчики, покинувшие рабочий процесс на этом узле либо потому, что совпали критерии выхода, либо потому, что они отменили подписку

Вот как выглядят аналитические данные на уровне узлов для активного рабочего процесса push-уведомлений от пробной версии к платной для SaaS с моделью PLG, 2000 пробных версий в месяц и ежемесячным тарифом 99 долларов (иллюстративные цифры):

Узел	В очереди	Завершено	Выбыло	Примечания
СТАРТ (trial_ends_in_3_days)	0	2,000	0	Все соответствующие пробные версии входят
ДЕЙСТВИЕ: push-уведомление "пробная версия скоро закончится"	0	2,000	0	Уведомление отправлено
ОЖИДАНИЕ 1 день	38	1,710	252	252 подписчика обновили подписку после первого касания (конверсия 12,6% только от касания)
РЕШЕНИЕ: подписка обновлена	0	1,710	0	1 710 остаются неконвертированными
ДЕЙСТВИЕ: "пробная версия закончится завтра" + пример исследования	0	1,710	0	Уведомление отправлено
ОЖИДАНИЕ 1 день	24	1,510	200	Еще 200 обновлений (дополнительные 10% конверсии)
ДЕЙСТВИЕ: "последний день" + скидка на ограниченное время	0	1,510	0	Финальное касание
КОНЕЦ	н/д	1,510	н/д	1 510 не обновили подписку

В этой когорте 452 пробные версии были конвертированы в платные во время нахождения в рабочем процессе (из 2000) — коэффициент конверсии из пробной в платную составил 22,6%, обусловленный тремя касаниями рабочего процесса. При ежемесячном плане в 99 долларов это составляет 44 748 долларов MRR, добавленных на когорту, или примерно 537 000 долларов дополнительного ARR в год, если размер когорты сохранится. Два ожидания (касание №1 и касание №2) являются узлами с наибольшим количеством выбывших в воронке, что является ожидаемой закономерностью: решения об обновлении принимаются в окнах ожидания, а не в окнах действий. Если ваш рабочий процесс показывает обратную картину — много выбывших на узлах действий, мало выбывших на узлах ожидания — ваши касания срабатывают слишком поздно, и окна ожидания следует сократить.

Расчет затрат аналогичен расчету для электронной коммерции, с добавлением каналов, специфичных для SaaS. Веб-push и внутриприложения сообщения бесплатны для отправки после получения согласия. Стоимость электронной почты зависит от вашего контракта с ESP (Customer.io, Iterable, Klaviyo) — для списка SaaS из 50 000 подписчиков одна отправка уведомления об окончании пробного периода обычно обходится в несколько сотен долларов за касание. Время работы специалиста по работе с клиентами, с другой стороны, стоит реальных денег: менеджер по работе с клиентами, обрабатывающий 10-минутное обращение в Slack при годовой стоимости 90 000 долларов с учетом всех расходов, обходится примерно в 7,50 долларов за обращение. Задача рабочего процесса — использовать самый дешевый жизнеспособный канал в первую очередь и эскалировать только тогда, когда это требует ситуация. Когда в строке указано «рабочий процесс конвертации из пробной в платную восстановил 44 748 долларов MRR за последнюю когорту при общей стоимости 312 долларов на когорту», разговор на QBR будет коротким.

Создайте это в PushEngage Workflows для вашего SaaS

Каждый из пяти шаблонов SaaS напрямую сопоставляется с компонентами PushEngage Workflows. Таблица сопоставления:

Шаблон	Используемые типы узлов	Типы используемых действий	Параметр рабочего процесса
Серия активаций	START, WAIT, DECISION, ACTION, END	SendPushNotification, AddSegment, Workflow.Start	Тип запуска: Одиночный
Восстановление "момента ага"	START, WAIT, DECISION, ACTION, END	SendPushNotification, HttpRequest, Workflow.Start	Тип запуска: Одиночный
Конверсия из пробной версии в платную	START, WAIT, DECISION, ACTION, END	SendPushNotification	Тип запуска: Одиночный; выход при достижении цели subscription_upgraded
Стимул к расширению/обновлению	START, WAIT, DECISION, ACTION, END	SendPushNotification, HttpRequest	Тип запуска: Несколько последовательных
Предотвращение оттока	START, WAIT, DECISION, ACTION, END	SendPushNotification, HttpRequest, AddSegment	Тип запуска: Одиночный; триггер на основе аудитории

Механизм Workflows поставляется с более чем 60 готовыми шаблонами, охватывающими каждый из этих потоков. Шаблоны, ориентированные на электронную коммерцию (приветствие, брошенная корзина, возврат клиента), легко адаптируются для SaaS путем замены триггерного события и цели условия выхода. Приветственные шаблоны становятся основой автоматизации push-уведомлений для онбординга в SaaS — серии активаций, восстановление "момента ага" и остальная часть последующей цепочки Blueprint 1. Логика шаблона брошенной корзины становится логикой перехода от пробной версии к платной версии с заменой cart_abandoned на trial_ends_in_3_days и purchase на subscription_upgraded. Архитектура является вертикально-агностической; меняется только лексика.

Для более широкого обзора того, как PushEngage подходит для использования в SaaS — цены, интеграции, примеры клиентов — PushEngage для SaaS является канонической целевой страницей. Для немедленного пути к пробной версии: бесплатный план дает вам 200 подписчиков, все каналы (веб-пуш, пуш в приложении, WhatsApp, живой чат) и полный механизм Workflows с первого дня. Этого достаточно, чтобы реализовать план перехода от пробной версии к платной для вашей следующей когорты и иметь обоснованное число MRR для следующего QBR.

Что это меняет

Если вы вынесете что-то одно из этой статьи, вынесите это: автоматизация push-уведомлений для SaaS — это архитектура рабочего процесса, а не список кампаний. Путь от пробной версии к платной, который завершается обновлением, серия активаций, которая переходит в восстановление "момента ага", и межканальная оркестровка, которая эскалируется до живого представителя службы поддержки только тогда, когда алгоритмическое восстановление терпит неудачу, — все имеют одинаковую форму. Один START, несколько WAIT, несколько DECISION, несколько ACTION, один EXIT. Четыре автономных триггера не могут этого сделать. Один движок рабочего процесса может. Математика NRR накапливается оттуда.

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