Схема целиком
Сначала карта, дальше — по шагам, что в какой системе настраивается.
Шаг 1. Один вход: чат в продукте на Intercom
Первое правило: у клиента должна быть одна очевидная точка входа, а у вас — один инбокс, где всё видно. Мы использовали Intercom — виджет чата прямо в интерфейсе продукта плюс почта в тот же инбокс.
Почему чат в продукте, а не форма на сайте: клиент пишет в момент, когда столкнулся с проблемой, и вы видите контекст — тариф, что он делал, какой аккаунт. Форма «напишите нам» ловит только самых терпеливых.
Важная оговорка: единый инбокс собирает только то, что клиент написал сам. Идеи, сказанные на звонке продажнику или на встрече с аккаунтом, сюда не попадут никогда — для них работает отдельное правило, о нём шаг 4.
Порядок масштаба, чтобы понимать нагрузку: около 7 000 активных клиентов давали 2 000–3 300 обращений в месяц. То есть 30–50 обращений на каждые 100 клиентов ежемесячно — это и есть та река, которую нужно разложить по руслам.
Шаг 2. Теги и триаж: три типа обращений — три маршрута
На закрытии каждое обращение получает тег. Без тега тикет не закрывается — это правило, а не пожелание. Но одних тем мало: важнее тип, потому что от него зависит маршрут.
| Тип | Куда идёт | Что получает клиент |
|---|---|---|
| Баг — сломано то, что должно работать | Внутренний канал разбора → задача в Jira | Срок или объяснение, если срока нет |
| Вопрос — работает, но непонятно | Ответ + статья в базу знаний + сценарий боту | Ответ сейчас и самообслуживание в следующий раз |
| Идея / пожелание — хочет то, чего нет | Публичный борд идей | Ссылка на карточку, где виден статус |
Дополнительно каждое обращение метится темой продукта — у нас это были эпики: дашборд, статистика, автопостинг, комментарии и директ, отчёты, API. Так через квартал видно, какой модуль генерирует поток: например, «претензии, условия, возврат» за год выросли со 156 до 746 обращений в месяц — и внутри почти всё это оказалось одной операцией, которую клиент не мог сделать сам.
Шаг 3. Куда отправлять клиента с идеей: публичный борд
Ответ «передадим разработчикам» — это чёрная дыра. Вместо него у клиента должен быть адрес, где его идея живёт видимой жизнью. Мы завели публичный борд идей на отдельном поддомене (у нас — ideas.вашдомен.ru) на платформе FeatureOS (раньше называлась Hellonext).
Что умеет такая платформа из коробки:
- Публичные карточки запросов с описанием и комментариями.
- Голосование — клиенты голосуют за чужие идеи, и вы видите реальный спрос, а не громкость одного клиента.
- Статусы: принято → в оценке → запланировано → в работе → выпущено → не будем делать.
- Автоуведомления всем проголосовавшим при смене статуса — тот самый замкнутый цикл.
- Публичный роадмап и чейнджлог — витрина того, что вы уже сделали.
- Интеграция с Jira — двусторонняя синхронизация статусов.
Механика для команды поддержки: получив пожелание, оператор не пишет «передам», а создаёт карточку на борде и присылает клиенту ссылку: «вот ваша идея, здесь появится статус, за неё можно голосовать». Если похожая карточка уже есть — клиента ведут в неё и добавляют его голос.
Шаг 4. Правило для всей команды: идея приходит откуда угодно
Самая частая ошибка при внедрении: борд считают инструментом поддержки. А поток идей через чат — это меньшая их часть. Основное клиент говорит там, где никто не ведёт учёт: на демо с продажником, на квартальной встрече с аккаунт-менеджером, в личном чате с внедренцем, в курилке на конференции — собственнику компании.
Поэтому договорённость распространяется на всех, кто хоть как-то разговаривает с клиентами — поддержка, аккаунтинг, продажи, внедрение, маркетинг, руководители и собственник. Услышал идею — обязан сделать одно из трёх:
| Действие | Когда применяем | Что говорим клиенту |
|---|---|---|
| 1. Показать борд | Клиент готов сам оформить и следить за статусом | «У нас есть открытый список идей — оставьте там свою, за неё смогут проголосовать другие, а вы будете видеть статус» |
| 2. Завести карточку самому | Клиенту некогда, идея прозвучала вскользь на звонке или встрече | «Я сам занесу это в наш список идей и пришлю вам ссылку — там будет видно, что с ней происходит» |
| 3. Дополнить существующую | Похожая карточка уже есть | «Такое уже просили, я добавлю ваш случай и ваш голос — так у идеи больше веса» |
Чего делать нельзя ни при каких обстоятельствах — сказать «передам разработчикам» и не сделать ничего. Это единственный по-настоящему запрещённый ответ.
Третий вариант — самый ценный
Дополнить существующую карточку новым пользовательским сценарием полезнее, чем завести дубль. Продукту важна не частота повторов, а то, зачем разным клиентам одно и то же:
- Кто — сегмент и размер клиента (агентство на 40 аккаунтов, а не «клиент Иванов»).
- Что делает сейчас — какой костыль или обходной путь использует.
- Зачем — какую свою задачу закрывает, что произойдёт, если сделаем.
- Цена вопроса — сколько времени тратит, влияет ли на решение о продлении.
Три разных сценария под одной карточкой почти всегда меняют её приоритет и нередко — саму постановку: продукт видит, что за «добавьте кнопку выгрузки» стоят три разные задачи, и решает их одним, но другим способом.
Как сделать, чтобы это работало
- Один адрес, который знают все. Ссылка на борд — в подписи почты, в закреплённом сообщении рабочих чатов, в карточке клиента в CRM, в базе знаний. Не «где-то в Confluence», а в одном месте, куда дотягивается любой сотрудник за пять секунд.
- Памятка на одну страницу: три действия из таблицы выше и готовые фразы. Раздаётся на онбординге всем, кто общается с клиентами, — включая продажи и руководителей.
- Единый маршрут для всех, без исключений для начальства. Если собственник приносит «мне на конференции сказали» — это тоже карточка на борде, а не задача напрямую разработчику. Иначе приоритет продукта определяется случайной встречей, а квота на клиентские запросы разваливается за месяц.
- Разбор на еженедельном ревью: смотрите, из каких отделов вообще приходят карточки. Если 95% заводит поддержка — правило знают не все, и половина голоса клиента теряется на звонках продаж.
Шаг 5. Разбор и оценка: продуктовое ревью раз в неделю
Раз в неделю — короткая встреча: продукт, разработка, поддержка, аккаунтинг. Разбираются новые карточки борда и топ по голосам. По каждой отвечаем на четыре вопроса:
| Вопрос | Что фиксируем |
|---|---|
| Какую задачу клиента решает? | Формулировка через сценарий: «пользователь хочет …, чтобы …» |
| Сколько клиентов это просят? | Голоса на борде + число обращений по тегу |
| Какие это деньги? | Подписка проголосовавших, а по возможности — риск оттока |
| Какой размер? | T-shirt: S / M / L / XL |
T-shirt-оценка нужна, чтобы не тонуть в точных сроках: она занимает пять минут вместо недельного анализа.
| Размер | Порядок работ | Как поступаем |
|---|---|---|
| S | Часы: настройка, текст, мелкая правка | Берём почти без обсуждения |
| M | Дни: доработка существующего механизма | Основная масса клиентских запросов |
| L | Недели: новый функционал в модуле | Только с обоснованием по охвату и деньгам |
| XL | Месяцы: новая подсистема, интеграция | Не в квоту — в продуктовую стратегию отдельным решением |
Приоритет считается не по громкости, а по формуле охват × деньги ÷ размер. Несколько S и M дают клиентам больше ощущения «нас слышат», чем одна XL, которую обсуждают квартал.
Шаг 6. Интеграция с Jira и канбан-приоритизация
Когда карточка получает статус «запланировано», она уезжает в Jira — и это ключевой технический стык всей схемы.
- Отдельные проекты под типы работ: у нас были разделены баги и продуктовые задачи — так видно, сколько ёмкости съедает поломанное, а сколько идёт в развитие.
- Задача из карточки борда создаётся в один клик — интеграцией платформы с Jira. В задаче остаётся обратная ссылка на карточку и число голосов.
- Метка источника (например, voc или customer-request) ставится автоматически. Без неё невозможно посчитать долю клиентских задач в спринте — а именно она защищает квоту.
- Синхронизация статусов обратно: задача переходит в «в работе» и «готово» в Jira — статус меняется на публичной карточке, всем проголосовавшим уходит письмо. Никто не пишет клиентам руками.
- Канбан-доска с автоматической сортировкой: колонки «оценка → готово к разработке → в работе → релиз», внутри колонок задачи ранжируются по полю приоритета, куда сложены голоса и деньги. Правила доски двигают карточки сами, спорить о порядке не приходится.
Для багов маршрут другой и более быстрый: обращение → внутренний канал разбора в корпоративном мессенджере (у нас Mattermost, подойдёт Slack или Telegram) → воспроизведение → задача в Jira со ссылкой на переписку. Канал разбора обязателен: он экономит разработчикам часы, потому что половина «багов» оказывается вопросами, ограничениями платформ или уже известными проблемами.
Шаг 7. Квота 20% — договорённость, без которой всё бесполезно
Всё выше — теги, борд, оценки, интеграции — не стоит ничего, если в спринте нет места для клиентских задач. А его никогда нет: стратегия, техдолг, срочное от руководства. Поэтому мы договорились с продуктом и разработкой: 20% ёмкости — на задачи с меткой клиентского источника.
Три условия, без которых квота превращается в профанацию: заполняет её владелец процесса VOC; приоритет внутри — по охвату и деньгам, а не по симпатии; берём преимущественно S и M, чтобы за квартал клиенты видели поток изменений, а не одну долгую задачу.
Грабли, на которые мы наступили
Честно про то, что ломалось — эти места придётся чинить и вам.
- «Решили без задачи в Jira». Разработчик починил на лету, задачи нет — значит, нет ни истории, ни статистики, ни уведомления клиенту. Лечится правилом: любое изменение в продукте существует только как задача.
- «Забрали, но ни ссылки на задачу, ни сроков нет». Обращение уходит в никуда, поддержка не может ответить клиенту. Лечится обязательным полем «ссылка на задачу» в разборе.
- Поддержка не умеет описывать проблему. «Кнопка не нажимается» — это не баг-репорт. Помогает шаблон: что делал → что ожидал → что получил → аккаунт и время → скриншот или запись.
- Нет общего процесса передачи между отделами. Один пишет в личку разработчику, другой — в общий чат, третий заводит задачу. Пока маршрут не описан и не единственный — статистики не будет.
Инструкция: собрать за четыре недели
- Неделя 1. Один инбокс и теги. Подключите чат в продукте, заведите короткий список тегов и тип обращения (баг / вопрос / идея). Запретите закрывать тикет без тега.
- Неделя 2. Борд идей. Поднимите публичный борд на поддомене, настройте статусы и уведомления, добавьте ссылку в чат, базу знаний и подпись поддержки. Обучите операторов: не «передам», а «завёл карточку, вот ссылка».
- Неделя 3. Маршрут багов и Jira. Заведите канал разбора, шаблон баг-репорта, отдельные проекты под баги и продукт, метку источника voc и интеграцию борда с Jira с обратной синхронизацией статусов.
- Неделя 4. Правило команды, ритуал и квота. Раздайте всем, кто общается с клиентами, памятку из трёх действий и разложите ссылку на борд по всем рабочим местам. Поставьте еженедельное продуктовое ревью на 40 минут, введите t-shirt-оценку и договоритесь о доле спринта на клиентские задачи. Зафиксируйте договорённость письменно — иначе она забудется на первом же горящем квартале.
Дальше система живёт сама: поток обращений размечается, идеи копят голоса, ревью раз в неделю наполняет квоту, статусы возвращаются клиентам автоматически. Ваша задача — раз в месяц смотреть сводку по тегам и показывать её продукту.
Стек одним списком
| Задача | Что использовали | Чем заменить |
|---|---|---|
| Единый инбокс и теги | Intercom | Crisp, HelpCrunch, Chatwoot, Юздеск |
| Публичный борд идей | FeatureOS | UserEcho (РФ), Canny, Nolt, Frill, Fider (free) |
| Задачи разработки | Jira | YouTrack, Kaiten, Яндекс Трекер, Linear |
| Канал разбора багов | Mattermost | Slack, Telegram, Rocket.Chat |
| База знаний для клиентов | встроенная в чат | Notion, Confluence, Document360 |
Методика самого сбора и обработки пожеланий — в статье «Голос клиента: система обработки пожеланий». Как из тех же тегов вырастает разбор по темам и зонам ответственности — в разборе механик оттока, а про инструменты, которыми это всё меряется, — в статье о дашбордах.