Вопросы на собеседовании: Sales Engineer
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Middle.
Смотреть пример резюме: Sales Engineer →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Я превращу оценку в совместно согласованный технический план до начала разработки PoC.
- Я подтвержу бизнес-метрику, технические критерии решения, владельца решения и конкретный production-сценарий, который должен доказать PoC.
- Я составлю карту зависимостей со стороны клиента, нашего AE, product engineering, security и моей загрузки, назначив владельца и дату каждой.
- К пятому дню я опубликую архитектуру, scorecard успеха, реестр рисков и критерии остановки, затем получу письменное согласование обоих технических спонсоров.
Зачем это спрашивают: Интервьюер проверяет, устанавливаете ли вы контроль, доказательства и ответственность в начале дорогой технической оценки.
Я сделаю доступы и security approvals явными gates, а до них выполню все тесты, доступные на контрактах и mocks.
- К 2-му дню владелец SAP должен назначить замещающего approver и передать примеры интерфейса, а security получит точные egress destinations и классификацию данных.
- До 12-го дня команда проверит Salesforce, наш API, схемы и обработку ошибок через точный SAP mock, но результаты mock не будут считаться финальным доказательством интеграции.
- Если live-доступ к SAP не согласован к 17-му дню, я приостановлю PoC; иначе дни 18-25 уйдут на end-to-end нагрузочные и failure tests, а пять дней останутся на проверку evidence.
Зачем это спрашивают: Интервьюер проверяет, выявляет ли кандидат зависимости заранее, честно ли использует mocks и сохраняет ли время для доказательств на live-интеграции.
Я останусь владельцем решения, а engineering подключу только к продуктовым пробелам, которые нельзя проверить через поддерживаемые интерфейсы.
- Я разложу 180 часов на конфигурацию, интеграцию, дефекты продукта и новые функции, затем уберу работу, не влияющую на критерии выхода.
- Поддерживаемый путь интеграции я соберу сам, а у engineering запрошу ограниченную помощь с acceptance-тестами и фиксированным лимитом часов.
- Оставшаяся зависимость от новой функции попадёт в реестр рисков с влиянием, владельцем, датой решения и kill-триггером до начала разработки.
Зачем это спрашивают: Интервьюер проверяет, защищаете ли вы ресурсы engineering, сохраняя техническую ответственность за сделку.
Я оформлю multi-region failover как формальное изменение, а не незаметно включу его в оставшиеся 20 дней.
- Я свяжу запрос с исходным критерием решения и уточню, какой сценарий отказа или уровень доступности сделал его необходимым.
- Я оценю дополнительную работу на окружение, тесты и доказательства, затем предложу ограниченную симуляцию failover или новую дату завершения.
- Если спонсор не принимает ни один вариант, я отмечу срок красным и применю согласованное правило остановки вместо ложного отчёта об успехе.
Зачем это спрашивают: Вопрос проверяет контроль скоупа и способность сохранить достоверность технической оценки под давлением руководства.
Я сразу пересмотрю оценку по плану зависимостей, а не буду компенсировать задержку скрытой работой.
- Я покажу заблокированные выходные тесты, потерянные календарные дни и крайний срок каждой зависимости клиента.
- Я предложу синтетические данные и временный endpoint с allowlist только если они проверяют то же техническое утверждение без ослабления security.
- Если prerequisites не готовы к последней дате восстановления, я приостановлю PoC и сохраню окружение и доказательства для будущего квалифицированного перезапуска.
Зачем это спрашивают: Интервьюер хочет увидеть, что вы объективно управляете зависимостями клиента и не фабрикуете технический успех.
Я буду вести PoV через единый журнал решений и scorecard, куда региональные сессии поставляют общие доказательства.
- Дважды в неделю 25-минутный checkpoint охватывает статус критериев, новые риски, владельцев и даты, а архитектурные решения фиксируются асинхронно.
- У каждой интеграции будет один владелец со стороны клиента и один со стороны поставщика, чтобы передача между часовыми поясами не размывала ответственность.
- Я назначу architecture review на 10-й день, проверку готовности к нагрузочному тесту на 35-й и финальную проверку доказательств на 55-й.
Зачем это спрашивают: Сильный ответ показывает лёгкое управление между регионами, которое не подменяет техническую доставку совещаниями.
Я покажу уверенность по prerequisites и критериям выхода, а не субъективный процент готовности.
- Я представлю пройденные, рискованные и заблокированные критерии вместе с уже собранными доказательствами по каждому пройденному пункту.
- Critical path будет включать настройку identity, private connectivity, репрезентативные данные, дату нагрузочного теста и окна проверки клиента.
- Я назову три главных риска, даты их срабатывания и решение, которое требуется от спонсора на этой неделе.
Зачем это спрашивают: Интервьюер оценивает, умеете ли вы сообщать технический прогресс в форме, пригодной для принятия решений.
Я выясню, блокирует ли дефект обязательный результат клиента или только выбранную нами реализацию.
- Я воспроизведу проблему с request ID, логами, версией и минимальными данными, затем получу от engineering severity и реалистичную дату исправления.
- Если поддерживаемая альтернатива доказывает тот же результат, я задокументирую и проверю её, не скрывая исходный дефект.
- Если валидного пути в срок нет, я отмечу критерий как проваленный и применю заранее согласованное kill-правило, а не пообещаю неподтверждённый фикс.
Зачем это спрашивают: Вопрос проверяет честную работу с дефектом, техническую глубину и ответственность за итог оценки.
Я оценю семь явно названных критериев квалификации: use case, измеримый результат, готовность данных, доступ к интеграциям, реализуемость security, технический champion и процесс решения с владельцем и датой.
- Для каждого критерия действует одна шкала: 0 означает отсутствие, 1 означает неподтверждённое утверждение, 2 означает доказательство артефактом, наблюдаемым доступом либо подтверждёнными владельцем и датой.
- Я опубликую сумму из 14 баллов, но ноль по готовности данных, доступу к интеграциям, реализуемости security или процессу решения блокирует PoC независимо от суммы.
- Я свяжу каждый ненулевой балл с доказательством клиента и не позволю account-команде оценивать предположения как факты.
Зачем это спрашивают: Интервьюер проверяет, предотвращает ли discovery scoring расход технических ресурсов на слабые возможности.
Я отвечаю за технические доказательства внутри MEDDIC и делаю пробелы видимыми до начала PoC.
- Metrics превращаются в измеримые технические результаты, например p95 ниже 200 мс или приём 50 000 событий в секунду.
- Decision criteria и process называют архитектурные, security и операционные гейты, их проверяющих и даты проверки.
- Я подтверждаю техническую боль с champion и выясняю, какой блокер нужно снять для economic buyer, а AE ведёт более широкую коммерческую часть.
Зачем это спрашивают: Сильный ответ использует MEDDIC для квалификации технической работы, а не просто расшифровывает аббревиатуру.
Я отмечу возможность как технически неготовую, пока у доступа к SAP не появятся владелец и достоверная дата.
- Я отделю силу боли от готовности к исполнению в scorecard, чтобы энтузиазм не скрывал отсутствующую зависимость.
- Stub на основе контракта может проверить нашу логику маппинга, но не может закрыть end-to-end критерий SAP.
- Если доступ не появится к 20-му дню, я порекомендую перенести PoC, а не тратить оставшийся месяц на частичное доказательство.
Зачем это спрашивают: Интервьюер проверяет, отличаете ли вы ценную проблему от квалифицированной технической оценки.
Я превращу процент в сценарии отказа, ожидания восстановления и влияние на транзакции.
- Я уточню, какие процессы идут во время сбоя, их пиковую стоимость в минуту и могут ли накопленные запросы завершиться после восстановления.
- Я разделю доступность сервиса, региональную устойчивость, RTO, RPO и доступность зависимостей.
- Критерий PoC проверит реальную потребность, например восстановление за пять минут без потери подтверждённых событий, вместо бездоказательного повторения 99,99%.
Зачем это спрашивают: Вопрос проверяет, умеете ли вы превращать необоснованное нефункциональное требование в измеримые технические критерии.
Я проверю champion по его доступу, влиянию и действиям, а не по положительным отзывам о нас.
- Он должен привести на discovery владельцев identity, network, security и приложений и исправлять наши архитектурные предположения.
- Он должен описать критерии решения и внутренний путь проверки достаточно точно, чтобы предсказать следующий технический гейт.
- Я дам конкретную задачу, например получить репрезентативные Kafka topics к пятнице, и обновлю квалификацию по фактическому результату.
Зачем это спрашивают: Интервьюер оценивает, проверяете ли вы силу champion через наблюдаемое техническое поведение.
Я добьюсь единого ранжированного scorecard решения до реализации теста любой из команд.
- Я свяжу каждый критерий с бизнес-сценарием и посчитаю последствия промаха, например устаревшие fraud-решения или задержанные dashboards.
- Владелец решения должен назначить веса и минимальные пороги, например 60% полноте и 40% задержке с жёстким минимумом для обеих.
- Если до дедлайна скоупа нет владельца, способного разрешить конфликт, возможность не готова к PoC для принятия решения.
Зачем это спрашивают: Сильный ответ устанавливает полномочия и измеримые приоритеты вместо посредничества на уровне мнений.
Я отклоню его, если оценка не способна привести к решению, хотя технология может работать.
- Примеры: нет владельца технического решения, доступа к репрезентативным системам или критерии меняются после каждой встречи.
- Я также отклоню PoC, где запрошенная кастомная разработка превышает переиспользуемую инженерную ценность и не имеет подтверждённого product path.
- Я задокументирую проваленные измерения квалификации и точные условия для повторного рассмотрения.
Зачем это спрашивают: Интервьюер проверяет, считаете ли вы технические ресурсы инвестицией, а не одобряете каждый реализуемый запрос.
До развёртывания кластера я определю проходные критерии по throughput, latency, корректности, устойчивости и эксплуатации.
- Система должна два часа держать 80 000 событий в секунду при end-to-end p99 ниже 500 мс без необъяснимых потерь.
- Тест отказа брокера должен восстановиться за пять минут, сохранить порядок по согласованным ключам и удержать долю дублей ниже 0,01%.
- Клиент должен воспроизвести прогон по документированной конфигурации и принять dashboard, логи и отчёт к 42-му дню.
Зачем это спрашивают: Вопрос проверяет, измеряется ли успех PoC одновременно по performance, reliability и готовности клиента к эксплуатации.
Я задам kill-критерии по неподдерживаемой продуктовой работе, пропущенным зависимостям и провалу основной нагрузки.
- Остановка, если connector требует больше согласованных 40 инженерных часов или обходит поддерживаемую аутентификацию.
- Остановка, если репрезентативные исходные данные и credentials недоступны к 12-му дню 35-дневного плана.
- Остановка, если первый масштабный тест отстаёт от минимального throughput больше чем на 30% и нет проверенного исправления за пять рабочих дней.
Зачем это спрашивают: Сильный ответ делает остановку объективной и защищает инженерное время и техническую достоверность.
Я применю согласованный порог и бизнес-вес, а не растворю промах в среднем балле.
- Я проверю метод тестирования, отделю вклад нашего сервиса от зависимости клиента и один раз повторю прогон в контролируемых условиях.
- Если p99 latency является жёстким минимумом для критичного процесса, результат будет отрицательным, даже если остальные пять критериев пройдены.
- Я представлю измеренный разрыв, подтверждённую причину и поддерживаемое продуктом исправление с датами, не меняя scorecard после результата.
Зачем это спрашивают: Интервьюер проверяет, сохраняете ли вы заранее согласованные правила решения, когда дорогая оценка почти прошла.
Я продлю PoC только тогда, когда дополнительное время закрывает ограниченный пробел в доказательствах без смены исходной проблемы или архитектуры.
- Допустимый случай: пятидневная задержка сети по стороне клиента, когда окружение и оставшийся тест уже готовы.
- Продление получает одного владельца, один deliverable, фиксированную дату завершения и не включает новые кастомные функции.
- Я остановлю PoC, если изменились спонсор, use case, порог успеха или необходимая возможность продукта.
Зачем это спрашивают: Вопрос проверяет дисциплину продлений и способность не превращать слабую оценку в zombie PoC.
Я не объявлю технический успех, пока жёсткий критерий выхода не проверен.
- Я отделю завершённые функциональные доказательства от нерешённого риска capacity и посчитаю последствия для production.
- Если клиент принимает меньший документированный объём, владелец решения может формально изменить требование до теста, а не после неудачного прогона.
- В противном случае я выпущу статус incomplete с ближайшей достоверной датой нагрузочного теста и оставлю риск открытым.
Зачем это спрашивают: Интервьюер оценивает честность и способность сопротивляться давлению, требующему преувеличить технические доказательства.
Закрытые вопросы
- 21
Как спроектировать scorecard PoC, если часть критериев обязательна, а часть имеет веса?
proof-of-conceptdesignevaluation-scorecard - 22
60-дневный healthcare PoV не успевает завершить GDPR-тест удаления данных к 50-му дню. Как вы примете решение?
proof-of-valuegdpr - 23
Как вы спроектируете интеграцию SAP для 40-дневного order-management PoC с 300 000 заказов в день?
proof-of-conceptdesign - 24
PoC на $1,1 млн ARR должен синхронизировать Salesforce opportunities с вашей платформой не дольше 60 секунд. Как вы построите архитектуру?
proof-of-conceptannual-recurring-revenue - 25
Как подключить Kafka-кластер клиента к SaaS PoC, не выставляя ни одну сеть в public?
proof-of-conceptkafkacloud - 26
Проспект использует Kubernetes и требует развернуть ваш collector на 2 000 nodes за 45 дней. Какую архитектуру вы предложите?
kubernetes - 27
Как вы спроектируете 50-дневный PoC, отправляющий продуктовые события в Snowflake с отставанием dashboards не больше пяти минут?
proof-of-conceptdesignsnowflake - 28
Клиент использует BigQuery и ожидает 20 ТБ в день с вашей платформы. Что вы проверите до выбора архитектуры PoC?
proof-of-conceptarchitecturevalidation - 29
Как интегрировать SaaS-платформу с on-premises SAP, если входящий интернет-доступ запрещён?
system-designcloud - 30
35-дневный identity PoC требует SAML SSO и SCIM provisioning для 40 000 пользователей. Как вы его спроектируете?
proof-of-conceptdesign - 31
Клиент хочет OIDC для сотрудников и workload identity для Kubernetes-сервисов в одном PoC. Как вы разделите эти дизайны?
proof-of-conceptdesignkubernetes - 32
Salesforce-to-Kafka PoC создаёт дубли и переставляет изменения статуса. Как исправить архитектуру?
kafkaproof-of-concept - 33
Как доказать private connectivity для 55-дневного PoC на $2,8 млн ARR между AWS и Azure?
proof-of-conceptannual-recurring-revenue - 34
Клиент хочет объединить в PoC master data из SAP, accounts из Salesforce и факты из warehouse. Как вы определите identity и ownership?
soft-skillsownershipwarehouse - 35
Ваш API должен отправлять данные и в Kafka, и в data warehouse во время 30-дневного PoC. Будете ли вы делать dual-write из request path?
warehouseapikafka - 36
Как превратить нефункциональные требования в план PoC для сервиса с 5 000 запросов в секунду и доступностью 99,95%?
proof-of-concept - 37
Нагрузочный тест достигает целевого throughput, но p99 latency растёт со 180 мс до 1,4 секунды. Как вы расследуете?
latencythroughputload-testing - 38
Какую observability вы потребуете для 45-дневного enterprise PoC до первого масштабного теста?
proof-of-conceptobservability - 39
Как спроектировать нагрузочный тест Kafka PoC с burst-целью 120 000 событий в секунду?
kafkadesignload-testing - 40
Проспект требует RTO 10 минут и RPO 0 для 50-дневного PoV. Как проверить это требование?
proof-of-valuevalidation - 41
Kubernetes PoC работает на 100 pods, но ломается на 1 500. Какие данные вы соберёте перед эскалацией?
proof-of-conceptkubernetesescalation - 42
Как координировать SOC 2 evidence для 40-дневного PoC в financial services без неподтверждённых заявлений?
proof-of-concept - 43
PoC платёжной платформы может затронуть cardholder data. Как вы скоординируете PCI scope и доказательства?
proof-of-concept - 44
Европейский проспект требует GDPR evidence для 55-дневного PoV с customer data. Что вы соберёте?
proof-of-valuegdpr - 45
Как вести technical security risk register для 60-дневного PoV на $3,5 млн ARR?
proof-of-valueriskannual-recurring-revenue - 46
Penetration test находит high-severity проблему в PoC-окружении, до конца осталось 12 дней. Что вы сделаете?
proof-of-conceptseverity-priority - 47
В 45-дневном PoC три команды клиента интегрируются по вашему OpenAPI-контракту. Какое governance вы установите?
proof-of-conceptopenapi - 48
Product API переименовывает обязательное поле во время PoC на $1,4 млн ARR. Как защитить интеграцию клиента?
proof-of-conceptapiannual-recurring-revenue - 49
Как управлять OpenAPI error responses для интеграции с 10 млн вызовов в день?
openapi - 50
Сгенерированный клиентом SDK ломается после additive OpenAPI change. Как вы диагностируете и организуете исправление?
openapi - 51
Сделка на $900K ARR устно одобрена, но CTO все еще сомневается в заявленном времени восстановления, а procurement закрывается через шесть рабочих дней. Как вы доведете техническую часть до закрытия?
annual-recurring-revenueprocurementtechnical-close - 52
За два дня до подписания сделки на $1.2M архитектор клиента обнаруживает, что приложение к договору по архитектуре обещает active-active регионы и срок поставки, который product не согласовывал. Что вы сделаете?
promises - 53
Ваш champion говорит, что техническая команда довольна, но никто не готов подтвердить завершение оценки, а квартал заканчивается в пятницу. Как избежать ложного технического закрытия?
technical-evaluationchampiontechnical-close - 54
Проспект успешно завершил четырехнедельную оценку, но продолжает просить еще один воркшоп перед покупкой на $600K ARR. Как остановить разрастание технического цикла?
annual-recurring-revenuetechnical-evaluation - 55
На финальной встрече по покупке платформы за $2M CIO просит гарантировать экономию на инфраструктуре 25 процентов. Ваши данные подтверждают только диапазон от 12 до 20 процентов. Что вы ответите?
- 56
В bake-off трех поставщиков конкурент публикует бенчмарк с удвоенной пропускной способностью, а у клиента 80 процентов операций составляют записи небольшого размера. Как вы ответите?
competitive-bake-offcompetitive-positioningthroughput - 57
Конкурент предлагает кастомную функцию для сделки на $750K и обещает доставку за 30 дней; ваша продуктовая команда не будет делать аналог в этом квартале. Как вы спозиционируете разрыв?
competitive-positioning - 58
Ваш продукт выигрывает шесть из семи технических критериев, но стоит на 18 процентов дороже текущего решения при его замене. Как провести финальное сравнение?
renewal - 59
Во время live bake-off конкурент говорит, что у вашего продукта нет data residency в Канаде, хотя канадский хостинг запущен месяц назад. Как исправить утверждение и не сорвать сессию?
competitive-bake-offcompetitive-positioningsessions - 60
Покупатель дает каждому поставщику 90 минут на демо, но scorecard содержит 40 требований, включая 12 слабых для вашего продукта. Как построить bake-off сессию?
evaluation-scorecarddesignsessions - 61
Вы получили RFP на 320 вопросов со сроком пять рабочих дней, а библиотека ответов не проверялась девять месяцев. Как успеть и не отправить устаревшие заявления?
rfp - 62
RFI спрашивает о поддержке доступности 99,999 процента, публичный SLA равен 99,9 процента, а внутренняя телеметрия за прошлый год показала 99,97 процента. Что вы напишете?
- 63
В общей RFP-библиотеке 180 security-ответов, а три изменения продукта сделали 27 из них неверными. Как восстановить доверие к библиотеке в этом квартале?
rfp - 64
Государственный RFP требует подписанный accessibility conformance report к пятнице, но ваш VP говорит: «Мы в целом соответствуем WCAG». Как обработать ответ?
a11ysoft-skillsrfp - 65
Одобренный полгода назад ответ RFP утверждает, что данные клиента никогда не покидают ЕС, но новый support diagnostic могут просматривать инженеры из США. Что нужно сделать до завтрашней отправки?
rfp - 66
Ваша команда проводит 25 демо в неделю, подготовка каждого окружения занимает 70 минут, а сбои setup отменяют 8 процентов сессий. Что автоматизировать первым?
sessions - 67
Релиз продукта выходит в среду, а у 14 SE назначены клиентские демо в четверг. Как предотвратить drift окружений, не замораживая всех на старой версии?
product-demoiac - 68
Три региональные SE-команды поддерживают разные demo scripts одного продукта, а передача сделки занимает два дня. Как стандартизировать работу и не сделать все демо одинаковыми?
product-demotechnical-handoff - 69
Ваш автоматический demo seed содержит похожие на клиентские финансовые записи и скопирован в 40 sandbox. Что изменить до следующего цикла демо?
product-demo - 70
Live demo зависит от партнерского API, который падает примерно на одном из 20 вызовов, а завтра executive-сессия по сделке на $1.5M. Как сделать демо убедительным и устойчивым?
product-demoapisessions - 71
Проспект на $300K просит шестинедельный кастомный PoC на 240 инженерных часов, а стандартный PoC подтверждает четыре из пяти критериев за десять дней. Что вы порекомендуете?
proof-of-conceptfundamentalssuccess-criteria - 72
Стратегическому аккаунту на $2.5M нужен коннектор, который также просили еще три целевых аккаунта. Оценка product составляет четыре недели. Включать ли его в кастомный PoC?
proof-of-conceptestimation - 73
Покупатель на $950K прошел стандартный PoC, но перед подписанием просит брендированный sandbox для 200 sales reps, требующий трех недель кастомной работы. Что вы порекомендуете?
proof-of-conceptbuyer - 74
Проспект отказывается от стандартного PoC, потому что тестовые данные не похожи на его 12 миллионов записей, но предоставить production-данные он не может. Какой компромисс разумен?
proof-of-concept - 75
AE утверждает, что каждая сделка выше $500K заслуживает кастомный PoC. В прошлом квартале было 11 PoC, три победы и 900 потраченных инженерных часов. Как изменить правило?
proof-of-concept - 76
За десять дней до планируемого подписания на $800K security review выявляет три обязательных контроля, которым продукт соответствует не полностью. Покупатель готов продолжить только при достаточных компенсирующих контролях или принятом остаточном риске. Как вы проведете процесс со стороны SE?
buyer - 77
Legal спрашивает, может ли продукт принять неограниченную ответственность за утечку, а AE просит объяснить, почему архитектура делает это безопасным. Как вы ответите?
architecture - 78
Европейский банк требует доказательства penetration test за семь дней. В закрытом полном отчете есть одна открытая критическая находка, которая еще исправляется. Какой пакет вы предложите?
- 79
Procurement требует сертификат удаления данных в течение 24 часов после расторжения договора, а operations может подтвердить удаление только за семь дней. Как обработать разрыв?
procurementsoft-skills - 80
Медицинский клиент просит SE подписать заявление, что сервис соответствует HIPAA, до завершения BAA. Подписание завтра. Что вы сделаете?
buyer - 81
Клиент ожидает загрузку 40 TB в месяц, но выбрал пакет с включенными 10 TB, а AE не хочет обсуждать превышение до подписания. Как вы поступите?
soft-skills - 82
SSO и audit logs доступны только в enterprise tier, но проспект на 600 мест заложил бюджет standard tier и называет обе функции обязательными. Что вы сделаете?
- 83
Usage-based API сделка прогнозирует 200 миллионов вызовов в месяц, но новый workflow может утроить трафик. Как технически поддержать обсуждение цены?
pricingapi - 84
Покупатель хочет пакет с retention 30 дней, но также требует поиск по аудиту за 13 месяцев. Add-on удваивает стоимость хранения. Как представить варианты?
retentionbuyer - 85
Проспект на $1M просит engineering сделать разовый формат экспорта на 120 часов, а подписать договор планирует через три недели. Как представить запрос внутри компании?
estimation - 86
Engineering получил от вашего пода пять запросов с пометкой «deal blocker» за месяц, но только у одного аккаунта подтвержден ответственный за техническое решение. Как исправить процесс?
deal-blockercommunicationconcurrency - 87
Product согласился на функцию для стратегической сделки, но не сможет доставить ее до 45 дней после целевого go-live клиента. Как сохранить честность всех сторон?
- 88
Инженер потратил два дня на прототип для вашей сделки, но клиент изменил направление и не будет его использовать. Что делать дальше?
prototypes - 89
CISO клиента на звонке утверждает, что ваша схема шифрования нарушает регуляторное требование, а доступные доказательства не решают спор. Что делать на встрече и после нее?
encryptiondesign - 90
Проспект сообщает, что ваш API потерял 0,3 процента событий в тесте, команда не может это воспроизвести, а финальное решение через четыре дня. Как эскалировать?
escalationapidebugging - 91
Economic buyer повторяет утверждение конкурента, что миграция на вашу платформу потребует шесть месяцев простоя. До конца встречи 15 минут. Как ответить?
buyereconomic-buyercompetitive-positioning - 92
Ваш champion должен представить платформу скептическому architecture board в следующий вторник, но вас не пригласили. Как его подготовить?
championarchitecture - 93
CFO подключается к финальному звонку по сделке на $1.8M и спрашивает, почему техническую миграцию нужно финансировать в этом году. Какой нарратив вы используете?
migrations - 94
Ваш technical champion любит продукт, но говорит руководству, что он требует «ноль интеграционной работы». Как исправить его и не ослабить поддержку?
championtechnical-champion - 95
За квартал вы проиграли четыре enterprise-сделки одному конкуренту, но в CRM указано только «цена». Как получить полезный win-loss synthesis?
win-loss-analysiscompetitive-positioning - 96
Win-loss review показывает 70 процентов побед при наличии migration workshop и только 28 процентов без него. Как решить, нужно ли менять playbook?
win-loss-analysismigrations - 97
В 12 недавних проигрышах упомянут отсутствующий dashboard, но продуктовая телеметрия показывает, что похожие dashboards используют менее 5 процентов текущих клиентов. Что вы порекомендуете?
- 98
Вы принимаете сделку на $3M с восемью открытыми техническими проблемами, security review через девять дней и без risk register. Что создать за первые 24 часа?
riskownership - 99
У вашего пода постоянно больше квалифицированной работы по сделкам, чем доступных часов SE. Только на этой неделе шесть сделок на $5.4M ARR конкурируют за 20 часов. Какую постоянную политику портфельной оценки вы введете?
annual-recurring-revenuecapacity - 100
В понедельник у вас bake-off на $1.4M в среду с одним непроверенным сценарием масштаба, RFP на $850K в пятницу и сделка на $2.2M, заблокированная условием legal-security. Один инженер может помочь восемь часов на этой неделе. Как вы один раз распределите это время?
competitive-bake-offrfp