Я не превращаю каждое обращение в поддержку в функцию продукта

Обращение в поддержку легко принять за готовый план развития продукта. Клиент пишет: «Добавьте кнопку», «Сделайте выгрузку», «Пусть система сама подставляет значение». Кажется, что всё уже решено: осталось поставить задачу команде.

Я стараюсь не делать этого сразу. Одно обращение говорит о неудобстве конкретного человека. Функция меняет жизнь всех пользователей и остаётся в продукте надолго. Между этими двумя вещами должна появиться работа мысли.

Запрос — это не правило

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

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

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

Что я смотрю до постановки задачи

Первое — повторяемость. Не количество одинаковых формулировок в чате, а одинаковость ситуации. Два клиента могут просить разные кнопки, но оба пытаются проверить, можно ли менять условия заказа после согласования. Это уже кандидат на правило продукта.

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

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

Поддержка полезна именно своей близостью к реальности

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

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

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

Иногда лучший ответ — не новая функция

После такого разбора запрос может привести к четырём разным действиям. Мы можем исправить подсказку в интерфейсе. Можем добавить право доступа. Можем описать редкий ручной порядок. И только четвёртый вариант — новая функция.

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

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

Короткая проверка перед тем, как сказать «сделаем»

• Какую задачу человек пытается закончить?
• Какое правило сейчас держится на памяти сотрудника поддержки?
• Увидим ли мы этот же сценарий у другой роли или компании?
• Что сломается, если действие выполнить не вовремя?
• Можно ли сначала сделать правило понятным, а не автоматическим?

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

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