Benchmark Learnings: Emailing Operations

Выводы из бенчмарка: письма в отдел операций

Как писать холодные письма руководителям операций (и что говорят 231 818+ писем о ваших ошибках)

Из 231 818 холодных писем в нашем последнем Cold Email Benchmark Report операции — один из самых важных отделов, в которые пишут продавцы. И один из наименее благодарных. Показатель ответов? 3,4%.

‍

Это ставит операции почти в самый низ среди отделов. И тому есть причина: ops-руководители — самые занятые люди в любой компании. Они управляют процессами, которые поддерживают движение всего остального. Поэтому, если ваше письмо не связано с процессом, который они и сами считают сломанным, это просто шум.

‍

Но вот что показывают данные: лишь 13,1% писем в адрес операций получили оценку A от Lavender. Это значит, что примерно 7 из 8 писем в почтовых ящиках ops содержат явные, устранимые проблемы, исправление которых повысило бы показатель ответов.

‍

Когда продавцы пишут операциям письма уровня A, показатель ответов поднимается до 5,4%. Прирост в 58%. Это один из крупнейших приростов за счёт качества среди всех отделов. Ops-руководители действительно отвечают на холодные письма. Им просто нужно быстро понять очень конкретную причину, по которой стоит ответить.

‍

Так что же действительно работает? И почему большинство писем в ops уходят впустую?

‍

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

Операции не игнорируют ваше письмо. Они игнорируют расплывчатые сценарии.

Главная закономерность в данных такова: ops-покупатели откликаются на письма, которые называют конкретный процесс. Не категорию. Не «вызов в рабочих процессах». А процесс. То самое, на что они тратят время.

«Вы всё ещё управляете документами вручную?» — это реальный вопрос, заданный ops-руководителю, из нашего набора данных. Он не сработал. Он слишком общий. Какими документами? Для кого? В каком рабочем процессе? Ops-руководитель читает это и думает: этот человек не знает, чем я занимаюсь.

Вот тут и вступает в дело персонализация (настоящая, релевантная персонализация)!

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

Это персонализация не в личном смысле. Это персонализация в смысле 1:1 — «я понимаю вашу работу исходя из вашего конкретного бэкграунда и ситуации».

Вот краткая выжимка из того, что по данным работает и не работает при письмах операциям:‍

Что работает: Подача через эффективность с конкретными рабочими процессами. Короткие, прямые письма с понятными результатами. Сигналы доверия работают. Прямой CTA с понятным следующим шагом.‍

Что не работает: Абстрактная стратегия без привязки к процессам. Плотные абзацы. Несколько ценностных предложений сразу. Чрезмерно продажный тон. Презумптивные формулировки о проблемах, которых у них может и не быть.

Последний пункт специфичен именно для ops и заслуживает внимания. Данные пометили письма, которые открываются с допущений вроде «Большинство IT-команд вашего размера работают на пределе» или «Управление непредсказуемым потоком посетителей в лобби, вероятно, становится растущим операционным вызовом». Ops-руководители читают это и думают: вы гадаете. И они правы.

Решение: спрашивайте, а не предполагайте. Превратите свою гипотезу в вопрос. Это то же самое наблюдение, но оно приглашает к разговору, а не навязывает проблему.

Но что вы говорите и как это подаёте, меняется в зависимости от уровня должности. COO и координатор процессов думают об операциях с очень разной высоты. Так что давайте разложим по полочкам.

Продажи руководителям операций (COO, VP of Ops, Head of Operations)

Должности, на которые вы нацеливаетесь: COO, VP of Operations, VP of Business Operations, VP of Revenue Operations, Head of Operations, Head of Business Ops, VP of Customer Operations‍

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

Что это означает конкретно для ops-руководителей: Руководители операций мыслят системами. Их задача — следить, чтобы организация масштабировалась, не ломаясь. Каждое письмо проходит через фильтр: помогает ли это нам делать больше, не наращивая численность пропорционально? Снижает ли это операционный риск быстрого роста?

Тон должен быть прямым и эффективным. Ops-руководители уважают краткость, потому что сами её практикуют. Не тратьте время на установление контакта перед сутью. Начинайте с сути.

Что делать

