CRM в банке: почему 7 из 10 внедрений не дают результата — и как не попасть в это число

Почти в каждом банке есть CRM. Проблема в другом: в большинстве случаев она не управляет клиентским опытом — она просто существует.

Оператор открывает пять-семь окон на один звонок. Клиент заново объясняет свою ситуацию каждому следующему сотруднику. Корпоративная сделка живет в почте менеджера, а не в системе. И когда что-то надо изменить — выясняется, что даже небольшая правка тянет за собой квартал разработки.

Это не проблема конкретной платформы. Это проблема подхода.

Ниже разбор того, как банковская CRM работает на практике, где проекты теряют деньги и время, и что реально стоит проверить, прежде чем начинать внедрение или миграцию.

Главная ошибка при выборе CRM— смотреть как на систему учета лидов и контактов. В банке этого недостаточно уже на старте, потому что у банковской CRM три разных контура, которые должны работать вместе.

Операционная CRM — это то, в чем работают операторы и менеджеры ежедневно: единая карточка клиента, история взаимодействий, обращения, заявки, маршруты обслуживания, контроль SLA.

Аналитическая CRM — сегментация, скоринг, оценка склонности к оттоку, кросс-продажи. Здесь банк отвечает на вопрос: кому, когда и что предложить.

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

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

Особенность №1: Физлица и юрлица — это не два сегмента, а две разные логики
Для розничного клиента критичны скорость, автоматизация, омниканальность и масштаб. Для корпоративного длинный цикл сделки, несколько ЛПР, группа компаний, документооборот, много согласований.
Если система не поддерживает обе модели в едином контуре, банк начнет «дошивать» недостающую логику вручную. Именно так и появляются таблицы в Excel рядом с CRM стоимостью в несколько миллионов рублей.

Особенность №2: Регуляторика — часть архитектуры, не пожелание
В банковском контуре CRM проектируется не только под удобство, но и под обязательства. Это журналирование действий, контроль доступа, аудит изменений, соответствие требованиям по обработке персональных данных (ФЗ-152, требования ЦБ к КИИ), управляемость изменений, локализация данных и инфраструктуры.
Когда процессы меняются под требования регулятора, а в банковском секторе это происходит регулярно, то CRM должна поддерживать эти изменения, а не становиться тормозом.

Один из самых дорогих разрывов в банковской операционке — когда фронт-офис и кредитный конвейер живут как отдельные системы без двусторонней связи.

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

Конкретный пример. В одном из розничных банков с потоком около 4 000 обращений в день оператор тратил порядка 40–50 секунд только на сбор контекста по клиенту: открыть карточку, проверить статус продукта, найти последние обращения, посмотреть комментарии по незавершенной заявке. После того как карточка клиента была связана с активными процессами в едином интерфейсе, это время сократилось до 8–12 секунд. На масштабе нескольких тысяч обращений это эквивалентно 1,5–2 дополнительным ставкам в смене — только за счет устранения переключений.

• Как должна работать связка на практике

Рабочая модель выглядит так: менеджер открывает карточку клиента и сразу видит продукты, историю, предыдущие заявки и их статусы. На основе контакта создается новая заявка, которая автоматически уходит в кредитный конвейер. Конвейер выполняет проверки — и статусы, замечания по комплектности документов, результаты скоринга возвращаются обратно в CRM. Сотрудник видит не факт существования заявки, а ее реальное состояние прямо сейчас.
Это звучит очевидно. Но реализовано так во многих банках только частично.

Что передается между CRM и конвейером в нормально выстроенной интеграции: клиентские идентификаторы, состав и параметры заявки, согласия, документы, результаты проверок, скоринговые статусы, замечания по комплектности, текущий этап маршрута.

Если эта схема не спроектирована заранее, CRM превращается в красивую обложку, а реальная жизнь процесса уходит в соседние системы — и все возвращается к пяти открытым вкладкам.

• Где здесь работает ИИ

