CRM, которая знает, что было после сделки: три уровня ИИ в Citeck

«За последний год Low-code заметно сблизился с ИИ: модели начинают встраиваться не только в приложения, но и в сам процесс разработки. В ближайшие 1–2 года ИИ станет обязательной частью Low-code-платформ. При этом ИИ не заменит Low-code, а усилит его: модели дадут скорость разработки, а платформа — предсказуемость, управляемость и соответствие архитектуре. Победит их связка», — Илья Кайгородов, технический директор Citeck компании SL Soft fabricaONE.AI.

ИИ-функции сегодня есть почти в каждой CRM. Но письмо, написанное нейросетью, не меняет экономику продаж. Разница появляется там, где CRM «знает», что происходит с клиентом после того, как сделка выиграна: как идет проект, что и у каких поставщиков закуплено под него, удается ли уложиться в срок и бюджет. В Citeck CRM — не отдельная система, а один из модулей AI Low-Code платформы с общими данными и процессами. Именно это превращает ИИ из модной надстройки в рабочий инструмент.

Почему «CRM плюс нейросеть» — это мало

Типичная картина в средней и крупной компании: продажи ведут в CRM, проекты — в таск-трекере, закупки — в ERP или почте, договоры — в СЭД. Каждая система отвечает за свой участок — и ни одна не отвечает за клиента целиком. Менеджер закрыл сделку — и информация расходится по четырем контурам, а в CRM возвращается разве что комментарием «сдали с задержкой».

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

Как устроена CRM в Citeck

Citeck — AI Low-Code платформа, на которой собраны готовые модули: CRM, управление проектами, договоры, закупки, СЭД, Service Desk и другие. Модели данных у модулей свои, но справочники — контрагенты, сотрудники, продукты — общие, а объекты можно связывать между собой напрямую. Движок процессов BPMN 2.0 и система прав при этом общие для всей платформы. Сделка, проект, заявка на закупку и договор — не записи в разных базах, а связанные карточки одной системы.

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

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

Сквозная цепочка: сделка → проект → закупка

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

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

Затем в модуле управления проектами по шаблону создается проект — уже на основе данных сделки и подписанного договора: этапы, вехи, бюджет и сроки. Команда работает на канбан-доске и в диаграмме Ганта, руководитель видит план/факт по каждому этапу.

Потребности этапа — оборудование, лицензии, субподряд — превращаются в заявки на закупку, связанные с проектом и сделкой. Модуль закупок (SRM) проводит запрос предложений среди поставщиков, фиксирует конкурсную процедуру и ее результат, а договор с поставщиком заключается в том же модуле управления договорами — с согласованием, версиями и подписью.

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

Почему это важно именно для ИИ? Пока сделка существует только как запись в CRM, модель может анализировать преимущественно коммерческий контекст. Когда с ней связаны проект, договоры, закупки, обращения и фактические результаты, появляется возможность сопоставлять обещанное клиенту с тем, что произошло на самом деле.

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

Сквозная цепочка CRM → Проекты → Закупки и общая платформа под ней

Диаграмма Ганта в платформе Citeck

Заказчик внутри процесса

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

Внешний портал: обращение по оборудованию

Не в «зеленое поле»

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

Три уровня ИИ

Только на таком фундаменте ИИ становится инструментом, а не украшением интерфейса. В Citeck мы различаем три уровня — по тому, сколько работы ИИ берет на себя.

Уровень 1. Генеративный помощник. Ассистент пишет письмо клиенту и текст коммерческого предложения — не с чистого листа, а из карточки сделки: продукты, история общения, условия. Запись встречи в видеоконференции превращается в расшифровку и резюме с договоренностями, которое ложится в сделку. Семантический поиск отвечает на вопрос «что у нас с этим заказчиком» сразу по CRM, проектам, договорам и переписке. Это самый быстрый по эффекту уровень: он экономит часы менеджеров.

Панель ИИ-ассистента в карточке сделки: генерация письма

Уровень 2. Аналитический помощник. Здесь ИИ работает с данными, которых у изолированной CRM нет. Оценка лида опирается не на заполненность полей, а на историю самой компании: как закрывались похожие сделки, сколько длился цикл, чем заканчивались проекты. Ассистент замечает риск («в трех из пяти проектов этого типа закупка серверов сдвигала срок на месяц»), проверяет контрагента по отчету Контур.Фокуса, предлагает допродажу по завершенным проектам и обращениям в Service Desk. Он же находит закономерности, которых не видно в отчетах: сегмент, где сделки закрываются быстрее, или тип КП, который чаще уходит в доработку. Итог — следующий шаг, а не еще один дашборд.

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

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

Уровень 3. Процессный агент. ИИ не советует, а выполняет цепочку действий. Агент в Citeck — участник BPMN-процесса со своими инструкциями, инструментами и правами, как у сотрудника. После выигрыша сделки движок процессов BPMN 2.0 запускает связанные процессы, а ИИ закрывает в них «умные» шаги: проверяет полноту данных и оценивает контрагентов, готовит текст документов, договоров и заявок на закупку из спецификации КП, а менеджеру в диалоге помогает создать проект и задачи. Согласование, напоминания и контроль сроков — работа процесса: так цепочка остается управляемой, а не зависит от настроения модели. В отличие от RPA-скрипта агент понимает смысл документов и данных: в нетиповой ситуации он запросит недостающее у менеджера, а не остановится с ошибкой. Ключевые решения остаются за людьми — это точки согласования в процессе, а каждое действие агента записано в истории. Агенту не нужны интеграционные «костыли»: он работает с теми же карточками, что и люди.

Три уровня ИИ: что делает каждый и какие данные платформы ему нужны

Что важно для CIO

Такая архитектура снимает несколько привычных вопросов.

• Единый источник данных о клиенте: сделка, проект, договор и закупка связаны ссылками внутри одной платформы, а не синхронизацией между CRM, трекером и ERP.

• Управляемый ИИ: языковая модель подключается на выбор заказчика — локальная в собственном контуре или облачная у вендора. Если данные не должны покидать периметр, они его не покидают.

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

• Изменяемость: новые этапы, поля и процессы добавляются средствами Low-Code силами аналитика, а не в рамках разработки.

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

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

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

Резюме

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

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