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

Почему исходящая рассылка кажется рискованной для пользователей бесплатного тарифа
Исходящая коммуникация меняется в тот момент, когда кто‑то уже пользуется вашим продуктом. Классический холодный аутрич начинается без контекста, поэтому основной критерий — релевантность. С пользователями бесплатного тарифа у вас есть контекст, но также и больше способов ошибиться. Если в письме будет намёк, что вы слишком за ними наблюдали, это может показаться creepy, даже если ваша цель — действительно помочь.
Поэтому PLG‑аутрич часто похож на ход по канату. Сигналы использования делают письмо своевременным, но чем конкретнее вы становитесь, тем более навязчивым это может выглядеть.
Большинство команд пытаются сбалансировать две цели:
Во‑первых, помочь пользователю быстро получить ценность. Во‑вторых, понять, есть ли реальный путь к расширению (большая команда, админ‑функции, повышенные лимиты). Когда эти цели смешиваются, письма начинают звучать как «Мы заметили, что вы достигли лимита — платите», и люди становятся защищающимися.
Более безопасный подход — воспринимать сигналы как повод начать обычный деловой разговор, а не как доказательство наличия у вас панировочной камеры. Вы можете быть конкретными, не цитируя чувствительных деталей: фокусируйтесь на результатах и типичных сценариях и дайте людям простой способ вас поправить.
Простой пример: маленькая команда на бесплатном тарифе быстро приглашает коллег и создаёт проекты. Рискованное письмо: «Мы видели, что вы пригласили 7 пользователей вчера и создали 12 проектов». Безопаснее: «Команды, которые начинают приглашать коллег, часто сталкиваются с вопросами по совместному доступу и отчётности. Вы тот, кто это настраивает, или мне обратиться к другому человеку?» Вы всё ещё действуете на основании сигнала, но не раскрываете их точную активность.
Сдвиг в мышлении прост: вы не указываете на них. Вы предлагаете помощь в момент, когда она, вероятно, уместна, и позволяете им самим решить, что дальше делиться.
Что считается сигналом продукта (а что нет)
Сигнал продукта — это небольшая наблюдаемая подсказка, что кто‑то пытается получить ценность из вашего продукта. Это не биография всех их действий.
Полезный тест: ожидал бы обычный пользователь, что вы заметите это? Если да — обычно безопасно упомянуть в общих чертах. Если нет — оставьте это только для внутреннего таргетинга.
Сигналы, которые хорошо работают как «полезный контекст»
Сигналы, связанные с успешностью, трением или очевидным следующим шагом, обычно безопасно упоминать в общих чертах. Примеры: запуск ключевого рабочего процесса (например, создание первого проекта), подключение интеграции, приглашение коллег или достижение видимого лимита.
Если что‑то мешает прогрессу (повторяющиеся ошибки импорта, сбои в проверках настройки, ошибки валидации), это тоже может быть поводом предложить помощь — при условии, что вы остаётесь общими.
Даже с безопасными сигналами держите формулировки широкими. «Мы заметили, что вы начали настраивать X» звучит нормально. «Увидели, что вы кликали X три раза» — уже нет.
Данные, которые не стоит прямо упоминать
Некоторые данные полезны для скоринга и маршрутизации внутри команды, но смотрятся странно в письме. Избегайте:
- Точных временных меток и пошаговых хронологий действий.
- Страничного или покликного отслеживания.
- Личных данных, которые вам не нужны для решения проблемы.
- Контента, который они вводили в продукт (загруженные файлы, черновики, списки контактов).
- Чувствительных атрибутов, выведенных из поведения.
Практическое правило: разделяйте таргетинг и месседжинг. Подробную аналитику можно использовать для выбора аудитории, но в письме оставайте минимум контекста, который делает сообщение полезным. Если команда близка к лимиту бесплатного тарифа, «Похоже, вы приближаетесь к месячному ограничению» обычно достаточно. Не указывайте день, час или перечень действий, которые к этому привели.
Выбирайте персону по сигналам, а не по должностям
Должности в PLG запутанные. «Head of Product» может никогда не пользоваться вашим приложением, а «Analyst» — управлять им ежедневно. Самый безопасный способ решить, кому писать, — следовать за тем, что люди делают, а не за их профилем.
Простая карта персон (по поведению)
В большинстве бесплатных аккаунтов встречаются несколько повторяющихся ролей. Их можно определить по лёгким, не‑криповым сигналам:
- Builder (повседневный пользователь): создаёт проекты, отправляет конфигурации, запускает воркфлоу, сталкивается с ошибками и пробует снова.
- Champion (внутренний промоутер): приглашает коллег, делится ссылками, помогает другим принять продукт.
- Approver (владелец бюджета): спрашивает про цены, лимиты, счета и добавление мест.
- Security/IT (проверяющий риски): запрашивает SSO, audit logs, SCIM, документы по вендору.
- Procurement (ответственный за бумажную работу): сосредоточен на онбординге поставщика и условиях оплаты.
То, что вы отправляете, должно соответствовать сигналу. Если кто‑то пригласил трёх коллег — это, скорее всего, проблема чемпиона или администратора, а не закупщика. Если кто‑то назначает роли и права, это обычно лучший первый контакт для разговоров о развёртывании.
Правила для аккаунтов с несколькими пользователями
Когда в аккаунте несколько пользователей, начинайте с того, кто ближе к боли, и расширяйтесь аккуратно.
Если сигнал — трение (лимиты, ошибки, тайм‑ау́ты), сначала пишите builder. Если сигнал — принятие (приглашения, новый рабочий пространство, несколько активных пользователей), начинайте с чемпиона или администратора. Если сигнал — соответствие требованиям (SSO, домены, экспорт данных), держите сообщение коротким и адресуйте Security/IT. Если сигнал — намерение купить (клики по апгрейду, прямые «нужны дополнительные места»), подключайте approver.
Если не уверены, выбирайте того, кто совершил последнее значимое действие, а не того, у кого выше должность.
Приватность и тон: как ссылаться на сигналы безопасно
Самый быстрый способ потерять доверие пользователей бесплатного тарифа — показаться шпионящим. Вы можете использовать продуктовые сигналы, но описывайте их как подсказку, а не как отчёт наблюдения.
Простое правило: упоминайте, что происходит, но не как вы это узнали.
«Заметили, что вы активнее приглашаете команду» звучит нормально. «Увидели, что вы кликали Настройки > Роли в 9:12» — уже creepy.
Безопасный способ объяснить причину обращения
Ваше «почему сейчас» должно звучать как поддержка, а не как уличение. Используйте нейтральные формулировки и не намекайте, что пользователь сделал ошибку.
Хорошие шаблоны:
- «Пишу, потому что команды обычно сталкиваются с X, когда начинают делать Y.»
- «Даю быструю подсказку на случай, если это сэкономит вам время.»
- «Если вы тот человек — отлично. Если нет, подскажите, кто этим занимается?»
- «Если это неактуально, можете не отвечать — я не буду продолжать.»
Держите просьбу лёгкой. Один небольшой вопрос — достаточно: «Нужна ли вам двухшаговая настройка?» или «Стоит ли 10‑минутный созвон?» Сильные вопросы вроде «Какой у вас бюджет и сроки?» слишком тяжёлы, когда человек ещё просто изучает продукт.
Когда переходить на более общие формулировки
Некоторые сигналы слишком чувствительны, чтобы называть их прямо, даже если они верны. Использование данных, связанных с конкретным клиентом, типом данных или внутренним процессом, может выглядеть навязчиво. В таких случаях будьте менее конкретны и предложите выбор.
Вместо «Я видел, что вы импортировали 4 812 контактов» скажите «Если вы начинаете импортировать большой список, есть несколько настроек, которые помогут избежать проблем позже». Вы всё ещё звучите релевантно, но даёте пространство.
Наконец, сделайте отказ простым: «Ответьте «нет» и я прекращу» — это снижает давление и воспринимается уважительно.
Пошагово: как собрать список для исходящих на основе сигналов
Начинайте с идеи, что вы не рассылаете всем подряд. Вы реагируете на небольшие моменты, которые обычно означают, что кто‑то может столкнуться с проблемой, апгрейдиться или приглашать других.
1) Определите 3–5 триггеров
Выберите триггеры, которые можно объяснить одной фразой и которые соответствуют реальному следующему шагу. Примеры: достижение 80% лимита, использование ключевой функции дважды за неделю, добавление второго пользователя, создание проекта, но незавершение его.
Опишите, что вероятно означает каждый триггер («получают ценность», «оценивают», «может отток»). Если вы не можете описать значение, уберите триггер.
2) Добавьте простую систему приоритетов
Вам не нужен сложный скоринг. Достаточно понять, на что действовать в первую очередь.
Hot: сильный сигнал в последние 24–72 часа. Warm: значимая активность, но не срочно. Nurture: ранний или неактивный этап.
Затем задайте окно для аутрича. Hot — тот же день или на следующий. Warm — в течение недели. Nurture — ежемесячные касания или автоматические сообщения.
3) Добавляйте только те данные, которые действительно используете
Прежде чем тянуть дополнительные поля, спросите: изменит ли это письмо, которое я пишу?
Полезные поля обычно: роль (или функция), приблизительный размер компании, внутренняя команда или агентство. Техстек помогает, но только если вы можете говорить о нём естественно.
Если поле не меняет тему письма, первый абзац или того, кому писать — пропускайте его.
4) Наладьте чистую передачу ответов
Решите, что передаётся человеку, а что остаётся автоматикой. Например: аккаунты с высоким намерением идут в отдел продаж, «застрявшие» — в customer success, nurture остаётся в лёгкой последовательности.
Если используете платформу для холодных писем вроде LeadTrain, держите ту же структуру в отдельных сегментах, чтобы нужная команда видела нужную очередь и аккаунт не контактировали дважды.
5) Поддерживайте список в актуальном состоянии
Сигналы быстро теряют актуальность. Пересобирать список по расписанию (ежедневно для hot, еженедельно для warm). Удаляйте тех, кто ответил, апгрейднулся или отписался. Релевантность защищает доверие и доставляемость.
Пошагово: напишите первое письмо и follow‑up
Когда кто‑то уже пользуется бесплатным тарифом, письмо должно восприниматься как помощь, а не слежка. Задача первого сообщения проста: дайте безопасную причину обратиться, предложите понятный следующий шаг и упростите отказ.
Хорошее первое письмо обычно состоит из четырёх частей:
- Контекст: лёгкое упоминание продукта в общих чертах (без временных меток и счётчиков)
- Ценность: одна конкретная выгода, которую можно получить за 10 минут
- Вопрос: один простой выбор (да/нет или A/B)
- Мягкое завершение: разрешение прекратить или перенаправить к нужному человеку
Держите язык простым. Чем больше деталей о точном поведении, тем выше риск реакции «откуда вы это знаете?».
Шаблоны для распространённых триггеров
Используйте их как отправную точку, а не копируйте слепо:
Subject: Quick help with {product} limits?
Hi {FirstName} -
Noticed your team may be getting close to the free tier limit in {product}. If it helps, I can share the 2-3 easiest ways teams avoid getting blocked (without committing to a plan).
Worth sending that over, or is someone else the right contact?
- {Name}
Subject: Adding teammates in {product}
Hi {FirstName} -
Saw you’ve started inviting teammates. When teams do that, the next question is usually “who owns setup and access?”
Do you handle this, or should I reach out to whoever runs the account?
- {Name}
Subject: About the {integration} setup
Hi {FirstName} -
Looks like you began connecting {integration} in {product}. If you want, I can send a short checklist that avoids the most common hiccups.
Do you want the checklist, or would a 10-minute call be easier?
- {Name}
Follow‑up‑ы должны быть реже и полезнее, чем в классическом холодном аутриче. Простая последовательность:
Touch 1: помощь, привязанная к сигналу. Touch 2 (через 2–3 дня): один совет или чек‑лист, один вопрос. Touch 3 (через 4–7 дней): «закрыть вопрос?» с вежливым выходом.
Доставляемость всё ещё важна, даже если письма «тёплые». Отправляйте с аутентифицированного домена (SPF/DKIM/DMARC), используйте прогретые ящики и держите объёмы стабильными. Если вы используете LeadTrain, настройка доменов и прогрева живёт в одном месте с последовательностями, что помогает не дать базовым вещам сбиться.
Реалистичный пример: команда на бесплатном тарифе близка к лимиту
Маленькое дизайн‑агентство регистрируется на бесплатном тарифе. На первой неделе один человек создаёт рабочее пространство. На второй неделе они приглашают трёх коллег и начинают ежедневно использовать основную функцию. Через несколько дней они достигают лимита (проектов, мест, интеграций или месячного использования). Работа блокируется, но они не попросили помощи.
Первый контакт обычно — тот, кто изначально создал рабочее пространство или админ по биллингу (если он есть). Такому человеку обычно менее странно получить сообщение от продукта. Если этот человек активен, но не принимает решения, следующим лучшим контактом часто будет тот, кто приглашает коллег — он выступает внутренним чемпионом.
В целом первое письмо должно содержать:
- Нейтральную причину обращения: возможная блокировка из‑за лимита при развёртывании
- Общее наблюдение: команды часто достигают лимитов сразу после добавления коллег
- Один полезный вариант: краткое руководство, быстрый звонок или рекомендация, чтобы избежать перебоев
- Чёткий выбор: продолжать на бесплатном тарифе с обходным решением или апгрейднуть при необходимости
Цель — быть полезным, когда появляется трение, а не перечислять всё, что вы знаете.
Возможные ответы и дальнейшие действия
Если они отвечают «Да, нас заблокировало», предложите два варианта времени для короткого созвона или задайте один вопрос для маршрутизации (срочно ли, размер команды). Если они не готовы апгрейдиться, пришлите краткое руководство по работе на бесплатном тарифе и запланируйте напоминание вернуть вопрос позже.
Если они перенаправляют к IT или procurement, уточните, кто принимает решение, и перешлите краткое резюме, адаптированное под эту персону. Если просят «перестать писать», подтвердите отписку и исключите их из дальнейшего аутрича.
Если ответ — это реальная проблема поддержки, переадресуйте её в Customer Success, а не пытайтесь продавать.
Распространённые ошибки, которые делают вас навязчивыми
Пользователи бесплатного тарифа уже имеют отношение к продукту, но не всегда к вашей команде. Самый быстрый путь показаться creepy — говорить так, будто вы отслеживаете каждый клик.
Часто вызывают реакцию «откуда вы это знаете?» следующие паттерны:
- Чрезмерная конкретика о поведении (точные кнопки, экраны или метки времени).
- Давление на встречу до ясной пользы.
- Добавление личных деталей, не связанных с использованием продукта (данные из профилей, хобби, история работы).
- Письмо с плохо настроенного домена, которое попадает в спам.
- Ошибочный выбор получателя, что создаёт внутреннее трение.
Безопаснее ссылаться на ситуацию в общих чертах. Вместо «Я видел, что вы создали 7 проектов вчера» скажите «Заметили, что ваша команда активизируется в рабочем пространстве. Хотите краткую заметку о том, как команды избегают достижения лимитов?»
Доставляемость тоже часть тона. Если письмо выглядит как спам, люди будут подозревать спамные намерения. Прогревайте ящики, аутентифицируйте домены и держите объёмы стабильными.
Быстрая проверка перед отправкой
Перед тем как писать пользователям бесплатного тарифа, проведите простую перепроверку. Цель — обратиться на основании реального события так, чтобы это выглядело нормально и полезно.
Пятиминутный чек‑лист перед отправкой
- Сигнал свежий и значимый. Если это случилось недели назад или это расплывчатая метрика вроде «вошёл один раз», пропустите.
- Вы можете объяснить письмо без «как мы это отследили». Если хочется ссылаться на метки времени или названия страниц — смягчите формулировку.
- Вы контактируете нужного человека для этого сигнала. Активный пользователь не всегда — покупатель. В сомнении напишите так, чтобы сообщение имело смысл, если читатель «лишь пользователь».
- Ваша просьба маленькая и понятная. Один вопрос, один простой вариант.
- Базовые настройки отправки в порядке. SPF/DKIM/DMARC, разумный дневной объём и обработка отписок.
Пример: если сигнал — «создано второе рабочее пространство», не пишите «Мы видели, что вы создали Рабочее пространство B в 15:12». Напишите тому, кто его создал: «Похоже, вы разделяете проекты по рабочим пространствам. Для чего это — права, отчёты или что‑то ещё?» Это показывает релевантность без раскрытия деталей отслеживания.
Если хотя бы одна проверка провалена — подождите. Лучшие письма возникают из чистых сигналов, разумного угадания персоны и невысокого давления.
Следующие шаги: запускайте регулярно без лишних инструментов
Начните с малого. Выберите один надёжный триггер и одну короткую последовательность, затем запускайте её каждую неделю. Последовательность важнее сложности, особенно когда сигналы меняются ежедневно.
Простая стартовая настройка:
- Один триггер (80% лимита, приглашены 2 коллеги или повторное использование ключевой функции)
- Одна гипотеза по персоне, привязанная к триггеру (админ, power user, владелец бюджета)
- Одна короткая последовательность (2–4 письма в течение 7–12 дней)
- Одная чёткая цель (забронировать звонок, разблокировать триал, добавить места)
Считайте каждый тип триггера мини‑экспериментом. Не смешивайте результаты. Триггер «приближение к лимиту» может давать больше встреч, а «приглашения коллег» — быстрее приводить к расширению.
Держите отчётность лёгкой, но конкретной: процент ответов и встреч по триггеру, расширение в течение 30 дней (если можно измерить) и отписки или жалобы как раннее предупреждение.
Решите на раннем этапе, что остаётся вручную. Автоматизируйте скучные части, а решения оставьте людям. Сбор списков, отправка последовательностей и сортировка ответов можно автоматизировать. Выбор правильных аккаунтов, оценка силы сигнала и личная первая строка для высокоценных аккаунтов часто остаются ручными.
Разрастание инструментов — где команды теряют импульс. Если домены, почтовые ящики, прогрев, последовательности и обработка ответов живут в разных сервисах, еженедельное выполнение превращается в рутину, а доставляемость страдает. Если нужно всё в одном месте, LeadTrain объединяет домены и почтовые ящики, автоматический прогрев, многоступенчатые последовательности и AI‑классификацию ответов, что помогает тратить меньше времени на сортировку реальных откликов и больше — на общение с нужными людьми.
Когда будете готовы масштабировать, добавляйте по одному триггеру и сохраняйте ту же структуру последовательности. Так вы будете учиться быстрее, а ваша рассылка останется последовательной и уважительной.
Часто задаваемые вопросы
How do I reference product usage in an email without sounding creepy?
Используйте сигнал для выбора времени и аудитории, но опишите его простыми, обобщёнными словами. Скажите, в какой ситуации может оказаться пользователь, и предложите небольшой следующий шаг, не указывая точные количества, метки времени или экраны.
What product signals are safe to mention to free tier users?
Хороший сигнал — то, что обычный пользователь мог бы ожидать, что вы заметите: запуск ключового рабочего процесса, приглашение коллег, подключение интеграции или приближение видимого лимита. Если сигнал явно указывает на то, что им может понадобиться помощь прямо сейчас, его обычно можно аккуратно упомянуть.
What should I never include in a PLG outbound email?
Не приводите покликное отслеживание, точные временные последовательности или то, что они вводили или загружали в продукт. Чувствительные или неожиданные данные оставляйте только для внутренней маршрутизации, а в письме фокусируйтесь на результатах и типичных сценариях.
Who should I email first when multiple people are active in the same account?
Начните с того, кто ближе всего к проблеме. Сигналы трения (ошибки, неудачная настройка, блокировка процесса) обычно адресуют тому, кто работает с продуктом напрямую (builder). Сигналы принятия (приглашения, несколько активных пользователей) чаще идут к чемпиону или администратору.
What if I’m not sure who the decision maker is?
Напишите так, чтобы сообщение оставалось уместным, если вы ошиблись. Задайте один вопрос для перенаправления, например: «Вы отвечаете за настройку или лучше обратиться к кому-то другому?» — и держите просьбу минимальной, чтобы не создавать внутреннего напряжения.
How quickly should I follow up on a product signal?
Свяжитесь, пока сигнал свеж: обычно тот же день или в течение 24–72 часов для высокоинтенционных сигналов. Если сигнал старше недели и нет очевидного «почему сейчас», лучше дождаться нового триггера или отправить более общий чек-ин.
How do I email someone who’s close to a free tier limit without it feeling like pressure?
Сначала предложите помощь, а не цену. По умолчанию предложите быстрый совет, чек-лист или короткий звонок, чтобы избежать блокировки работы, а затем дайте выбор: остаться на бесплатном тарифе с обходным решением или перейти на платный план при необходимости.
What’s a good follow-up cadence for PLG outbound?
Сохраняйте последующие сообщения короче и полезнее, чем в классическом холодном аутриче. Одно полезное сообщение, второе — с конкретным совѐтом, и финальное «закрыть вопрос?» обычно достаточно.
How should I handle opt-outs and “stop emailing me” replies?
Сделайте отказ простым и уважительным: «Ответьте «нет» и я больше не буду писать». Фактически исключите их из рассылок, чтобы сохранить доверие и избежать жалоб.
How do I protect deliverability when emailing free tier users?
Аутентифицируйте домен отправителя (SPF, DKIM и DMARC), используйте прогретые почтовые ящики и держите объёмы стабильными. Платформы вроде LeadTrain помогают держать домены, почтовые ящики, прогрев и последовательности в одном месте, чтобы настройки не сдвигались и ответы быстро сортировались.