Самый полезный ИИ-инструмент в банковской CRM не тот, который «умеет поговорить», а тот, который работает внутри процесса. На этапе заявки ИИ-агент может проверить заполненность обязательных полей, сопоставить состав документов с типом продукта, заметить несоответствие между анкетой и вложениями, подсказать следующий шаг оператору.

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

Типичный сценарий: CRM внедряют «под розницу», а корпоративный сегмент остается на потом. Потом наступает — и выясняется, что нужно перепроектировать половину системы.
Корпоративный клиент — это не один контакт и не одна сделка. Это несколько ЛПР, бухгалтерия, юристы, финансисты, бенефициары, связанные и дочерние компании, несколько продуктовых направлений, длинный цикл согласований с набором документов и версий.
Если система не умеет работать с этой сложностью как с нормой, корпоративный блок начинает жить рядом с CRM, а не внутри нее.

Три места, где банк теряет деньги без нормального корпоративного контура

1. Потеря контекста при смене менеджера. Когда менеджер уходит в отпуск или меняется, сделка провисает, потому что значимая часть знаний жила у конкретного человека, а не в системе. Это не редкость, это норма там, где CRM не ведет корпоративную сделку как процесс.
2. Удлинение цикла из-за мелочей. Сделка с юрлицом почти никогда не срывается из-за одного большого провала. Она растягивается из-за десятков маленьких задержек: забытый документ, незафиксированное согласование, неотправленное КП, пропущенное уведомление. Каждый из этих инцидентов — два-три дня потерь. В цикле из 30–40 касаний это легко превращается в лишние 3–4 недели.
3. Упущенные кросс-продажи. Компания активно использует расчетный счет, обороты растут, но в банке не настроен триггер на предложение кредитной линии или зарплатного проекта. Данные есть, но они не превращаются в действие. Это прямая потеря дохода, которая не видна ни в каком отчете.

Что здесь может делать ИИ?
В корпоративном блоке ИИ особенно полезен как контекстный помощник менеджера.

Он может:

• анализировать активность клиента по событиям и продуктам;
• подсказывать вероятные следующие шаги и предложения;
• выявлять «тихие» сделки, где давно не было движения;
• готовить черновики писем и внутренних резюме;
• выделять риски в ходе сопровождения сделки.

Это особенно ценно там, где менеджер ведет десятки клиентов одновременно и физически не может вручную отслеживать все сигналы.

Минимально рабочая модель для юрлиц

Корпоративная CRM должна поддерживать: карточку организации с иерархией связей, структуру контактов и ролей, ведение длинной сделки по этапам, задачи и ответственность внутри команды банка, единый документооборот по сделке, контроль SLA и сроков — и совместную работу нескольких ролей: менеджера, кредитного аналитика, юриста, риск-блока.

Зрелая банковская CRM для корпоративного блока — это не «B2B-версия карточки клиента». Это полноценная процессная модель работы с компанией.

В 2025–2026 году тема миграции CRM в банковском секторе перестала быть вопросом стратегии и стала вопросом операционной устойчивости. Часть зарубежных платформ ушла с рынка или утратила предсказуемость поддержки. Требования к локализации данных и импортозамещению стали обязательными для системообразующих организаций.

Но главная практическая проблема не в том, какую систему выбрать. А в том, что «заменить CRM»,это почти никогда не значит «поставить новую систему».

Банк мигрирует не только карточки клиентов. Он мигрирует процессную логику, исторические связи, пользовательские сценарии, интеграции, исключения и «скрытые» обходные правила, которые за годы накопились в старой системе.

Что обычно вскрывается в ходе миграции:

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

Парадоксально, но именно миграция часто становится первым честным аудитом того, как банк реально работает, а не как это описано в регламентах.

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

Самый переоцененный сценарий последних двух лет — «добавим ИИ в CRM». Проблема не в идее, а в том, что под ИИ часто подразумевают поверхностные вещи: шаблонные подсказки, автоответы, внешний чат поверх базы знаний, отдельный «умный помощник», не встроенный в реальную работу.
Это уже не работает как конкурентное преимущество, это базовый минимум.

