Отказать нельзя выполнить: что делать с хотелками клиентов

Разберитесь, что клиенту нужно на самом деле

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


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


Когда ситуация стала критической, подключилось руководство компании. У клиента начали выяснять: «Зачем?». После ряда вопросов выяснилось, что ему нужно просто отслеживать SLA сотрудников второй линии. Но для этого не нужен метод API, это вообще никак не связано. Стало понятно, что у нас в системе уже есть то, что ему нужно, просто он об этом не знал.


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

Катерина Виноходова

Кофаундер Юздеска

Наш лайфхак: как понять, что нужно клиенту

Когда клиент приходит с запросом, мы выясняем три ключевых момента:

КОГДА: описываем ситуацию, в которой пользователю понадобилась новая фича.

Я ХОЧУ: описываем работу, которую нужно выполнить пользователю без привязки к нашему сервису

ЧТОБЫ: цель, для чего нужно выполнять эту работу. Цель никак не связана с сервисом. Это помогать нам понять, чего пользователь хочет в итоге, а не делать фичу ради фичи.

Например:

КОГДА: в нерабочее время, когда обращается вип-пользователь.

Я ХОЧУ: чтобы руководитель получал уведомления в телеграм.

ЧТОБЫ: быстро реагировать — сразу увидеть обращение пользователя и ответить на него.

Чтобы глубоко разобраться в задаче, часто нужно много времени. Иногда приходится разговаривать с клиентом по 20 минут чтобы выяснить эти три вещи: А зачем? А если вот так? А вот это решило бы эту задачу? У саппорта нет столько времени. Если попадается задача, в которой не удаётся быстро разобраться, оператор передаёт её нашему специалисту Customer Success. Он отдельно связывается с клиентом и выясняет, какие задачи он хочет решить.

Зафиксируйте массовость и адекватность запроса

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

Два клиента хотят одну и ту же фичу. Как только появится третий, продакт отправит запрос на рассмотрение

Установите порядок принятия решений по хотелкам клиентов

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

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

Вы можете установить свой график и механизм рассмотрения хотелок — главное, чтобы он был и работал.

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

Отказывайте клиентам правильно

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