ИИ видит клиента, но не видит его заказ: как связать данные для точного ответа

Salesforce в инженерной публикации от 14 сентября описала использование Data 360 Data Graphs для подготовки клиентского контекста. Команда связывает сведения об организациях, продуктах, договорах, заказах и правах на услуги, а агент получает подходящую для своей задачи выборку. Компания подчёркивает, что подбор данных нужно строить вокруг реальных запросов: слишком большой граф перегружает обработку, а чрезмерное дробление возвращает необходимость соединять сведения при каждом обращении.

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

Начните с вопросов, на которые нужен ответ

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

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

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

Свяжите записи по устойчивым идентификаторам

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

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

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

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

Передавайте агенту компактную сводку с основаниями

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

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

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

Проверьте ошибки, которые дорого исправлять

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

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

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

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

Видео: подготовка базы знаний для ИИ-агента

Алексей Колесов показывает создание базы знаний с n8n и Supabase. Это практическое дополнение о подготовке и получении данных для помощника. Связи клиента с заказами и правила определения статуса услуги необходимо описать отдельно для вашей системы учёта.