Основная стоимость клиентского процесса в банке в том, чтобы не потерять контекст, не допустить ошибку, не нарушить маршрут, не перегрузить сотрудника ручной проверкой. Следующий уровень зрелости, это ИИ не рядом с CRM, а внутри процессов.

Три поколения AI в CRM

Бот отвечает на вопрос. Агент видит текущую карточку клиента, понимает этап процесса, использует внутренние данные, может запускать разрешенные действия и передавать результат дальше по маршруту.

Практические сценарии, которые реально работают:

• Квалификация входящего обращения. ИИ-агент анализирует содержание, определяет тему и срочность, направляет в нужный контур без ручной сортировки.
• Проверка комплектности документов. Сопоставляет тип продукта, статус клиента и набор вложений. Если чего-то не хватает, сотрудник видит это сразу, а не после двух-трех циклов возврата заявки.
• Подготовка черновиков ответов. Для претензий и сервисных коммуникаций ИИ-агент готовит черновик на основе контекста клиента и истории взаимодействий. Сотрудник не пишет с нуля, а проверяет и корректирует. На потоке в несколько сотен претензий в день экономия составляет 30–40% времени на обработку.
• Мониторинг клиентской активности. Система замечает поведенческие сигналы: долгое молчание, падение продуктовой активности, высокий риск оттока и автоматически создает задачу менеджеру.
• Next best action (следующее лучшее действие). На основании текущего этапа и клиентского профиля агент подсказывает, какой шаг сейчас наиболее уместен: запросить документ, предложить продукт, перевести в другой сценарий.

Важное ограничение: ИИ в банке должен работать в рамках управляемой корпоративной архитектуры с понятными ролями, ограничениями и зонами ответственности. Не «черный ящик», который сам решает что делать, а цифровой участник процесса с четко заданными правами.

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

Этап 1. Аудит текущей работы (2–4 недели)
Главная задача — понять не какие системы есть, а как реально работают сотрудники. Обычно анализируют путь обращения, путь заявки, фронтовые сценарии, узкие места, ручные действия, дублирование данных.
На этом этапе банк нередко впервые видит, сколько операций выполняется не по регламенту, а «как привыкли» и эта разница принципиально важна для проектирования.

Этап 2. Определение приоритетного контура (1–2 недели)
Попытка охватить все сразу почти всегда ошибка. Разумнее выбрать стартовый контур с заметным эффектом: фронт-офис, заявки, сервисное обслуживание, корпоративные сделки или контакт-центр.
Лучше запустить один значимый рабочий процесс за 3–4 месяца, чем год строить идеальную схему «на все сразу».

Этап 3. Пилот (4–8 недель)
Хороший пилот — это не демо-версия, а проверка архитектуры на живом участке.

Три вопроса, на которые должен ответить пилот:

• удобнее ли пользователям на практике
• выдерживает ли система реальную нагрузку и интеграции
• какие бизнес-правила оказались неочевидными до запуска

Этап 4. Интеграции (6–16 недель — самый сложный участок)
Внедрить интерфейс относительно просто. Встроить его в экосистему банка так, чтобы данные не терялись, статусы не расходились, а процесс был управляемым, принципиально сложнее.
Что обычно занимает больше времени, чем ожидалось: согласование форматов данных, обработка нестандартных сценариев, синхронизация статусов, разбор исторических исключений, устранение расхождений между «как должно быть» и «как реально работает».

Из опыта: именно здесь большинство проектов превышают первоначальные оценки по срокам — как правило, на 30–50%.

Этап 5. Обучение и запуск (2–4 недели)
Хорошо спроектированная CRM сокращает не только время операций, но и время адаптации новых сотрудников. Когда система собирает работу в одном интерфейсе, оператору не нужно учить «карту хаоса» из множества внутренних систем. Типичное сокращение периода онбординга с 3–4 недель до 1–1,5.

