Боли клиента

Происхождение и история термина

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

В обзоре 2016 года Кэтрин Лемон и Питер Верхуф связывают исследование клиентского опыта с моделями покупательского поведения 1960–1970-х годов, исследованиями удовлетворённости в 1970-х и качества услуг в 1980-х. Далее в их исторической схеме появляются отношения с клиентами, управление этими отношениями и вовлечённость. ^{[4, с. 71]} Это история исследовательских оснований, а не утверждение, что авторы перечисленных моделей изобрели выражение «боли клиента».

Практическое следствие такого развития — внимание к месту возникновения проблемы. В обзоре Лемон и Верхуфа опыт складывается из контактов в разных каналах; он включает познавательные, эмоциональные, поведенческие, чувственные и социальные реакции. ^{[4, с. 70–71]} Поэтому задержку ответа, непонятное условие и разочарование результатом нужно рассматривать в связи с действиями клиента, а не сводить к одной отрицательной оценке компании.

Учебник OpenStax описывает осознание потребности как замеченное различие между действительным и желаемым состоянием. ^[1] Руководство британской Government Digital Service — государственной службы цифрового развития, далее GDS — предлагает исследовать задачи пользователей и возникающие у них затруднения. ^[2] Эти подходы помогают уточнять проблему, сохраняя различие между потребностью, препятствием и возможным решением.

Суть и механизм

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

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

Следующее поле — задача. «Передать сведения о ремонте коллеге до конца смены» описывает результат. «Получить новый личный кабинет» уже называет один способ его достижения. В данном учебном случае передать сведения можно разными средствами; прежде чем выбирать программу, нужно выяснить, на каком шаге нынешний способ перестаёт работать.

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

Последствие делает описание проверяемым. В условном сценарии сменщик повторно звонит клиенту, чтобы узнать уже сообщённые сведения. Это конкретное действие. Запись «клиенты перестают доверять компании» потребовала бы дополнительных свидетельств. Приписывать ей ту же доказанность, что повторному звонку, нельзя: одно наблюдение не устанавливает все последующие причины и результаты.

GDS предлагает основывать потребности на исследовании и описывать проблему отдельно от возможного решения. ^[2] Поэтому в рабочей карточке полезно разделить факт, объяснение и предложение. «Сменщик повторно спросил номер» — запись действия; «статус не передаётся» — проверяемое объяснение; «изменим форму передачи» — решение для следующего испытания.

Виды и классификации

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

Например, отсутствие статуса может породить и лишний звонок, и сомнение в том, принята ли заявка. В такой записи первая часть относится к процессу, вторая — к проверяемости условий. Метки помогают обсудить разные последствия; они не должны заставлять исследователя выбирать только одну «правильную боль».

Полезно также различать рассказ и наблюдение. Человек может сообщить, что вчера долго искал срок ответа; исследователь может увидеть, как он ищет его в тестовом задании сегодня. Это разные свидетельства о разных эпизодах. Их сопоставляют по условиям, не объявляя автоматически одно правдивым, а другое ошибочным.

Как применяется на практике

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

Исследователь просит участника вспомнить последнее обращение. Тот рассказывает: оборудование требовалось для работы, но на сайте не было понятно, когда дадут предварительную оценку и понадобится ли оставлять устройство. Он закрыл форму и позвонил в другую мастерскую. Этот эпизод указывает на неопределённость условий; он не доказывает, что цена вообще не важна.

Возможный вопрос редакции: «Что вы хотели узнать перед заявкой и что сделали, когда не нашли ответ?» Он не подсказывает участнику, что тот должен был бояться или хотеть скидку. Рекомендация GDS строить беседу на открытых нейтральных вопросах и реальных историях поддерживает именно такую логику интервью. ^[3]

Команда записывает препятствие: при срочном ремонте человек не узнаёт порядок предварительной оценки. Затем предлагает изменение — объяснить этапы и условия ответа. Для проверки выбирают задачу: может ли участник до отправки заявки сказать, что произойдёт дальше? Ожидаемый результат сформулирован заранее, поэтому красивый новый блок на сайте не будет сам по себе считаться решением проблемы.

