RFP на CRM: структура, критерии, scoring-модель выбора подрядчика

В прошлом году к нам обратилась крупная торговая компания из Алматы. Они уже полгода выбирали CRM-систему: посмотрели демо десяти вендоров, провели бесконечные созвоны, собрали гору коммерческих предложений. И всё равно не могли принять решение. Почему? Потому что каждый вендор показывал своё решение под своим углом. Сравнивать было невозможно — как сравнить яблоки с апельсинами и грушами одновременно.

Мы помогли им составить RFP — Request for Proposal, структурированный запрос предложений. Через три недели у них была чёткая таблица сравнения с баллами, и решение приняли за один день. Экономия времени — минимум два месяца. Экономия нервов — бесценна.

RFP — это не бюрократия и не формальность для тендеров госзакупок. Это рабочий инструмент, который превращает хаотичный выбор в системный процесс. В этой статье расскажу, как составить RFP на CRM-систему или подрядчика по внедрению, какие критерии включить и как построить scoring-модель для объективного сравнения.

RFI, RFP, RFQ — три буквы, разные задачи

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

RFI (Request for Information) — запрос информации. Используется на ранней стадии, когда вы ещё изучаете рынок. «Расскажите о себе, что вы умеете, с кем работали». Цель — составить длинный список потенциальных вендоров и понять, какие решения вообще существуют.

RFP (Request for Proposal) — запрос предложений. Это уже серьёзно. Вы знаете свои требования и просите вендоров предложить конкретное решение под ваши задачи. «Вот наши потребности, покажите, как вы их закроете, сколько это будет стоить и за какое время».

RFQ (Request for Quote) — запрос цены. Самый простой формат. Требования уже определены до мелочей, нужна только стоимость. «Вот ТЗ, дайте цену».

Для выбора CRM-системы обычно нужен именно RFP. RFI полезен, если вы совсем не ориентируетесь на рынке — тогда начните с него, чтобы сузить список до 5-7 вендоров, а затем отправьте им полноценный RFP. RFQ для CRM используется редко — слишком много переменных, чтобы дать точную цену без понимания деталей.

Почему без RFP выбор превращается в лотерею

Кажется, что можно просто посмотреть несколько демо и выбрать понравившуюся систему. На практике это работает плохо, и вот почему.

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

Проблема 2: Невозможно сравнивать. Один вендор прислал презентацию на 50 слайдов, другой — таблицу в Excel, третий — письмо на две страницы. Как их сравнить? RFP заставляет всех отвечать в одном формате на одни и те же вопросы.

Проблема 3: Скрытые расходы. «Внедрение — 500 тысяч тенге». А обучение входит? А миграция данных? А поддержка первый год? Без структурированного запроса вы узнаете о дополнительных расходах, когда уже подписали договор.

Проблема 4: Эмоциональные решения. Харизматичный продавец, красивая презентация, обещания «всё сделаем» — и вы выбираете не лучшее решение, а лучшего продавца. RFP переводит решение в плоскость фактов и цифр.

Пять ошибок, которые убивают RFP

За годы работы мы видели сотни RFP — хороших и не очень. Вот ошибки, которые встречаются чаще всего и которых стоит избегать.

Ошибка 1: Копипаст чужого RFP

Скачали шаблон из интернета, поменяли название компании, отправили. Проблема в том, что шаблон написан для другого бизнеса, другой отрасли, другой страны. Половина требований вам не нужна, а ваших специфических потребностей там нет.

Используйте шаблоны как отправную точку, но адаптируйте под себя. Уберите лишнее, добавьте важное для вашего бизнеса.

Ошибка 2: Размытые требования

«Система должна быть удобной». «Интерфейс должен быть современным». «Должна быть хорошая аналитика». Что это значит? Каждый вендор скажет, что у него именно так.

Формулируйте измеримо: «Создание новой сделки — не более 3 кликов». «Мобильное приложение для iOS и Android». «Отчёт по воронке с возможностью фильтрации по менеджеру, источнику, периоду».

Ошибка 3: Только про функции, ничего про внедрение

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

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

Ошибка 4: Нереалистичные сроки

«Ответ нужен через три дня». За три дня серьёзный вендор не сможет подготовить качественное предложение. Вы получите либо шаблонные отписки, либо отказы от участия.

Давайте минимум две недели на ответ. Для сложных проектов — три-четыре. Качество предложений окупит ожидание.

Ошибка 5: Секретный бюджет

Компании часто скрывают бюджет, надеясь получить «честные» цены. В результате получают предложения от 500 тысяч до 50 миллионов тенге — и тратят время на анализ заведомо неподходящих вариантов.

Укажите хотя бы диапазон или порядок величины. Это поможет вендорам предложить адекватное решение, а не стрелять вслепую.

Структура RFP: семь обязательных разделов

Хороший RFP — это баланс между полнотой и читаемостью. Слишком короткий — вендоры не поймут, что вам нужно. Слишком длинный — никто не дочитает до конца. Оптимально: 10-15 страниц основного текста плюс приложения.

1. О компании и контекст проекта

Кто вы, чем занимаетесь, почему ищете CRM. Это не формальность — понимание вашего бизнеса позволяет вендору предложить релевантное решение.

Что включить: отрасль и бизнес-модель, размер компании (сотрудники, обороты), текущие системы и их проблемы, цели проекта (что хотите улучшить), масштаб (количество пользователей, филиалов).

