---
title: "Карта вендора"
url: "https://kzsaleshub.com/framework/vendor-map/"
type: "framework"
category: "Продажи"
language: "ru"
source: "KZSalesHub"
published: "2026-08-11"
last_updated: "2026-09-03"
---

# Карта вендора

**Суть.** Новый вендор в портфеле разбирается не по прайсу и не по презентации, а по шести слоям: какая идея лежит в основе продукта, как устроена архитектура, как вендор зарабатывает через партнёров, какие компетенции требуются, кому это подходит и где решение честно не работает. Слои изучаются в этом порядке — иначе продавец знает названия продуктов и не может объяснить, зачем они.

## Шесть слоёв

| Слой | Главный вопрос | Где искать ответ |
| --- | --- | --- |
| Логика | Какую проблему вендор решает принципиально иначе, чем остальные | История компании и первый продукт: он объясняет всё последующее |
| Архитектура | Что является ядром и как остальное к нему присоединяется | Схема эталонного решения, а не список продуктов |
| Партнёрская модель | На чём зарабатывает партнёр и что защищает его сделку | Условия программы: уровни, регистрация сделок, фонды |
| Компетенции | Какой минимум обязателен, чтобы вообще участвовать | Сертификации и требования уровней программы |
| Сегменты | У кого болит именно то, что вендор лечит лучше всех | Референсные отрасли и типовые сценарии |
| Границы | Где решение проигрывает и что честно сказать заказчику | Сравнения, отзывы инженеров, свой опыт внедрений |

## Как этим пользоваться

**Слой логики важнее остальных.** Почти у каждого вендора есть одна исходная идея: «всё в одной платформе», «лучшее в своём классе», «управление из облака», «открытость и совместимость». Из неё выводятся и архитектура, и типичные возражения, и то, с кем вендор конкурирует. Продавец, который понял идею, отвечает на новый вопрос без подсказки; продавец, который выучил продукты, — нет.

**Архитектуру учат через один сценарий.** Не пытаться охватить весь портфель. Взять один типовой запрос — защита удалённых сотрудников, обновление сети филиалов, консолидация серверов — и пройти его целиком: что ставится, что настраивается, что лицензируется, кто внедряет и сколько это занимает.

**Границы выясняют до первой сделки.** Вопрос инженеру: «в каких случаях вы бы это не предлагали». Ответ на него стоит дороже любого маркетингового материала и снимает половину будущих проблем на внедрении.

## План на неделю

1. День 1: базовый курс вендора и его же обзорный документ по архитектуре
2. День 2: один эталонный проект целиком, с составом спецификации
3. День 3: условия партнёрской программы и правила регистрации сделок
4. День 4: разговор с инженером, который внедрял, — про границы и типичные ошибки
5. День 5: собрать свою таблицу сегментов и три вопроса для первой встречи

## Где ломается

**Учат прайс.** Через месяц он меняется, а понимание не появляется.

**Пропускают слой границ.** Продавец обещает то, что решение не делает, и теряет доверие уже на пилоте.

**Изучают вендора, не изучая сегмент.** Знание продукта без понимания, кому он нужен, даёт хорошие демонстрации и пустую воронку.

## Что отмечать по каждому вендору

| Поле | Зачем |
| --- | --- |
| Роль в портфеле | Основной, дополняющий, нишевый или защитный — от этого зависит объём вложений |
| Уровень авторизации | Что даёт текущий статус и что требуется для следующего |
| Экономика | Скидка, бонусы за результат, стоимость сертификации и стендов |
| Компетенции | Сколько людей сертифицировано, кто заменяет ключевого инженера |
| Пересечения | С какими другими вендорами конкурирует внутри вашего же портфеля |
| Зависимость | Доля выручки: выше трети — стратегический риск |

## Как читать карту

1. Найти дублирование: два вендора закрывают одну задачу, но ресурс делится пополам и ни одна компетенция не доходит до уровня, за который платят.
2. Найти дыры: задача, о которой регулярно спрашивают клиенты, а закрывать нечем.
3. Найти вендоров без движения: статус есть, сделок за год нет — авторизация стоит денег и внимания.
4. Проверить концентрацию: если один вендор даёт больше трети выручки, нужен план на случай изменения его политики.

## Правило пересмотра

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

## Частые вопросы

**Сколько вендоров оптимально**

Столько, сколько команда способна поддерживать компетенцией. Практический ориентир — не больше двух-трёх основных на одно техническое направление.

**Как решать, брать ли нового вендора**

По трём вопросам: есть ли неудовлетворённый спрос у текущих клиентов, кто внутри будет отвечать за компетенцию и что придётся сократить ради этого.

**Что делать с вендором, который не окупается**

Перевести в защитный статус: держать минимальную авторизацию для сделок, где его требуют, и не вкладывать в развитие. Полный выход обычно дороже, чем кажется.

## Связанное

- [Партнёрская программа канала](https://kzsaleshub.com/framework/partner-program/)
- [Профиль идеального клиента](https://kzsaleshub.com/framework/icp/)
- [Ценностное предложение](https://kzsaleshub.com/framework/value-proposition/)

Продавец, который не может объяснить отличие вендора от соседа по рынку, будет продавать ценой. Карта вендора — подготовка к разговору, а не внутренний документ.

---
Источник: https://kzsaleshub.com/framework/vendor-map/