Benchmark Learnings: Emailing Technical Buyers

Уроки бенчмаркинга: письма техническим покупателям

Как писать холодные письма техническим покупателям (и что, по нашим бенчмарк-данным, вы делаете не так)

Из 231 818 холодных писем в нашем последнем Cold Email Benchmark Report engineering и product — два самых часто прорабатываемых технических отдела в B2B. Reply rate? 5,2%.

И это даже выше среднего. Технические покупатели отвечают чаще, чем HR, маркетинг, финансы или ops. Но есть нюанс.

Только 11% этих писем получили оценку A по Lavender. И когда продавцы пишут A-уровневые письма этой группе, reply rate поднимается лишь до 5,5% — рост 6%. Это, пожалуй, наименьший прирост качества среди всех групп отделов в датасете, но наши модели помогли enterprise-команде SDR, прорабатывающей CISO, увеличить общее число ответов в 10 раз. Так почему такое расхождение?

Вот почему это важно: для большинства отделов написание «лучшего» письма стабильно приносит больше ответов. У технических покупателей связь между качеством письма и reply rate слабее. Это намекает на то, что критерии «хорошего» холодного письма для маркетолога или HR-лидера плохо переносятся на то, как engineering- и product-лидеры оценивают ваше сообщение.

Так что же работает? И чем это отличается?

Возьмём реальные примеры, будто мы продавцы в Launch Darkly. Engineering использует его для безопасных деплоев и контроля инфраструктуры. Product — для контролируемых раскатов, экспериментов и отгрузки фич конкретным сегментам. У обеих команд есть реальные, но разные причины интересоваться.

Технические покупатели не игнорируют ваше письмо. Они игнорируют вашу достоверность.

Главный паттерн в данных таков: engineering- и product-покупатели отвечают людям, которые явно понимают технический мир, в котором те работают. Не тем, кто позаимствовал технический язык у своего маркетингового отдела. А тем, кто понимает реальные workflow, компромиссы и ограничения настолько хорошо, что может объяснить это даже нетехническим людям. С инженерами нужно уметь спускаться в детали. Но есть важный нюанс. Технический жаргон отталкивает инженеров. Лучше работает разговор о конкретном use case или workflow на языке, который ощущается аутентичным. Если вы не можете объяснить это ясно, они решат, что вы недостаточно понимаете технические тонкости, чтобы тратить на вас время.

Product-покупатели — другие, но похожие. Они не хотят, чтобы вы слишком рано уходили в технические детали. Они хотят, чтобы вы говорили о более широких roadmap-инициативах и продуктовых приоритетах до любых конкретных технических деталей. Технической глубиной нужно заслужить право, а не начинать с неё.

Вот сводка того, что по данным работает, а что нет:

Что работает для engineering: Персонализированная релевантность, привязанная к запросам, событиям или контексту. Техническая конкретика с реальными use case. Чёткие CTA с понятным следующим шагом. Краткость и сигналы доверия.

Что работает для product: Контекст, привязанный к продуктовым приоритетам и темам roadmap. Один сфокусированный value prop. Конкретные примеры и доказательства. Низкозатратные CTA для проверки интереса.

Что не работает ни для кого: Общие шаблоны. Слишком длинные письма с избытком жаргона. Слабые CTA («learn more»). Широкие продуктовые заявления без контекста. Чрезмерно sales-овый тон.

Общая нить: аутентичность. Это покупатели, которые зарабатывают на жизнь созданием вещей. Они уважают людей, которые понимают, что они строят и почему это сложно. Они не уважают тех, кто копирует баззворды с сайта.

Но то, как вы демонстрируете это понимание, меняется в зависимости от seniority. У CTO и security engineer — совсем разные фильтры. Разложим по полочкам.

Продажи техническим руководителям (CTO, VP of Engineering, VP of Product, CISO)

Должности, на которые вы целитесь: CTO, VP of Engineering, VP of Product, VP of Infrastructure, VP of Security, Head of Engineering, Head of Product, Head of Platform, CISO

