|
|
|
Professor Seleznov
|
За типичной заявкой «не работает, посмотрите» может скрываться необходимость пересмотра архитектуры системы. В то же время, «добавьте мне новый процесс» нередко решается простой настройкой фильтров или прав доступа.
Где здесь проходит грань, за которую лучше не заходить без допаналитики? Почему ИИ-помощь в одних задачах повышает риск провала, а в других становится настоящим спасением? Покажем, как распаковывать запросы в поддержку, чтобы добраться до сути проблемы и не потратить лишние ресурсы — свои и клиента.
Привет, Хабр! Меня зовут Лера, я — тимлид в службе поддержки ITSM 365. В прошлый раз не договорила о том, как мы выстраиваем процессы, чтобы всем было максимально хорошо. Чтобы узнать больше о планировании, учете времени, контроле работ по заявкам и организации дежурств — читайте первую часть моего рассказа.
Сразу скажу, что все фичи из данной статьи реализованы во внутреннем портале поддержки, который сделан на основе системы ITSM 365. Именно в продукт эти функции не входят, но ничто не мешает их настроить — гибкая платформа способна на все. А теперь — о наших повседневных инструментах и подходах, которые обычно остаются за кадром.
Аналитика кейсов: без контекста хорошего решения не будет
Самый частый антипаттерн в поддержке любого продукта: клиент пишет «добавьте кнопку X», ее добавляют, через неделю клиент недоволен. Почему? Потому что выполнили озвученную задачу, а не решили реальную проблему. Про проблему, которую этой кнопкой хотят решать, вообще никто не спросил. Чтобы такого не было, нужно вникать в кейс и распаковывать задачу.
Хорошее решение начинается с вопросов
Мы выясняем ситуацию и фиксируем все в отдельном атрибуте «Кейс» задачи по клиенту. Нас интересует предыстория, текущая проблема и мотивация. Чтобы понять, какую реальную проблему хочет решить клиент, мы всегда уточняем:
- Что происходит сейчас? Почему данная задача стала актуальна?
- Какую проблему планируется решить предложенным способом?
- Кто участвует в процессе и какую роль играет?
- Как вы планируете использовать решение?
- Какой результат ожидаете?
Ситуацию по запросу клиента подробно фиксируем в атрибуте «Кейс»
Допустим, клиент пишет: «Хочу сделать списание трудозатрат по заявке обязательным». Звучит несложно, но что за этим может стоять?
Сотрудники постоянно забывают проставлять трудозатраты, начинают трекать время «задним числом» — в итоге в системе некорректные данные. А ведь на основе этих данных клиент отчитывается перед своими заказчиками и выставляет счета.
Решение: не просто сделать поле обязательным, а настроить автоматическое списание времени в зависимости от статуса заявки. Точные данные = довольные заказчики = счастливый клиент.
Аналитика или настройка: как разграничивать задачи
Все задачи мы делим на два типа. Разница — не в теме, а в глубине погружения.
Клиент хочет добавить дополнительное поле или изменить поведение кнопки. Переписки в заявке достаточно, отдельные встречи не требуются. Чаще всего берет любой свободный специалист, делает за час-два, дожидается подтверждения от клиента, закрывает. Конечно, бывают и более масштабные настройки. Для них нам не достаточно просто обсудить тему в заявке – требуется созвон, погружение в специфику процессов клиента, понимание его проблемы и проработка решения. И вот это как раз – задача на аналитику и последующую реализацию.
Речь о запросах вида:
«Нам нужно согласование бюджетов» — а какие роли? какие этапы? что делать при отклонении?
«Хотим интегрироваться с SAP» — какие данные? в каком формате? как часто передавать? как действовать в случае ошибок?
Для таких обращений назначается конкретный аналитик, который идет по плану:
- Изучает существующий процесс, если он есть, и собирает новые требования.
- Проводит встречи с клиентом. Даже очевидные вещи иногда лучше проговорить вслух — именно из «очевидного» потом вырастают конфликты в логике приложения.
- При необходимости рисует схему нового процесса и пишет ТЗ на доработки. Обязательно анализирует совместимости — как новое решение ляжет на существующие настройки.
- Согласовывает ТЗ с клиентом, передает в разработку.
| Критерий |
Настройка |
Аналитика |
| Среднее время разбора |
<1 часа |
>1 часа |
| Формат общения |
Переписка |
Переписка, вебинары |
| Документация |
Комментарии к задаче |
Комментарии, ТЗ |
| Погружение в кейс |
Уже есть понимание, как это делать, или требуется небольшое погружение в контекст |
Требуется детальное изучение клиентского кейса |
| Объем изменений |
Локальный |
Процесс целиком или его часть |
Как мы изучали один клиентский кейс
Чтобы было понятнее, с какими задачами сталкиваемся в рамках аналитики, приведем пример из жизни.
Получили запрос: «Добавьте возможность контролировать выезды инженеров на завод».
Что удалось выяснить по кейсу после 30 минут разговора.
- Компания раньше оказывала только удаленную поддержку
- Теперь инженеры стали выезжать на заводы клиентов — 500+ км, командировки на неделю
- Нужно учитывать:
логистику — когда уехал, когда вернулся;
расход материалов — что увезли со склада, что потратили;
время работы — сколько часов провели на объекте;
тип работы — требуется ремонт, обслуживание, замена или установка.
Решение: новый процесс с 8 статусами, отдельным SLA и формами отчетности, интеграцией с 1С для учета материалов.
Без погружения в кейс явно получилось бы что-то не то. Нам пришлось бы потратить много часов на переделку, клиенту тоже потребовалось бы подключаться к корректировкам и расходовать свое время.
Фичи портала для работы над задачами
Помимо погружения в конкретную ситуацию важно удерживать общий контекст: кто этот клиент, как он общается, что было раньше. Для этого в портале есть несколько инструментов, без которых я уже не представляю нашу работу.
Что это: произвольный текст, который видят все, кто открывает какую-либо заявку по клиенту.
Зачем: фиксировать важные моменты и договоренности, которые могут быть полезны в работе.
Примеры:
- «Предпочитает вебинары, переписку читает редко»
- «Очень внимателен к деталям, нужны ссылки на документацию и примеры»
- «В компании 3 разных подразделения с разными процессами — всегда уточнять, про кого речь»
После внедрения заметок время на вхождение в текущую ситуация для новых сотрудников сократилось в разы. Также эта функция помогает и более опытным сотрудникам, ведь помнить все важные нюансы о каждом из сотен клиентов попросту невозможно.
Что это: атрибут, обозначающий зрелость клиента как пользователя системы.
Зачем: адаптировать стиль ответа на клиентский запрос. Новичку пишем пошагово со скриншотами, эксперту — «добавьте атрибут X в контент Y, не забудьте про выдачу прав на просмотр и редактирование».
Примеры:
- Новичок — первый месяц работы с системой
- Продвинутый — работает 3+ месяца
- Эксперт — знает систему лучше нас
Субъективно, но после внедрения фичи клиенты-новички стали реже писать «не понял». Эксперты — меньше раздражаться на разжевывание базовых вещей.
- «Вайбы» — эмоциональная карта клиентов
Экспериментальная фича, которую мы запустили год назад.
Идея в основе новой функции: кроме разовых оценок тона в конкретной задаче, хотим видеть историю впечатлений о взаимодействии с клиентами.
Как работает:
- В карточке клиента есть кнопки: плюс вайб для позитивного опыта взаимодействия и минус вайб — для негативного
- Специалист может нажать и добавить комментарий:
👍 «Классно поблагодарил после решения сложной задачи»
👎 «Третий раз за неделю грубит в переписке»
- Вся история вайбов сохраняется в карточке клиента
Зачем:
- Понимать, с кем приятно работать и можно помочь чуть больше
- Видеть паттерны — например, клиент систематически груб с нашими специалистами → возможно, проблема не в нас
- Использовать в Customer Success — если вайбы становятся негативными, есть повод обсудить причины
Важная деталь: мы фиксируем вайбы клиента по отношению к нам и наш вайб по отношению к клиенту. Да, это всегда субъективные мнения, но они помогают видеть в ретроспективе, как вели себя мы, а как — клиент.
Так выглядит вайбометр по клиенту
Сначала думали оценивать вайбы автоматически по ML-анализу переписки, но отказались от этой идеи. Сотрудники лучше разбираются в ситуации: иногда клиент пишет резко, но по делу — это не негативный вайб. А еще мы общаемся с клиентами не только письменно в комментариях к заявке, но и на вебинарах, к которым у ИИ-агента нет доступа, а значит — нет и полного контекста общения.
ML-функции в портале
Впечатления от общения с клиентами описываем только вручную, но есть задачи, которые проще и быстрее выполнять вместе с ИИ. Есть три основных, вполне стандартных сценария, которые мы используем каждый день.
Анализ настроения
Что это: модель анализирует текст комментариев и выставляет метку по заявке — негативное, нейтральное или позитивное общение.
Зачем:
- Быстро понять настроение в длинной переписке
- Выделить «горячие» заявки, где клиент недоволен
- Анализировать, с какими клиентами/темами связано больше негатива
В целом довольно удобная штука. Например, наши менеджеры по Customer Success просматривают последние настроения в заявках перед созвоном с клиентом. Если видят много негатива, изучают, что именно происходило, и готовятся дать комментарии — скорее всего, клиент вспомнит об этих ситуациях и захочет их обсудить.
Саммари
Что это: ассистент резюмирует заявку с большим количеством комментариев, помогая быстро вникнуть в суть.
Зачем:
- Понять контекст, когда подключаешься к заявке не с самого начала
- Экономить время при вхождении в заявку с сотней комментариев
- Передать заявку без дополнительных усилий на ввод в курс дела
Особенно выручает, когда сотрудник уходит в отпуск или увольняется. Не заменяет погружение в детали, но дает надежную отправную точку.
Форма добавления саммари по заявке предзаполнена стандартной инструкцией
Умный поиск
Что это: модель ищет информацию по документации, похожим заявкам, задачам и статьям в базе знаний. Результаты сохраняются на карточке заявки.
Зачем:
- Быстро найти ответ, если сотрудник не уверен в решении
- Обнаружить похожие кейсы, которые уже решались ранее
- Не терять контекст — поиск привязан к конкретной заявке
Очень помогает в работе по текущим задачам на небольшие настройки. Не поможет в аналитике — процессы у разных компаний слишком отличаются по сути.
Чтобы узнать больше о других особенностях хранения и использования знаний в нашей службе поддержки, читайте статью на Хабре.
Коротко о главном
Все процессы в нашем клиентском сервисе строятся на одном принципе: сначала понять — потом делать.
Кейс клиента, правильные вопросы, четкое разграничение задач — это способ не тратить время на решение не той проблемы.
Инструменты — вайбы, заметки, ML-функции — помогают держать контекст там, где его легче всего потерять.
В итоге клиенты получают тщательную аналитику новых процессов, когда важно предложить оптимальную реализацию без лишних затрат, а также быстрые и точные настройки с помощью функций портала, чтобы ежедневная работа в системе шла гладко.
Мы работаем в портале на основе собственного продукта — ITSM 365. Low-code платформа в его основе кастомизируется под любые процессы, не только сервисные. Чтобы узнать больше о возможностях системы, изучите кейсы клиентов, свяжитесь через форму на сайте или напишите нам на почту.-Источник
|
|
|
|
