Какие данные из CRM действительно нужны AI-суфлёру

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

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

Начните со сценария, а не со списка API

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

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

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

Что получать из CRM до разговора

1. Идентификаторы и связь сущностей

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

2. Ответственный сотрудник

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

3. Стадия и тип сделки

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

4. Несколько бизнес-полей

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

5. Ссылка на карточку

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

Что не стоит забирать «на всякий случай»

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

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

Какие данные используются во время разговора

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

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

Живой аудиопоток обычно поступает не из CRM, а с рабочего места или телефонии. Поэтому CRM-интеграция и захват разговора — разные контуры. На страницах планируемой интеграции с Bitrix24 и планируемой интеграции с amoCRM это разделение указано явно.

Что возвращать в CRM после звонка

Краткое резюме

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

Договорённости и следующий шаг

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

Структурированные ответы

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

Причина результата

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

Правила записи результата

1. Не перезаписывать молча. Если в карточке уже есть значение, правило конфликта должно быть заранее определено.
2. Отделять факт от вывода. «Клиент назвал срок — октябрь» и «вероятно, проект стартует осенью» имеют разную надёжность.
3. Хранить источник. Для спорного значения полезно знать, из какого разговора и когда оно получено.
4. Не создавать действия без владельца. Следующий шаг должен быть назначен конкретному сотруднику или очереди.
5. Учитывать права пользователя. Интеграция не должна обходить модель доступа CRM.

OAuth, токены и поддержка

Публичная интеграция должна получать доступ через предусмотренный CRM механизм авторизации, хранить токены в защищённом хранилище и уметь корректно обновлять и отзывать их. Нельзя просить пользователя передавать логин и пароль в поддержку. В рекомендациях amoCRM отдельно указано, что access token, refresh token и client secret являются приватными данными и требуют безопасного хранения.

Для модерации важен не только happy path. Пользователь должен понимать, что произошло при истёкшем токене, недоступном поле или недостаточных правах, а сообщение об ошибке должно содержать контакт поддержки OCC, но не секрет или содержимое разговора.

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

Пример минимального сценария

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

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

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

Чек-лист для проектирования

• Определён один пользовательский сценарий
• Указаны входные CRM-объекты
• Для каждого поля описана польза
• Лишние права исключены
• Есть правило сопоставления сделки
• Определён результат после звонка
• Описаны конфликты полей
• Есть отключение и отзыв токенов
• Ошибки ведут в поддержку OCC
• Подготовлена схема потока данных
• Проверено разграничение тенантов
• Маркетинговое описание совпадает с кодом

Источники и методика

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

• Bitrix24: порядок публикации решений
• amoCRM: требования к публичным интеграциям
• amoCRM: OAuth 2.0
• HubSpot: требования App Marketplace