Что говорят данные о руководителях: C-Suite-покупатели отвечают на 4,8%, VP — 3,4%, Head — 4,4%. У Head прирост на A-письмах составляет 42% — самый высокий среди executive-уровня. Вероятно, это потому что Head'ы чаще работают в небольших организациях или занимают более «исполнительские» позиции внутри крупных. Они реже думают «может, делегировать это…»

Что это значит конкретно для технических руководителей: Технические руководители фильтруют всё через две линзы: снижает ли это риск и помогает ли ship быстрее? Выручка для них важна, но для engineering обычно подаётся как стоимость нерешённой проблемы: downtime, утечки, замедление скорости. Это не прямая игра на выручку. Для product это тоже про решение проблем и упущенные возможности от непопадания в продуктовые milestones. Это разблокирует выручку, но опосредованно.

Тон должен быть прямым и достоверным. Не тёплым, как с HR. Не неформальным, как с маркетингом. Технические руководители хотят чувствовать, что говорят с тем, кто понимает ограничения engineering-организации, а не с тем, кто читает sales-плейбук и пытается фамильярничать.

Повторим важный нюанс: product-руководители и engineering-руководители думают по-разному. VP of Engineering заботится об инфраструктуре, надёжности и security posture. VP of Product — о приоритетах roadmap и о том, как решение вписывается в продуктовую стратегию. Корректируйте подход соответственно.

Что делать

Начинайте с технического наблюдения уровня компании — миграция, архитектурное решение, сдвиг в security posture, запуск продукта. Связывайте это с риском или вызовом для скорости разработки, актуальным на их стадии. Доказательства держите конкретными и техническими (время деплоя, метрики покрытия, снижение числа инцидентов). Формулируйте CTA как совместный шаг. Дайте им возможность делегировать нужному техническому лиду.

Что НЕ делать

Не начинайте с продуктовых фич. Не используйте баззворды, которые не можете подкрепить. Не пишите более 100 слов. Не используйте хайповый язык вроде «world-class», «cutting-edge» и «next-generation». Это мгновенные «убийцы доверия» для этой аудитории. И не делайте несколько запросов сразу. Глубокое техническое погружение оставьте для уровня пониже.

Пример: вы AE в LaunchDarkly, пишете VP of Engineering

Вы заметили, что их компания недавно выкатила крупное обновление продукта, и в их engineering-блоге упомянут переход на еженедельные релизные циклы.

James, прочитал пост о переходе на еженедельные релизы. Большой сдвиг. Полагаю, команда оборачивает каждый релиз в feature flags? Понимаю, что у вас может быть in-house решение. Но это много нового кода. Это могла бы быть возможность сократить нагрузку на поддержку, если бы каждый релиз оборачивался автоматически. Если этим занимается DevOps, рад законнектиться с ними напрямую.

Почему это работает:

Опенер: Ссылка на конкретный пост в engineering-блоге (не на вакансию или пост в LinkedIn) сразу сигнализирует о технической достоверности. Это технический сдвиг в workflow.

Проблема: Безопасный ship и управление откатами — очевидная проблема, не нужно говорить им то, что они и так знают. Мы устанавливаем доверие, предполагая, что они уже используют feature flags. Вместо этого мы переформулируем проблему как поддержание feature-обёрток на всём новом коде.

Решение: Быстро предлагаем альтернативу, чтобы они двигались быстрее и безопаснее.

CTA: Два пути — вовлекаться напрямую или делегировать. Упоминание DevOps показывает, что вы понимаете, как устроены engineering-организации.

Стиль: 64 слова. Прямо. Без хайпа. Сокращение «w/» и неформальные обороты не дают письму звучать корпоративно.

Продажи техническим директорам и senior-лидерам

Должности, на которые вы целитесь: Director of Engineering, Director of Product, Director of Security, Director of Infrastructure, Director of Platform, Senior Engineering Manager, Senior Product Manager, Director of DevOps, Director of Cloud Engineering