Начните с наблюдения на уровне компании, привязанного к сигналу масштабирования: рост численности, новые продукты, новые офисы, новые сегменты клиентов. Свяжите это с операционным узким местом, которое всплывает на этом этапе. Подкрепите конкретным результатом из релевантной компании. Сформулируйте CTA как совместный. Дайте им путь делегировать тому, кто ближе к конкретному процессу.

Чего не делать

Не начинайте с функций продукта. Не используйте абстрактный стратегический язык («оптимизируйте свою операционную эффективность»). Не делайте несколько запросов сразу. Не пишите больше 100 слов. И не предполагайте, что знаете их проблемы. Спрашивайте. Ops-руководители видели слишком много продавцов, которые гадали неверно. Детали уровня процесса приберегите для более низких уровней должности.

Пример: вы — AE в Scribe, пишете VP of Operations

Вы заметили, что их компания утроила продуктовый каталог за прошлый год и нанимает customer success менеджеров в нескольких часовых поясах.

Dana, каталог продуктов вырос в 3 раза за год, и при этом вы онбордите CS-специалистов в разных часовых поясах. Любопытно, держит ли ops всё это под контролем. Наш продукт автоматически генерирует документацию процессов по мере работы команды. Никому не нужно останавливаться и что-то писать. Одна ops-команда сократила время на документирование с 2 недель до 2 часов. Думаете, это могло бы помочь новым сотрудникам (и нынешним CS-специалистам) держать всё в порядке? P.S. Если кто-то в вашей команде ближе к процессам онбординга, с радостью свяжусь с ним напрямую.

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

Начало: Два проверяемых сигнала (рост продуктового каталога + найм в нескольких часовых поясах), объединённые в единый операционный вывод, поданный без допущений. Фразой «любопытно, держит ли ops под контролем» письмо пытается проверить, есть ли у них KPI, по которому их оценивают. Это попадает в нужную высоту для VP.

Проблема: Проблема очевидна из первого абзаца, и углубление в очевидные вещи не поможет с персоной, которая не любит сообщения в духе «ops-руководители вроде вас». Вместо этого боль ещё раз акцентируется в CTA.

Решение: Два предложения. Что делает Scribe и почему это важно. Никакого списка функций. Доказательство конкретно (2 недели → 2 часа) и напрямую привязано к описанному узкому месту в документировании.

CTA: Два пути. Подключиться напрямую, если релевантно, или делегировать. «Кто-то в вашей команде, кто ближе к процессам онбординга» показывает, что вы понимаете: VP сам документацию не пишет.

Тон: 86 слов. Прямо. Неформальные обороты вроде ops, под контролем, держать в порядке и скобки придают разговорность. Сообщение не презумптивно, оно скорее говорит: если это в фокусе — мы можем помочь, но дайте знать, если я не прав.

Продажи директорам и старшим руководителям операций

Должности, на которые вы нацеливаетесь: Director of Operations, Director of Business Operations, Director of Revenue Operations, Director of Customer Operations, Senior Operations Manager, Director of Process Improvement‍

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

Эта группа недообслужена хорошими холодными письмами. В этом ваша возможность.‍

Что это означает конкретно для ops-директоров: Директора в операциях владеют конкретными операционными доменами: онбординг клиентов, внутренние процессы, инфраструктура rev ops, кросс-функциональные рабочие процессы. Они не определяют стратегию компании. Они следят, чтобы машина работала. Широкие питчи об «операционной трансформации» не ложатся ни на что, за что они отвечают.

Что работает: назовите конкретный процессный домен, которым они владеют. Покажите, что понимаете, где он трещит. Данные говорят об этом ясно: эта группа откликается на релевантность функциональным приоритетам и конкретные сценарии. Шаблонные письма и продажный язык — вот что убивает вовлечённость.

Что делать

Будьте конкретны относительно операционного домена, которым они владеют. Если вы пишете Director of Customer Operations — говорите о процессах онбординга и передачи дел. Если это Director of Rev Ops — говорите о чистоте данных или стандартизации процессов в команде GTM. Привяжите своё наблюдение к видимому сигналу. Ограничьтесь одним релевантным доказательством. Сформулируйте CTA вокруг сравнения подходов.

Чего не делать

