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

Запрос коммерческого предложения (ЗКП, RFP — Request for Proposal) — это не просто формальный документ для закупки, а инструмент фильтрации рынка. Слишком подробные технические задания на этапе запроса отсекают сильных игроков, которые не хотят тратить часы на изучение специфики, не видя контекста бизнеса. Слишком скудные — привлекают нецелевые предложения с завышенными ценами и рисками. Цель грамотного ЗКП — получить 3–5 качественных ответа от компаний, способных решить задачу, а не просто выполнить список функций.

Главный принцип: запрос должен описывать проблему и ограничения, а не диктовать решение. Исполнитель должен понять, зачем это нужно бизнесу, какие есть жесткие рамки (бюджет, сроки, интеграции, регуляторика) и по каким критериям будет выбран победитель. Всё, что не влияет на выбор поставщика или не является жестким ограничением — лишний балласт.

От чего зависит качество ответов на ЗКП

Рынок B2B-услуг и сложных товаров работает по принципу взаимного отбора. Сильные интеграторы, разработчики, поставщики оборудования и консалтинговые фирмы оценивают заказчика по качеству входящего запроса. Если ЗКП выглядит как «хочу всё, недорого, вчера, по ГОСТу 2005 года, с гарантией результата, которого не бывает» — лучшие просто проигнорируют его. Ответят новички, компании на грани банкротства или те, кто планирует «добить» заказчика доп соглашениями.

Качество входящих предложений определяется тремя факторами:

• Контекст бизнес-задачи. Понимание «зачем» позволяет исполнителю предложить альтернативу, которая дешевле/быстрее/надежнее формального ТЗ.
• Четкость критериев отбора. Когда поставщик знает, что цена весит 30%, а экспертиза в отрасли — 40%, он готовит акцентное предложение, а не шаблон.
• Реалистичность ограничений. Адекватные сроки, бюджетный диапазон (хотя бы форк) и понятные этапы оплаты сигнализируют о зрелости заказчика.

Обязательная структура эффективного ЗКП

Документ не обязательно оформлять как 50-страничный PDF. Достаточно структурированного письма с вложением или страницы в портале закупок. Критично наличие шести блоков:

1. Контекст и бизнес-цель

Два–три абзаца: что делает компания, какая боли или возможность инициировала закупку, какой результат ожидается через 6–12 месяцев после внедрения. Пример: «Мы масштабируем e-commerce с 500 до 5000 заказов в сутки, текущая CMS не справляется с пиками, нужна платформа с автоскейлингом и готовыми интеграциями 1С и OMS».

2. Жесткие ограничения (Must have)

То, без чего предложение не будет рассмотрено. Только фактические параметры:

• Бюджетный диапазон (CAPEX/OPEX) или принцип формирования цены (фикс / T&M / выделенная команда).
• Критические дедлайны (например, «запуск к Черной пятнице 2025»).
• Обязательные интеграции и стандарты обмена данными (API, EDI, протоколы).
• Регуляторные требования (152-ФЗ, PCI DSS, ГОСТ Р 57580, локализация данных).
• География команды / дата-центров, если важно для комплаенса.

3. Функциональные и нефункциональные требования (Must / Should / Could)

Используйте матрицу MoSCoW или простую градацию:

• Must — без этого проект бессмыслен (авторизация по SAML, выгрузка в 1С в реальном времени).
• Should — важно, но есть workaround (персонализация рекомендаций, PWA-версия).
• Could — желательно, если уложимся в бюджет (чат-бот в Telegram, голосовой поиск).
• Won’t — явно исключено из текущей фазы (маркетплейс, мобильное приложение).

Нефункциональные требования (производительность, доступность, безопасность, UX) пишите количественно: «RPS ≥ 2000, 99.9% uptime, время отклика API p95 < 200 мс». Избегайте формулировок «быстрый», «удобный», «современный».

4. Критерии оценки и их веса

Публикуйте матрицу оценки в самом запросе. Это дисциплинирует поставщиков и снимает подозрения в предвзятости. Типовый набор:

