# Нерабочие заявки: Причины и точка увода

Отчёт "Нерабочие заявки: Причины и точка увода" предназначен для детального анализа конверсии и причин потери <mark style="background-color:yellow;">**лидов**</mark>. Инструмент позволяет отследить путь заявки до момента перехода в нерабочий статус, помогая выявить наиболее критические этапы оттока и конкретные факторы отказа. Это позволяет оптимизировать работу на <mark style="background-color:yellow;">**воронке продаж**</mark> и повысить качество обработки входящего трафика.

<figure><img src="https://2409287958-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfkymnT1WRuXnrJRm6ZIO%2Fuploads%2FfhlAZTq7wLT4fsC3ew6V%2F%D0%BD%D0%B7%D0%BF%D0%B8%D1%82%D1%83%201.jpg?alt=media&#x26;token=f3810871-ec5f-499e-b586-62221b7623a1" alt=""><figcaption></figcaption></figure>

### Работа с отчётом

Для формирования точной выборки в отчёте предусмотрена гибкая система <mark style="background-color:purple;">**фильтров**</mark>. С их помощью вы можете сегментировать данные и сфокусироваться на конкретных показателях.

Основные фильтры:

* Дата создания заявки — устанавливает временной период, в который была создана заявка.
* Категория — позволяет выбрать [<mark style="background-color:yellow;">**типы объектов недвижимости**</mark>](#user-content-fn-1)[^1], указанные в заявках.
* Мин. срок увода — задает минимальное количество дней, прошедших с момента создания заявки до её перевода в <mark style="background-color:blue;">**нерабочий статус**</mark>. Этот фильтр позволяет исключить из анализа заявки, которые были переведены в нерабочий статус ранее указанного количества дней. Это помогает сфокусироваться на анализе тех обращений, с которыми проводилась длительная работа.
* Интерес к домам — ограничивает выборку по конкретным жилым комплексам или строениям.
* Отдел продаж — фильтрует данные по принадлежности заявок к конкретным офисам или отделам продаж.
* Причина увода — позволяет детально проанализировать заявки, закрытые по определенным причинам.
* Опции — содержит параметр «Уникальные первичные обращения», при активации которого из отчёта исключаются повторные заявки, оставляя только новые уникальные.

<figure><img src="https://2409287958-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfkymnT1WRuXnrJRm6ZIO%2Fuploads%2FfdTMkGPM2VgfoxIcXCBq%2F%D0%BD%D0%B7%D0%BF%D0%B8%D1%82%D1%83%202.jpg?alt=media&#x26;token=a90b719a-72e4-422a-95fa-9fc48b1c4655" alt=""><figcaption></figcaption></figure>

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

#### Ключевые особенности представления данных

Динамическое формирование столбцов. В таблицах отображаются только те [<mark style="background-color:blue;">**этапы**</mark>](#user-content-fn-1)[^1], на которых зафиксирован реальный отток заявок. Например, если из статуса <mark style="background-color:blue;">**Подбор**</mark> ни одна заявка не была переведена в категорию <mark style="background-color:blue;">**Отложенное**</mark>, соответствующий столбец в таблице «Отложенное» будет скрыт. Это избавляет отчёт от пустых ячеек и упрощает визуальный анализ.

Детализация до <mark style="background-color:yellow;">**подстатусов**</mark>. Отчёт учитывает не только <mark style="background-color:yellow;">**основные этапы воронки**</mark>, но и все настроенные в компании подстатусы[^1]. Это обеспечивает максимальную глубину анализа и позволяет видеть точную точку увода заявки.

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

Для удобства дальнейшей работы каждая из [трёх таблиц](#user-content-fn-1)[^1] снабжена индивидуальной кнопкой «Экспорт».

<figure><img src="https://2409287958-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfkymnT1WRuXnrJRm6ZIO%2Fuploads%2F42GHpg9P03KkmP37HsQW%2F%D0%BD%D0%B7%D0%BF%D0%B8%D1%82%D1%83%203.jpg?alt=media&#x26;token=eab9d555-da58-4c02-a3d6-3c41e46b7410" alt=""><figcaption></figcaption></figure>

Это позволяет выгружать данные в Excel-формате по каждой категории отдельно. Файлы сохраняют структуру веб-интерфейса, что исключает необходимость дополнительной ручной сортировки или разделения общего массива данных.

### Технический паспорт отчёта

В основе отчёта лежит анализ [<mark style="background-color:yellow;">**истории изменений**</mark>](#user-content-fn-1)[^1]. Система фиксирует момент перехода заявки из активной фазы воронки в «терминальное»[^1] состояние: Нецелевые, Отложенное или Отказ.

Поскольку отчет базируется на группировке заявок, прошедших идентичный путь — от конкретного исходного этапа к причине закрытия — его логику можно выразить через программный код. Ниже представлен типовой SQL-запрос. С его помощью вы можете получить точные количественные показатели по каждому менеджеру, адаптировав параметры под конкретные задачи вашего анализа.

Принцип выбора данных в <mark style="background-color:purple;">**MacroData**</mark> без учёта дополнительных фильтров:

```sql
SELECT    
    users.users_name, 
    COUNT(estate_buys.id) AS total_leads 
FROM 
    estate_buys 
JOIN 
    users ON estate_buys.manager_id = users.id 
JOIN 
    estate_buys_statuses_log ON estate_buys.id = estate_buys_statuses_log.estate_buy_id 
JOIN 
    estate_statuses_reasons ON estate_buys.status_reason_id = estate_statuses_reasons.status_reason_id 
WHERE   
    estate_buys.status = 3  
    AND estate_buys_statuses_log.status_from = 30  
    AND estate_statuses_reasons.name = 'Уже купили' 
GROUP BY 
    users.users_name;
```

Вы можете изменять параметры фильтрации в SQL-запросе, чтобы получить данные по другим статусам или причинам. Вносите изменения в следующие строки блока WHERE:

* **Текущий статус заявки.** `estate_buys.status = 3` Замените число 3 на ID интересующего вас итогового статуса. Список всех ID и соответствующих им названий приведён в таблице ниже.
* **Исходный статус (откуда перешла заявка).** `AND estate_buys_statuses_log.status_from = 30` Замените число 30 на ID статуса, из которого была [переведена заявка](#user-content-fn-1)[^1].
* **Фильтрация по подстатусам.** Если вам необходимо найти заявки, которые перешли из конкретного подстатуса, замените строку с `status_from` на следующую: `AND estate_buys_statuses_log.status_custom_from = 'Платная бронь'` Вместо 'Платная бронь' впишите точное наименование нужного вам подстатуса в одинарных кавычках.
* **Причина закрытия заявки.** `AND estate_statuses_reasons.name = 'Уже купили'` Замените текст 'Уже купили' на любую другую [причину, зафиксированную в вашей системе](#user-content-fn-1)[^1]. Текст должен быть написан в одинарных кавычках и в точности совпадать с названием в справочнике.

#### Таблица статусов по ID

<table data-header-hidden><thead><tr><th width="100">ID</th><th width="236">Наименование статуса</th></tr></thead><tbody><tr><td>0</td><td>Удалено</td></tr><tr><td>1</td><td>В архиве</td></tr><tr><td>2</td><td>Служ.процесс</td></tr><tr><td>3</td><td>Нецелевой</td></tr><tr><td>4</td><td>Отказ</td></tr><tr><td>5</td><td>Неразобранное</td></tr><tr><td>7</td><td>Оценка</td></tr><tr><td>8</td><td>Необходим обзвон</td></tr><tr><td>10</td><td>Проверка</td></tr><tr><td>15</td><td>Отложено</td></tr><tr><td>20</td><td>Подбор</td></tr><tr><td>30</td><td>Бронь</td></tr><tr><td>32</td><td>Маркетинговый резерв</td></tr><tr><td>40</td><td>Сделка расторгнута</td></tr><tr><td>50</td><td>Сделка в работе</td></tr><tr><td>52</td><td>Маркетинговая сделка</td></tr><tr><td>53</td><td>Сделка в работе *</td></tr><tr><td>90</td><td>Сдано</td></tr><tr><td>100</td><td>Сделка проведена</td></tr></tbody></table>

<br>

[^1]:


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.macrodigital.ru/manual/macrocrm/otchety/nerabochie-zayavki-prichiny-i-tochka-uvoda.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.