Что произошло в небольшом бизнесе недвижимости

Американская компания Levron Labs опубликовала кейс владельца Logan Smith Properties — малого оператора недвижимости, который уже пользовался генеративным ИИ через отдельные запросы, но продолжал вручную отправлять follow-up, готовить статусы и связывать разрозненные инструменты. По данным исполнителя, административная работа занимала около 14 часов в неделю.

После аудита команда не стала добавлять ещё один чат. Она связала существующие процессы автоматизационным слоем: настроила последовательности общения с клиентами, триггеры вместо ручных проверок, автоматические обновления статусов и AI-помощь в рутинных операциях. Исполнитель сообщает, что недельная административная нагрузка снизилась до менее одного часа, то есть высвободилось 50–60 часов в месяц без найма и покупки нового прикладного ПО.

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

Почему это прежде всего автоматизация процесса

В кейсе перечислены четыре изменения:

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

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

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

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

Архитектура, которую можно повторить

Для малого оператора недвижимости или сервисной компании минимальный контур выглядит так:

1. **Источник события.** Новая заявка, изменение статуса объекта, истечение срока, входящее письмо или отсутствие ответа в заданный период.
2. **Нормализация данных.** Проверка обязательных полей, телефона, адреса, ответственного и согласия на коммуникацию.
3. **Маршрутизация.** Простые правила определяют тип операции. Только неоднозначный текст отправляется модели.
4. **AI-шаг.** Классификация запроса, извлечение сущностей или подготовка черновика по утверждённым данным.
5. **Контроль.** Схема проверяет формат, запретные поля, наличие источника и допустимость действия.
6. **Подтверждение.** Сотрудник принимает важное сообщение, изменение условий или действие с юридическими последствиями.
7. **Исполнение и журнал.** CRM, почта или система задач выполняет разрешённое действие и сохраняет событие аудита.

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

Какие данные и интеграции нужны

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

Минимальный набор обычно включает:

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

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

Отдельно проверьте качество идентификаторов. Один клиент может фигурировать под разными телефонами и адресами, а один объект — под внутренним номером и адресом. До автоматизации нужно определить правило объединения записей, иначе система начнёт уверенно дублировать follow-up.

Где уместны локальная модель, RAG и агент

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

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

**Агент** оправдан, когда задача действительно многошаговая: проверить карточку, найти документ, подготовить черновик и создать задачу. На первом этапе выдавайте ему read-only инструменты. Отправка письма, изменение цены, подписание документа или перенос денег остаются отдельными инструментами с явным подтверждением человека.

Что проверить в безопасности

Недвижимость и профессиональные услуги работают с персональными и договорными данными. Даже локальный контур не решает проблему автоматически.

Нужны базовые меры:

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

NIST AI Risk Management Framework рекомендует учитывать надёжность на этапах проектирования, использования и оценки. Для МСП это не обязательно большой комитет: достаточно владельца процесса, реестра рисков на одну страницу и заранее определённых условий остановки.

Как считать экономику без маркетинговой оценки

Поставщик оценил высвобождённое время по ставке 75 долларов в час и получил около 49 500 долларов в год. Для российского бизнеса эта ставка не является ориентиром. Используйте собственную полную стоимость часа и фактическое время после проверки.

Формула пилота:

**годовой эффект = сэкономленные часы × полная стоимость часа − лицензии − инфраструктура − поддержка − стоимость ошибок.**

Если принять заявленное сокращение с 14 до менее одного часа, верхняя оценка экономии составляет около 13 часов в неделю. Но в расчёт нужно включить:

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

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

Пилот на четыре недели

**Неделя 1.** Замерьте время на 50–100 реальных операциях и выпишите повторяющиеся события. Не автоматизируйте исключения.

**Неделя 2.** Свяжите один источник с одной системой задач. Пусть правило создаёт черновик или задачу, но ничего не отправляет самостоятельно.

**Неделя 3.** Добавьте AI только для одного неструктурированного шага. Сотрудник отмечает принятие, исправление и отказ.

**Неделя 4.** Сравните полное время, ошибки и пропуски с базовым периодом. Решите, расширять сценарий, оставить в теневом режиме или закрыть.

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

Управленческий вывод

Кейс небольшого оператора недвижимости полезен не цифрой «14 часов», а последовательностью. Сначала команда нашла повторяемые ручные переходы между системами, затем связала их правилами и только после этого добавила AI к неструктурированным задачам.

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