Критерий	Вес	Как проверяется
Релевантный кейс / экспертиза в домене	30%	Портфолио, контакты заказчиков, демо
Архитектурное решение / подход к интеграциям	25%	Техническое предложение, схема, ADR
Команда (сеньорность, доступность ключевых ролей)	15%	CV лидов, подтверждение выделения
Тотальная стоимость владения (TCO) на 3 года	20%	Финансовая модель: лицензии, инфраструктура, поддержка
Сроки и план рисков	10%	Гантт-чарт, матрица рисков, митапы

5. Процесс и таймлайн закупки

Укажите конкретные даты (или относительные от публикации):

• Дедлайн вопросов по ЗКП.
• Дата публикации ответов на вопросы (общего FAQ).
• Дедлайн подачи предложений.
• Дата демо / презентаций (если предусмотрено).
• Дата итогового решения и уведомления участников.

Прозрачный календарь снижает риск «пропущенных» дедлайнов и показывает, что у заказчика есть внутренний процесс, а не хаос.

6. Формат ответа и требования к оформлению

Задайте жесткую структуру ответа, чтобы сравнивать предложения «яблоки с яблоками»:

• Исполнительное резюме (1 страница).
• Понимание задачи и предложенное решение (архитектура, стек, паттерны).
• Команда: роли, ФИО ключевых людей, их загрузка на проекте.
• План-график с этапами, контрольными точками, зависимостями от заказчика.
• Коммерческая модель: разбивка по этапам/модулям, условия оплаты, стоимость изменений.
• Риски и митигация.
• Приложения: кейсы, CV, сертификаты, черновик Договора/СЛА.

Ограничьте объем: «Техническая часть — не более 15 страниц, коммерческая — 3 страницы». Это заставляет поставщика писать по сути.

Что считается «лишними требованиями» и почему это вредно

Лишнее — это всё, что не является жестким ограничением и не влияет на выбор победителя, но требует от поставщика времени на анализ, оформление или соблюдение. Типовые примеры:

• Жесткий технологический стек без бизнес-обоснования. «Только Java 17 + Spring Boot, PostgreSQL, Kubernetes на bare metal». Если это не диктуется компетенциями внутренней команды поддержки или лицензией — вы теряете лучших Go/Node/.NET команд, которые сделают быстрее и дешевле.
• Требование сертификатов, не регламентированных законом. ISO 27001 для внутренней CRM, где нет гостайны или платежных данных — просто барьер для входа.
• Фиксированная цена на этапе неопределенности. Просьба назвать точную сумму за «разработку CRM под ключ» без ТЗ — признак незрелости. Профессионалы ответят «от X до Y после discovery» или откажутся.
• Шаблоны заполнения на 50 листов. Таблицы с перечислением каждого класса, метода, поля БД. Это работа аналитика, которую должен оплачивать заказчик (или делать совместно на платной фазе предпроекта).
• Гарантии результата, которых не существует. «Гарантия роста конверсии на 20%», «гарантия нулевых багов», «гарантия прохождения пентеста с первой попытки». В контракте это оформляется через SLA, штрафы, этапную приемку — не через обещания в коммерческом предложении.
• Требование предоставить исходники / IP до подписания контракта. Для оценки архитектуры достаточно схемы, ADR и референсов. Код — предмет перехода прав по акту приемки.
• Множественные обязательные очные встречи до подачи предложения. Один вводный колл (30–60 мин) — норма. Три этапа презентаций «чтобы мы вас познакомились» — неуважение к времени поставщика.

Пошаговый алгоритм подготовки ЗКП

