Вопросы на собеседовании: BDR / SDR

Стратегия должна объяснять, откуда придёт pipeline, почему этим аккаунтам важен наш продукт и от какой работы мы откажемся.

• Я определяю ICP, приоритетные сегменты, триггеры покупки и бизнес-проблему каждой персоны.
• Я перевожу план по выручке в число принятых opportunities, охват аккаунтов и реалистичную ёмкость BDR-команды.
• Я задаю роль каждого канала и критерии остановки, чтобы слабый motion не жил только потому, что команда занята.

Я выбираю motion по экономике сделки и реальному процессу покупки, а не по любимому каналу команды.

• Enterprise-аккаунты с высоким ACV оправдывают исследование, multi-threading и тесную работу BDR с AE на небольшом списке.
• Транзакционному сегменту нужны широкий охват, больше автоматизации и короткий путь от ответа до квалификации.
• Сначала я тестирую один узкий сегмент и сравниваю принятый pipeline на час работы, а уже потом масштабирую людей или инструменты.

ICP должен совместно управляться sales, marketing, RevOps и данными о клиентах, но у решения должен быть один ответственный.

• Я использую данные closed-won, closed-lost, удержания и длины цикла, чтобы отличать привлекательные логотипы от клиентов, которых мы умеем выиграть и сохранить.
• Предложение об изменении описывает сегмент, доказательства, влияние на routing и работу, которую придётся отложить.
• Модель пересматривается регулярно, но срочное изменение допустимо, если продуктовые или регуляторные условия сломали исходное предположение.

Я обновляю ICP, когда меняется качество дальше по воронке, а не только когда падают ответы.

• Снижение sales-accepted rate, удлинение цикла или слабое удержание в когорте показывают, что гипотеза о fit могла быть неверной.
• Повторяющиеся возражения могут выявить отсутствующий триггер или персону, которая чувствует боль, но не управляет бюджетом.
• До изменения scoring и списков я сверяю эти сигналы с изменениями продукта и рынка.

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

• Fit включает устойчивые признаки: индустрию, размер компании, географию и техническую среду.
• Timing включает сигналы изменений: найм, инвестиции, смену руководства или релевантный compliance-дедлайн.
• Tier one получает ручное исследование и multi-threading, а нижние уровни работают с более лёгкой персонализацией и широким охватом.
• Я проверяю конверсию по уровням, чтобы модель оценивалась по принятому pipeline, а не по внешней сложности.

Я меняю стоимость работы с аккаунтом и глубину координации в соответствии с ценностью сделки и сложностью покупки.

• SMB требует быстрой квалификации, стандартных сообщений и строгого лимита времени на исследование аккаунта.
• Mid-market допускает исследование и ветвление по персонам, но всё ещё нуждается в повторяемых sequences для достаточного охвата.
• Enterprise требует named-account планирования, нескольких стейкхолдеров, executive-контекста и участия AE ещё до первого митинга.

Полезная территория балансирует рыночный потенциал и нагрузку, а не просто число аккаунтов.

• Я моделирую доступные аккаунты по ICP-уровню, ожидаемой конверсии, стоимости сделки, языку и часовым поясам.
• Владение named accounts остаётся стабильным достаточно долго для multi-threading, а для спящих аккаунтов и передач действуют явные правила.
• Я сравниваю attainment и охват территорий, чтобы найти системный дисбаланс до обвинения конкретного сотрудника.

Я предотвращаю конфликты единой моделью владения в CRM и правилами, отражающими путь покупателя.

• Для named accounts, активных opportunities, окон recycle и обработки ивентов нужны явный владелец и срок окончания владения.
• Routing должен быть виден в Salesforce, а исключения должны проходить через RevOps, а не через личные таблицы.
• Я отслеживаю дубли касаний и споры о передаче, потому что они показывают неясность operating model.

Я сравниваю доступный рынок со скоростью обработки аккаунтов без их преждевременного истощения.

• Из общего TAM я исключаю клиентов, активные opportunities, плохой fit, запрещённые контакты и аккаунты без применимого триггера.
• Расход аккаунтов на сотрудника зависит от длины cadence, recycle-политики и глубины работы с каждым уровнем.
• Если ради квоты приходится слишком часто возвращаться к тем же аккаунтам, я меняю сегмент, цель или размер команды до найма.

Я даю каждому каналу отдельную роль в разговоре, а не повторяю один pitch повсюду.

• Email несёт короткий бизнес-кейс и создаёт сообщение, которое проспект может переслать.
• Телефон быстро проверяет срочность и возражения, а LinkedIn добавляет контекст и помогает достучаться до тех, кто игнорирует почту.
• Async video остаётся для ценных аккаунтов, где визуальное доказательство или исследование оправдывают время производства.
• Я сравниваю дополнительный принятый pipeline по каналам, а не просмотры и лайки.

