Ключевые выводы
- RFP для CDP-проекта — это не формальность для тендерной комиссии, а инструмент структурированного выбора подрядчика по 12+ критериям
- Качественный RFP сокращает разброс цен в коммерческих предложениях с 200% до 30-40%, упрощая сравнение
- Минимально необходимая структура — 9 разделов: контекст, цели, scope, требования к платформе и подрядчику, формат ответа, критерии оценки, сроки, контакты
- Самая частая ошибка — давать подрядчику слишком много свободы в формулировке решения. Жёсткая структура ответа делает КП сравнимыми
- Сроки тендера должны включать buffer на вопросы и уточнения от подрядчиков — иначе финальные КП готовятся «по интуиции»
RFP для CDP-проекта что включить — вопрос, который встаёт у CIO перед запуском тендера на 20-40 млн ₽. От качества документа зависит, насколько сравнимы будут коммерческие предложения, насколько подрядчик поймёт ваш контекст и насколько финальный выбор будет рациональным.
Эта статья — структурированный шаблон RFP для CDP-проекта со всеми разделами и пояснениями, что куда писать. На основе 30+ проведённых тендеров в разных отраслях. Без юридических заморочек — с практическим фокусом на сравнимость предложений.
Почему важна структура RFP
Если оставить подрядчикам полную свободу в формулировке КП, вы получите 5 документов в разных стилях с разной структурой и разной детализацией. Сравнить их объективно невозможно: один сделал акцент на технике, другой — на методологии, третий — на цене.
Хорошо структурированный RFP с обязательными разделами в ответе:
- Сокращает разброс цен с 200% до 30-40% (потому что все понимают одинаковый scope)
- Делает каждый раздел сравнимым по горизонтали
- Снижает время оценки КП с 2 недель до 3-5 дней
- Уменьшает количество уточняющих вопросов от подрядчиков на 50-70%
Раздел 1: Контекст бизнеса
Опишите вашу компанию настолько подробно, чтобы подрядчик мог оценить специфику без дополнительных встреч:
- Отрасль и подсегмент (например: «retail, fashion mid-market»)
- Размер бизнеса: годовая выручка, количество сотрудников, география
- Существующая клиентская база: количество профилей, источники, каналы коммуникаций
- Текущий tech-stack: 1С/SAP/Oracle, e-com платформа, CRM, BI
- Маркетинговая активность: количество кампаний в месяц, сегментация, частота
- Болевые точки: что именно не работает в текущем процессе
Этот раздел — не маркетинговая страница «о нас». Это контекст, по которому подрядчик понимает специфику. 1-2 страницы достаточно.
Раздел 2: Цели и метрики проекта
Конкретные измеримые цели, на которые подрядчик должен ориентироваться:
- Бизнес-цели: прирост revenue от персонализации (целевой %), снижение оттока (целевой %), снижение CAC
- Технические цели: единый профиль клиента, real-time сегментация, omnichannel-доставка
- Compliance-цели: 152-ФЗ соответствие, готовность к проверке Роскомнадзора
- Операционные цели: сокращение времени на запуск кампании с N дней до M часов
- Сроки достижения: по каждой цели — целевой квартал/год
Чёткие цели позволяют подрядчику сформировать сценарии работ и привязать к ним бюджет. Без целей КП превращается в «делаем, что попросите, по часам».
Раздел 3: Scope проекта
Самый важный раздел. От его детализации зависит, насколько сравнимы будут предложения. Минимум 5 подразделов:
3.1. Источники данных
Список всех систем, из которых нужно собирать данные о клиентах. По каждой:
- Название и версия (1С УНФ 8.3, Bitrix 24, Adobe Commerce)
- Способ интеграции (REST API, ODBC, файловая выгрузка)
- Объём данных (миллионы строк, частота обновления)
- Критичность (требует real-time или batch достаточно)
3.2. Каналы коммуникаций
Список всех каналов, через которые CDP будет отправлять коммуникации:
- Email (с указанием SMTP-провайдера)
- Push (iOS, Android, Web)
- SMS (с указанием SMS-провайдера)
- Мессенджеры (Telegram, WhatsApp, ВКонтакте)
- In-app (мобильное приложение)
- Личный кабинет на сайте
3.3. Сегментация
Описание базовых сегментов, которые должны быть готовы к моменту запуска:
- Демографические (возраст, пол, география)
- Поведенческие (RFM, активность, частота покупок)
- Транзакционные (сумма покупок, средний чек)
- Программа лояльности (статусы, баллы)
- Бизнес-специфичные (для retail — категории товаров; для banking — продукты)
3.4. Сценарии коммуникаций
Список целевых сценариев на запуск (обычно 10-20 на старте):
- Welcome-цепочка для новых клиентов
- Брошенная корзина
- Реактивация неактивных клиентов
- Поздравление с днём рождения
- Промо-акции по сегментам
- Транзакционные уведомления
3.5. Аналитика и отчётность
Какие отчёты должны быть готовы к моменту запуска:
- Дашборд активности кампаний (open rate, CTR, конверсия)
- Аналитика сегментов (динамика численности)
- Отчёт по revenue от каждого канала
- Custom-отчёты под бизнес-процессы
Раздел 4: Требования к платформе
Если выбор платформы ещё не сделан — это требования к решению, которое подрядчик должен предложить:
- Модель развёртывания: SaaS / on-prem / hybrid
- Compliance: 152-ФЗ, банковский ЦБ, реестр отечественного ПО
- Объём данных: текущий и целевой через 3 года
- SLA: доступность 99.95%, RTO 30 мин, RPO 5 мин
- Производительность: поддержка пиковых нагрузок (high-season)
- Интеграционные возможности: готовые коннекторы, API, webhook'и
- Безопасность: RBAC, audit trail, шифрование, MFA
Если платформа уже выбрана — пишите её прямо: «требуется внедрение Mindbox/Altcraft/StackFortCDP». Это сужает круг подрядчиков и упрощает сравнение.
Раздел 5: Требования к подрядчику
Минимальные критерии допуска к тендеру:
- Опыт работы: минимум 5 лет, минимум 100 млн ₽ годовой выручки
- Опыт в платформе: минимум 5 внедрений (с подтверждающими кейсами)
- Опыт в отрасли: минимум 3 проекта в схожей отрасли
- Команда: минимум PM, аналитик, 2 разработчика, DevOps, тестировщик
- Compliance-сертификации (если применимо): ФСТЭК, реестр отечественного ПО
- Финансовая устойчивость: отсутствие судов, банкротств, длительных просрочек
Раздел 6: Формат ответа (КП)
Жёстко зафиксированная структура коммерческого предложения, без отклонений:
- Резюме (1 страница)
- Понимание задачи (как подрядчик прочитал ваш контекст)
- Архитектура решения (с диаграммой)
- Методология проекта (фазы, артефакты, контрольные точки)
- Команда (с фамилиями и опытом каждого члена)
- График работ (по неделям или месяцам)
- Бюджет (с разбивкой по фазам и статьям)
- Гарантии после запуска
- Договорные условия
- Портфолио (3-5 кейсов с цифрами)
- Контакты для проверки клиентов
Раздел 7: Критерии оценки
Веса по каждому критерию — для прозрачности оценки:
| Критерий | Вес |
|---|---|
| Понимание задачи | 15% |
| Качество предложенной архитектуры | 15% |
| Опыт в отрасли | 10% |
| Опыт в платформе | 10% |
| Состав команды | 10% |
| Методология проекта | 10% |
| Цена | 15% |
| Сроки | 5% |
| Договорные условия | 5% |
| Гарантии | 5% |
Цена занимает 15-20% от общей оценки — этого достаточно, чтобы избежать выбора в пользу демпингующего подрядчика без компетенций.
Раздел 8: Сроки тендера
Реалистичный график:
- Неделя 1-2: рассылка RFP подрядчикам, ответы на первичные вопросы
- Неделя 3: сбор уточняющих вопросов от всех подрядчиков, опубликование общих ответов
- Неделя 4-5: подготовка коммерческих предложений
- Неделя 6: приём КП, первичная проверка комплектности
- Неделя 7-8: оценка матрицы, выбор финалистов (топ-2)
- Неделя 9: защита финалистов, презентация решения
- Неделя 10: финальное решение, согласование договора
Сжатие графика до 4-5 недель приводит к выбору «по первому впечатлению». Растяжение свыше 12 недель — теряется фокус и подрядчики уходят на другие проекты.
Раздел 9: Контакты и формат коммуникации
- Имя и роль контактного лица для технических вопросов
- Имя и роль контактного лица для коммерческих вопросов
- Канал коммуникации (email, телефон, мессенджер)
- Время ответов на вопросы (например, в рабочие дни до 17:00, ответ в течение 24 часов)
- Формат подачи КП (PDF + Excel со сметой, объём, способ передачи)
Что НЕ нужно включать в RFP
Несколько вещей, которые часто включают, но они вредят качеству ответов:
- Готовое техническое задание. Если ТЗ уже написано, подрядчик просто оценит часы — а вы не получите взгляда на архитектуру со стороны. ТЗ — это результат начала работы по выбранному подрядчику, а не вход в RFP.
- Жёсткие ценовые потолки. Это приводит к тому, что подрядчики режут scope или подсовывают джунов. Лучше указать диапазон бюджета (или не указывать вовсе) и оценивать по value-for-money.
- Слишком много уточняющих вопросов в формате ответа. Если в RFP есть 20+ вопросов с обязательными ответами, подрядчик тратит больше времени на формальную сторону, чем на содержательную. 5-7 ключевых — оптимум.
FAQ о RFP для CDP-проекта
Кому отправлять RFP — широкому рынку или приглашённым?
Лучше — приглашённым 4-6 подрядчикам, которые прошли pre-screening. Широкая рассылка приводит к 20+ КП низкого качества, и оценка занимает несколько недель. Приглашённый формат даёт 4-6 проработанных предложений за 4-5 недель и более высокое среднее качество.
Можно ли проводить тендер без RFP?
Можно для проектов до 5 млн ₽, где детализация не критична. Для проектов 10+ млн ₽ — это рискованно: вы не сможете объяснить совету директоров обоснованность выбора, и при инцидентах подрядчик легко перенесёт ответственность на «недостаточно чётко поставленную задачу».
Как часто обновлять RFP-шаблон?
Раз в 1-2 года, или при существенном изменении регуляторной среды. В 2026 году ключевые обновления связаны с ужесточением 152-ФЗ — соответствующие требования должны быть отражены в RFP. Также добавляются вопросы по реестру отечественного ПО и сертификации ФСТЭК для проектов в гос-сегменте.
Стоит ли указывать в RFP ожидаемый бюджет?
Если ваша цель — получить креативные решения и подрядчики могут предложить разные архитектуры — не указывать. Если цель — отобрать только тех, кто укладывается в ваш бюджет — указать диапазон. Конкретное число (например, «бюджет 22 млн ₽») приводит к тому, что все КП будут именно на 21-23 млн ₽, что искажает картину.
Можно ли отправлять разным подрядчикам разные версии RFP?
Не рекомендуется. Если по результатам тендера один из проигравших подрядчиков узнает, что у него был неполный или искажённый RFP, это может стать поводом для жалобы и судебных разбирательств. Все подрядчики должны получить одинаковый документ. Если есть NDA-материалы — они передаются после подписания соглашения о конфиденциальности по одинаковой процедуре для всех участников.
Что в итоге
Качественно подготовленный RFP для CDP-проекта что включить — вопрос, ответ на который определяет успех тендера. 9 ключевых разделов (контекст, цели, scope, требования, формат ответа, критерии, сроки, контакты) дают подрядчикам полное понимание задачи и делают их КП сравнимыми.
Время на подготовку RFP — обычно 2-3 недели работы внутренней команды или 1.5-2 млн ₽ работы консультанта. Эта инвестиция окупается за счёт качественного выбора подрядчика и значительной экономии на последующих переделках.
Готовы передать рабочий шаблон RFP в формате Word/Google Docs с пометками «что писать в каждом разделе». Свяжитесь — отправим без условий.
Дополнение: типичные ошибки в формулировках scope
Из опыта сопровождения 30+ тендеров — топ-5 ошибок в разделе scope, которые приводят к разногласиям с подрядчиком после подписания договора:
- «Подключить все источники данных». Не указано, какие именно. На пресейле подрядчик закладывает 3-4, а в реальности их 8-10. На полпути проекта возникает спор — это уже scope или допработы.
- «Реализовать персонализацию». Под этим словом разные стороны понимают разное: один — динамический контент в email; другой — рекомендательную систему на ML; третий — сегментированные офферы. Нужно конкретизировать.
- «Соответствие 152-ФЗ». Подрядчик отчитается «соответствует», но при первой проверке Роскомнадзора окажется, что не реализован, например, отзыв согласия. Нужно перечислять конкретные требования: фиксация согласий, отзыв, аудит-след.
- «Real-time сегментация». Что значит «real-time»: 100 мс, 1 секунда, 10 секунд? Разница между этими значениями — порядок цены и сложности. Указывайте конкретное SLA.
- «Интеграция с CRM». Какая именно CRM (1С, Bitrix, Salesforce), какие сущности, в какую сторону, с какой частотой. Без этого разговор «интегрировали» — у вас и подрядчика отличается на 2-3 человеко-месяца.
Точная формулировка scope — самая дорогая часть документа. Час, потраченный на детализацию scope, экономит неделю переговоров после подписания договора.
Если коротко обобщить, RFP для CDP проекта что включить — это вопрос дисциплины: чем строже структура и чем чётче scope, тем дешевле и быстрее проходит весь тендер.