Этап 6. Масштабирование и итерации (непрерывно)
После запуска работа только начинается. Нормальный путь зрелой банковской CRM — не «проект завершен», а цикл: собрать обратную связь, скорректировать маршруты, добавить автоматизацию, расширить ИИ-сценарии там, где они реально дают отдачу.

Ошибка 1. Начинать с аналитики, когда нет нормальной операционной базы

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

Ошибка 2. Недооценивать интеграционную сложность

Проект «на бумаге» почти всегда выглядит проще, чем в реальном банковском ландшафте. Интеграции, а не интерфейс, определяют реальный срок и стоимость внедрения. Закладывайте на этот блок вдвое больше времени, чем кажется нужным.

Ошибка 3. Автоматизировать хаос как есть

Если плохой процесс перенести в новую CRM-систему, он не станет хорошим. Он станет быстрее фиксироваться. Автоматизация умножает то, что уже есть и плохое, и хорошее.

Ошибка 4. Делать систему только силами ИТ

Если бизнес-пользователи не участвуют в проектировании сценариев, система получается логичной для архитекторов и неудобной для реальной работы. Это не метафора — это буквально то, что происходит в большинстве проектов, где заказчик «делегировал» внедрение ИТ-департаменту.

Ошибка 5. Оценивать ИИ по эффекту на презентации

Самый красивый ИИ-сценарий не всегда самый полезный. В банке важен не «вау-эффект», а снижение числа ручных операций, уменьшение ошибок и ускорение маршрута. Если ИИ-функция не дает измеримого операционного результата, то это украшение, а не инструмент.

1. Безопасность и регуляторный контур

• Развертывание в контуре банка (on-premise или частное облако)
• Журналирование всех действий пользователей
• Ролевая модель доступа с гранулярными правами
• Аудит изменений с историей
• Соответствие требованиям ФЗ-152 и требованиям ЦБ
• Предсказуемость жизненного цикла решения: поддержка, обновления, развитие

2. Интеграции

• Нормальный документированный API (не «можно доработать»)
• Готовые коннекторы или опыт интеграции с АБС, DWH, кредитным конвейером
• Устойчивость к асинхронным сценариям
• Прозрачная обработка ошибок — сотрудник видит, где завис процесс
• Интеграция с телефонией и контакт-центром
• Интеграция с ЭДО и каналами коммуникаций

3. Функционал клиентской работы

• Единая карточка клиента
• Полная история взаимодействий
• Поддержка физлиц и юрлиц в едином контуре
• Омниканальный контекст
• Контроль SLA
• Встроенная логика сервисных и продуктовых сценариев

4. Гибкость изменений

• Настройка маршрутов без тяжелой разработки
• Изменение форм, полей, этапов силами бизнес-аналитика
• Low-code инструменты, пригодные для реальной эксплуатации (не только для демо)
• Скорость адаптации процессов под новые регуляторные требования

5. ИИ-готовность

• Возможность встроить ИИ в реальные процессы, а не только как внешний ассистент
• Ограничение роли и действий ИИ-агентов
• Поддержка разных моделей
• Логирование и контроль результатов ИИ

6. Внедрение и поддержка

• Реальный опыт проектов в банках (запросить контакты референсных клиентов)
• Понимание фронта, кредитных маршрутов, корпоративного блока
• SLA поддержки с конкретными метриками
• Возможность банка развивать систему без зависимости от вендора на каждом изменении

Мы внедряли ELMA365 в банковском и финансовом секторе, поэтому говорим об ее архитектурных особенностях на основе реального проектного опыта, а не по теории и документации по платформе. Когда смотришь на рынок платформ с позиции интегратора, который работал с несколькими из них, разница между ELMA365 и большинством альтернатив становится видна не в списке функций, а в архитектурных решениях, которые в банковском контексте либо решают проблему, либо создают новую.

