Из переписки в карточку запроса: ИИ-помощник риелтора

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

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

Почему копирования сообщений недостаточно

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

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

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

Какие поля нужны в карточке запроса

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

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

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

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

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

Как сохранить источник и изменения

Для выбранного текстового диалога подходит такая последовательность:

1. Пользователь передаёт разрешённый диалог.
2. Помощник выделяет фрагменты, относящиеся к запросу.
3. На их основе появляется черновик карточки.
4. Неизвестные и противоречивые сведения превращаются в вопросы.
5. Риелтор сверяет значения с сообщениями и подтверждает карточку.

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

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

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

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

Учебный пример карточки

Условная переписка, не реальный клиент.

Клиент пишет: «Нужна квартира рядом с метро, второй этаж не хочу». Позже уточняет: «Второй этаж всё-таки можно, если окна во двор. Бюджет уточню».

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

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

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

Когда решение должен принимать человек

Риелтор проверяет карточку перед использованием. Особого внимания требуют четыре ситуации:

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

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

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

ИИ-агент, бот или обычная интеграция

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

Чат-бот — это интерфейс диалога. Он может запросить недостающее поле или показать карточку риелтору, но наличие чата само по себе не делает систему ИИ-агентом.

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

Для описанного сценария подходит услуга Switch On AI «ИИ-помощник для продаж». Сначала можно определить поля карточки и правила подтверждения, затем проверить их на обезличенных диалогах. Каналы, рабочие подключения и запись в CRM согласуются отдельно.

Подход к ручному импорту и проверке исходных реплик показан в прототипе помощника риелтора. Это именно прототип: выбранный диалог передаётся текстом или JSON, карточку подтверждает пользователь, а подключение Битрикс24 относится к следующему этапу. Такой статус нельзя считать готовым внедрением во все каналы агентства.

Как принять пилот

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

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

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

Что подготовить к обсуждению

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

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

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