Не питчите широко. Не используйте несколько ценностных предложений в одном письме. Не пишите длинных вступлений. И не будьте презумптивны относительно их проблем. Данные особо отметили это как паттерн провала для ops. «Управление непредсказуемым потоком посетителей в лобби, вероятно, растущий вызов» не работает. «Как вы справляетесь с X по мере масштабирования?» — работает.

Пример: вы — SDR в Scribe, пишете Director of Customer Operations

Вы заметили, что их компания недавно запустила self-serve уровень продукта наряду с существующим enterprise-предложением и нанимает специалистов по внедрению.

Marcus, self-serve + enterprise на одном продукте — это два очень разных сценария онбординга. Представляю, что по мере того как команда видит затыки у self-serve, вы адаптируете enterprise-документацию под этих self-serve пользователей. Если бы вы могли авто-генерировать эти документы прямо по ходу работы команды (вместо того чтобы выкраивать время на их написание) — помогло бы это? P.S. Помогли одной команде собрать документацию для нового продукта вдвое быстрее. Дайте знать, стоит ли показать, как они это сделали.

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

Начало: Называя оба уровня продукта и подавая это как операционный вызов (два сценария онбординга), вы показываете, что понимаете сложность.

Проблема: Явная проблема подразумевается через чёткое видение их ситуации: «по мере того как команда видит затыки у self-serve, вы адаптируете enterprise-документацию под этих self-serve пользователей». Эта фраза показывает, что их время уходит на перестройку документации процессов по мере возникновения проблем.

Решение: Подано как вопрос («помогло бы это?»), что позволяет им самим себя квалифицировать. Контраст в скобках (авто-генерация против выкраивания времени) обозначает ценность без вываливания функций.

Доверие: Вплетённое в P.S., оно показывает ценность быстрого использования решения. Не всякая клиентская история ложится 1:1 на ситуацию получателя. Но из неё легко извлечь, что документирование новых продуктов вдвое быстрее может быть напрямую применимо к их ситуации.

Продажи менеджерам операций

Должности, на которые вы нацеливаетесь: Operations Manager, Process Manager, Business Operations Manager, Customer Operations Manager, Implementation Manager, Enablement Manager, Onboarding Manager‍

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

Что это означает конкретно для ops-менеджеров: Менеджеры операций — это слой исполнения. Именно они строят SOP, проводят сессии онбординга, управляют инструментами и чинят сломанные передачи дел. Их волнует практическая польза: облегчает ли это процесс, который я запускаю каждую неделю?

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

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

Что делать

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

Чего не делать

Не говорите о стратегии компании. Не используйте несколько ценностных предложений. Не пишите стены текста. И не используйте продажный язык или расплывчатые CTA. «Что думаете?» с ops-менеджерами не работает. Они хотят точно знать, что именно вы предлагаете и что именно они получат, согласившись.

Пример: вы — SDR в Scribe, пишете HR Operations Manager

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

Jamie, в одном из ваших отзывов на Glassdoor указывают на культуру «выплывай или тони». Понимаю, что источник может быть предвзятым. Но документирование процессов могло бы стать простым способом смягчить это, если этот отзыв действительно сигнал о проблемах с текучкой. Мы можем автоматически фиксировать работу людей в Slack, почте, инструментах и т. д. Превращать это в плейбуки. Помогать новичкам быстро освоиться. Хотите посмотреть, как мы помогли одному стартапу навести порядок в документации в течение месяца после онбординга?

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

Начало: Отзывы на Glassdoor — щекотливый сигнал. Они указывают на реальную проблему, но, отмечая, что источник может быть предвзятым, и используя формулировки вроде «если этот отзыв действительно», вы показываете, что не тычете пальцем.

Решение: Конкретно описывает, откуда продукт может автоматически вытягивать информацию для решения задачи документирования. Это конкретно, так что они видят, где именно могут это применить к командам.

Доверие: Упоминание других стартапов с той же проблемой говорит «вы не одни». Но также говорит: мы уже делали это раньше.

CTA: Предложение посмотреть, как это делает другая компания, гораздо тактичнее, чем предложение демо или расплывчатый вопрос, полезно ли это.

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

Продажи рядовым сотрудникам (IC) в операциях

