Skip to main content
SaaS

Как правильно отправлять cold emails

О том как отправлять холодные письма, когда у вас SaaS стартап, выжимка из разных материалов на западе + взгляд глазами автора

Алмас

В целом ТК в этом видео на пальцах обьяснил:

Шаги следующие:

  1. Четко понять кого мы хотим найти, чтобы в холодную написать письмо
  2. Четко определиться с месседжем, позиционированием и ценностным предложением
  3. Персонализировать письмо, показав, что ты провел какой-то ресерч по компании и понимаешь человека, к которому обращаешься

Разберу со своей колокольни.

Step 1 – Target

Определим понятие Use Case = Persona + Context + Capability

Persona = конкретная роль или должность человека, чью проблему мы можем решить

Context = ситуация и проблематика, в которой находится Persona. На примере Calendly:

  • Менеджер по продаж хочет назначать созвоны с потенциальными клиентами, поэтому ему нужно решение, позволяющее назначать звонок по заранее настроенным тайм слотам в календаре
  • Менеджер в компании хочет назначать 1-1 звонок с коллегами в целом распределенной компании, где команда находится в разных таймзонах, поэтому ему нужно решение, позволяющее назначать звонок по заранее настроенным тайм слотам в календаре
  • Консультант хочет назначать часовой консалтинг-звонок с клиентом, поэтому ему нужно решение, позволяющее назначать звонок по заранее настроенным тайм слотам в календаре

Capability

💡
Вчитайтесь во фразу, которая обьединяет все Use Cases: "Позволяющее назначать звонок по заранее настроенным тайм слотам в календаре" - заметьте, данная функция идентична во всех трех Use Cases. Это и есть ключевое общее определение продукта ("Capability"), при этом контекст помогает доформировать ценностное предложение под конкретный типаж целевой аудитории.

Замечу, что это одновременно сложно и хорошо, когда внезапно в продукте, который ты создал возникают разные Use Cases. Хорошо для продаж и потенциала маркетинга. Дьявольская деталь заключается в том, чтобы вы аккуратно подходили к вопросу ответвления фичей для одной из ниш. Из моего опыта нужно максимально аккуратно подходить к вопросу о ветвлении фичей в продукте под один Use Case из множества. По умолчанию вообще лучше избегать, чтобы продукт гнул генеральную линию мысли и смог обслуживать без изменения все категории ЦА. под которые продукт подходит.