> For the complete documentation index, see [llms.txt](https://gravii.gitbook.io/kzsaleshub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gravii.gitbook.io/kzsaleshub/shablony-i-skripty/shablon-discovery-call.md). # Шаблон discovery call Discovery call — самый важный звонок в цикле сделки. Не демо. Не презентация. Не питч. Discovery — это глубокое исследование ситуации клиента. Цель: понять боль, измерить её, найти Champion и Economic Buyer, понять процесс принятия решения. Сейлз который пропускает discovery и сразу делает демо — тратит время на показ продукта людям которые не купят. Сейлз который делает глубокий discovery — знает всё что нужно для закрытия до того как отправил первое КП. *** ### Структура discovery call — 45 минут #### Блок 1 — Открытие (3-5 минут) Цель: установить доверие, задать ожидания, получить разрешение на глубокие вопросы. Скрипт: "\[Имя], спасибо что нашли время. Предлагаю построить разговор так: сначала я задам несколько вопросов чтобы понять вашу ситуацию — это займёт минут 20-25. Потом если увижу что можем помочь — расскажу как именно. Если нет — скажу честно. Вам подходит такой формат?" Почему это работает: — Даёт клиенту понять структуру — Снимает ощущение что его сейчас будут питчить — Создаёт психологический контракт на честный разговор *** #### Блок 2 — Situation (5-7 минут) Цель: понять контекст. Не трать здесь много времени — то что можно найти в открытых источниках не стоит спрашивать. Вопросы: "Расскажите как сейчас устроен ваш отдел продаж — сколько человек, какие роли?" "Какие продукты и решения продаёте — какой средний чек, цикл сделки?" "Какие инструменты используете для управления продажами сейчас?" "Как давно работаете в текущей конфигурации?" Правило: не больше 3-4 ситуационных вопросов. Клиент устаёт от анкеты. Быстро переходи к боли. *** #### Блок 3 — Pain (10-15 минут) Самый важный блок. Здесь рождаются или умирают сделки. Цель: найти острую боль, понять её глубину, заставить клиента самого осознать масштаб проблемы. Открывающий вопрос: "Что привело вас к тому чтобы посмотреть на решения в этой области именно сейчас?" Или: "Если бы вы могли изменить одну вещь в том как работают ваши продажи — что это было бы?" После ответа — углубляй: "Расскажите подробнее..." "Как долго это происходит?" "Как часто с этим сталкиваетесь?" "Кто ещё страдает от этой проблемы кроме вас?" "Что уже пробовали чтобы решить?" "Почему это не сработало?" Техника углубления боли (5 почему): Клиент называет проблему → спроси почему это проблема → углубляй каждый ответ → дойди до корневой боли. Пример: Клиент: "Нам сложно управлять pipeline" Ты: "Что конкретно сложно?" Клиент: "Не видим реальную картину" Ты: "Что происходит когда не видите?" Клиент: "Прогноз постоянно неточный" Ты: "Как это влияет на бизнес?" Клиент: "CEO давит — обещаем одно, получаем другое" Ты: "Что происходит с командой в таких ситуациях?" Теперь ты знаешь настоящую боль: не "нет инструмента" — а "CEO теряет доверие к команде продаж". *** #### Блок 4 — Impact (5-7 минут) Цель: измерить боль в деньгах и времени. Без цифр нет бизнес-кейса. Без бизнес-кейса нет сделки. Вопросы: "Если перевести в деньги — сколько стоит эта проблема компании сейчас?" "Сколько времени в неделю уходит на \[проблема]?" "Во сколько обходится одна потерянная сделка из-за этой ситуации?" "Что происходит если не решить это в этом году?" "Какова стоимость бездействия на горизонте 12 месяцев?" Если клиент затрудняется с цифрами — помоги посчитать вместе: "Давайте попробуем посчитать вместе. Сколько сделок в месяц теряете из-за \[проблема]? Какой средний чек? Итого — \[сумма] в месяц. За год — \[сумма × 12]. Это похоже на реальность?" *** #### Блок 5 — Decision Process (5-7 минут) Цель: понять как принимается решение, кто участвует, какие сроки. Вопросы: "Кроме вас — кто ещё будет участвовать в принятии решения?" "Как обычно принимаются решения о таких инвестициях в вашей компании?" "Есть ли кто-то кто может заблокировать проект?" "Какой процесс согласования — нужен ли тендер?" "Какой бюджет рассматриваете для решения этой задачи?" "Когда планируете принять решение?" "Что должно произойти для того чтобы вы двинулись к финальному решению?" *** #### Блок 6 — Мини-питч (5-7 минут) Только после того как выявил боль. Не раньше. Не питчируй продукт — питчируй результат. Структура: "На основе того что вы рассказали — \[повтори боль своими словами]. Мы работаем с \[тип компаний] у которых \[та же боль]. Вот что мы делаем: \[механизм — 1-2 предложения]. Например, \[клиент из той же индустрии] получил \[конкретный результат] за \[срок]. Это релевантно для вашей ситуации?" *** #### Блок 7 — Закрытие на следующий шаг (3-5 минут) Никогда не заканчивай звонок без конкретного следующего шага с датой. "\[Имя], по тому что вы рассказали — думаю есть смысл двигаться дальше. Предлагаю \[конкретный следующий шаг]: \[демо / встреча с командой / технический звонок / КП]. Это займёт \[время]. Вам удобнее \[день] или \[день]?" *** ### Карточка вопросов — распечатай Держи перед собой на каждом звонке: SITUATION (не больше 3): * Как устроена команда продаж? * Какие инструменты используете? * Какой средний чек и цикл сделки? PAIN (основной блок): * Что привело к поиску решения именно сейчас? * Что самое сложное в текущей ситуации? * Как давно это проблема? * Что уже пробовали? IMPACT (измеряем боль): * Сколько это стоит в деньгах? * Что происходит если не решить в этом году? DECISION PROCESS: * Кто ещё участвует в решении? * Какой процесс согласования? * Какой бюджет рассматриваете? * Когда планируете решение? CHAMPION CHECK: * Кто внутри компании больше всего заинтересован в решении? * Кто пострадает если не решить? *** ### Красные флаги на discovery Клиент не может назвать конкретную боль: Продолжай копать или дисквалифицируй. "Просто смотрим рынок" — нет срочности, нет сделки. Клиент не знает кто принимает решение: Красный флаг. Уточни: "А кто в вашей компании отвечает за такие решения обычно?" Клиент называет нереальный бюджет: Не спорь. Уточни: "Откуда эта цифра? Что в неё входит по вашему пониманию?" Клиент уклоняется от вопросов о сроках: Нет Critical Event = нет urgency. Создай или дисквалифицируй. Клиент говорит 10% времени: Ты говоришь слишком много. Замолчи. Задай вопрос. Слушай. *** ### Метрики качества discovery Talk Ratio: Ты: 30-40%, клиент: 60-70%. Если ты говоришь больше — это презентация, не discovery. Количество вопросов: Норма: 12-15 вопросов за 45 минут. Если меньше 8 — недостаточно глубоко. Боль измерена в цифрах: Обязательно к концу звонка. Если нет цифр — вернись к Impact блоку. Следующий шаг зафиксирован: С конкретной датой, не "скоро". 100% звонков должны заканчиваться конкретным next step. Decision Maker идентифицирован: Знаешь кто подписывает бюджет. Если нет — это главная дыра в сделке. *** ### После discovery call В течение 2 часов после звонка: 1. Обнови CRM — внеси все данные пока свежи. 2. Отправь follow-up письмо. Структура письма: "\[Имя], спасибо за разговор. Фиксирую ключевые моменты: Ситуация: \[кратко что обсудили] Боль: \[что назвал как главную проблему] Impact: \[в деньгах или времени] Следующий шаг: \[что договорились сделать, дата] Если что-то упустил или что-то изменилось — дай знать. До встречи \[дата/время]." 3. Оцени сделку по MEDDIC: Что знаешь, что пока неизвестно, какие риски, следующие действия. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://gravii.gitbook.io/kzsaleshub/shablony-i-skripty/shablon-discovery-call.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.