Что говорят данные об этом уровне: Директора отвечают на 3,4% в целом. Senior-уровневые покупатели подскакивают до 8,4% на A-письмах — самый большой абсолютный прирост во всём датасете по seniority.

Эта группа недополучает качественный outbound. Это ваш шанс.

Что это значит конкретно для технических директоров: Директора владеют конкретными техническими доменами. Director of Infrastructure заботится об uptime и масштабировании. Director of Security — об обнаружении угроз и compliance. Director of Product — о roadmap для своей продуктовой области. Широкие питчи промахиваются совсем, потому что не привязаны к тому, чем этот человек реально владеет.

Данные говорят прямо: эта группа отвечает на ясную релевантность функциональным приоритетам и конкретным use case. Общие шаблоны и sales-овый язык — главные «убийцы». Для engineering-директоров отдельно: техническая конкретика в паре с реальными use case — вот что работает. Для product-директоров — контекст, привязанный к темам roadmap, с одним сфокусированным value prop.

Что делать

Конкретизируйте домен, которым они владеют. Привязывайте наблюдение к чему-то видимому — архитектурному паттерну, недавнему инциденту, релизу продукта, требованию compliance. Связывайте это с вызовом, специфичным для их функции. Доказательства — один релевантный пример с конкретными результатами. CTA формулируйте как возможность сравнить подходы, а не что-то купить.

Что НЕ делать

Не питчите широко. Не используйте несколько value prop сразу. Не пишите длинные вступления. Не используйте жаргон, который не можете подкрепить. Директора это быстро поймают. И не используйте sales-овую рамку. «I'd love to show you a demo» воспринимается этой группой очень иначе, чем «want to see how other companies have set it up».

Пример: вы SDR в LaunchDarkly, пишете Director of Product

Вы заметили, что их компания недавно запустила freemium-уровень рядом с существующим enterprise-продуктом. Это видно по обновлению страницы pricing и нескольким твитам маркетинговой команды.

Priya, с новым freemium-уровнем, полагаю, команда ожидает много новых продуктовых данных. Как команда сейчас устроена для деплоя экспериментов? Думаю, это повлияет на множество будущих roadmap-решений, которые могут затронуть и enterprise-предложения. Было бы полезно перенести эти эксперименты в product, а не в dev? Atlassian смогли запустить в 25 раз больше экспериментов благодаря нашей feature toggle-системе. Не страшно, если ваша команда чувствует, что у вас всё под контролем. Просто подумал, что момент удачный.

Почему это работает:

Опенер: Запуск freemium — видимое, верифицируемое продуктовое решение с downstream-эффектами на данные, к которым у них будет доступ. Подача как «проблема контроля» делает их героями следующего удачного релиза.

Проблема: Скорость экспериментов даёт product возможность принимать лучшие решения. Если они не могут это контролировать, они не могут это решить.

Решение / CTA: Сначала подано как вопрос («как вы деплоите эксперименты?»), который открывает диалог. Затем проблема углубляется вопросом о ценности альтернативы. Затем подкрепляется релевантным proof point.

Достоверность: Инженеры не очень любят name drop… а product — любит. Кейс упомянут намеренно. Инженеры лучше отреагировали бы на более ясное понимание того, как это вписывается в workflow.

Продажи техническим менеджерам

Должности, на которые вы целитесь: Engineering Manager, Product Manager, Security Manager, DevOps Manager, IT Manager, Infrastructure Manager, Cloud Operations Manager, Application Security Manager

Что говорят данные о менеджерах: Менеджеры отвечают на 4,3% в целом, а A-письма поднимают это до 6,3% — прирост 49%. Почти вдвое больше ответов только за счёт того, что письмо написано лучше.