Cold calling остаётся полезным, когда он таргетирован и используется для обучения, а не как ритуал объёма.

• Звонки быстро показывают, убедительны ли проблема, персона и timing-сигнал.
• Я ставлю direct dials в приоритет для аккаунтов с сильным fit или intent, а не требую одинаковое число звонков по каждому списку.
• Connect-to-conversation и conversation-to-meeting важнее числа наборов, потому что отдельно показывают качество данных и сообщения.

Deliverability является ограничением дизайна, поэтому репутация домена важнее максимального объёма отправки.

• Я использую проверенные рабочие контакты, контролируемый темп отправки, понятную идентификацию и простые письма без лишнего tracking и тяжёлых вложений.
• Негативные ответы, bounce и spam complaints анализируются отдельно, потому что требуют разных исправлений.
• При падении репутации я снижаю объём и чиню качество списков, а не маскирую проблему дополнительными доменами.

Я использую async video, когда показать конкретный инсайт убедительнее, чем описать его ещё в одном письме.

• Канал подходит стратегическим аккаунтам, где можно менее чем за минуту показать релевантный workflow, пробел продукта или наблюдение об аккаунте.
• Я шаблонизирую структуру, но не доказательство, поэтому видео остаётся личным и не требует двадцати минут производства.
• Успех оценивается по митингам и принятым opportunities целевой когорты, а не по запускам видео.

Я организую sequences вокруг устойчивых сочетаний сегмента, персоны и триггера, а не позволяю каждому BDR создавать личную cadence.

• Основная sequence содержит проверенное сообщение для частого use case и даёт команде сопоставимый baseline.
• Triggered и strategic-account sequences дают больше контекста там, где timing или стоимость сделки это оправдывают.
• У каждой sequence есть владелец, аудитория, история версий и правило закрытия, поэтому портфелем можно управлять.

Я закрываю sequence, когда её downstream-результат больше не оправдывает расход аккаунтов и времени BDR.

• Сначала нужен достаточный объём, чтобы отличить слабое сообщение от случайности, затем я смотрю positive replies и sales acceptance по когорте.
• Sequence также закрывается, если триггер устарел, продукт изменился или аудитория уже получила слишком много касаний.
• Команда фиксирует причину и сохраняет вывод, чтобы провальная идея не вернулась под новым названием в следующем квартале.

Я меняю один значимый элемент для сопоставимой аудитории и выбираю метрику решения до запуска.

• Тест может сравнивать две формулировки проблемы или два CTA, но не пять изменений одновременно на разных списках.
• Я балансирую отправителей, сегмент и время, чтобы победителя не определили опыт BDR или качество аккаунтов.
• Positive reply и конверсия в принятую opportunity важнее open rate, который шумит и искажается функциями приватности.

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

• Высокая стоимость сделки, сильный ICP fit, убедительный триггер и доступ к нескольким стейкхолдерам оправдывают ручное исследование.
• Аккаунты меньшей ценности получают релевантный язык сегмента и персоны, но не фальшивые личные детали из профиля.
• Я сравниваю принятый pipeline на час работы по уровням, потому что reply rate может поощрять дорогую работу без конверсии.

Я разделяю стандарты sequences, только когда поведение покупателей или экономика продаж требуют разных правил работы.

• Я сравниваю качество ответов, долю принятых opportunities, длину цикла и риск отписок по сегментам, а не опираюсь на объём активности.
• Enterprise-аккаунтам может требоваться медленный исследовательский multi-threading, а массовый SMB-сегмент допускает больше автоматизации и быстрых тестов.
• Общие правила compliance и CRM остаются едиными, чтобы кастомизация не превратилась в неуправляемую библиотеку sequences.

Хороший multi-threading строит релевантный кейс с несколькими людьми, не превращая контакт с аккаунтом в спам.

• Я определяю владельца проблемы, пользователя, economic buyer и возможного блокера, затем связываю сообщение каждого с его ролью.
• Касания координируются в CRM, чтобы контакты получали дополняющий контекст, а не одинаковый текст в один день.
• Ответ одного стейкхолдера меняет план по остальным, особенно если он называет реального владельца или активную инициативу.

Я иду назад от требуемой выручки через наблюдаемую конверсию воронки и ожидаемую стоимость opportunity.

• Модель переводит pipeline target в принятые opportunities, проведённые митинги, позитивные разговоры и доступные аккаунты.
• Для каждого сегмента используется своя конверсия, потому что enterprise и SMB не могут иметь одну норму продуктивности.
• До расчёта headcount или quota я учитываю ramp, отпуска, ёмкость AE и запас списков.