> 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/enterprise-prodazhi/rabota-s-vozrazheniyami.md).

# Работа с возражениями

Возражение — это не отказ. Это запрос на дополнительную информацию или сигнал что что-то не прояснено.

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

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

### Четыре типа возражений

Прежде чем отвечать — определи тип. Разные типы требуют разных подходов.

#### Тип 1 — Возражение по цене

"Это дорого" "У конкурента дешевле" "Бюджета нет"

Это самое частое и самое поверхностное возражение. В 80% случаев за ним стоит не реальная нехватка денег, а одно из:

* Недостаточно понята ценность
* Нет доверия к результату
* Нет срочности — зачем платить сейчас

Никогда не давай скидку сразу. Скидка без борьбы сигнализирует: "Я изначально поставил завышенную цену" — и разрушает доверие к тебе как партнёру.

Техника работы с ценой — Reframe на ROI:

Клиент: "Это слишком дорого для нас"

Ты: "Понимаю что цена важна. Давайте посмотрим на это с другой стороны. Вы сказали что сейчас теряете около \[сумма] в месяц на \[боль которую назвал]. Наша годовая стоимость — \[цена]. Это значит что за \[N месяцев] решение окупается полностью, а дальше это чистая экономия. При таком раскладе вопрос не 'дорого ли это' — а 'можем ли мы позволить себе не решить это'.

Что именно кажется несоразмерным — сама сумма или соотношение с результатом?"

***

Техника — изоляция возражения:

Прежде чем работать с ценой — убедись что это единственное препятствие.

"Если бы вопрос цены решился — всё остальное вас устраивает и вы готовы двигаться вперёд?"

Если "да" — работай с ценой. Если "ну и ещё есть вопросы..." — сначала разберись с реальными возражениями.

***

Техника — сравнение с альтернативой:

"Давайте сравним не с нулём, а с альтернативами:

Альтернатива 1 — не делать ничего: Вы продолжаете терять \[сумма] ежемесячно. За год это \[сумма × 12].

Альтернатива 2 — нанять человека: Зарплата + налоги + онбординг = минимум \[сумма] в год, и это без гарантии результата.

Альтернатива 3 — наше решение: \[Цена] в год с гарантированным результатом \[метрика] за \[срок].

При таком сравнении наш вариант — самый дешёвый из трёх."

***

#### Тип 2 — Возражение по доверию

"Мы не знаем вашу компанию" "Вы маленькие — а вдруг закроетесь" "У конкурента больше клиентов" "Нам важен проверенный вендор"

Это возражение про риск, не про цену. Клиент говорит: "Я боюсь ошибиться с выбором и выглядеть плохо перед своим руководством"

Техника — Social Proof через релевантность:

Не просто "у нас 500 клиентов". А: "У нас 12 клиентов в финтехе Казахстана и Центральной Азии, включая \[название если можно раскрыть]. Могу организовать звонок с их CTO — он расскажет как проходило внедрение и что получили в итоге. Вам было бы полезно?"

Референс-звонок с похожим клиентом — самый мощный инструмент закрытия возражения по доверию.

***

Техника — снижение риска через пилот:

"Понимаю что брать обязательства на полный год без опыта работы с нами — это риск. Именно поэтому мы предлагаем начать с пилота на \[срок] на \[часть команды].

Вы увидите реальный результат на своих данных, ваша команда попробует продукт в реальных условиях — и дальше решение будет основано на фактах, а не на презентации.

Пилот стоит \[сумма / бесплатно]. Если результат не устроит — расходимся без обязательств."

***

Техника — Proof of Concept для Technical Buyer:

Технические скептики не верят словам. Дай им попробовать:

"Давайте сделаем POC на ваших реальных данных — 2 недели, ваша IT-команда работает напрямую с нашими инженерами. По итогу у вас будет не наши слова о возможностях, а реальные результаты на вашей инфраструктуре."

***

#### Тип 3 — Возражение по срочности

"Сейчас не лучшее время" "Давайте вернёмся к этому в следующем квартале" "У нас сейчас другие приоритеты"

Это самое опасное возражение — потому что оно вежливое. Клиент не говорит "нет", он говорит "потом". А "потом" в B2B продажах часто означает "никогда".

За этим возражением обычно стоит одно из:

* Нет реального Critical Event
* Боль недостаточно острая
* Ты не добрался до Economic Buyer
* Есть невидимый конкурент или внутренний проект

Техника — вскрыть реальную причину:

"Понимаю. Помогите мне разобраться: когда вы говорите 'не лучшее время' — это вопрос бюджета, приоритетов команды или что-то ещё что я, возможно, не учёл?"

Слушай внимательно. Реальное возражение появится здесь.

***

Техника — стоимость бездействия:

"Хочу убедиться что мы смотрим на полную картину.

