Иллюзия пожара: что делать, когда баги не чинят, а на клиентов всем пофиг
Статья для профессиональных обманщиков, которые просят дать время, но сами не верят, что что-то починится.
Евгений работает в поддержке. Каждый день он заваривает чай, садится к компу и открывает хелпдеск. В топе обращений один и тот же баг.
Эта задача мелькает у него перед глазами по сто раз на дню. Жалобы всегда одинаковые: «У вас опять ничего не работает» и «Исправьте немедленно».
Евгений отвечает по скрипту: «Мы передали задачу разработчикам, спасибо за терпение». И чувствует, что врёт. Он знает, что таск лежит в трекере третий год. Никто его даже не открывает.
Женя благодарит за терпение сто раз в день. У него складывается странное ощущение: с одной стороны, компания выпускает апдейты, новые разделы, красивые интерфейсы, даже какие-то презентации для инвесторов. С другой — саппорт вечно получает по шапке, а баги так и лежат мёртвым грузом.
Евгению кажется, что компании на клиентов плевать. Что разработчики делают чёрт-те что вместо реальной пользы. А он сам сидит и собирает в панамку чужое раздражение. Ну и зачем такая работа?
Эта задача мелькает у него перед глазами по сто раз на дню. Жалобы всегда одинаковые: «У вас опять ничего не работает» и «Исправьте немедленно».
Евгений отвечает по скрипту: «Мы передали задачу разработчикам, спасибо за терпение». И чувствует, что врёт. Он знает, что таск лежит в трекере третий год. Никто его даже не открывает.
Женя благодарит за терпение сто раз в день. У него складывается странное ощущение: с одной стороны, компания выпускает апдейты, новые разделы, красивые интерфейсы, даже какие-то презентации для инвесторов. С другой — саппорт вечно получает по шапке, а баги так и лежат мёртвым грузом.
Евгению кажется, что компании на клиентов плевать. Что разработчики делают чёрт-те что вместо реальной пользы. А он сам сидит и собирает в панамку чужое раздражение. Ну и зачем такая работа?
Почему баги не чинят
Может показаться, что если задачу не трогают годами, то всем на неё плевать. Чаще причина в другом: у разработки приоритизация устроена так, что мелкие баги тонут в потоке крупных задач, техдолг копится. Есть бизнес-фичи, «сделай срочно», проекты для инвесторов и маркетинга — всё это уходит в работу раньше, чем проблема, которая глючит у пары процентов пользователей.
Вот и не чинится таска с багом: лежит, стареет, обрастает комментариями, но каждый спринт её снова обходят стороной. Всё новое и громкое побеждает старое и мелкое.
Так формируется иллюзия наплевательского отношения. На самом деле у разработчиков просто нет процесса, который заставляет чинить мелочи регулярно, как мыть посуду сразу после еды. В итоге саппорт получает сотни жалоб, а разработчики ничего не делают. Дело не в лени и не в равнодушии.
Может показаться, что если задачу не трогают годами, то всем на неё плевать. Чаще причина в другом: у разработки приоритизация устроена так, что мелкие баги тонут в потоке крупных задач, техдолг копится. Есть бизнес-фичи, «сделай срочно», проекты для инвесторов и маркетинга — всё это уходит в работу раньше, чем проблема, которая глючит у пары процентов пользователей.
Вот и не чинится таска с багом: лежит, стареет, обрастает комментариями, но каждый спринт её снова обходят стороной. Всё новое и громкое побеждает старое и мелкое.
Так формируется иллюзия наплевательского отношения. На самом деле у разработчиков просто нет процесса, который заставляет чинить мелочи регулярно, как мыть посуду сразу после еды. В итоге саппорт получает сотни жалоб, а разработчики ничего не делают. Дело не в лени и не в равнодушии.
Всё правда так плохо?
Если копнуть глубже, всё не так ужасно.
Долю клиентов, которые обращаются в саппорт (звонят, пишут, чатятся) относительно общего числа пользователей, называют Contact Rate (CR). Мне не удалось найти ни одного большого исследования, которое показало бы, какая доля обращающихся считается средней в области. Но по моему опыту и опыту знакомых руководителей больших поддержек, 80–90% клиентов вообще не обращаются в саппорт. Среди них есть и те, кто тоже сталкивается с багами, но им лень о них писать, и те, у кого всё хорошо.
А вот какие данные есть: в среднем 68% тикетов по данным Surveypal решаются при первом обращении, без тягомотины, а 75% пользователей по статистике Plivo очень даже удовлетворены общением с саппортом.
Просто нам не видно ни больших цифр, ни людей, у которых всё ок с продуктом. Мы сидим внутри пожара, поэтому кажется, что горит вообще всё. Если поднять голову и посмотреть шире, оказывается:
Просто мы видим то, что стоит за цифрами в красивых презентациях у менеджеров.
Если копнуть глубже, всё не так ужасно.
Долю клиентов, которые обращаются в саппорт (звонят, пишут, чатятся) относительно общего числа пользователей, называют Contact Rate (CR). Мне не удалось найти ни одного большого исследования, которое показало бы, какая доля обращающихся считается средней в области. Но по моему опыту и опыту знакомых руководителей больших поддержек, 80–90% клиентов вообще не обращаются в саппорт. Среди них есть и те, кто тоже сталкивается с багами, но им лень о них писать, и те, у кого всё хорошо.
А вот какие данные есть: в среднем 68% тикетов по данным Surveypal решаются при первом обращении, без тягомотины, а 75% пользователей по статистике Plivo очень даже удовлетворены общением с саппортом.
Просто нам не видно ни больших цифр, ни людей, у которых всё ок с продуктом. Мы сидим внутри пожара, поэтому кажется, что горит вообще всё. Если поднять голову и посмотреть шире, оказывается:
- большинство людей спокойно пользуются продуктом;
- большинство тикетов решаются быстро;
- большинство пользователей довольны нашей работой.
Просто мы видим то, что стоит за цифрами в красивых презентациях у менеджеров.
Что делать саппорту
Евгений расстроен, потому что думает, что польза саппорта измеряется в количестве багов, с которыми он смог помочь. Евгений не прав.
Управляйте последствиями
Вы не можете заставить разработку починить баг, но только вы можете решить, как к багу отнесётся юзер. Это не значит, что пользователь с критичным багом выйдет из поддержки счастливым, но согласитесь: если бы на обращение с багом вообще никто не ответил, было бы ещё хуже. Вы управляете человеческой реакцией на сбой.
Помогайте людям, а не закрывайте тикеты
Ваша задача — не решить тикет (это не всегда в вашей власти), а помочь человеку с проблемой. Его проблема — не баг, а стресс, потраченное время и ощущение, что его кинули. Вот эти и занимайтесь: посочувствуйте, дайте статус, предложите обходной путь.
Требуйте не починки бага, а информации
Если таска висит годами, вы вряд ли добьётесь её закрытия. Получите хотя бы статус по багу: «Это баг, его не будут чинить, вот так отвечайте» или «Вот примерные сроки». Боритесь за прозрачность: это даст вам опору и избавит от чувства, что вы постоянно врёте.
Смотрите на тикеты как менеджер
Ваша роль — не собирать возмущение в панамку, а анализировать и передавать данные туда, где они пригодятся.
❌ Клиенты опять ругаются, сколько можно, один негатив
✅ Баг № 4873 генерирует 70 тикетов в неделю, что стоит нам 25% от общего числа негативных отзывов
Так вы из жертвы становитесь сейсмографом.
Евгений расстроен, потому что думает, что польза саппорта измеряется в количестве багов, с которыми он смог помочь. Евгений не прав.
Управляйте последствиями
Вы не можете заставить разработку починить баг, но только вы можете решить, как к багу отнесётся юзер. Это не значит, что пользователь с критичным багом выйдет из поддержки счастливым, но согласитесь: если бы на обращение с багом вообще никто не ответил, было бы ещё хуже. Вы управляете человеческой реакцией на сбой.
Помогайте людям, а не закрывайте тикеты
Ваша задача — не решить тикет (это не всегда в вашей власти), а помочь человеку с проблемой. Его проблема — не баг, а стресс, потраченное время и ощущение, что его кинули. Вот эти и занимайтесь: посочувствуйте, дайте статус, предложите обходной путь.
Требуйте не починки бага, а информации
Если таска висит годами, вы вряд ли добьётесь её закрытия. Получите хотя бы статус по багу: «Это баг, его не будут чинить, вот так отвечайте» или «Вот примерные сроки». Боритесь за прозрачность: это даст вам опору и избавит от чувства, что вы постоянно врёте.
Смотрите на тикеты как менеджер
Ваша роль — не собирать возмущение в панамку, а анализировать и передавать данные туда, где они пригодятся.
❌ Клиенты опять ругаются, сколько можно, один негатив
✅ Баг № 4873 генерирует 70 тикетов в неделю, что стоит нам 25% от общего числа негативных отзывов
Так вы из жертвы становитесь сейсмографом.
Выгорание наступает, когда вы пытаетесь пробить головой стену системных проблем. Перестаньте это делать.
Рассмотрите эту стену повнимательнее. Нанесите на карту каждую трещину — сколько тикетов приходит из-за старого бага, какого именно, какой ущерб это наносит клиентскому опыту. Формулируйте проблему не как «вот опять этот баг!», а как отчёт для руководства: «Проблема X генерирует Y обращений в неделю, что отнимает Z часов у команды и создаёт N% негативных отзывов. Предлагаю запросить у разработки чёткий статус по задаче».
Это вернёт чувство контроля и смысл в рутину. Не бейтесь об стену головой: составьте план стены, чтобы показать его тем, у кого есть молоток.
Это вернёт чувство контроля и смысл в рутину. Не бейтесь об стену головой: составьте план стены, чтобы показать его тем, у кого есть молоток.
📚 Эти ссылки подобрали для вас вручную:
Как отдыхать, чтобы отдохнуть
Если вы уже отлежали себе бока диваном и готовы с него подняться, время задуматься о качественном отдыхе: регулярных приятных делах, который вы запланируете и устроите себе сами.
Как не утонуть в рутине работы в поддержке
Поддержка — это не только бесконечные тикеты и шаблонные ответы. Делайте работу живее и интереснее — для себя и для пользователей. Собрали классные способы не сгореть в рутине, прокачать скиллы и даже получать кайф от процесса.
«Ой, мы не хотели»: кризисные ситуации в работе поддержки
«Ой, это было не вам» — фраза, которая хотя бы раз заставляла кровь стынуть в жилах любого саппорта. Ещё не отправляли клиенту скриншот своего чата с подругой вместо ответа по тикету? Ваш час придёт. Встретьте его во всеоружии.