Я не прячу ручной обход в SaaS — сначала выясняю, чего не хватает продукту

Я не считаю ручной обход в SaaS мелочью, которую можно тихо оставить команде. Если клиенту регулярно помогают сделать важное действие, это уже часть продукта. Просто она пока живёт в чате, таблице или в голове у сотрудника.

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

Обход — это не всегда просьба о новой кнопке

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

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

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

Когда ручная работа ещё полезна

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

Важно назвать это именно временным режимом. У него должны быть владелец, понятная точка проверки и способ собрать наблюдения. Иначе временное решение незаметно становится обещанием клиенту.

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

Три вопроса перед тем, как автоматизировать обход

Первый: одинаково ли люди приходят за помощью? Если каждый раз речь о своём, строить общий механизм рано. Второй: можно ли объяснить решение правилом? Фраза «опытный менеджер понимает по ситуации» — сигнал, что правило ещё не достали на свет. Третий: что изменится после автоматизации для клиента и для команды? Не «станет удобнее», а, например, «клиент сам завершит подключение без ожидания ответа».

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

Как не потерять сигнал

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

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

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

Пример без героизма

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

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

Что я считаю хорошим результатом

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

Не все обходы надо превращать в продукт

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

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

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

Как связать наблюдение с планом развития

Я не предлагаю переносить журнал обходов прямо в backlog. В нём сначала должны появиться гипотеза и проверка. Например: «клиент не завершает настройку, потому что не видит, кто должен подтвердить приглашение». Для такой гипотезы можно посмотреть путь, позвать нескольких пользователей на короткий разговор или проверить записи поддержки. Только потом выбирать форму: подсказка, изменение роли, новый статус или функция.

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

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

Разговор с поддержкой, который даёт материал продукту

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

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

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