Вы упомянули что \[боль] стоит вам \[сумма] в месяц. Если мы переносим на квартал — это \[сумма × 3] которые уходят пока мы ждём. Плюс ваша команда продолжает работать в условиях \[боль].

Что должно произойти чтобы это стало приоритетом раньше?"

***

Техника — найти или создать Critical Event:

Если Critical Event нет — помоги клиенту его найти.

"Есть ли у вас квартальный review с советом директоров? Когда он?"

"Вы упоминали что планируете нанять 10 новых сейлзов в Q3. Если система не будет готова к их выходу — как это повлияет на их онбординг?"

"Регулятор объявил новые требования с дедлайном в сентябре. Как вы сейчас готовитесь к этому?"

***

#### Тип 4 — Возражение по соответствию

"Нам нужна функция X которой у вас нет" "Это не интегрируется с нашей системой" "Нам нужна локализация данных в КЗ" "Ваш продукт не подходит для нашей отрасли"

Это единственный тип возражений где иногда правильный ответ — согласиться. Не каждый клиент твой клиент.

Но сначала проверь: это реальное требование или предположение?

Техника — уточнение и приоритизация:

"Расскажите подробнее про функцию X. Как именно вы её используете сейчас? Что происходит если её нет?"

Часто оказывается что функция X — nice to have, а не must have. Или что ваш подход решает ту же задачу по-другому.

***

Техника — роадмап и кастомизация:

"Эта функция сейчас в нашем роадмапе на Q3. Если мы начнём работать сейчас — вы получите её в числе первых и сможете влиять на её развитие через наш advisory board.

Без этой функции — насколько критично для старта пилота?"

***

Техника — workaround до решения:

"Прямо сейчас нативной интеграции нет. Но вот как наши клиенты решают это через \[Zapier / API / промежуточное решение]. Это закрывает потребность на период пока мы строим нативную интеграцию?

Или это hard blocker для рассмотрения?"

***

### Универсальный алгоритм работы с любым возражением

Используй этот алгоритм для любого типа:

Шаг 1 — Выслушай полностью. Не перебивай. Дай клиенту договорить. Пауза 2-3 секунды после того как он закончил.

Шаг 2 — Подтверди что услышал. "Понимаю. Это важный момент." Не соглашайся с возражением — подтверди что услышал его.

Шаг 3 — Уточни. "Расскажите подробнее. Что именно вызывает это сомнение?" В 50% случаев клиент сам отвечает на своё возражение пока объясняет.

Шаг 4 — Изолируй. "Если бы этого вопроса не было — всё остальное вас устраивает?"

Шаг 5 — Ответь. Используй одну из техник выше.

Шаг 6 — Подтверди закрытие. "Это отвечает на ваш вопрос?" "Мы можем двигаться дальше?"

***

### Возражения специфичные для КЗ рынка

#### "Нам нужен местный вендор"

Контекст: госсектор и квазигос часто требуют отечественного производителя. Частные компании иногда предпочитают локального из-за языка и поддержки.

Ответ если ты международный вендор: "Понимаю важность локального присутствия. У нас есть сертифицированный партнёр в Казахстане — \[название] — который обеспечивает внедрение, поддержку на русском и казахском языках и хранение данных на серверах в КЗ. Фактически вы работаете с локальной командой с экспертизой глобального продукта."

***

#### "Нам нужно пройти тендер"

Контекст: это не возражение — это процесс. Но часто означает что решение уже принято в пользу другого вендора.

Как проверить: "Вы уже определились с предпочтительным решением или тендер полностью открытый?"

Если тендер открытый: "Отлично. Чем мы можем помочь в подготовке технического задания? Хотим убедиться что ТЗ отражает реальные потребности вашего бизнеса, а не только формальные требования."

Помогай писать ТЗ — это легальная и стандартная практика. Кто пишет ТЗ — тот и выигрывает тендер.

***

#### "У нас уже есть решение"

Контекст: замена существующего вендора — самая сложная продажа. Стоимость смены (switching cost) высокая: данные, обучение, интеграции, психологическая инерция.

Техника — найти боль с текущим решением: "Расскажите как вы сейчас используете \[X]. Что работает хорошо? А что хотели бы изменить если бы могли?"

Фокус на пробеле между тем что есть и тем что нужно. Не атакуй конкурента — атакуй статус-кво.

"Вы упомянули что \[X] не делает \[функцию]. Как вы сейчас решаете это? Сколько времени это занимает у команды?"

***

### Чего никогда не делать при возражениях

Не спорить и не доказывать что клиент неправ — даже если он объективно неправ. Люди покупают у тех с кем комфортно, а не у тех кто их переспорил.

Не давать скидку как первый ответ на любое возражение — это разрушает позицию и доверие.

Не игнорировать возражение и двигаться дальше — клиент запомнит что ты ушёл от вопроса.

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

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


---

# 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/enterprise-prodazhi/rabota-s-vozrazheniyami.md?ask=<question>
```

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.