Что это значит конкретно для технических менеджеров: Технические менеджеры балансируют между исполнением и планированием. Engineering manager управляет спринтами, распределяет ресурсы и держит свою команду разблокированной. Product manager определяет требования, приоритизирует backlog и принимает компромиссные решения. Обоим важна практическая полезность — как это вписывается в работу, которую мы уже делаем?

Данные по этому уровню показывают напряжение. Для product manager в частности слишком ранние технические детали убивают вовлечённость. Они хотят, чтобы вы говорили о приоритетах и результатах до того, как уйти в «как». Engineering manager более восприимчивы к технической конкретике, но всё равно хотят, чтобы она была привязана к узнаваемому workflow.

Тон должен балансировать между профессиональным и прямым. Помните, что первое впечатление от письма в 8 раз чаще формируется на мобильном устройстве — поэтому структура важна. Короткие абзацы. Легко сканировать. Одна идея на блок.

Что делать

Сфокусируйтесь на конкретном workflow или техническом вызове, которым они управляют прямо сейчас. Покажите, что понимаете компромиссы, с которыми они сталкиваются (скорость vs. безопасность, покрытие vs. сложность, фичи vs. инфраструктура). Будьте прямы в том, что вы решаете и как. CTA держите конкретным — привязанным к проблеме, которую вы можете решить, с чётким следующим шагом.

Что НЕ делать

Не говорите о трансформации уровня всей компании. Не перегружайте несколькими value prop. Не пишите простыни текста. Для product manager: не начинайте с технических спецификаций. Для engineering manager: не используйте жаргон, который не сможете объяснить, если спросят. И не используйте размытые CTA — «thoughts?» — это не следующий шаг.

Пример: вы SDR в LaunchDarkly, пишете DevOps Manager

Возьмём тот же пример с freemium, но применим его к engineering на более низком уровне.

Chris, как команда сейчас управляет раскатами на новый freemium-уровень против enterprise? Enterprise захочет стабильности. Freemium требует быстрых итераций. Если бы можно было быстро помечать фичи для этих уровней — стало бы проще? Devs обычно говорят нам, что у них есть внутренние тулы для этого. Но инструмент вроде LaunchDarkly мог бы перевести это на автопилот, выступая обёрткой для каждого релиза.

Почему это работает:

Опенер: Открытие вопросом о наблюдаемой реальности ломает типичный паттерн, когда наблюдение просто констатируют.

Проблема: Вызов — сохранить enterprise-клиентов довольными. Это значит, что давление «ship быстрее» не должно им навредить.

Решение: Прямо о том, что делает LaunchDarkly, с технической конкретикой. Но обрамлено допущением, что у них, скорее всего, есть собственные внутренние инструменты для этого.

CTA: Просто спрашивает, могло бы решение быть полезным.

Форматирование: Короткие абзацы, легко сканировать на мобильном. Прогрессия наблюдение → проблема → запрос → решение чистая и быстрая. (67 слов)

Продажи индивидуальным контрибьюторам (инженеры, аналитики, специалисты по безопасности)

Должности, на которые вы целитесь: Software Engineer, Security Engineer, DevOps Engineer, SRE, Cloud Engineer, Product Analyst, Security Analyst, IT Specialist, Infrastructure Engineer, Application Security Engineer

Что говорят данные об IC: Индивидуальные контрибьюторы отвечают на 5,3% — выше, чем директора, VP и менеджеры. A-уровневые письма поднимают это до 8,0% — прирост 49%. ICs — одна из самых отзывчивых групп в датасете.

Что это значит конкретно для технических IC: ICs волнуют тулы, которые делают их работу лучше. Точка. Не org-стратегия, не приоритеты руководства — а та штука, с которой они каждый день работают руками. Если они управляют облачной инфраструктурой, говорите об облачной инфраструктуре. Если они запускают security-сканы, говорите про сканирование безопасности.

Тон должен быть самым неформальным и прямым во всей seniority-лестнице. Краткость, ясность и релевантность — вот что приносит ответы. Sales-овые тона и расплывчатое позиционирование — вот что их убивает.

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

