Как подключить GPT или Claude к CRM и проверять каждое изменение?

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

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

Ниже — схема для обсуждения с разработчиком. Она не привязана к конкретной CRM и не является отчётом о протестированной интеграции.

Что API даёт нейросети и приложению?

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

При function calling модель предлагает вызов функции, а приложение выполняет его. Этот порядок описан в документации OpenAI. У Claude для собственных инструментов приложения используется похожий цикл: модель возвращает вызов, приложение исполняет его и передаёт результат. В документации Anthropic такие инструменты называются client tools; у провайдера есть и другие инструменты, исполняемые на его стороне.

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

С какого сценария начать интеграцию?

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

Пусть система предлагает: «Уточнить требования к отчёту». Если срок в разговоре не назван, поле срока остаётся незаполненным и требует решения менеджера. Модель не должна превращать своё предположение в договорённость с клиентом.

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

Как провести изменение от предложения до проверки?

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

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

Проверка. Приложение проверяет допустимые поля, идентификаторы и значения. Менеджер видит, что именно предлагается записать, и согласует эту версию. Строгая структура ответа помогает разобрать поля, но не подтверждает их истинность — это ограничение отмечено и в Structured Outputs.

Запись. Непосредственно перед ней приложение заново сверяет состояние сделки. Если с момента согласования изменились значимые данные, нельзя молча применять прежнее предложение. Нужна повторная проверка или согласованное правило обработки конфликта. Когда CRM поддерживает условные обновления по версии, разработчик может использовать этот механизм; иначе остаются ограничения конкурентной записи, которые надо отдельно учитывать.

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

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

Что записать в договорённость с разработчиком?

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

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

Почему после таймаута нельзя просто повторить запись?

Запрос на создание задачи ушёл в CRM. Ответ не пришёл вовремя. Это ещё не доказывает, что задача не создана: операция могла выполниться, а ответ потеряться. Повтор способен создать вторую задачу. Такой риск описан в Microsoft Retry pattern.

Внутренний журнал помогает распознать повтор события у себя. Но он сам по себе не гарантирует единственную запись во внешней CRM.

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

Какие сбои нужно показать на приёмке?

Попроси продемонстрировать поведение системы на таких ситуациях:

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

Что прочитать дальше?

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