Допустим, в проверке человек теперь понимает порядок, но всё равно отказывается из-за отсутствия доставки. Это не повод переписать исходное наблюдение так, будто оно было ложным. Удалось устранить одно затруднение, а для принятия предложения обнаружилось другое условие. Проверка проблемы, проверка решения и проверка покупки отвечают на разные вопросы.

Рассмотрение всего пути клиента помогает расширить исследование за пределы формы сайта. Точкой контакта называют отдельное взаимодействие с компанией: например, звонок, письмо или визит. Связь таких контактов с опытом обсуждают Лемон и Верхуф. ^[4] В учебном проекте задержка могла возникнуть при передаче заявки мастеру, хотя команда первоначально хотела менять только текст кнопки.

Как измерить или проверить

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

Один рабочий показатель — доля участников, у которых наблюдалось заданное препятствие: p = k / n × 100%, где k — число участников с препятствием, n — все участники этой проверки, p — доля в процентах. Если один человек столкнулся с проблемой трижды, для этого показателя он всё равно учитывается один раз. Для числа повторений нужна другая метрика.

Учебные числа: из 20 участников 8 не нашли нужные сведения. Получаем p = 8 / 20 × 100% = 40%. Это доля в конкретной группе и процедуре. Если людей набрали среди ранее жаловавшихся клиентов, результат описывает эту группу; называть его долей всех покупателей нельзя. Чтобы другой исследователь понял число, рядом нужны условия набора и само задание.

Другой показатель — время выполнения. В учебном сравнении медианное время, то есть значение в середине упорядоченного ряда результатов, составило 6 минут до изменения и 4 минуты после него. Разность равна 6 − 4 = 2 минутам; относительное сокращение — 2 / 6 × 100% ≈ 33,3%. Указание медианы точнее расплывчатого «типичного сценария»: понятно, какую характеристику группы сравнивали.

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

Наконец, стоит сохранять основание вывода. Условная запись «пять жалоб» мало говорит о числе случаев: это могли быть пять обращений одного человека. Раздельные поля для участника, эпизода и повторения помогают не смешивать эти количества. В журнале также можно отмечать, что получено непосредственно, а что остаётся объяснением команды.

Ошибки, ограничения и спорные вопросы

Первая ошибка — приписать человеку скрытый мотив по одной фразе. В учебном примере «не оставил заявку» не равнозначно «боится обмана». Для описания боли достаточно установить препятствие и его последствия. Медицинские диагнозы или характеристики личности из такой записи не следуют.

Вторая ошибка — собирать только удобные свидетельства. Если команда уже решила дать скидку, вопрос «насколько вам мешает высокая цена?» направляет беседу к готовому ответу. Полезнее проверить и альтернативы: понятны ли условия, подходит ли срок, удалось ли завершить действие. Здесь это редакционные примеры организации проверки, а не универсальный опросник.

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

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

Правовой аспект

Для российского исследования, содержащего персональные данные, действуют требования 152-ФЗ в редакции от 26.07.2026: часть 2 статьи 5 ограничивает обработку конкретными, заранее определёнными законными целями; части 4 и 5 связывают состав и объём данных с этими целями. Основания обработки установлены частью 1 статьи 6. ^[5]

В пункте 9 части 1 статьи 6 для статистических или иных исследовательских целей предусмотрено обязательное обезличивание и оговорено исключение целей статьи 15. ^[5] Поэтому назвать сбор «исследованием клиентов» недостаточно для вывода о допустимости конкретной записи или дальнейшего использования сведений. Правовое основание, объём и способ работы с записями требуют оценки применительно к проекту; статья не заменяет проверку юриста.

Частые вопросы

Связанные термины

• Целевая аудитория
• CJM (карта пути клиента)
• Сегментация рынка
• Позиционирование
• Ценностное предложение
• Глубинное интервью