Три недели сообщений одного ID пользователя: чем жалоба отличается от намерения сменить поставщика
Менеджер по маркетингу продукта отслеживает сообщения одного пользователя в течение трех недель в группе конкурента Telegram и замечает момент, когда тема изменилась с «как мне это исправить» на «как мне выйти».
Пятница, вторая половина дня: еженедельный обзор Telegram-группы конкурента. Один ID пользователя отнял у меня дополнительные сорок минут.
Он был активен в течение трёх недель. В моем листе отслеживания было написано «продолжайте смотреть». Затем я извлек каждое опубликованное им сообщение, сложил их в один документ, а не по неделям, и понял, что что-то упустил.
Я и раньше просматривал его сообщения, но никогда за все три недели сразу. Как только я это сделал, около дюжины сообщений разделились на три стопки, и каждая стопка задавала разные вопросы.
(Все сообщения Telegram ниже являются иллюстративными или составными сценами. Временные рамки и имена пользователей изменены исключительно для демонстрации аналитического подхода.)
Первая неделя: семь сообщений об одной функции
Все семь сообщений первой недели указывали на одно — модуль отчетности.
3 марта, 9:12 — Ежедневный отчёт не запускается, появляется ошибка. У кого-нибудь ещё так?
4 марта, 10:05 — Ночной отчёт снова завис.
5 марта, 8:30 — Поддержка говорит, что работает над этим. Исправят сегодня? Нам нужен отчёт к утренней планёрке.
5 марта, 15:18 — Некоторое время работало, а после обеда снова сломалось.
6 марта, 9:44 — Цифры в еженедельном отчёте не совпадают с моими расчётами. Разница почти в две тысячи.
7 марта, 10:02 — Поддержка говорит, что проблема в кэше. Уже третий раз за месяц.
7 марта, 16:30 — Снова не работает.
Если вы следите за группами конкурентов, эти сообщения покажутся знакомыми. Пользователь снова и снова сталкивается с одной проблемой и каждый раз возвращается, чтобы рассказать о ней. Я записал в таблице отслеживания «модуль отчётов, повторяющаяся обратная связь» и поместил идентификатор пользователя в раздел «продолжать наблюдение». Больше ничего.
На этом этапе каждое сообщение описывало состояние: функция работает плохо. Он ни разу не спросил: «что делать дальше», «есть ли альтернатива» или «когда заканчивается мой контракт». Сами жалобы не предсказывали дальнейших действий, но помогли запомнить идентификатор. Если те же жалобы продолжатся на следующей неделе, нужно будет выяснить, касается ли проблема одного пользователя или это более широкий сбой — второй вариант важнее и достоин еженедельного обзора.
Вторая неделя: вопрос изменился
На второй неделе сообщений было меньше, но их тип изменился.
11 марта, 14:22 — Раз встроенные отчёты ненадёжны, есть ли другой способ? Например, получать данные через API (интерфейс прикладного программирования — способ программно соединять системы) на собственную панель.
13 марта, 10:30 — Быстрый вопрос: можно ли массово выгрузить исторические данные? Нужно подготовить квартальный отчёт.
Обратите внимание на изменение формулировок. На первой неделе он спросил, «как долго это будет исправлено» и «будет ли оно работать к сегодняшнему дню». На второй неделе он спросил: «Есть ли другой способ» и «Как мне экспортировать». Оба набора сообщений имеют одну и ту же предпосылку — функция отчетности ненадежна — но они указывают в разных направлениях. Первый ждет, пока поставщик его исправит. Второй ищет способ, не зависящий от признака.
Это различие, а не окончательный вывод. У вопроса об экспорте данных есть много разумных объяснений: квартальные сводки действительно повторяются, а команда могла просто оценивать свою техническую конфигурацию. Это не означает, что пользователь готовится сменить поставщика. Но изменения хватило, чтобы обновить заметку до «смена поведения — ищет способ вывести данные» и добавить напоминание: «проверять сообщения этого ID пользователя каждую неделю, не ждать общего обзора».
Третья неделя: три новых ключевых слова
На третьей неделе было всего три сообщения, но каждое содержало информацию, не появлявшуюся в предыдущие две недели.
17 марта, 10:03 — Кто-нибудь использовал модуль данных в [название продукта конкурента]? Напишите в личку, если готовы поделиться опытом.
18 марта, 16:15 — Контракт действует до середины июля. Можно ли ещё договориться о цене продления или уже применяется новый прайс?
19 марта, 9:30 — Когда будет готов API данных? Мне нужно сдать квартальный отчёт к 10 апреля.
Три сообщения — и три детали, которых не было в первые две недели: название продукта конкурента, месяц окончания контракта (середина июля) и внутренний срок (10 апреля).
Каждое сообщение, прочитанное отдельно, имеет альтернативное объяснение. Если вы спросите о модуле конкурента, это поможет кому-то еще изучить рынок. Вопрос о ценах на продление может быть обычным финансовым обзором. Вопрос о сроках API может быть обычной проверкой планирования проекта. Любое из них, появившееся изолированно, вероятно, было бы чем-то, что я прокрутил бы при обычном сканировании.
Но за одну неделю пришло три сообщения, а за две недели до них уже была завершена последовательность — жалоба на функцию, затем вопрос о выходе данных. Я увидел эту последовательность только потому, что поместил записи за три недели на одну страницу. Если бы я поймал только одно из этих сообщений в один день, не считая недель до и после, я бы не связал их.
Три действия, которые я записал
Я не сделал вывод: «этот пользователь меняет поставщика». Записи группового чата могут показать мне, что тема меняется, но не могут сказать, почему. Вместо этого я записал еще три конкретных действия.
Во-первых, проверьте, публиковал ли этот пользователь одно и то же сообщение в нескольких группах конкурентов. Если он одновременно спрашивал о «модуле данных [продукта конкурента]» в нескольких группах — запись проверки с межгрупповым контекстом покажет это без ручных переходов, — его поведение больше похоже на исследование рынка, чем на подготовку к миграции. Это важное различие; до проверки я бы не повышал приоритет случая.
Во-вторых: проверьте общедоступный статус данных API. На момент его последнего сообщения ответ службы поддержки группы был «все еще в очереди» — тот же статус, который существовал, когда он впервые пожаловался на отчеты на первой неделе, и который не изменился на третьей неделе. Но «еще не решено» — это не то же самое, что «не может быть решено». Мне нужно было знать, опубликовала ли служба поддержки новые сроки или план запуска после его последнего сообщения.
В-третьих, добавьте дату в таблицу отслеживания. «Проверить в середине июня: совпадает ли месяц окончания контракта с окном автоматического продления?» Сейчас пользователь спрашивает о цене продления. Но если в контракте есть пункт об автоматическом продлении, вопрос о цене может остаться просто вопросом и не потребовать дальнейших действий. В переписке этого не видно: нужно дождаться новых сообщений или подтвердить через другой канал.
Дата архива — через два месяца
На следующей неделе я ничего не буду делать. Никакого прямого сообщения, никакой передачи на рассмотрение бизнес-команды, никакой отдельной записи в еженедельном сводке. На этикетке архива я написал одну дату: 15 июня.
Эта дата — не заключение, а контрольная точка. Когда она наступит, я снова просмотрю сообщения и проверю три вещи: появились ли после упомянутого на третьей неделе срока 10 апреля новые сообщения; перешёл ли пользователь от «расспросов» к практическим шагам — процедурам миграции, срокам переноса данных или внутреннему согласованию; вошёл ли месяц окончания контракта в окно продления.
Если к тому времени обсуждение не продвинется, я отправлю запись в архив. Если появится что-то новое, решу, что делать дальше.
(Все приведенные выше отрывки из чата являются иллюстративными или составными сценами. Они предназначены для демонстрации метода анализа и не представляют реального пользователя или продукта.)
Как обнаруживается Signal, заслуживающий внимания
Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.