Должности, на которые вы нацеливаетесь: Operations Coordinator, Operations Analyst, Process Coordinator, Implementation Specialist, Onboarding Specialist, Operations Associate, Business Analyst, Revenue Operations Analyst‍

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

Что это означает конкретно для ops-IC: Ops-IC — это люди, которые делают работу. Именно они запускают процессы, строят документацию (когда есть время), обучают новичков и отвечают на вопросы «а где документ по этому?». Их волнует одно: сделать повторяющуюся часть их работы менее повторяющейся.

Тон должен быть самым неформальным на всей лестнице должностей. Прямо, дружелюбно, коротко. Никакого жаргона про улучшение процессов. Никакого «операционного совершенства». Просто: вот кое-что, что может сэкономить вам время.

Важная оговорка: у ops-IC редко есть полномочия на покупку. Но именно они часто выносят рекомендации по инструментам своему менеджеру. Ваша цель — начать разговор, а не закрыть сделку.

Что делать

Делайте коротко. Правда коротко. Назовите конкретную задачу, на которую они, вероятно, тратят время. Подайте выгоду как сэкономленное на этой задаче время. Держите CTA нацеленным на знакомство.

Чего не делать

Не говорите о ROI или организационных результатах. Не пишите длинных писем. Не используйте формальный язык. И не питчите. Ops-IC скорее всего ответят, если письмо ощущается как полезный совет от коллеги, а не как продажная цепочка.

Пример: вы — SDR в Scribe, пишете Revenue Ops Specialist

Вы заметили, что их компания недавно запустила новую продуктовую интеграцию и онбордит к ней партнёров.

Taylor, ты отвечаешь за создание новой партнёрской документации для запуска интеграции? Спрашиваю, потому что они зададут вопросы, которых твоя команда ещё не получала. Пока вы разбираетесь с подключением этих ребят, мы можем авто-документировать (подтягивая из Slack, почты, инструментов и т. д.), чтобы быстрее зафиксировать правильный процесс.

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

Длина: 47 слов. Неформально и прямо.

Персонализация: Привязана к конкретной, видимой инициативе (новая интеграция + онбординг партнёров) и связана с вероятной задачей IC (создание документации).

Тон: «ты отвечаешь?» — неформальный способ спросить об их текущем процессе. «Спрашиваю, потому что» сохраняет разговорность.

Решение: Напрямую привязано к конкретной работе, которую нужно сделать, так что они видят, как именно это может им помочь.

CTA: Вы можете подумать, что его нет. Или что CTA — это квалифицирующий вопрос, отвечают ли они за это. На самом деле CTA подразумевается. Этот нюанс делает сообщение похожим не на формальное продажное письмо, а на сообщение от друга. Если работа релевантна, понятно, что они ответят. Это также готовит почву для того, чтобы вы продолжили и задали более конкретные вопросы, привязанные к тому, что вы неверно угадали в их работе, — чтобы вы могли переписать сообщение и затронуть другие способы, которыми этот новый процесс может создавать для человека новые проблемы в его роли.

Сквозная линия

Операции — это отдел, который работает на процессах. Они откликаются на письма, которые называют конкретный из них.

Закономерность в данных ясна: абстрактный стратегический язык без привязки к процессам не работает. «Оптимизируйте свои операции» не значит ничего. «Авто-генерируйте документы онбординга, которые у вашей команды нет времени писать» значит всё.

Но что меняется по лестнице должностей — это масштаб процесса, на который вы ссылаетесь.

Для COO это узкое место масштабирования на уровне компании. Система, которая вот-вот сломается.

Для директора это конкретный операционный домен, которым он владеет. Онбординг клиентов. Внутренний enablement. Инфраструктура rev ops.

Для менеджера это процесс, который он запускает каждую неделю, и место, где возникает трение.

Для IC это задача, которую он делает вручную и которую можно автоматизировать.

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

86,9% писем, попадающих в почтовые ящики операций, не получают оценку A. Но прирост в 58% на письмах A говорит вам, что возможность реальна. Назовите процесс. Покажите, что он сломан. Докажите, что можете его починить.

Вот так вы заслуживаете ответ от того, кто поддерживает работу машины.‍

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

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

‍

Об авторе