Пример: «ТОО „Астана-Логистик" — транспортная компания, 8 филиалов по Казахстану, 200 сотрудников. Сейчас используем Excel и 1С:Управление торговлей. Цель: сократить время обработки заявки с 4 часов до 30 минут, увеличить повторные продажи на 25%. Пользователей CRM — 45 человек».

2. Функциональные требования

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

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

3. Технические требования

Ограничения и предпочтения по технологиям — то, что часто забывают, а потом система не встаёт в инфраструктуру.

Что включить: модель развёртывания (облако, on-premise, гибрид), требуемые интеграции (1С, телефония, сайт, мессенджеры), безопасность (хранение данных в РК, соответствие законодательству), производительность (нагрузка, время отклика), доступность (SLA, бэкапы).

4. Требования к внедрению

Как проект должен быть выполнен — этапы, сроки, ответственность.

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

5. Требования к вендору

Квалификация исполнителя не менее важна, чем качество продукта.

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

6. Коммерческие условия

Как должно быть структурировано ценовое предложение — чтобы можно было сравнивать.

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

7. Процедура отбора

Прозрачность процесса повышает качество ответов.

Что включить: сроки (дедлайн подачи, дата объявления результатов), критерии оценки (по каким параметрам сравниваете), этапы отбора (письменный ответ → шорт-лист → демо → финал), контакты для вопросов и формат Q&A, требования к формату ответа.

Scoring-модель: как объективно сравнить вендоров

RFP собран, ответы получены. Теперь самое сложное — выбрать. Если у вас 5-7 предложений, субъективные ощущения не помогут. Нужна система баллов.

Принцип простой: каждому критерию присваиваете вес (важность), каждому ответу — балл. Итог = сумма (вес × балл) по всем критериям. Побеждает тот, у кого выше итоговый балл.

Веса — не догма. Настройте их под свои приоритеты. Если бюджет ограничен — увеличьте вес стоимости. Если критична интеграция с 1С — добавьте вес технологиям.

Шкала оценки

Используйте единую шкалу для всех критериев. Рекомендую пятибалльную — достаточно детальную, но не перегруженную.

Пример сравнительной таблицы

Вот как выглядит финальное сравнение трёх вендоров. В скобках — взвешенный балл (оценка × вес).

В этом примере Вендор Б лидирует, несмотря на более высокую стоимость. Его преимущество в функциональности и опыте перевешивает ценовую разницу. Это и есть ценность scoring-модели: она показывает, что дешевле — не значит лучше.

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

После scoring: финальные шаги

Scoring — не финальное решение, а инструмент для формирования шорт-листа. Топ-2-3 вендора проходят в следующий этап.

Демонстрация на ваших данных

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

Референсные звонки

Попросите контакты 2-3 текущих клиентов вендора из вашей или смежной отрасли. Позвоните и спросите: что не понравилось? какие проблемы были при внедрении? пошли бы снова к этому подрядчику? Честные отзывы от реальных клиентов — бесценны.

Пилотный проект

Для крупных внедрений имеет смысл провести пилот на ограниченной группе: один отдел, один филиал. Это снижает риски и даёт реальные данные для финального решения. Подробнее о пилотах — в статье Внедрение CRM с нуля: план на 90 дней.

Переговоры

После выбора финалиста — торгуйтесь. Обсудите скидки за годовую подписку, бесплатные часы доработок, расширенную поддержку на первый год. Вендор, прошедший через RFP, мотивирован закрыть сделку.

Что учесть в RFP для казахстанского бизнеса

Если вы работаете в Казахстане, есть несколько специфических моментов, которые стоит включить в RFP.

Локализация данных

Если вы храните персональные данные клиентов, уточните у вендора, где физически расположены серверы. Законодательство РК может требовать хранения данных на территории Казахстана. Для некоторых отраслей это критично.

Интеграция с локальными сервисами

1С, Kaspi, Halyk Bank, местные провайдеры телефонии — проверьте, есть ли у вендора готовые интеграции. Кастомная разработка коннекторов может стоить дороже самой CRM. Подробнее об интеграциях: Интеграция Kaspi Магазин с CRM.

Валютные риски

Многие международные вендоры номинируют цены в долларах. Уточните возможность фиксации курса или оплаты в тенге. Колебания курса на 10-15% могут серьёзно повлиять на бюджет проекта.

Поддержка на русском языке

Даже если интерфейс переведён, техническая поддержка может быть только на английском. Уточните язык коммуникации и часовой пояс команды поддержки — разница в 8 часов превращает любую проблему в двухдневный квест.

RFP окупается уже на этапе сравнения

Да, на хороший RFP уйдёт несколько дней. Иногда — неделя-две, если требования сложные и нужно согласовать их с разными отделами. Кажется, что это долго. Но вспомните торговую компанию из начала статьи — они потратили полгода на хаотичный выбор. С RFP управились бы за месяц.

RFP не обязан быть идеальным. Ошибки можно уточнить в процессе Q&A с вендорами. Пропущенные требования — добавить. Главное — начать: отправить «80%-ный» документ сегодня полезнее, чем вылизывать идеальный ещё месяц.

Напоследок — простой тест. Если после получения ответов вы можете свести всех вендоров в одну таблицу и сравнить по одинаковым критериям — RFP сработал. Если каждый ответ приходится «переводить» и додумывать — значит, что-то пошло не так ещё на этапе формулировки требований.