Статус: текущий этап договора

Статус — это текущий этап договора: «рассчитать стоимость», «назначить выезд», «выполнен», «рекламация». Сам статус ничего не выполняет — он работает как переключатель: от него зависят доступные задачи, расчёты, автоматизации и набор фильтров.

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

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

С чем связан

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

Зависимость односторонняя: договор зависит от статуса, а статус от договора — нет.

Какие данные хранит

название статуса;
порядок и визуальные параметры (цвет, иконка);
ссылку на родительский статус — она задаёт уровень в последовательности обработки.

Иерархия статусов — это не жёсткая воронка с автоматическими переходами, а свободная структура под процессы компании. На практике складывается шаблон из нескольких уровней: первичная обработка заявки (рассчитать, предложить, уточнить), основной цикл выполнения (забрать, обработать, отвезти, закрыть) и отдельные процессы вне цикла (рекламация и её обработка). Количество и смысл уровней целиком определяет администратор — система структуру не предписывает.

Как это настраивается

Статусы создаёт администратор на этапе настройки системы и добавляет новые по мере появления новых процессов. На каждом статусе задаются название, порядок, цвет и место в дереве уровней (через родительский статус). Сотрудники со статусами как со справочником не работают — они только присваивают их договорам в ходе обычной работы.

Как участвует в процессах

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

Правила и ограничения

нельзя выполнить задачу на неподходящем статусе;
нельзя запустить расчёт, если статус не разрешён;
нельзя назначить типовую задачу вне допустимого статуса;
фильтры договора и товаров или услуг не показываются вне подходящего статуса.

Типичные сценарии

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

Оператор переводит договор на «Назначение выезда» — появляются фильтры этого этапа («Адрес», «Удобный день»), а автоматика создаёт задачу водителю.

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

Примеры настройки

Трёхуровневый процесс. Уровень первичной обработки — «Рассчитать стоимость», «Сделать предложение», «Уточнить решение»; основной цикл — «Забрать», «Обработать», «Отвезти», «Закрыть»; отдельные процессы — «Рекламация», «Забрать рекламацию», «Вернуть». Каждый верхнеуровневый статус становится родителем для своих, порядок задаёт последовательность в списке.

Статус под автоматику и фильтры. На статус «Назначение выезда» настраивают появление фильтров «Адрес» и «Удобный день» и автоматическую задачу водителю — как только договор попадает на этот статус, поля и задача появляются сами.

Частые вопросы и подводные камни

Можно ли переименовать статус, если на него уже навешана автоматика? Да. Задачи, расчёты и фильтры привязаны к самому статусу, а не к его тексту, поэтому переименование меняет только подпись и не ломает настроенную логику.
Что произойдёт при изменении родительского статуса — переедут ли договоры? Нет. Родительский статус задаёт лишь место в дереве уровней; договоры привязаны к конкретному статусу, а не к его родителю, и сменой родителя не перемещаются.
Иерархия или плоский список — что лучше? Иерархия удобна, когда процессов несколько (основной цикл, рекламация и т. п.) и их нужно визуально сгруппировать. Если этапов немного, плоский список проще. Система не навязывает ни того, ни другого.
Что будет, если убрать статус из условий типовой задачи, но он уже стоит на договорах? Изменение условий влияет на будущую доступность шаблона — уже созданные задачи на договорах это не затрагивает, они живут по правилам, действовавшим при создании.

Диагностика: статус ведёт себя не так, как ожидалось

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

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