1. Сформулируйте бизнес-метрику успеха. Не «нужен новый сайт», а «снизить CAC на 15% за счет сокращения времени загрузки до 1.5с и внедрения A/B тестов».
2. Соберите внутренних стейкхолдеров. Безопасность, инфраструктура, финансы, юристы, бизнес-заказчик. Согласуйте Must/Should/Could и бюджетный форк заранее, а не в процессе оценки.
3. Напишите черновик ЗКП по структуре выше. ИспользуйтеPlain text / Markdown / Confluence — не Word с трек-чейнджами.
4. Прогоните «тест на разумность». Передайте черновик доверенному внешнему эксперту (не потенциальному поставщику) с вопросом: «Понятно ли, что нужно? Есть ли противоречия? Хотел бы ли ты отвечать?».
5. Опубликуйте и распределите. Целевая рассылка (10–20 компаний по профилю) дает лучший конверсию, чем открытый тендер на портале. При открытом размещении добавьте преквалификацию (краткая анкета) чтобы отсеять случайных.
6. Проведите Q&A сессию. Соберите вопросы, анонимизируйте, опубликуйте ответы единым документом. Это уравнивает информационное поле.
7. Примите предложения и оцените по матрице. Две независимые оценки (бизнес + тех) снижают субъективность. Совещание по согласованию оценок — обязательно.
8. Дайте обратную связь всем участникам. Кратко: почему выбран победитель, в чем слабое место у остальных. Это строит репутацию адекватного заказчика — в следующем разду придут лучшие команды.

Сценарии: когда нужен RFI, RFP или RFQ

Не каждый запрос — это полноценный RFP. Выбор формата экономит время обеим сторонам:

Формат	Когда применять	Что в ответе	Типовые сроки
RFI (Request for Information)	Ранняя стадия: неясен рынок, стек, бюджет, подходы. Нужен обзор ландшафта.	Обзор возможностей, типовые архитектуры, ориентировочные диапазоны цен, кейсы.	1–2 недели
RFP (Request for Proposal)	Проблема понятна, ограничения зафиксированы, нужны конкретные технические и коммерческие предложения.	Детальное решение, план, команда, TCO, SLA, договор.	3–6 недель
RFQ (Request for Quotation)	Товар/услуга стандартизированы (лицензии, «железо», стандартная поддержка, тиражирование готового ПО). Выбор только по цене и SLA.	Прайс, сроки поставки, условия гарантии/поддержки.	3–10 дней

Частая ошибка — запускать RFP там, где нужен RFI (неясные требования) или RFQ (коммодити). RFP на «покупку 50 ноутбуков» — бюрократия. RFQ на «построение платформы данных» — риск получить неработающее решение по низкой цене.

Типичные ошибки заказчиков и их последствия

• Скрытый бюджет «чтобы не завысили». Результат: поставщики кладут заложенные риски + 30–50% сверху, либо предлагают урезанный функционал, который потом дорабатывается за отдельные деньги. Открытый форк (±20%) дает честные расчеты.
• ТЗ как копипаст из интернета / конкурента. Содержит неактуальные модули, противоречивые версии библиотек, требования к легаси, которого нет. Исполнители видят это сразу и либо игнорируют, либо закладывают рефакторинг в цену.
• Отсутствие критериев оценки. Оценка «по чувству» приводит к выбору дешевле/знакомого, а не лучшего. Позже — претензии, срывы сроков, смены команд.
• Требование бесплатного прототипа / PoC / пилота «для оценки». Работа за еду отсекает зрелых игроков. Нормально: оплачиваемый Discovery / Pre-project (1–2 недели, фикс) с артефактами: архитектура, оценка, риски, демо сложного куска.
• Жесткий дедлайн подачи «вчера». Качественное предложение на сложный проект требует 2–3 недель работы пресейла, архитекторов, лидов. Давление сроками = шаблонный ответ.
• Игнорирование вопросов или ответы «читайте ТЗ». Сигнал: заказчик не в теме или не хочет диалога. Поставщики уходят.

Чек-лист перед отправкой ЗКП (самостоятельная проверка)

Пройдитесь по пунктам за 10 минут. Если хотя бы один пункт «нет» — доработайте документ.

• [ ] Бизнес-цель описана одной фразой с метрикой успеха.
• [ ] Жесткие ограничения (бюджет, сроки, регуляторика, интеграции) перечислены явно, без «по возможности».
• [ ] Требования разделены на Must / Should / Could / Won’t.
• [ ] Нефункциональные требования заданы количественно (RPS, latency, uptime, RPO/RTO).
• [ ] Матрица оценки с весами опубликована в запросе.
• [ ] Календарь закупки с датами Q&A, дедлайном, демо, итогом.
• [ ] Формат ответа регламентирован (структура, лимиты страниц, файлы).
• [ ] Убран жесткий стек без обоснования, лишние сертификаты, требование бесплатного PoC.
• [ ] Указан контактный лицо для вопросов (имя, роль, мессенджер/email, время ответа).
• [ ] Предусмотрена обратная связь всем участникам после итогов.

