ИИ заполняет карточку CRM: как извлекать и проверять поля

Открыть схему крупнее ↗

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

Составьте словарь полей

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

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

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

Свяжите каждое значение с репликой

Извлечение должно сохранять смысл, включая отрицания, исправления и степень точности. В высказывании «не в сентябре, перенесём на октябрь» прежняя дата отменена, а новая указана явно. В словах «примерно пять сотрудников» число следует сохранить как приблизительное. Фраза «пока не решили» не должна превращаться в любое значение из допустимого списка.

Рабочая таблица может выглядеть так:

В схеме проверки полезно хранить также исходный текст и статус: подтверждено, приблизительно, не уточнено или конфликт. Так сотрудник видит происхождение данных, а обработчик может решить, что делать дальше.

Отделите структуру ответа от достоверности

Схема полей помогает ограничить допустимую форму вывода. Например, Structured Outputs в OpenAI API позволяет задавать формат через JSON Schema для поддерживаемого API и модели (документация OpenAI по Structured Outputs). Это помогает проверить форму результата — например, что дата оказалась в поле даты. Из этого следует отдельное правило приёмки: типовая проверка структуры не доказывает, что значение верно понято из разговора. Для этого нужно сравнить его с исходной репликой.

Если вы используете Битрикс24, документация полей CRM описывает типы объектов, доступность чтения и записи, а также поля только для чтения и только для создания (справочник полей CRM Битрикс24). Условия конкретной CRM следует проверить до настройки: имя поля, его тип и права зависят от выбранного объекта и конфигурации.

Нормализуйте значения по правилам бизнеса

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

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

Разрешите конфликты с CRM и ручными правками

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

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

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

Проверьте работу по полям

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

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

Ограничения и следующий шаг

Качество результата зависит от распознавания речи, структуры разговора, словаря полей и настроек CRM. Даже валидная JSON-структура может содержать неверно извлечённый факт, а корректное значение может не сохраниться из-за прав доступа или правил объекта.

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