Агентству нужен не каталог объявлений, а рабочий контур изменение → объект → проверка → действие → результат. Центральная сущность — карточка наблюдаемого объекта. Главный экран — очередь значимых изменений.
Содержание
Кейс — демонстрационная модель продукта. Данные гипотетического клиента, внутренние показатели и ожидаемый эффект используются, чтобы показать реалистичный сценарий разработки, а не отчёт о уже внедрённой системе.
Агентство работает с жилой недвижимостью Минска и ближайших пригородов. Сотрудники наблюдают примерно за 18 000 активных объявлений из шести разрешённых источников: партнёрских выгрузок, отраслевых фидов, собственной базы и ссылок, которые брокеры добавляют вручную.
Это внутренний контур наблюдения за рынком, а не CRM для агентства недвижимости: здесь нет квалификации покупателя и показов, есть сигнал изменения и реакция команды. Портал также не собирает досье загородного дома: единица работы — очередь аналитика агентства, а не проект покупки для конкретной семьи.
До проекта аналитики несколько раз в день открывают сохранённые подборки, сравнивают карточки, переносят изменения в таблицы и отправляют находки в рабочие чаты. Изменение стоимости, снятие объявления или повторное размещение объекта могут быть замечены через несколько часов либо не замечены вовсе. История одной квартиры распадается на дубли, а руководитель не понимает, какие сигналы уже проверены и к каким действиям они привели.
Граница первой версии — мониторинг жилых объектов и реакция команды, без замены CRM и без публичного каталога. Заселение к уже проживающим соседям — другой продукт: проект заселения в комнату с соседями, а не жилой мониторинг продаж и аренды.
| Показатель | Значение |
|---|---|
| География | Минск и ближайшие пригороды |
| Активные объявления | ~18 000 |
| Разрешённые источники | 6 |
| Брокеры | 45 |
| Аналитики | 4 |
| Руководители групп | 5 |
| Основной процесс | Сбор изменения → сопоставление → проверка → назначение → действие → результат |
Каталог объявлений не нужен: команде нужен единый объект контроля, чтобы изменение не терялось между источником, таблицей, чатом и сводкой.
Основной пользователь. Разбирает неоднозначные совпадения и потенциально важные изменения: подтверждает, отклоняет, объединяет или разделяет объекты.
Ограничение
Не должен просматривать все 18 000 записей: только исключения и сигналы, которые система не может закрыть сама.
Получает подтверждённые сигналы по территории, типу объекта или персональной подписке и фиксирует результат: контакт, обновление подбора, отложение с причиной.
Ограничение
Не видит весь поток рынка — только релевантные изменения своей зоны.
Смотрит отклонения: сигналы высокой важности без реакции, просроченные действия, перегруженных исполнителей.
Ограничение
Не должен собирать сводку по чатам и таблицам.
Подключает разрешённые источники, расписание обновлений, права, справочники территорий и базовые правила значимости.
Ограничение
Не меняет аналитические выводы сотрудников.
Рабочий день начинается не с анализа, а с восстановления картины рынка. Аналитик открывает несколько источников, повторяет одинаковые фильтры и просматривает новые карточки. Затем сверяет их с общей таблицей и пытается понять, является ли объявление новым или собственник изменил фотографии и заново разместил тот же объект.
Если цена изменилась, старое и новое значение записываются вручную. Если объявление исчезло, нельзя сразу определить причину: объект продан, снят с рекламы, заблокирован источником или будет опубликован заново. Чтобы передать наблюдение брокеру, аналитик копирует ссылку и комментарий в чат. Через несколько дней связь между сигналом и действием теряется.
Одна квартира появляется несколько раз: от собственника, от разных агентов, после снятия и повторной публикации. Сравнение идентификаторов источника создаёт ложные сигналы.
Снижение цены остаётся сообщением без владельца, срока и результата. Неясно, кому передали сигнал и связался ли брокер с собственником.
При повторном размещении старое объявление исчезает, новое начинает историю заново. Для объекта нужна непрерывная последовательность снимков.
Техническое исправление описания и исчезновение эксклюзивного предложения попадают в одну массу. Аналитик тратит внимание на шум.
В сводке видно количество найденных изменений, но не качество работы с ними: что не проверено, у чего нет ответственного, что просрочено.
Источник, таблица, чат, сводка
четыре версии одной ситуации
Нужен единый контур
изменение → объект → проверка → действие → результат
Корневая причина — отсутствие единого жизненного цикла наблюдаемого объекта. Пока изменения, проверка и реакция существуют отдельно, команда управляет сообщениями, а не объектами.
Основа сервиса — не лента объявлений, а карточка наблюдаемого объекта: публикации, история параметров, сигналы, решения сотрудников и следующее действие.
Система не принимает коммерческие решения за сотрудника. Она определяет, что изменилось, собирает доказательства и предлагает приоритет. Решение о контакте, корректировке подбора или изменении статуса остаётся у брокера либо аналитика. Жизненный цикл здесь — у сигнала изменения, а не у карточки гарантийного дефекта: там единица работы — замечание после передачи квартиры, здесь — рыночное событие до сделки.
Центральная карточка отделяет физический объект от его публикаций. Это позволяет хранить непрерывную историю даже при смене источника или идентификатора объявления. Это рыночная история публикаций, а не эксплуатационный паспорт уже введённого дома: УК ведёт осмотры и оборудование, агентство — снимки объявлений.
| Сущность | Назначение |
|---|---|
| Объект недвижимости | Устойчивая запись о квартире или доме: нормализованный адрес, параметры, статус наблюдения |
| Публикация | Конкретное объявление в источнике с внешним идентификатором и автором |
| Снимок состояния | Набор значений публикации на момент проверки — не техпаспорт коммерческой недвижимости, а версия объявления |
| Сигнал | Значимое изменение, требующее проверки или реакции |
| Подписка | Условия, по которым сотрудник получает релевантные сигналы |
| Действие | Решение сотрудника, срок, статус и результат реакции |
Если уверенности в совпадении недостаточно, система не объединяет записи молча. Она создаёт задачу аналитика с двумя карточками рядом и объясняет признаки сходства. Ошибочное объединение двух квартир искажает всю последующую историю.
Домашним экраном аналитика становится не обзорный dashboard, а рабочая очередь. Большую часть дня пользователь последовательно разбирает события, поэтому интерфейс оптимизирован под принятие решения, а не под наблюдение за графиками. Та же логика рабочей очереди, но другая единица: система размещения персонала закрывает заселение сотрудника, здесь — рыночный сигнал по лоту.
В верхней части — быстрые фильтры: «Новые объекты», «Изменение стоимости», «Снято», «Повторно опубликовано», «Возможный дубль», «Изменены характеристики». Рядом — территория, тип объекта, источник, уровень значимости и статус проверки.
Основная таблица содержит время обнаружения, тип изменения, адрес и краткие параметры, предыдущее и новое значение, уровень значимости, уверенность сопоставления, назначенного сотрудника, срок реакции и статус.
По выбору строки справа открывается контекстная панель без перехода на новую страницу: две версии карточки, связанные публикации, история последних событий и действия «Подтвердить сигнал», «Отклонить», «Объединить объекты», «Назначить брокеру». Такой паттерн «очередь + боковая панель» часто закладывают в разработку CRM на Laravel.
Цвет используется только как сигнал состояния. Красный — просрочка или критичная ошибка, янтарный — необходимость проверки, синий — новое событие, зелёный — подтверждённая обработка. Тип изменения всегда дублируется текстом и пиктограммой.
Руководителю не нужна полная техническая лента. Его экран показывает отклонения: сигналы высокой важности без реакции, просроченные действия и повторные события без решения. Управление по исключениям знакомо и управлению сетью парковок, только единица работы здесь — рыночное изменение, а не инцидент на площадке. Та же идея контроля отклонений, но не уборка: контроль качества клининга закрывает факт смены, здесь — реакцию брокера на сигнал.
В шапке карточки — адрес, тип объекта, статус наблюдения, ответственный и следующее действие. Ниже — вкладки «История», «Публикации», «Сигналы», «Действия» и «Данные».
На вкладке «История» события собраны в одну шкалу: первая фиксация, вторая публикация, подтверждение совпадения, изменение стоимости, назначение брокеру, снятие, повторное появление с другим идентификатором, результат проверки.
Сервис сохраняет снимки и вычисленную разницу, а не только текущее значение. Для снятых публикаций различаются «Не обнаружено при проверке», «Источник сообщил о завершении» и «Ошибка источника». Эти состояния нельзя автоматически трактовать как совершённую сделку.
Публикация не находит надёжного совпадения. Аналитик проверяет адрес, параметры и похожие карточки. Если совпадений нет — подтверждает создание объекта. Новый объект появляется один раз и сразу попадает релевантным сотрудникам.
Совпадают адрес и площадь, различаются этаж и часть фотографий. Аналитик видит карточки рядом и выбирает «Это один объект» либо «Разные объекты». Решение попадает в журнал и уточняет правила сопоставления.
Изменение стоимости превышает порог или объект связан с клиентским подбором. После подтверждения сервис назначает действие брокеру и срок реакции. Изменение становится контролируемым действием, а не сообщением в чате.
Публикация пропадает. Сначала ставится «Не обнаружена»; после повторной проверки — «Снято». Похожая публикация с новым идентификатором возвращается в прежнюю карточку объекта.
Руководитель видит события высокой значимости без реакции, просрочки и накопившиеся очереди. Он переназначает действие или запрашивает комментарий, не просматривая закрытые сигналы.
Первая версия замыкает один процесс полностью: от появления изменения в источнике до зафиксированного результата реакции сотрудника.
Эти функции не нужны, чтобы проверить основную гипотезу: станет ли работа с изменениями быстрее и управляемее, если у каждого события появятся контекст, статус, ответственный и результат.
Автоматизация строится на прозрачных правилах. Для каждого сигнала пользователь может увидеть, почему он создан и почему получил определённую значимость.
| Правило | Автоматическое действие | Исключение |
|---|---|---|
| Новая версия публикации отличается от предыдущей | Сохранить снимок и вычислить изменённые поля | Игнорировать технические поля и перестановку фотографий без изменения состава |
| Совпадают нормализованный адрес и устойчивые параметры | Предложить связь с существующим объектом | При конфликте этажа, площади или типа — отправить случай аналитику |
| Публикация отсутствует в одном цикле | Статус «Не обнаружена» | Не считать снятой до повторной проверки или явного статуса источника |
| Сигнал соответствует подписке | Определить получателя и рабочую группу | При нескольких возможных ответственных — очередь руководителя |
| Изменение превышает порог значимости | Повысить приоритет и сократить срок реакции | Аналитик может понизить приоритет с обязательной причиной |
| Срок действия истёк | Отметить просрочку и показать руководителю | Руководитель переназначает или закрывает с объяснением |
| Один источник временно недоступен | Повторить загрузку и показать состояние интеграции | Не создавать массовые сигналы о снятии до восстановления источника |
Приоритет не является непрозрачным «умным рейтингом». В MVP он считается по понятным факторам: тип и величина изменения, территория, связь с подпиской, активность объекта и срок с момента обнаружения.
MVP работает только с источниками, для которых у организации есть разрешённый способ получения данных:
Для каждого источника хранятся происхождение записи, время получения и технический статус. Если источник меняет структуру данных, импорт останавливается изолированно: уже сохранённая история объектов остаётся доступной.
Сервис не обходит ограничения доступа и не скрывает способ получения данных. Подключение каждого нового источника проходит отдельную проверку условий использования, состава полей, частоты обновления и допустимого срока хранения. Система не должна зависеть от способа сбора, который могут прекратить без предупреждения.
Аналитик одновременно работает с таблицей, фильтрами, панелью сравнения и локальным состоянием выбранной строки. Цвет ячейки сопровождается подписью статуса: янтарный означает «нужна проверка», а не «объект плохой». Просрочка видна отдельно от нового события.
Для MVP подходит единое Laravel-приложение в форме модульного монолита: бизнес-логика, фоновые процессы, интерфейс и интеграционные адаптеры разделены на предметные модули, но живут в одном контуре.
Client
React используется внутри Laravel через Inertia, а не как отдельный SPA. TypeScript снижает риск ошибок в структурах снимков и различий между состояниями. Отдельный публичный REST API на первом этапе не нужен: сессионная аутентификация Laravel.
Application
Модули: пользователи и доступ; источники и импорт; объекты и публикации; сопоставление; мониторинг снимков; подписки и сигналы; действия и контроль; отчёты и аудит.
Data
Полнотекстовый и trigram-поиск закрывают адреса и похожие записи без отдельного поискового движка на модельном объёме 18 000 объявлений.
Queue
Redis обоснован потоком регулярных импортов: задания разных источников выполняются параллельно, повторяются после временных ошибок и не блокируют интерфейс.
Infrastructure
Мониторинг нужен, чтобы рано увидеть остановившийся импорт. WebSocket, объектное хранилище медиа, микросервисы и Kubernetes на первом этапе не добавляются.
Доступ ограничивается рабочими группами и ролями. Брокер видит объекты и сигналы своей зоны, аналитик — очередь проверки, руководитель — действия команды, администратор — настройки источников. Критичные действия пишутся в аудит.
Pest покрывает нормализацию, сопоставление, переходы статусов, расчёт значимости, идемпотентность импорта и правила просрочки. Playwright — разбор сигнала, подтверждение дубля, назначение действия, фиксацию результата и контроль просрочки.
Проект внедряется не сразу на всю организацию, а через ограниченный рабочий контур. Срок до пилота — 12–13 недель.
Форматы двух приоритетных источников, единый вид районов и типов объектов, обязательные поля, примеры дублей. Вместе с аналитиками фиксируются первые правила значимости и причины закрытия сигналов.
Импорт, объекты, публикации, снимки, сопоставление, очередь изменений и карточка объекта. На тестовых выгрузках проверяется, что повторная загрузка не создаёт дубли и что временное исчезновение источника не превращается в массовое снятие.
Подписки, маршрутизация, сроки, уведомления и экран руководителя. Пилот: один аналитик, пять брокеров, один руководитель, два источника, одна категория и два района.
Разбор ложных сигналов, пороги, права, упрощение частых действий. Параллельное ведение старой таблицы — только на контрольный период, затем архив.
После пилота источники и рабочие группы подключаются поочерёдно. Для каждой новой территории проверяются качество адресов, доля неоднозначных совпадений и нагрузка на аналитика. Масштабирование останавливается, если очередь проверки растёт быстрее, чем команда успевает её разбирать.
Показатели ниже — целевые диапазоны демонстрационного сценария, а не результаты реального внедрения. Базовая линия собирается две недели до пилота, затем сравнивается с четырьмя неделями стабильной работы пилотной группы.
| Метрика | Модельное состояние до | Цель пилота | Как измеряется |
|---|---|---|---|
| Медианное время от получения изменения до обнаружения сотрудником | 1,5–3 часа | до 20 минут | Время появления данных в источнике и время создания сигнала |
| Ручные переходы между инструментами на одно изменение | 6–8 | 2–3 | Наблюдение за типовым сценарием |
| Доля сигналов высокой значимости без назначенного ответственного | 15–25% | менее 5% | Статусы сигналов на конец рабочего дня |
| Доля объектов с непрерывной историей после повторной публикации | 45–60% | более 85% | Выборка повторных публикаций |
| Медианное время подготовки оперативной сводки руководителя | 40–60 минут | менее 10 минут | Хронометраж подготовки одной сводки |
| Доля неоднозначных дублей, обработанных в срок | не измеряется | более 90% | Журнал задач аналитика |
Дополнительно на вручную проверенной выборке измеряются доля корректных автоматических связей и доля пропущенных дублей. Если качество ниже согласованного порога, система чаще отправляет случаи на ручную проверку и не компенсирует ошибку более агрессивным объединением.
| Риск | Вероятность | Влияние | Снижение |
|---|---|---|---|
| Источник меняет формат или прекращает выгрузку | Средняя | Высокое | Изолированные адаптеры, журнал импорта, раннее уведомление, отсутствие зависимости от одного источника |
| Низкое качество адресов создаёт лишние дубли | Высокая | Высокое | Нормализация, словарь адресов, порог уверенности и ручная проверка |
| Аналитик получает слишком много малозначимых сигналов | Средняя | Высокое | Пилотные правила, группировка однотипных изменений, разбор причин отклонения |
| Сотрудники продолжают вести параллельную таблицу | Средняя | Среднее | Ограниченный контрольный период, импорт стартовой истории, единые правила фиксации результата |
| Ошибочное объединение разных объектов искажает историю | Средняя | Высокое | Двухуровневое сопоставление, запрет автообъединения при конфликте полей, возможность отмены |
| Условия использования данных ограничивают мониторинг | Средняя | Высокое | Проверка разрешений до подключения, происхождение данных, отключаемый адаптер |
| Массовый сбой источника создаёт ложные события | Средняя | Высокое | Карантин аномальной выгрузки, повторная проверка, запрет массового снятия |
Следующие функции имеют смысл только после того, как накоплена качественная история объектов и сотрудники стабильно фиксируют результаты действий.
Было
Станет
Главное изменение — не ускорение просмотра объявлений. Сервис создаёт управляемый контур наблюдения: событие обнаруживается, связывается с объектом, проверяется, получает владельца и заканчивается зафиксированным решением. У агентства появляется не просто больше данных о рынке, а воспроизводимый процесс работы с изменениями.
Человеку остаётся часть работы, где нужен контекст и профессиональное решение. Машине передаются повторяющиеся операции: сбор состояний, сравнение версий, маршрутизация и контроль сроков. Аналитик занимается качеством сигналов, брокер — действиями по релевантным объектам, руководитель — отклонениями, которые требуют вмешательства.
Нужна разработка сервиса мониторинга объявлений, очереди изменений и карточки объекта, MVP на Laravel + Inertia — см. разработку на Laravel. Другие концепции — в каталоге решений (раздел «Решения» в навигации выше).
