Привет, Хабр и коллеги-техписы! Я Оля Исхакова, работаю техническим писателем в Т-Банке. Мы с командой занимаемся развитием документации для внутренних продуктов, пишем коммуникации, анализируем пользовательский путь и предлагаем идеи по улучшению интерфейсов. 

Расскажу историю о том, как мы доказали на цифрах, что документация приносит пользу бизнесу.

Как понять, куда идти

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

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

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

Как команда технических писателей начала мерить качество документации. Эволюция редакции на примере человечества
Привет! Я Оля Коршунова, лид первой редакции технических писателей в Т-Банке. Боль технических писат...
habr.com

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

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

Направо пойдешь — поддержку при крупном заезде спасешь

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

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

Как мы это сделали:

  • Бизнес-аналитик выгрузил обращения в поддержку за месяц, вручную отсортировал их: отделил технические вопросы типа «Сервис не работает, что делать?» от консультационных — «Как посмотреть расписание моей группы?».

  • Определили, какой процент от общего количества обращений составляют консультационные вопросы — 26%.

  • Провели модерируемое UX-тестирование доки на 10 пользователях: посмотрели, все ли вопросы покрываются. Те, что не покрывались, добавили перед публикацией.

Результат: через месяц после публикации доки количество консультационных вопросов не только не увеличилось, но и сократилось с 26 до 11,6%. Мы были в восторге от такого результата, а продуктовая команда с головой ушла в развитие сервиса.

Налево пойдешь — время бизнес-аналитику сэкономишь

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

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

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

Раз у инженеров все ок, а страдают ответственные за продукт, будем снижать их время.

Что мы сделали:

  • Попросили аналитика замерить, сколько времени уходит на консультации. Получилось 7 часов в неделю. Это почти полный рабочий день!

  • Сфокусировались при написании документации на самых частых вопросах пользователей.

  • Провели модерируемое UX-тестирование и дополнили документацию информацией по обратной связи с респондентами.

Результат: после публикации документации время бизнес-аналитика на консультации сократилось до 4 часов в неделю. А обратную связь с пользователями мы читали всей редакцией. Это была музыка для наших ушей:

  • «Я всегда ставлю себя на место новичка. Дока — круто. По наполненности всего хватило с головой».

  • «Приятное впечатление от документации, текст хорошо структурирован, легко читать».

  • «Положительно и круто. Все в одном месте».

Прямо пойдешь — и аналитику, и поддержке поможешь

Последний кейс мой любимый. Работали с продуктом, который отвечает за доступы сотрудников в системы Т-Банка. Команда разбирала много обращений: вопросы поступали в два канала.

Документация у продукта была давно. Сначала предположили, что в доке не хватает информации, поэтому пользователи задают вопросы поддержке. Аналитик продукта выгрузила все обращения из каналов за месяц и кластеризовала их. Разделила по тематикам, выделила количество тех вопросов, которые можно покрыть докой, — так мы вычислили процент от общего количества обращений. Мы поняли, что ответы на все вопросы сотрудников есть в документации. 

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

Чтобы это была не просто проба, а понятный результат, мы с продуктом решили закоммититься на метрике «количество обращений в поддержку». Тогда еще у продукта было два канала и эта метрика била в их боль. Аналитик измерил AS IS в каналах, я поменяла структуру, и через месяц собрали новую статистику — TO BE.

Как подошли к задаче:

  • Бизнес-аналитик выгрузил обращения из двух каналов поддержки продукта за месяц и отобрал только консультационные.

  • Назвали разделы доки как вкладки интерфейса, а большие статьи разбили на маленькие.

Результат:

  • В одном канале количество вопросов сократилось на 90%, в другом — на 65%.

  • Количество обратной связи по документации уменьшилось. При этом пользователи продолжали активно использовать продукт.

  • Бизнес-аналитик смог посвящать значительно больше времени развитию продукта.

Выводы

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

  • количество консультационных вопросов по продукту;

  • время, которое аналитик тратит на ответы пользователям.

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

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

Комментарии (0)