Одна платформа вместо связки систем. CRM, BPM, ECM и Service Desk в ELMA365 — это модули в единой архитектуре платформы, которая обеспечивает бесшовную работу и сквозные процессы в рамках всей системы. На практике это означает, что между модулями нет интеграций, а, следовательно, и нет необходимости в их поддержке, нет расхождений в данных и нет ситуаций, когда изменение в одной подсистеме – ломает общую логику всей системы. Для банка, где процессы сквозные по определению, это критично.

Low-code – подход, который работает для бизнес-аналитика. Изменить маршрут согласования, добавить поле в карточку клиента или перестроить этапы сделки можно без цикла разработки. Это напрямую влияет на скорость адаптации под регуляторные изменения, а они в банковском секторе происходят регулярно и не ждут следующего релиза.

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

Данные не покидают контур банка даже при работе с ИИ. ELMA Cortex разворачивается на собственных серверах и поддерживает локальные языковые модели. Это отличает его от большинства ИИ-интеграций, где запросы уходят во внешние облака и к сторонним провайдерам. Для банков с требованиями по КИИ и персональным данным это не вопрос предпочтений, а ограничение при выборе платформы.

Все это не означает, что ELMA365 подходит для любого проекта, выбор платформы всегда зависит от конкретного ландшафта, масштаба и зрелости компании. Но если смотреть по критериям 2025–2026 года: регуляторный контур, гибкость изменений, безопасный ИИ, это один из немногих вариантов, где все эти требования закрыты на уровне архитектуры самой платформы.

Три вопроса, которые стоит задать себе до выбора платформы:

1. Где банк сегодня теряет больше всего времени и качества — на фронте, в заявках, в корпоративных сделках, в маршрутизации?
2. Что должно принципиально измениться через год и есть ли у этого измеримый показатель?
3. Кто будет жить с этой системой после внедрения: только ИТ, или бизнес и ИТ смогут реально развивать ее вместе?

Три вопроса вендору:

1. Есть ли у вас реальные референсные проекты в банковском контуре?
2. Как система адаптируется под изменения процессов без полного цикла разработки?
3. ИИ в вашей архитектуре — это встроенный участник бизнес-процессов или внешний помощник поверх системы?

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

Именно поэтому успешный банковский CRM-проект сегодня строится вокруг трех вещей:

• правильно спроектированных процессов;
• надежных интеграций;
• возможности быстро менять систему без полной переработки.

А следующий уровень зрелости — это ИИ не как отдельный модуль «для галочки», а как встроенный механизм, который помогает банку обрабатывать больше клиентских сценариев с меньшей операционной нагрузкой и меньшим числом ошибок.

Статья основана на практике проектов автоматизации банковских процессов. Если у вас есть вопросы по конкретному сценарию внедрения — напишите или позвоните нам.

Сколько стоит внедрение CRM в банке?
Диапазон очень широкий — от 5–10 млн рублей для ограниченного пилота в одном контуре до 50–200+ млн для полноценного внедрения с интеграциями, корпоративным блоком и ИИ-сценариями. Основная статья расходов — это не лицензии, а внедрение интеграций и управление изменениями.

Сколько занимает внедрение CRM в банке?
Пилот в одном контуре — 3–5 месяцев. Полноценное внедрение с интеграциями — 9–18 месяцев. Миграция со старой системы: плюс 3–6 месяцев сверху на аудит и перенос данных.

Чем банковская CRM отличается от обычной?
Ключевые отличия: интеграция в регуляторный контур, двусторонняя интеграция с АБС и кредитным конвейером, поддержка сложной корпоративной логики, требования к локализации и журналированию, управляемость изменений под требования ЦБ.

Что важнее: функционал платформы или опыт интегратора?
Опыт интегратора в большинстве случаев важнее. Хорошая платформа без понимания банковского контура дает посредственный результат. Команда с опытом банковских проектов вытащит даже не идеальную платформу на приемлемый результат.