> 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/mutual-action-plan-map.md).

# Mutual Action Plan (MAP)

Mutual Action Plan — совместный документ который фиксирует все шаги от сегодня до подписания договора. Его видят обе стороны: ты и клиент.

MAP решает главную проблему Enterprise продаж: неопределённость. Клиент не знает что будет дальше, ты не знаешь что происходит внутри. MAP убирает туман войны с обеих сторон.

Компании которые используют MAP закрывают сделки на 30-40% быстрее и с win rate выше на 20%. Не потому что MAP — магия. А потому что MAP выявляет незаинтересованных клиентов на ранней стадии: если клиент отказывается заполнять MAP — сделка была иллюзией.

### Почему MAP работает

#### Создаёт взаимные обязательства

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

Психологически это важно: когда человек публично берёт обязательство — он с большей вероятностью его выполнит. Это называется эффект commitment и consistency (Cialdini).

#### Выявляет реальный уровень интереса

Предложи MAP на третьей встрече. Если клиент:

Активно участвует и добавляет свои шаги — сделка живая, клиент серьёзен.

Говорит "давайте позже" или игнорирует — сделка мертва. Ты тратишь время на призрака.

Заполняет формально без деталей — клиент вежливо присутствует но не покупает.

#### Помогает Champion продавать внутри

Твой Champion идёт на внутренние встречи без тебя. MAP даёт ему структуру: он показывает руководству не просто "мы смотрим на вендора", а конкретный план с этапами и датами. Это выглядит профессионально и серьёзно.

***

### Структура MAP

MAP состоит из пяти блоков:

#### Блок 1 — Цель и контекст

Зафиксируй одной страницей:

Бизнес-цель клиента: Что клиент хочет достичь и к какому сроку. Пример: "Автоматизировать квалификацию лидов и сократить цикл сделки с 45 до 30 дней до конца Q3 2026"

Боль которую решаем: Словами клиента — не твоими. Пример: "Сейлзы тратят 35% времени на неквалифицированные сделки. Это стоит компании $180,000 в год упущенной выручки"

Критическое событие: Почему именно сейчас и что будет если не решить в срок. Пример: "Новый CEO требует рост ARR на 40% в этом году. Без оптимизации процессов — план нереален"

***

#### Блок 2 — Критерии успешного решения

Запиши что клиент считает успехом. Это должны быть его слова, не твои.

Функциональные критерии: Что продукт должен делать обязательно. Пример:

* Интеграция с Salesforce за 2 недели
* Поддержка русского языка в интерфейсе
* Хранение данных на серверах в КЗ
* Онбординг команды из 15 человек за 1 неделю

Бизнес-критерии: Какой результат должен быть через 90 дней. Пример:

* Сокращение цикла сделки минимум на 20%
* Talk ratio на discovery calls ниже 40%
* Adoption rate команды выше 80%

Критерии выбора вендора: По чему будут сравнивать тебя с конкурентами. Пример:

* Опыт внедрений в финтех Казахстана
* Локальная поддержка на русском языке
* Референсы от компаний схожего размера
* TCO на 3 года

***

#### Блок 3 — Этапы и дедлайны

Это ядро MAP. Таблица совместных действий.

Каждая строка содержит:

* Что делается
* Кто отвечает (со стороны клиента и твоей)
* Дедлайн
* Статус

Пример MAP для 90-дневного цикла:

ЭТАП 1: Техническая оценка (Недели 1-2)

| Действие                                | Клиент      | Вендор  | Дедлайн | Статус |
| --------------------------------------- | ----------- | ------- | ------- | ------ |
| Технический созвон с IT-командой        | IT-директор | Твой SE | 5 апр   |        |
| Предоставить требования по безопасности | CISO        | —       | 7 апр   |        |
| Ответить на технические вопросы         | —           | Твой SE | 10 апр  |        |
| Провести POC на тестовых данных         | IT-команда  | Твой SE | 14 апр  |        |

ЭТАП 2: Бизнес-оценка (Недели 3-4)

