Я думала, что в системе одна статусная модель. Оказалось — три. И это объясняло все проблемы с поддержкой

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

Я пошла другим путём: сначала попробовала понять, почему пользователи вообще не понимают статус.

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

Но поддержка регулярно получала однотипные обращения: «Моя заявка в статусе X уже N дней. Что происходит?» Стандартные решения — «добавить подсказку», «переформулировать статус» — давали временный эффект. Проблема возвращалась.

Взяла список всех статусов и для каждого задала один вопрос: откуда этот статус берётся? Не «что он означает для пользователя», а именно — какая система или логика его устанавливает?

И здесь началось интересное.

Оказалось, что за единым интерфейсом работают три независимые статусные модели параллельно:

Внутренняя — состояния самой системы: заявка принята, обрабатывается, закрыта. Переходы по внутренним триггерам.

Интеграционная с внешним сервисом — статусы, которые приходят от внешней системы. У неё своя логика, свои задержки. Она может «молчать» несколько дней — и это штатная ситуация для неё, но аномалия с точки зрения пользователя.

Интеграционная с внутренним сервисом — ещё один участник цепочки, который живёт по собственному расписанию.

Все три агрегировались в одно слово — «В обработке». Пользователь не мог понять: это норма или что-то застряло?

Вместо одного агрегированного статуса стали показывать три параллельных — по одному от каждой модели.

Это противоречит совету «не перегружать пользователя». Но здесь важно различать сложность и прозрачность. «Ожидает подтверждения от внешнего сервиса» — это не сложно. Это понятно. Пользователь знает, что происходит, и знает, что ему делать.

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

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

Если в вашем продукте пользователи регулярно спрашивают «что с моей заявкой» — возможно, у вас не одна статусная модель, а несколько. Стоит проверить.