Первоуральскбанк

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

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

На практике это означало несколько системных проблем:

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

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

Ход проекта
Проект начали с глубокого аудита процессов клиентского блока, продаж, сопровождения, внутренних согласований и маршрутов обработки заявок. На этой основе была спроектирована целевая архитектура взаимодействия между amoCRM и Pyrus, где каждая система решает свою задачу, но при этом обе работают как единый механизм.

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

Отдельное внимание было уделено глубокой кастомизации самой amoCRM под банковские процессы. Были существенно переработаны карточки сделок, компаний и контактов, добавлены обязательные поля в зависимости от продукта, этапа и типа клиента, реализованы внутренние чек-листы, подсказки, сценарии действий, автоматические причины отказа, правила возврата в работу и контроль зависших сделок. За счёт этого CRM стала не просто системой учёта, а рабочим интерфейсом, который направляет сотрудника по процессу и снижает количество ошибок в сложных сценариях.

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

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

Дополнительно были синхронизированы ключевые сущности и параметры: клиент, компания, сделка, продукт, тип обращения, маршрут обработки, ответственные, комментарии, результаты согласований, внутренние статусы и отдельные параметры заявки. Это позволило связать две разные по назначению системы в один управляемый контур, где amoCRM отвечает за коммерческий и клиентский фронт, а Pyrus — за внутреннюю процессную логику банка.

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

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

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

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

Дополнительно была собрана аналитика по лизингу, партнёрскому каналу, повторным продажам, кросс-продажам и маршрутам обработки внутри банка.

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

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

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

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

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

В итоге amoCRM в связке с Pyrus и BI стала для ПЕРВОУРАЛЬСКБАНК не просто CRM-системой, а полноценной цифровой платформой, которая объединяет продажи, клиентский сервис, внутренние банковские процессы и управленческий контроль в единую управляемую архитектуру.