[БФТ] Интеграция ЛК агента с ТрендАгент по проверке контакта на уникальность

1. Служебная информация

Заказчик: Ткаченко Алексей
Продакт: 
Бизнес-аналитик: Николаев Николай Евгеньевич 
Руководитель IT-проекта: Бугакова Елизавета
Дата создания: 04.12.2025

Глоссарий

ЛК АН — Личный кабинет агента недвижимости.
ТрендАгент (ТА) — агрегатор/платформа, через которую агентства подают заявки.
Фиксация клиента — процесс проверки уникальности клиента по телефону и фиксация его за агентом.
Уникальность — возможность агента работать с клиентом и получать комиссионные от Догмы.
API фиксации — точка интеграции для проверки и фиксации клиента, описанная в файле спецификации.
ООО «Платформа Юг» — юрлицо, под которым ТрендАгент заведен в ЛК АН.

2. Контекст и цели

2.1. Описание проблемы

Сейчас проверка уникальности клиента выполняется вручную: сотрудник ТрендАгент каждый раз заносит данные в ЛК АН, ожидает ответ и вручную возвращает результат в свою систему, что приводит к высокой нагрузке, задержкам, ошибкам и негативному опыту агентов.

2.2. Цель

Автоматизировать процесс проверки уникальности и фиксации клиентов между ТрендАгент и ЛК АН, чтобы агенты могли самостоятельно и быстро выполнять эти операции прямо в личном кабинете ТрендАгента, с возможностью масштабирования на все регионы и корректной обработкой промежуточных статусов.

3. Зависимости, ограничения и р  иски

3.1. Зависимости и интеграции

• API интеграция ТА:
  https://documenter.getpostman.com/view/15642583/2sAY4vg2j9#50f994d3-4fcb-4b50-99fb-8d6b285a63d8

• ЛК ТрендАгент: инициатор запросов.

• Внутренние модули Догма:

  • механизм проверки уникальности;

  • модуль фиксации клиента;

  • модуль ручной проверки менеджерами;

  • бизнес-правила расчёта сроков фиксации.

• Служба безопасности Dogma — должна одобрить интеграцию внешнего сервиса (ограничения на API-доступ).

3.2. Ограничения и риски

• Регуляторика: передача персональных данных (ФИО, телефон) → требования 152-ФЗ.

• В Догма используется логика ручной модерации в ЦФО — может противоречить ожиданию «моментального ответа».

• Риск DDOS-атак.
  
  

4. Модели процессов

4.1. Процесс AS IS 

1. Агент отправляет заявку в ТА.

2. Оператор ТА вручную создает лид в ЛК АН, заполняя данные клиента( Телефон клиента, Имя клиента, Объект недвижимости, Комментарий "Клиенту не звонить. Связь через агента 'Имя агента' 'Телефон агента'").

3. ЛК АН производит проверку и возвращает результат (Контакт уникален/Контакт не уникален/ Проверка контакта).

4. Для ЦФО в случае пересечения номера телефона с лидами в Б24 происходит ручная проверка оператором КЦ Догмы. Во время проверки лид в ЛК АН имеет статус "Проверка контакта".
5. В случае уникальности клиента в ЦФО создается лид в Б24 - фиксация на 20 дней за агентством, по другим регионам лид в Б24 не создается.

6. Оператор ТА просматривает статус полученный в ЛК АН, затем устанавливает статус в интерфейсе ТА. Если лид имеет статус "Контакт не уникален" то устанавливает "Неуникальный".
   Если лид имеет статус "Контакт уникален", то:
   - для ЦФО устанавливает статус "Зафиксирован" и устанавливает дату фиксацию 20 дней
   - для остальных регионов устанавливает статус "Уникальный - не зафиксирован"

7. Агент получает решение.
   
   

4.2. Процесс TO BE

1. Агент отправляет заявку в ТА.

2. ТА автоматически формирует запрос к API ЛК АН на создание лида( Телефон клиента, Имя клиента, Объект недвижимости, Комментарий "Клиенту не звонить. Связь через агента 'Имя агента' 'Телефон агента'").

3. ЛК АН производит проверку и отправляет ответ ТА (Контакт уникален/Контакт не уникален/Проверка контакта)

4. ТА получает ответ API и отображает его агенту(Статус и Дату фиксации, если она есть).

5. При статусе «Проверка контакта»  после изменения статуса ЛК АН передает актуальный статус статус.

5. Бизнес-требования

5.1. Пользовательские истории (US)

US1. Как агент, я хочу в интерфейсе ТА мгновенно проверять уникальность клиента, чтобы понимать, могу ли я работать с ним.

US2. Как оператор ТА, я хочу избавиться от ручного ввода в ЛК Dogma, чтобы избежать ошибок и ускорить обработку лидов.

5.2. Функциональные требования

1. Автоматическая проверка клиента
   Система должна автоматически передавать данные клиента из ТА в ЛК АН и получать результат проверки уникальности без участия сотрудников.

2. Возврат статуса проверки
   Система должна возвращать один из статусов:

   • Контакт уникален;

   • Контакт не уникален;

   • Проверка контакта.

3. Поддержка ручной модерации
   Если по внутренним правилам Догмы требуется участие менеджера, система должна уметь передавать статус ожидания ручной проверки(Проверка контакта) и предоставлять возможность получать итоговый результат позже(Контакт уникален/Контакт не уникален).
4. Передача даты фиксации
   Если объект фиксируется по внутренним правилам Догмы, то система должна передавать данные о крайней дате фиксации.

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

6. Корректная обработка ошибок
   В случае некорректных данных или технических проблем система должна возвращать понятные и однозначные статусы ошибок, чтобы ТА мог корректно уведомить пользователей.

5.3. Нефункциональные требования

1. Защита данных согласно 152-ФЗ.

5.4. Критерии приемки

1. При запросе от ТА API возвращает корректный статус.

2. В ЛК АН корректно фиксируется лид, созданный ТА.

3. После ручной проверки(Проверка контакта) обновленный статус лида(Контакт уникален/Контакт не уникален) передается ТА.

4. Если объект фиксируется, то крайняя дата фиксации передается ТА.

5. Сотрудник ТА полностью не участвует в проверке уникальности.
   
   

6. Соответствие статусов систем

7. Артефакты

1. Запись процесса работы оператора ТА без фиксации: https://disk.360.yandex.ru/d/Bjuu8wtNdbvnfA
2. Запись процесса работы оператора ТА с фиксацией: https://disk.360.yandex.ru/i/SGVnlUXfncnMZQ