CRM/CDP для крупного ритейла: чек-лист тендера и демо

Актуальность проверена в сентябре 2026 года

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

До приглашения вендоров опишите процессы, карту систем, нужные бизнес-сценарии и целевые показатели. Вместо «нужна омниканальность» напишите: «Покупка на кассе должна попасть в профиль клиента, а через два часа — запустить сообщение в приложении, если он дал согласие на коммуникацию».

Ниже я разбираю проверки, которые отличают рабочую платформу от убедительной презентации. Маршрут выбора — на схеме ниже; чек-лист относится к этапам тендера и демо.

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

У вендора выясните:

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

Для многих ритейлеров 1С остаётся центральной учётной системой — логотипа 1С на слайде недостаточно. Уточните:

На демо заказ с сайта должен уйти в 1С, а новый статус — вернуться в CRM. Попросите показать очередь повторной отправки и журнал ошибок. В кейсе ELIS платформа RetailCRM стала хабом между сайтами, 1С, оплатой, доставкой и коммуникациями.

Проверьте:

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

Оператору нужны история покупок, обращений и сообщений в одном интерфейсе. Иначе каждый разговор начинается со сбора контекста.

В тендерные вопросы включите: поддержку телефонии, email, чатов и нужных мессенджеров; правила привязки обращения к клиенту; маршрутизацию между очередями; состав данных в карточке оператора. Сразу проверьте, можно ли скрыть персональные данные, финансовую информацию и группы заказов от сотрудников, которым они не нужны.

Готовых модулей хватает не всегда: у крупного ритейлера почти наверняка есть система под кастомный коннектор. Фраза «есть открытый API» ещё ничего не говорит о платформе. Запросите документацию по методам, webhooks, лимитам и авторизации, тестовую среду, журнал ошибок и правила версионирования. В договоре определите, кто восстанавливает кастомный коннектор после обновления и как вендор предупреждает о несовместимых изменениях.

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

Кейс KOLESATYT показывает, каким бывает пик: в распродажу 11.11 2020 года через маркетплейс приходили десятки заказов в минуту, и система на базе RetailCRM выдержала всплеск. Это один кейс, а не ориентир для вашей нагрузки. Отказ вендора обсуждать методику теста или фиксировать целевые показатели — основание исключить его из короткого списка.

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

Два показателя согласуйте особо: RPO определяет допустимую потерю данных, RTO — срок восстановления сервиса. Ответ «аптайм 99,9%» без методики измерения, исключений и ответственности — это не SLA.

С 1 июля 2025 года действует новая редакция части 5 статьи 18 закона № 152-ФЗ. При сборе персональных данных граждан РФ их запись, систематизация, накопление, хранение, уточнение и извлечение в базах за пределами России не допускаются, кроме предусмотренных законом исключений. Последующая трансграничная передача регулируется отдельно, поэтому юридическую схему проекта нужно оценивать целиком.

Запросите:

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

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

Проверьте:

В документации RetailCRM описаны двухфакторная аутентификация, ограничения доступа по IP, группы пользователей, журнал действий и журнал доступов. Сроки хранения записей у журналов различаются — сверьте их с внутренними требованиями.

Передайте всем вендорам один и тот же набор заданий заранее. На встрече попросите:

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

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

В кейсе Silver spoon клиентскую базу и рассылки перенесли из Mindbox в RetailCRM за два рабочих дня, а рассылка на Чёрную пятницу 2025 года принесла 415 130 ₽ выручки. Весь переход с согласованиями занял около четырёх недель, а заказы интернет-магазина компания вела в RetailCRM с 2020 года. Кейс подтверждает, что быстрый перенос возможен при таких условиях, но не задаёт норматив для любого проекта.

Цена лицензии — одна строка бюджета. В TCO включите лицензии по числу пользователей, объём базы и хранилища, каналы коммуникаций, внедрение, миграцию, интеграции, поддержку, доработки, услуги интегратора, обучение и мощности для on-premise. Запросите расчёт на три года с одинаковыми предпосылками роста и выделите расходы, которые не зафиксированы в договоре. Финалистов сравнивайте по этой сумме, а не по цене лицензии.

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

Шкала: 0 — не показано, 3 — показано на ваших данных без оговорок. Критичным группам назначьте больший вес, но не смешивайте вес и отсечение.

Среди платформ, которые можно прогнать по этой карточке, — RetailCRM для крупного бизнеса. Enterprise-версия разворачивается в собственной инфраструктуре и рассчитана на проекты с широким IT-контуром.

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

Обычно достаточно трёх–пяти платформ. Меньшее число сужает выбор, большее увеличивает объём встреч и сопоставления ответов, не улучшая решение.

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

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

Можно, если пилот проверяет будущую архитектуру, а не создаёт временный изолированный контур. Заранее определите границы пилота, данные, интеграции, метрики успеха и условия масштабирования.