Отвечай, как топовый специалист: как службе поддержки решать настоящие, а не озвученные проблемы клиентов

от автора

За типичной заявкой «не работает, посмотрите» может скрываться необходимость пересмотра архитектуры системы. В то же время, «добавьте мне новый процесс» нередко решается простой настройкой фильтров или прав доступа.

Где здесь проходит грань, за которую лучше не заходить без допаналитики? Почему ИИ-помощь в одних задачах повышает риск провала, а в других становится настоящим спасением? Покажем, как распаковывать запросы в поддержку, чтобы добраться до сути проблемы и не потратить лишние ресурсы — свои и клиента.

Привет, Хабр! Меня зовут Лера, я — тимлид в службе поддержки ITSM 365. В прошлый раз не договорила о том, как мы выстраиваем процессы, чтобы всем было максимально хорошо. Чтобы узнать больше о планировании, учете времени, контроле работ по заявкам и организации дежурств — читайте первую часть моего рассказа.

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

Аналитика кейсов: без контекста хорошего решения не будет

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

Хорошее решение начинается с вопросов

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

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

  • Какую проблему планируется решить предложенным способом?

  • Кто участвует в процессе и какую роль играет?

  • Как вы планируете использовать решение?

  • Какой результат ожидаете?

Ситуацию по запросу клиента подробно фиксируем в атрибуте «Кейс»

Ситуацию по запросу клиента подробно фиксируем в атрибуте «Кейс»

Допустим, клиент пишет: «Хочу сделать списание трудозатрат по заявке обязательным». Звучит несложно, но что за этим может стоять?

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

Решение: не просто сделать поле обязательным, а настроить автоматическое списание времени в зависимости от статуса заявки. Точные данные = довольные заказчики = счастливый клиент.

Аналитика или настройка: как разграничивать задачи

Все задачи мы делим на два типа. Разница — не в теме, а в глубине погружения.

  • Задача на настройку 

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

  • Задача на аналитику

Речь о запросах вида:

«Нам нужно согласование бюджетов» — а какие роли? какие этапы? что делать при отклонении?

«Хотим интегрироваться с SAP» — какие данные? в каком формате? как часто передавать? как действовать в случае ошибок?

Для таких обращений назначается конкретный аналитик, который идет по плану:

  1. Изучает существующий процесс, если он есть, и собирает новые требования.

  2. Проводит встречи с клиентом. Даже очевидные вещи иногда лучше проговорить вслух — именно из «очевидного» потом вырастают конфликты в логике приложения.

  3. При необходимости рисует схему нового процесса и пишет ТЗ на доработки. Обязательно анализирует совместимости — как новое решение ляжет на существующие настройки.

  4. Согласовывает ТЗ с клиентом, передает в разработку. 

Критерий

Настройка

Аналитика

Среднее время разбора

<1 часа

>1 часа

Формат общения

Переписка

Переписка, вебинары

Документация

Комментарии к задаче

Комментарии, ТЗ

Погружение в кейс

Уже есть понимание, как это делать, или требуется небольшое погружение в контекст

Требуется детальное изучение клиентского кейса 

Объем изменений

Локальный 

Процесс целиком или его часть 

Как мы изучали один клиентский кейс

Чтобы было понятнее, с какими задачами сталкиваемся в рамках аналитики, приведем пример из жизни.

Получили запрос: «Добавьте возможность контролировать выезды инженеров на завод». 

Что удалось выяснить по кейсу после 30 минут разговора.

  • Компания раньше оказывала только удаленную поддержку

  • Теперь инженеры стали выезжать на заводы клиентов — 500+ км, командировки на неделю

  • Нужно учитывать:

    логистику — когда уехал, когда вернулся;

    расход материалов — что увезли со склада, что потратили;

    время работы — сколько часов провели на объекте;

    тип работы — требуется ремонт, обслуживание, замена или установка.

Решение: новый процесс с 8 статусами, отдельным SLA и формами отчетности, интеграцией с 1С для учета материалов.

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

Фичи портала для работы над задачами

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

  • Заметки по клиенту

Что это: произвольный текст, который видят все, кто открывает какую-либо заявку по клиенту.