| Действие                       | Клиент   | Вендор   | Дедлайн | Статус |
| ------------------------------ | -------- | -------- | ------- | ------ |
| Демо для команды продаж        | Champion | AE       | 17 апр  |        |
| Собрать feedback от end users  | Champion | —        | 21 апр  |        |
| Встреча с Economic Buyer       | CFO      | AE + CEO | 24 апр  |        |
| Предоставить бизнес-кейс с ROI | —        | AE       | 24 апр  |        |

ЭТАП 3: Коммерческое предложение (Недели 5-6)

| Действие                           | Клиент   | Вендор | Дедлайн | Статус |
| ---------------------------------- | -------- | ------ | ------- | ------ |
| Уточнить объём и конфигурацию      | Champion | AE     | 28 апр  |        |
| Направить коммерческое предложение | —        | AE     | 1 мая   |        |
| Юридическое согласование договора  | Legal    | Legal  | 8 мая   |        |
| Финальное утверждение бюджета      | CFO      | —      | 12 мая  |        |

ЭТАП 4: Подписание и старт (Неделя 7-8)

| Действие            | Клиент        | Вендор   | Дедлайн | Статус |
| ------------------- | ------------- | -------- | ------- | ------ |
| Подписание договора | CEO/CFO       | —        | 15 мая  |        |
| Kick-off встреча    | Champion + IT | CSM + AE | 19 мая  |        |
| Начало внедрения    | IT-команда    | CSM      | 20 мая  |        |

***

#### Блок 4 — Участники со стороны клиента

Зафиксируй всех стейкхолдеров с ролями:

| Имя | Должность | Роль в процессе | Контакт |
| --- | --------- | --------------- | ------- |
|     |           | Economic Buyer  |         |
|     |           | Champion        |         |
|     |           | Technical Buyer |         |
|     |           | Legal           |         |
|     |           | End User Lead   |         |

***

#### Блок 5 — Риски и как их митигируем

Запиши открыто что может пойти не так:

Риск 1: Задержка юридического согласования Митигация: подключаем legal обеих сторон на этапе 2, не ждём финального предложения

Риск 2: Смена приоритетов у руководства Митигация: ежемесячная встреча с Economic Buyer для подтверждения приоритета проекта

Риск 3: Техническое несоответствие Митигация: POC на реальных данных клиента на этапе 1 закрывает этот риск полностью

***

### Как презентовать MAP клиенту

Никогда не отправляй MAP по email без созвона. MAP — это разговор, не документ.

Скрипт для введения MAP:

"По нашим разговорам вижу что у вас есть реальная потребность и дедлайн \[Critical Event]. Чтобы мы оба понимали как выглядит путь от сегодня до решения — я подготовил совместный план. Давайте пройдёмся по нему вместе, вы добавите что нужно со своей стороны, и у нас будет общая картина.

Главное: это не обязательство купить. Это просто структура чтобы мы оба не тратили время впустую если что-то не сходится"

***

### Сигналы что MAP работает

Хорошие сигналы:

* Клиент добавляет свои строки в таблицу
* Champion показывает MAP своему руководству
* Клиент сам напоминает о дедлайнах из MAP
* Legal клиента выходит на твой legal досрочно

Плохие сигналы:

* Клиент не открывает документ неделю
* "Давайте сдвинем всё на месяц" без причины
* Champion перестаёт отвечать на вопросы о внутреннем статусе
* Новые стейкхолдеры появляются на финальном этапе которых не было в MAP

***

### MAP в контексте Казахстана

Казахстанские клиенты иногда воспринимают MAP как давление. Особенно в госсекторе где формальные сроки не соблюдаются принципиально.

Адаптация для КЗ рынка:

В госсекторе: называй MAP не "планом сделки" а "дорожной картой проекта". Фокусируй на этапах внедрения, а не на коммерческих шагах. Сроки ставь с буфером 30-50%.

В частном секторе: MAP работает стандартно но адаптируй язык. Вместо "mutual action plan" говори "наш совместный план" или просто "следующие шаги которые мы зафиксировали".

В обоих случаях: первый дедлайн в MAP должен быть маленьким и лёгким для клиента. Например "прислать список требований по безопасности до пятницы". Маленькое выполненное обязательство создаёт momentum для следующих.


---

# 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/mutual-action-plan-map.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.