Как собирать метрики, чтобы повысить удовлетворенность пользователей “внутреннего” продукта. Часть 1.

То, что нельзя измерить нельзя улучшить. Питер Друкер

Кто я

Привет. Меня зовут Павел.

С 2012 года я управляю разработкой сложных IT-продуктов. SaaS B2B ERP и всё такое прочее :)

C конца 2023 года работаю руководителем цифровых проектов в компании Брусника и занимаюсь набором приложений для управления стройплощадкой. Ближайшие аналоги – Самолет 10D и iflat.io.

О чем этот текст и для кого

Я хочу рассказать о методике расчета индекса удовлетворенности потребителя (CSI). Как считать, на что обратить внимание и пример расчета.

Изначально, статья получилась объемной и поэтому решил разбить её на две части. В первой – теория, во второй – анализ данных на примерах.

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

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

Часть 1. Теория.

Введение

Перед началом разработки, в зависимости от практикуемой методологии мы собираем пользовательские истории (User Story Map) \ работ (Jobs To Be Done) \ фичей \ требований.

Для этого используем различные качественные исследования: User Research, CustDev, проблемные интервью и подобное.

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

Теперь наступает время количественных исследований, которые опираются на метрики и прокси метрики. Замерили. Посмотрели и ищем решения так, где метрики проседают.

Тут у меня возник вопрос: Что делать если метрик нет и речь идет о продуктах для внутренних пользователей? Что стоит измерять и как правильно начать?

Сразу пришло на ум что нет смысла замерять NPS т.к. нет нужды собирать рекомендации пользователей для коллег. И то, что коммерческие метрики типа Churn Rate \ Retention Rate не подходят, т.к. количество пользователей не зависит от качества продукта.

Остаются верхнеуровневые скоринги:

  1. Customer Satisfaction Index (CSI),
  2. Customer Effort Score (CES),
  3. Customer Satisfaction Score (CSAT).

CSI измеряет уровень удовлетворенности пользователей по нескольким аспектам продукта, включая функциональность, надежность, поддержку и другие факторы.

CES оценивает, сколько усилий требуется пользователю для выполнения определенной задачи в приложении.

CSAT измеряет уровень удовлетворенности клиента по конкретным аспектам или моментам взаимодействия с продуктом. Обычно задается вопрос в формате "Насколько вы удовлетворены?

Выбрал CSI, как наиболее гибкий и доступный способ независимой оценки приложений по уровню удовлетворенность и доверия пользователей.

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

1. Этап “Определение параметров потребительского качества”

Как собирать CSI, чтобы не пропустить важное для пользователя

Субъективная потребительская оценка качества и работы приложения состоит из двух этапов:

  • Этап 1 “Определение параметров потребительского качества”
  • Этап 2 “Опрос респондентов”

1. Этап “Определение параметров потребительского качества”

Задача этапа ответить на вопрос “Какие параметры являются самыми важными”

Для этого выбираем те параметры приложения \ продукта, которые считаем важными.

Источниками параметров на этом этапе могут стать:

  • Экспертное мнение сотрудников / руководителей, которые взаимодействуют с клиентами.
  • Предварительное разведывательное исследование.
  • Опрос экспертов отрасли.

Количество параметров от 10 до 15 наиболее значимых для данного сегмента / товара / компании

Обратите внимание, что параметры:

  • Однозначно понимаются (на языке потребителя).
  • Не конфликтуют между собой.
  • Могут быть оценены шкалой.
  • Не слишком общие, но и не слишком частные.
  • Выражены коротко и емко.
  • Имеют реальную ценность для потребителя.

2. Этап “Определение важности параметров”

Оцените важность параметров через предварительное разведывательное исследование. В зависимости от аудитории оно обычно содержит 5-7 вопросов. Это отборочные вопросы, чтобы понять, что “респондент соответствует” и три основных обязательных.

Вопрос 1. По каким параметрам (критериям) вы оцениваете наше приложение

Задаем, чтобы отобрать параметры, которые пользователя назвают чаще всего.

Вопрос 2. Оцените, в какой степени параметр важен лично для вас

  • 5 — очень важен
  • 4 — скорее важен
  • 3 — нейтрально
  • 2 — скорее не важен
  • 1 — совсем не важен

Вопрос 3. Какой параметр является для вас САМЫМ важным?

Респондент может выбрать только один вариант ответа.

На этом с теорией заканчиваю. Во второй части будут расчеты.

1 комментарий