Как оценить полученные предложения без боли

Получили 5–7 ответов. Не читайте их последовательно от обложки до последней страницы. Используйте трек-оценку:

1. Скрининг (15 мин на предложение). Проверьте соответствие Must-критериям: бюджет в форке? сроки реальные? есть релевантный кейс? команда подтверждена? Нет — в архив с причиной.
2. Техническая экспертиза (1–2 часа на сильное предложение). Архитектор / теч-лид оценивает архитектуру, подход к рискам, качество ADR, реалистичность плана. Ставьте баллы по матрице.
3. Коммерческая нормализация. Приведите все цены к TCO на 3 года: лицензии + инфраструктура + поддержка + прогноз изменений (change requests). Часто «дешевое» предложение обходится дороже за счет vendor lock-in или дорогой поддержки.
4. Калибровка оценок. Совещание экспертов: обсудите расхождения в баллах > 2 по 5-балльной шкале. Примите итоговый рейтинг.
5. Финал. Топ-2 на финальные переговоры / демо / уточнение контракта. Остальным — вежливый отказ с 2–3 конкретными пунктами слабости.

FAQ: частые вопросы при составлении ЗКП

Материал носит информационный характер. Для сложных закупок (госконтракты, регулируемые отрасли, высокие финансовые риски) рекомендуется привлекать профильных юристов и закупщиков для адаптации процедуры под требования законодательства и внутренних регламентов.

Нужно ли указывать точный бюджет в ЗКП?

Лучше указать форк (например, «бюджет проекта 8–12 млн руб. без НДС на 12 месяцев») или принцип финансирования (CAPEX лимит, OPEX лимит в месяц). Полное скрытие бюджета повышает спред цен в 2–3 раза и привлекает нецелевые игроки.

Можно ли требовать конкретных сотрудников в команде исполнителя?

Можно и нужно требовать роли и сеньорность (Tech Lead — 5+ лет, опыт миграции на k8s 3+ проекта). Конкретные ФИО на этапе ЗКП — нормально для ключевых ролей (архитектор, ПМ), но с оговоркой «замена только по согласованию заказчика на равносильного специалиста».

Как защитить интеллектуальную собственность на этапе запроса?

Подписывайте NDA (соглашение о неразглашении) перед передачей чувствительных данных (объемы, схемы БД, код легаси). В самом ЗКП не публикуйте коммерческие тайны — только контекст, достаточный для понимания масштаба.

Что делать, если пришел только один ответ?

Причины: слишком узкие требования, нереалистичный бюджет/сроки, закрытый рынок (монополия), плохая рассылка. Варианты: пересмотреть Must-лист, увеличить форк бюджета, продлить дедлайн, провести прямые переговоры с единственным игроком (с фиксацией обоснования цены), либо перейти на RFI для изучения рынка.

Стоит ли просить референзы (контакты бывших заказчиков) в ЗКП?

Да, но с оговоркой: «Контакты 2–3 заказчиков за последние 3 года для референз-звонка по согласованию». Не требуйте писем-рекомендаций в приложении — они часто формальные. Живой звонок 15 минут дает больше правды.

Главный принцип и следующий шаг

Качественный ЗКП — это уважение к времени профессионалов. Он говорит: «Мы знаем, чего хотим, понимаем свои ограничения, готовы платить за экспертизу и честно оценим предложения». Такой запрос собирает лучшие команды рынка.

Следующий шаг: возьмите текущий черновик запроса (или напишите новый по структуре выше) и прогоните его по чек-листу из 10 пунктов. Уберите всё, что не прошло фильтр «жесткое ограничение или критерий выбора». Добавьте матрицу оценки с весами. Расшлифуйте календарь. После этого — отправляйте целевой длинный список поставщиков. Качество входящих предложений вырастет заметно.