Зачем: фиксировать важные моменты и договоренности, которые могут быть полезны в работе.

Примеры:

  • «Предпочитает вебинары, переписку читает редко»

  • «Очень внимателен к деталям, нужны ссылки на документацию и примеры»

  • «В компании 3 разных подразделения с разными процессами — всегда уточнять, про кого речь»

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

  • Навыки клиента

Что это: атрибут, обозначающий зрелость клиента как пользователя системы.

Зачем: адаптировать стиль ответа на клиентский запрос. Новичку пишем пошагово со скриншотами, эксперту — «добавьте атрибут X в контент Y, не забудьте про выдачу прав на просмотр и редактирование».

Примеры:

  • Новичок — первый месяц работы с системой

  • Продвинутый — работает 3+ месяца

  • Эксперт — знает систему лучше нас 🙂 

Субъективно, но после внедрения фичи клиенты-новички стали реже писать «не понял». Эксперты — меньше раздражаться на разжевывание базовых вещей.

  • «Вайбы» — эмоциональная карта клиентов

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

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

Как работает:

  • В карточке клиента есть кнопки: плюс вайб для позитивного опыта взаимодействия и минус вайб — для негативного

  • Специалист может нажать и добавить комментарий:

👍 «Классно поблагодарил после решения сложной задачи»

👎 «Третий раз за неделю грубит в переписке»

  • Вся история вайбов сохраняется в карточке клиента

Зачем:

  • Понимать, с кем приятно работать и можно помочь чуть больше 

  • Видеть паттерны — например, клиент систематически груб с нашими специалистами → возможно, проблема не в нас

  • Использовать в Customer Success — если вайбы становятся негативными, есть повод обсудить причины

Важная деталь: мы фиксируем вайбы клиента по отношению к нам и наш вайб по отношению к клиенту. Да, это всегда субъективные мнения, но они помогают видеть в ретроспективе, как вели себя мы, а как — клиент.

Так выглядит вайбометр по клиенту :)

Так выглядит вайбометр по клиенту 🙂

Сначала думали оценивать вайбы автоматически по ML-анализу переписки, но отказались от этой идеи. Сотрудники лучше разбираются в ситуации: иногда клиент пишет резко, но по делу — это не негативный вайб. А еще мы общаемся с клиентами не только письменно в комментариях к заявке, но и на вебинарах, к которым у ИИ-агента нет доступа, а значит — нет и полного контекста общения.

ML-функции в портале

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

Анализ настроения

Что это: модель анализирует текст комментариев и выставляет метку по заявке — негативное, нейтральное или позитивное общение.

Зачем:

  • Быстро понять настроение в длинной переписке

  • Выделить «горячие» заявки, где клиент недоволен

  • Анализировать, с какими клиентами/темами связано больше негатива

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

Саммари

Что это: ассистент резюмирует заявку с большим количеством комментариев, помогая быстро вникнуть в суть.

Зачем:

  • Понять контекст, когда подключаешься к заявке не с самого начала

  • Экономить время при вхождении в заявку с сотней комментариев

  • Передать заявку без дополнительных усилий на ввод в курс дела

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

Форма добавления саммари по заявке предзаполнена стандартной инструкцией

Форма добавления саммари по заявке предзаполнена стандартной инструкцией

Умный поиск

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

Зачем:

  • Быстро найти ответ, если сотрудник не уверен в решении

  • Обнаружить похожие кейсы, которые уже решались ранее

  • Не терять контекст — поиск привязан к конкретной заявке

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

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

Коротко о главном

Все процессы в нашем клиентском сервисе строятся на одном принципе: сначала понять — потом делать.

Кейс клиента, правильные вопросы, четкое разграничение задач — это способ не тратить время на решение не той проблемы.

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

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

Мы работаем в портале на основе собственного продукта — ITSM 365. Low-code платформа в его основе кастомизируется под любые процессы, не только сервисные. Чтобы узнать больше о возможностях системы, изучите кейсы клиентов, свяжитесь через форму на сайте или напишите нам на почту.

ссылка на оригинал статьи https://habr.com/ru/articles/1037790/