Цифровой лизинговый конвейер на базе Pyrus

Ситуация на старте
Изначально проект начинался с переработки amoCRM. Однако уже на этапе анализа стало понятно, что основная сложность находится за пределами стандартной воронки продаж.

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

В нём участвуют:

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

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

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

На стороне продаж менеджер:
получает обращение → квалифицирует клиента → рассчитывает и согласовывает коммерческое предложение → собирает первоначальные данные и документы.

После этого заявка передаётся в Pyrus и проходит внутренний маршрут:
Заполнение → КАСКО → Осмотр → Оценка → Служба безопасности → внутренние проверки → риск-блок → подтверждение параметров → подготовка решения → Кредитный комитет → Договор → Выдача.

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

Поэтому основой внутреннего контура стал Pyrus.

Pyrus как ядро лизингового процесса
Центральной сущностью системы стала форма «Заявка на лизинг». По сути, она выполняет роль цифрового досье сделки.

По мере прохождения процесса в ней накапливаются:

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

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

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

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

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

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

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

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

Двусторонняя синхронизация Pyrus и amoCRM
После передачи заявки менеджер не теряет информацию о состоянии своего клиента.

Для проекта была разработана двусторонняя интеграция. Из amoCRM в Pyrus передаются данные клиента и параметры сделки, после чего автоматически создаётся заявка на лизинг.

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

Менеджер может видеть, что заявка:

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

При этом менеджеру не нужно погружаться во внутренние задачи каждого подразделения. Он видит фактическое состояние сделки непосредственно в amoCRM.

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

Стандартного обмена статусами для такой архитектуры оказалось недостаточно. Поэтому мы разработали специального бота-наблюдателя.

Он отслеживает изменения в связанных процессах, определяет фактическое состояние основной заявки и передаёт актуальный статус в amoCRM.

В результате удалось связать в одну систему:
основная заявка → вложенные проверки → результаты подпроцессов → возвраты → изменение маршрута → актуальный статус в CRM.

При этом сложную банковскую логику не пришлось искусственно упрощать ради интеграции.

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

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

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

В Pyrus возвраты стали полноценной частью маршрута.
При возврате система:

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

Благодаря этому статус заявки соответствует её реальному положению, а не просто последнему этапу, которого она когда-либо достигала.

Единое цифровое досье сделки
По мере движения заявки Pyrus формирует единое цифровое досье.

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

Каждый следующий участник получает уже подготовленный контекст.

Например:

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

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

ИИ-агент для предварительной проверки досье
Дополнительным уровнем автоматизации стал ИИ-агент, встроенный непосредственно в процесс Pyrus.
Комплект документов по лизинговой сделке зависит от типа клиента, поставщика, предмета лизинга и параметров финансирования. При этом важно проверить не только наличие файлов, но и соответствие данных в заявке приложенным документам.

Перед передачей заявки на ответственную внутреннюю проверку ИИ-агент анализирует:

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

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

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

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

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

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

Система определяет необходимый шаблон в зависимости от параметров сделки и переносит в него:

• реквизиты клиента;
• информацию о поставщике;
• параметры предмета лизинга;
• источник финансирования;
• согласованные условия;
• другие необходимые сведения.

Сформированный документ остаётся связанным с заявкой и проходит предусмотренные проверки и согласования.

Таким образом, одни и те же данные последовательно используются на всём маршруте:
сбор → проверка → принятие решения → формирование документа.

Это сокращает ручной перенос информации и снижает риск ошибок в реквизитах и условиях сделки.

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

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

Код и инструкции передаются технической команде банка, после чего приложение работает на инфраструктуре клиента.

Так удалось совместить кастомную интеграцию amoCRM и Pyrus с требованиями финансовой организации к размещению и обработке данных.

Управление отказами
Отрицательное решение также является частью процесса и не должно приводить к потере накопленной информации.

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

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

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

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

Что получил бизнес
На базе Pyrus был построен управляемый цифровой конвейер лизинговой сделки.

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

В результате:

• менеджеры продолжают видеть актуальное состояние клиента в amoCRM;
• внутренние подразделения работают в едином структурированном процессе Pyrus;
• сотрудники получают подготовленное досье без повторного сбора информации;
• руководство видит текущее положение каждой заявки и причины задержек;
• документы формируются на основании уже проверенных данных;
• первичная проверка досье усиливается ИИ-агентом;
• интеграционный слой работает внутри инфраструктуры банка.

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

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

При этом Pyrus управляет не только последовательностью этапов. Система запускает вложенные проверки, обрабатывает возвраты, сохраняет цифровое досье сделки и передаёт актуальное состояние процесса обратно в CRM.

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

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