Тендеры на выбор платформ чаще всего проводят крупные компании и корпорации — это требование регламента закупок. Но опыт показывает, что наличие тендера не гарантирует правильного выбора. Иногда компания с командой специалистов и многостраничным ТЗ в итоге не подписывает договор ни с одним вендором, потому что изначально искала не то или не так сформулировала задачу.
Малый и средний бизнес тендеры проводит реже, но тоже сталкивается с теми же проблемами: выбирают по красивой демонстрации, не проверяют критичные интеграции, ориентируются на чужие советы без учёта своей специфики.
enKod участвует в тендерах как поставщик ПО. На основе своего опыта мы подготовили статью для тех, кто хочет выбрать CDP, избежать популярных ошибок, затягивания процесса и без разочарования после подписания договора.
Почему тендеры часто не приводят к результату
Прежде чем говорить о том, как правильно проводить тендер, стоит разобраться, почему они часто заканчиваются ничем.
1. Искали интеграцию с конкретным инструментом, а не лучшее решение. Нередко компании уже используют одну платформу и ищут к ней дополнение — например, SMS-провайдера, который интегрируется с их текущей системой. Это не тендер на CDP, это тендер на узкую интеграцию. Вендоры, которые не являются такой интеграцией, автоматически выбывают, независимо от качества их продукта.
2. Требования не соответствуют возможностям рынка. Корпоративные требования по информационной безопасности — сертификат ISO, двухфакторная аутентификация, тесты на проникновение, разграничение прав по брендам и дивизионам — сужают круг подходящих вендоров до единиц. Если такие требования есть, нужно понимать это заранее и не тратить время на платформы, которые изначально не смогут их закрыть.
3. Клиент не выходит на связь. Вендор готов участвовать, но не получает ответов на вопросы по ТЗ, не может уточнить объём базы для расчёта коммерческого предложения. В итоге либо отказывается от участия, либо подаёт предложение вслепую. Ни тот, ни другой вариант не приводит к хорошему результату.
4. ТЗ написано так, что вендоры не могут на него ответить. Слишком общее или, наоборот, слишком объёмное — оба варианта работают против организатора тендера.
Шаг 1. Внутренняя подготовка: до того, как звать вендоров
Тендер начинается не с запроса коммерческих предложений, а с того, что вы чётко понимаете, что именно ищете, и почему текущее решение перестало подходить.
Если этого понимания нет, любая платформа будет выглядеть одинаково привлекательно на демо. И одинаково разочарует через три месяца после подключения.
Что нужно сформулировать внутри команды до начала тендера:
1. Какие задачи не решает текущий инструмент. Старайтесь формулировать конкретно: не «хочется больше функций», а «не можем сегментировать базу по поведению на сайте, нет возможности запустить триггерный сценарий, данные из CRM и рассылок живут в разных системах и не синхронизируются».
2. Кто будет работать в платформе. Маркетолог без технического опыта или команда с разработчиком? Это влияет на выбор: сложная, но гибкая платформа в руках новичка будет стоять без дела, а слишком простая затормозит рост опытной команды.
3. Какие интеграции критичны. CRM, сайт, мобильное приложение, система лояльности — составьте список. Интеграция, которой нет у вендора, либо потребует дорогой разработки, либо вы откажетесь от неё совсем. Оба варианта плохие.
4. Полный бюджет, а не только стоимость подписки. Учитывайте время разработчика на интеграцию, онбординг команды, возможную миграцию данных.
5. Кто принимает финальное решение. Если это коллегиальное решение, договоритесь заранее, по каким критериям вы будете голосовать. Иначе тендер превратится во внутреннюю политику, а не в объективное сравнение.
Шаг 2. Как правильно составить тендерное задание
Это один из самых недооцененных этапов. Плохое ТЗ затрудняет выбор, а также отпугивает хороших вендоров и привлекает тех, кто готов ответить на что угодно.
Что обязательно должно быть в ТЗ:
Объём базы контактов. Без этой цифры вендор не может рассчитать стоимость. Укажите текущий объём и планируемый рост на ближайший год.
Бизнес-цели и задачи. Не «нужна CDP», а «хотим автоматизировать коммуникацию с клиентами, снизить отток и увеличить повторные покупки». Это помогает вендору понять контекст и предложить подходящее решение.
Функциональные требования — конкретные, через сценарии. Не «нужна сегментация и автоматизация», которые есть у всех, а «нам нужно автоматически отправлять письмо тем, кто добавил товар в корзину и не оформил заказ в течение двух часов, с подстановкой конкретных товаров и ссылкой на корзину».
Список обязательных интеграций. Составьте список систем, с которыми должна работать платформа: CRM, сайт, мобильное приложение, служба доставки, система лояльности. Для каждой интеграции важно понять: есть ли она у вендора в готовом виде или придётся потратить время на интеграцию по API.
Дедлайн подачи предложений и дата принятия решения. Без этого вендоры не понимают, в каком темпе работать и насколько серьёзны ваши намерения.
Критерии оценки. По каким параметрам будет приниматься решение — цена, функционал, опыт в нише, скорость внедрения.
Почему объёмное ТЗ работает против вас
ТЗ на 10 и более листов — это не признак серьёзного подхода, это проблема. Вы тратите время на подготовку документов, а вендоры либо не участвуют в таких тендерах, либо отвечают формально, чтобы сэкономить время. В итоге вы получаете кипу одинаковых ответов, из которых сложно выбрать.
Хорошее ТЗ — это 1–2 страницы с чётко сформулированными требованиями. Остальное прояснится на демо.
Шаблон минимально достаточного ТЗ:
| Раздел | Что указать |
| О компании | Сфера, масштаб, используемые инструменты сейчас |
| Объём базы | Текущий и планируемый через год |
| Бизнес-задачи | 3–5 конкретных целей, которые должна закрыть платформа |
| Функциональные требования | Список сценариев с приоритетом: критично / желательно |
| Интеграции | Список систем, с которыми должна работать платформа |
| Бюджет | Диапазон или «готовы обсудить после КП» |
| Сроки | Дедлайн подачи КП, дата принятия решения |
| Контакт | Кто отвечает на вопросы вендоров |
Шаг 3. Сроки тендера
Затянутый тендер — один из главных рисков. Когда процесс растягивается на полгода, происходит несколько плохих вещей одновременно: команда теряет фокус, вендоры снижают вовлечённость, рынок меняется, а решение в итоге принимается не на основе анализа, а из-за горящего дедлайна.
Оптимальные сроки по этапам:
| Этап | Срок |
| Внутренняя подготовка, формирование ТЗ | 2–3 недели |
| Сбор предложений от вендоров | 2 недели |
| Демо с финалистами (3–5 платформ) | 2–3 недели |
| Тестовый период | 2 недели |
| Финальное решение и согласование договора | 1–2 недели |
| Итого | 9–12 недель |
Три месяца — разумный горизонт для качественного выбора. Если тендер затягивается дольше, скорее всего, проблема не в платформах, а во внутреннем согласовании или в том, что критерии выбора так и не сформулировали или сформулировали нечетко.
Важно: поддерживайте коммуникацию с вендорами.
Если вендор задаёт вопросы по ТЗ, то отвечайте оперативно. Вендор, который не получает ответов, либо готовит КП вслепую, либо снимается с тендера. Оба варианта не в ваших интересах.
Назначьте внутри команды ответственного за коммуникацию с вендорами — одного человека, который отвечает на вопросы в течение одного-двух рабочих дней.
Шаг 4. Как составить список требований, который реально поможет выбрать
Формулируйте требования через конкретные сценарии использования, а не через абстрактные функции.
Не «нужна брошенная корзина», а «нам нужно автоматически отправлять письмо тем, кто добавил товар в корзину и не оформил заказ в течение двух часов — с подстановкой конкретных товаров из корзины и ссылкой на неё».
Такие формулировки делают три вещи: помогают вам самим понять, что именно нужно, позволяют на демо попросить показать именно этот сценарий, а также дают возможность проверить его в тестовом периоде.
Шаблон таблицы требований:
| Сценарий | Приоритет | Примечание |
| Приветственная цепочка из 3 писем после подписки | Критично | Должно запускаться автоматически |
| Брошенная корзина с товарами | Критично | Нужна подстановка конкретных позиций |
| Сегментация по истории покупок | Критично | Данные из 1С через API |
| Web Push уведомления | Желательно | Рассмотрим как дополнительный канал |
| Конструктор Telegram-бота | Не нужно | Канал не используем |
| On-Premise версия | Не нужно | Работаем в облаке |
Шаг 5. Кого звать на тендер
Оптимальное количество платформ для сравнения — три-пять. Меньше трёх — нет выбора. Больше пяти — тендер превращается в работу ради работы.
Где искать кандидатов:
- Отраслевые обзоры и рейтинги российских CDP-платформ — хорошая отправная точка.
- Рекомендации коллег из похожих по размеру и нише компаний ценнее, потому что за ними стоит реальный опыт.
- Тематические сообщества email и CRM-маркетологов — там часто обсуждают реальные кейсы переезда с платформы на платформу.
Красные флаги, которые сразу исключают платформу:
- Серверы за рубежом при работе с персональными данными российских пользователей — риск несоответствия 152-ФЗ.
- Отсутствие внятной поддержки или поддержка только по email с ответом «в течение 3 рабочих дней» — для операционного инструмента это критично.
- Нет ни одного кейса в вашей нише или с компаниями похожего масштаба.
- Непрозрачное ценообразование, где реальная стоимость выясняется только после подписания договора.
Шаг 6. Демо: на что обратить внимание
Демо (демонстрация продукта) — это возможность понять, как платформа решает именно ваши задачи, а не задачи абстрактного клиента из презентации.
Хороший вендор не будет показывать только сильные стороны. Он задаст вопросы о вашем бизнесе, покажет подходящие сценарии и честно скажет, если что-то выходит за рамки возможностей платформы.
На что смотреть во время демо:
- Насколько вендор вникает в вашу задачу. Если менеджер сразу переходит к показу функций, не спросив о бизнесе — это сигнал.
- Могут ли показать конкретный сценарий из вашего списка требований, а не стандартный набор слайдов.
- Как отвечают на неудобные вопросы. Хороший вендор признаёт ограничения — это признак зрелого продукта, а не слабость.
Тестовый период.
После демо попросите доступ к платформе. Возьмите один-два сценария из критичных требований и попробуйте настроить их самостоятельно. Так вы увидите реальную сложность работы с платформой и поймёте, насколько команда справится без постоянной помощи поддержки.
Шаг 7. Как оценить предложения и выбрать платформу
Полная стоимость владения, а не только подписка.
Возьмите горизонт 12 месяцев: подписка + стоимость интеграции + время маркетолога на онбординг + миграция данных. Платформа, которая выглядит дешевле на старте, может оказаться дороже в перспективе года.
Скоринговая таблица для сравнения.
Оцените каждую платформу по каждому требованию по шкале от 0 до 3: 0 — функции нет, 1 — есть с ограничениями, 2 — есть в базовом виде, 3 — реализовано хорошо. Умножьте оценку на вес требования (критично = 3, желательно = 1).
| Требование | Вес | Платформа А | Платформа Б | Платформа В |
| Триггерные сценарии | 3 | 3 (9) | 2 (6) | 3 (9) |
| Интеграция с нашей CRM | 3 | 3 (9) | 1 (3) | 2 (6) |
| Сегментация по поведению | 3 | 2 (6) | 3 (9) | 3 (9) |
| Web Push | 1 | 3 (3) | 0 (0) | 2 (2) |
| Итого | 27 | 18 | 26 |
Что ещё учитывать:
Качество и скорость поддержки, наличие кейсов в вашей нише, соответствие 152-ФЗ и расположение серверов, гибкость ценообразования при росте базы.
Типичные ошибки при выборе CDP
Выбрать самую дешёвую платформу. Дешёвая платформа, с которой придётся переезжать через год, обходится дороже.
Выбрать самую функциональную. Если 80% возможностей не будут использоваться первые два года, то вы переплачиваете за воздух.
Не привлечь IT на этапе оценки интеграций. IT-специалист, который посмотрит на документацию API, сэкономит несколько месяцев боли после подписания договора.
Ориентироваться на чужие кейсы без учёта своей специфики. У другой компании другая база, другие интеграции, другая команда. Берите рекомендации как отправную точку, не как финальный аргумент.
Написать ТЗ на 10+ листов. Объём не равно качество. Хорошее ТЗ — это 1–2 страницы с конкретными требованиями.
Не отвечать на вопросы вендоров. Вендор, который не получает ответов, либо готовит КП вслепую, либо снимается с тендера.
Затянуть тендер. Тендер дольше трёх месяцев — признак того, что внутри не согласованы критерии выбора.
Как enKod участвует в тендерах
Мы понимаем, что выбор CDP — серьёзное решение, и не пытаемся его ускорить давлением.
Демо под ваши задачи. Мы не показываем стандартную презентацию. Пришлите два-три сценария из вашего списка требований, и мы покажем, как они реализуются в enKod.
Тестовый период 14 дней. После демо вы получаете полный доступ к платформе и можете попробовать настроить нужные сценарии самостоятельно.
Честный разговор об ограничениях. Если ваша задача не совпадает с нашими сильными сторонами, мы скажем об этом прямо. Лучше потерять сделку, чем подписать договор с клиентом, которому платформа не подходит.
Кейсы по вашей нише. У нас есть опыт работы с e-commerce, edTech, онлайн-сервисами и event-агентствами. Если нужны примеры из конкретной ниши — запросите, подберём подходящие.
