Я начинаю рабочий экран B2B-продукта с очереди решений, а не с дашборда

Я начинаю рабочий экран B2B-продукта не с виджетов и не с красивой сводки. Сначала ищу момент, в котором человеку нужно принять следующее решение. Если этот момент не виден, экран обычно превращается в витрину: цифр много, а работать всё равно приходится в переписке и Excel.

В корпоративном продукте человек редко приходит «посмотреть данные». Он должен подтвердить заказ, разобраться с исключением, передать задачу, заметить просрочку или понять, почему план не сходится с фактом. Хороший экран не обязан быть бедным. Он обязан помогать не тратить силы на поиск того, что делать прямо сейчас.

Начинаю с очереди решений

Представим менеджера, который утром открывает систему. Перед ним двадцать заказов, несколько запросов от клиентов и пара проблем со сроками. Если система показывает только общий оборот и красивые диаграммы, менеджер всё равно будет звонить коллегам: «Что у нас горит?»

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

Это похоже на стол мастера. Инструменты могут лежать в идеальном порядке, но если на стол не положили деталь, которую нужно обработать следующей, порядок мало помогает. В B2B-продукте «деталь» — это конкретная рабочая ситуация.

Одна очередь не должна быть общей для всех

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

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

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

Не путать срочное с заметным

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

Я стараюсь для каждой строки очереди ответить на четыре простых вопроса:

• что случилось;
• кто должен решить вопрос;
• что он может сделать из этой точки;
• когда решение перестанет быть своевременным.

Если ответа нет хотя бы на один вопрос, это обычно не задача, а сырые данные. Их можно положить в журнал, но не стоит выдавать за рабочую очередь.

Контекст важнее количества полей

Когда экран не помогает, в него часто добавляют ещё колонок. Это почти всегда увеличивает усталость. Лучше показать рядом с решением ровно тот контекст, который меняет выбор. Для заказа это может быть обещанная дата, остаток и последний комментарий клиента. Для согласования — сумма, основание и последствия задержки. Всё остальное должно открываться по запросу.

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

Где очередь заканчивается

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

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

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

Проверка без большого редизайна

Не нужно сразу рисовать весь новый интерфейс. Я бы выбрал один повторяющийся рабочий день и попросил трёх людей показать, как они начинают смену, где останавливаются и кого спрашивают. Потом можно собрать прототип очереди из настоящих ситуаций, даже без автоматизации.

Через неделю видно главное: какие строки закрываются сами, какие постоянно пересылаются, а какие оказываются вообще не нужны. Это честнее, чем спорить о цветах карточек на макете.

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

Рабочий экран B2B-продукта становится хорошим не тогда, когда в нём нечего добавить. Он хорош, когда человеку не нужно расшифровывать, что система ждёт от него. А уже после этого можно обсуждать отчёты, настройки и более сложные сценарии.

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