Что делать

Будьте кратки. Очень кратки. Сошлитесь на что-то конкретное из их технического окружения или workflow. Задайте вопрос о том, как они сегодня с чем-то справляются. Не питчите — исследуйте. Пусть подпись в письме и их любопытство сделают продажу за вас.

Что НЕ делать

Не говорите о ROI или бизнес-результатах (IC не так мыслят). Не пишите длинные письма. Не используйте маркетинговый язык. И не будьте sales-овыми, они не могут покупать. У технических IC нет времени с этим разбираться, и они удалят ваше письмо на середине предложения, если оно читается как pitch.

Вы SDR в LaunchDarkly, пишете Senior Software Engineer

Вы заметили, что они недавно смерджили PR на GitHub с самописной реализацией feature toggle.

Sam, видел PR с настройкой feature toggle. Похоже, вы пилите это in-house. Вы оборачиваете в флаги все релизы или только рискованные? Любопытно, как вы справляетесь с чисткой stale-флагов. Спрашиваю, потому что обычно именно там самописные решения начинают болеть на масштабе.

Почему это работает:

Длина: 47 слов. Прямо, технично и один-в-один.

Персонализация: Ссылка на конкретный GitHub PR — пожалуй, максимум персонализации, который можно сделать для инженера. Это сигнал: я реально смотрел вашу работу, а не LinkedIn.

Тон: «Curious», «asking bc» — неформально, на уровне peer-to-peer. Никакого корпоративного языка. Никакого pitch. Сокращение «bc» делает письмо похожим на сообщение в Slack.

CTA: Два искренних технических вопроса («все релизы или только рискованные?» и «как вы справляетесь с чисткой stale-флагов?»), которые приглашают к разговору между практиками. Это говорит «я знаю, что вы не держатель бюджета», но без снисхождения. Проблема (боль самописных решений на масштабе) и решение (LaunchDarkly) подразумеваются — и будут подкреплены подписью в письме.

Сквозная мысль

Технические покупатели — самая сложная группа для написания холодных писем, не потому что они не отвечают, а потому что стандартный плейбук «хорошего письма» работает с ними иначе.

Для большинства отделов написание отполированного, хорошо структурированного письма стабильно приносит больше ответов. Для engineering и product аутентичность важнее полированности. Если ваше письмо звучит так, будто его написал человек, реально понимающий работу, вам ответят. Если оно звучит так, будто его написал человек, который погуглил пару ключевых слов, — не ответят, как бы хорошо оно ни было оформлено.

Но то, что меняется по мере подъёма по seniority-лестнице, — это масштаб технического контекста, который вы приносите.

Для CTO или VP это про технический сдвиг уровня компании — миграция, вызов масштабирования, изменение security posture.

Для директора это про конкретный технический домен, которым он владеет, — его инфраструктура, его продуктовая область, его архитектура безопасности.

Для менеджера это про компромиссы в workflow, которые он каждую неделю прокручивает.

Для IC это про инструмент, репозиторий, конфиг, на который он сегодня смотрит.

Тон остаётся прямым на всех уровнях. Но глубина и конкретика меняются. И доказательства должны быть техническими, а не просто впечатляющими — известные клиенты значат меньше, чем релевантные архитектуры, конкретные метрики и доказательства того, что вы понимаете ограничения, в которых они работают.

89% писем, попадающих в engineering- и product-инбоксы, не получают оценку A. Но для этой группы получить A — это не про шлифовку текста. Это про то, чтобы доказать, что вам место в разговоре.

Вот так вы зарабатываете ответ от того, кто строит вещи на жизнь.

Если хотите увидеть полные бенчмарк-данные по всем отделам, уровням seniority и индустриям, Cold Email Benchmark Report уже доступен.

А если хотите писать такие письма — с реал-тайм коучингом, адаптированным под вашего покупателя — посмотрите, что Lavender может сделать для вас.

Об авторе