В этой статье мы продолжим разговор про Customer Journey Map (CJM) и рассмотрим, чем карта взаимодействия с клиентом отличается от Service Blueprint, зачем вообще нужен сервисный сценарий и как он связан с классикой бизнес-анализа: моделями as-is и as-to-be, а также с руководством BABOK.
Что такое Service Blueprint и чем он отличается от CJM
Начнем с определения: Service Blueprint или карта сервисного сценария – это визуальное представление идеального процесса взаимодействия с клиентом, направленное на достижение конкретной бизнес-цели с учетом всех возможных точек контакта: физических и цифровых [1]. Обычно Service Blueprint рассматривают как модификацию CJM, которая включает не только элементы потребительского поведения, но и бизнес-процессы обеспечения контактов, в т.ч. те, которые находятся «за сценой» [2]. Например, работа банковского бэк-офиса, складские операции в интернет магазине и прочие действия, которые не видны пользователю напрямую, но непосредственно связаны с оказанием бизнес-услуги. Таким образом, CJM — это внешний взгляд на продукт, сервис или бренд с позиции пользователя, а Service Blueprint – это представление бизнес-процессов, обеспечивающих эффективное взаимодействие с клиентом [3].
Как построить карту сервисного сценария
Карта сервисного сценария включает следующие компоненты [4]:
- Действия клиента (Customer Actions), выполняемые непосредственно потребителем как часть процесса предоставления им услуг. Например, приход на сайт или в физическое пространство, звонок в кол-центр и т.д. Обычно этот уровень представляет собой улучшенную CJM.
- Фронт-энд или действия на переднем этапе с видимым контактным лицом (Front-stage), которые предпринимаются сотрудниками компании в рамках личной встречи. К примеру, администратор гостиницы, хостес в ресторане, продавец в магазине и пр.
- Бэк-энд или действия на заднем плане (Back-stage), выполняемые сотрудниками за пределами видимости для потребителя: бронирование гостиницы или ресторана по телефону.
- Поддерживающие процессы (Support Processes), которые необходимы для оказания услуги: техническая поддержка, информационное обеспечение и пр.
- Физическое обеспечение (Physical Evidence): материальные элементы, которые могут повлиять на восприятие потребителем услуги: униформа официантов, оформление входной зоны и т.д.
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
MODP
Ближайшая дата курса
13 февраля, 2023
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.
Разделение бизнес-процессов по уровням показывается с помощью линий:
- видимости (Line of Visibility), которая отделяет фронт-энд от бэк-энда;
- взаимодействия (Line of Interaction), которая отделяет действия клиента от действий поставщика услуг;
- внутреннего взаимодействия (Line of Internal Interaction), которая разделяет бэк-офис и процесс поддержки;
- реализации (Line of Implementation), которая отделяет управление от поддержки – менеджмент отвечает за планирование и контроль мероприятий, а вспомогательные подразделения – за их подготовку.
Как и в случае CJM, наиболее популярным способом практического построения Service Blueprint является ручной – по крайне мере, на первом этапе проектирования. Действия на каждом уровне бизнес-процессов изображаются с помощью графических примитивов (круг, квадрат, прямоугольник), связанных между собой. Здесь не идет речь об использовании строгих нотаций бизнес-моделирования (IDEF, EPC, UML, BPMN), хотя на практике имеет смысл определить правила для изображения элементов и придерживаться их.
А что скажет BABOK: сервисный сценарий и классический бизнес-анализ
С точки зрения классического бизнес-анализа, подробно описанного в профессиональном руководстве BABOK®Guide (A Guide to the Business Analysis Body of Knowledge®), CJM описывает текущее состояние (модель «как есть», as-is). А Service Blueprint можно рассматривать в качестве модели желаемого будущего («как должно быть», as-to-be), которая будет реализована с помощью соответствующих решений: программных средств или организационных мероприятий. Примечательно, что BABOK не включает понятия CJM и Service Blueprint в перечень наиболее распространенных техник бизнес-анализа. Впрочем, это руководство подчеркивает, что за его рамками осталось еще множество полезных методов и средств. Некоторые из них, в частности, CJM, международный институт бизнес-анализа упоминает в качестве техник продуктового анализа в Guide to Product Ownership Analysis.
Кроме того, главные достоинства CJM и Service Blueprint (наглядность, понятность, простота построения и удобство использования) позволяют работать с ними не только профессиональным аналитикам, но и руководителям, маркетологам, дизайнерам, менеджерам и прочим профильным специалистам. Подробнее о том, что такое BABOK, мы рассказываем здесь.
С прикладной точки зрения Service Blueprint – отличный инструмент для построения целостной картины предоставления услуги в рамках процессного подхода к управлению, когда разные структурные единицы вовлечены в единую деятельности по созданию ценности. Благодаря наглядности карта сервисного сценария позволяет менеджеру найти возможности для оптимизации деятельности:
- выявить и предупредить дублирование операций;
- снизить операционные затраты на выполнение процессов, сократив количество шагов или уровень изменчивости;
- эффективно распределить нагрузку на персонал с учетом количества и длительности задач, выполняемых на каждом уровне.
Подобная оптимизация актуальна для любого бизнеса. Поэтому карта сервисного сценария – это полезная техника бизнес-анализа, которая пригодится каждому руководителю.
Как построить CJM и Service bluePrint, а также прочие вопросы продуктовой аналитики в контексте бизнес-анализа рассматриваются в нашем новом курсе «От процессов к продуктам: Product ownership и Agile-практики для бизнес-аналитика». Узнайте, как вписать продуктовое мышление, юнит-экономику и Agile-практики в классический бизнес-анализ, подружив продуктовые метрики с процессными показателями, а требования – с фичами. Построенный на изучении лучших практик из профессиональных сводов знаний от IIBA® (BABOK®Guide, Agile Extension и Guide to Product Ownership Analysis) с примерами их практического применения, курс также содержит советы и лайфхаками для подготовки к экзаменам ECBA, CCBA, CBAP, AAC, CPOA.
От процессов к продуктам: Product Ownership и Agile-практики для бизнес-аналитика
Код курса
POAP
Ближайшая дата курса
20 марта, 2023
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.
А детально освоить содержание руководства к профессиональному своду знаний по бизнес-анализу BABOK®Guide на практических примерах вам помогут курсы нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Лучшее из BABOK®Guide: ТОП-10 задач и техник для аналитика
- Управление бизнес-анализом — курс для руководителей
Источники
- https://leadstartup.ru/db/service-blueprint
- https://medium.com/@dmitriy.d.kapaev/краткий-гайд-по-cjm-19667b50fd7a
- https://medium.com/wonderfull-lab/как-перейти-от-cjm-к-service-blueprint-5d7ab7bdc08e
- https://en.wikipedia.org/wiki/Service_blueprint
- →
- →
- →
- →
- →
- →
Катерина Виноходова
Совладелец Юздеска
На первый взгляд, «сценарии» в обслуживании клиентов – антитеза исключительному сервису, а у клиентского обслуживания больше общего с гибким общением, чем с холодным безжизненным скриптом. Но как артисты тщательно готовят импровизацию, так и клиентщики планируют вау-решение в щекотливых ситуациях заранее. Правильный сервис строится на схемах и алгоритмах. Мы опишем некоторые из моих любимых ответов на трудные вопросы клиентов, не раз испытанные в бою. Используйте и смело корректируйте их в процессе поддержки.
1. Когда вы не знаете, что ответить клиенту
Без паники, если не знаете ответа. Задача – найти правильное решение, а не идеальное. «Я не знаю, я тут вообще новенький», — забудьте, это никому не интересно. Вместо того чтобы расписаться в беспомощности попробуйте так:
Смогу я на этом тарифе получать бесплатные бумажные отчеты? Отличный вопрос, я сейчас проверю!
Покажите, что вне зависимости от того, знаете вы ответ или нет, вы во что бы то ни стало отыщите его. Потом срочно звоните другу.
2. Когда товар временно отсутствует
Специалисты интернет-магазинов не любят сообщать, что товара на складе нет. После этого диалог не предвещает ничего хорошего — клиент обижается и покупает у другом магазине. Но есть способ не испортить настроение клиенту. Секрет в позитивном мышлении языке. Попробуйте сказать, что продукт появится в конце месяца.
Сравните:
Мы не можем предоставить товар до конца месяца, все это время он недоступен для заказа.
Ваш размер появится в следующем месяце. Я закажу эту куртку для вас прямо сейчас, и мы отправим посылку, как только она нам поступит.
Найдите в шаблонах и ответах частицу «не»: «Я не могу, у нас нет…» — и безжалостно удалите. Клиента заботит решение, поэтому сделайте акцент на том, что вы можете предложить.
3. Когда клиента нужно переадресовать
В топе ненавистных фраз от службы поддержки:»Пожалуйста, подождите, мы переведем ваш звонок«. Раздражает. Ощущение, что пустили по рукам и придется стопицот раз пересказывать свою историю.
В идеале избавьтесь от этой фразы. Пересмотрите схему IVR, чтобы клиенты сразу попадали туда, где им помогут, либо дайте больше полномочий, знаний о продукте и процессах первой линии поддержки. Что делать, если переключения не избежать?
1. Называйте причину и «адрес». Слышать, что проблема передана эксперту – уже легче.
Сейчас мы решим эту проблему. Я переведу вас на специально обученного сотрудника отдела X (главного юриста, бухгалтера, старшего продажника), он обязательно поможет вам.
2. Перескажите коллеге вкратце проблему и только после этого переводите звонок. Не тратьте время клиента. Каждое дополнительное усилие в поисках решения — позвонить, рассказать, подождать, еще раз рассказать, найти номер договора — снижает его настроение и лояльность к вам.
4. Когда просят о фиче, которая никогда не заработает
У клиентов часто возникают идеи, как использовать или улучшить ваш продукт, но вы видите развитие продукта по-своему, и последнее слово за вами.
Если клиент просит о том, что идет в разрез с вашим роуд мэпом, наберитесь смелости и откажите. «Да, посмотрим!» – дает ложную надежду, в конечном итоге правда выяснится через несколько недель и кольнет разочарованием. Не опасайтесь массового исхода клиентов, только потому что вы говорите «нет» их идеям о новых фичах.
Мы ценим, что вы нашли время, чтобы поделиться идеями. Но сейчас X не совсем то, что нам подходит, у нас нет непосредственных планов это реализовать. Зато мы планируем добавить другие полезные фичи – Y, Z. Если что-то изменится, мы в первую очередь сообщим вам.
Поблагодарите за советы, ласково, но твердо откажите и продайте новые фичи как альтернативу.
5. Когда просят о «единственном» исключении
Что делать, когда вы действительно не можете сказать «Да»? Однажды я остановилась в отеле с друзьями, у которых была аллергия на шерсть. Мы ужасом наблюдали, как пара умоляла оставить кошку, несмотря на строгое правило «без животных».
«Пожаааалуйста, позвольте Барсику остаться!» – и все в таком духе. Если бы сотрудник отеля сдался, это обернулось бы еще бОльшей проблемой, чем один расстроенный клиент. Девушка решила ситуацию блестяще:
Мне важно, чтобы запросы клиентов были удовлетворены, но боюсь, что нарушить это правило нельзя. Это повлияет на безопасность и комфорт других клиентов и может испортить им отдых. Давайте я сделаю пару звонков, возможно, вокруг есть отели, где вы сможете остаться с Барсиком?
Отличный ответ на дурацкий запрос – можно подумать, кто-то не знает, что в отель с животными нельзя. Учитесь говорить «нет», потому что запреты появляются не просто так, объясняйте причины и последствия «исключений». В неловкой ситуации, когда вы отказываете в просьбе, демонстрация сочувствия и готовность найти альтернативу – лучший способ обезболить укол отказа.
6. Когда что-то не так с товаром
То чувство, когда выдыхаешь, нажимаешь на кнопку «оплатить», ждешь с нетерпением доставки… но товар в коробке бракованный.
В ответе достигаем трех целей: сопереживаем удрученному заказчику, объясняем причину проблемы и даем четкое и немедленное решение+компенсацию за его страдания.
Нам так жаль, что это произошло, представляем, как вы разочарованы. Простите нас. Возможно, это нелепая ошибка в производстве. Мы отправим вам новый товар абсолютно бесплатно, а на следующую покупку подарим скидку 50%, что скажете?
Предлагайте альтернативу, возможно, клиент просто захочет вернуть деньги. Исходите из того, на что рассчитывает клиент и что для него будет решением.
7. Когда с клиентом пора прощаться
Одно из моих любимых – как завершить разговор. Это не закрытие продажи, здесь нужно убедиться в том, что вы выполнили миссию. Напомним, что средний бизнес слышит только 4% недовольных клиентов. Не пополняйте эту печальную статистику, бросая клиентов с нерешенной проблемой.
Чтобы сделать клиента счастливым, покажите ему три важные вещи:
- Вам важно ему помочь
- Вы продолжите искать решение
- Клиент определяет, когда проблема решена
Завершите разговор так:
Отлично! Я рад, что мы смогли разобраться и помочь вам. Может быть, у вас еще есть вопросы, я с удовольствием отвечу.
Клиент может поскромничать и уйти с еще одной невысказанной проблемой.«Я рад помочь» – маленькая деталь, которая расслабляет и показывает клиенту, что он не обуза, а вам в радость ваша работа – помогать.
8. Когда клиент злой и орет
Лучшие агенты поддержки как громоотводы берут на себя ярость клиента. Иногда этот гнев неоправдан, а порой клиент возмущен по делу. В любом случае разговаривать с ними трудно, но доктора телефонных наук знают метод для борьбы с этим типом клиентов:
Извиняйтесь искренне и сочувствуйте. «Простите нас» — обязательно. Ожидания клиента не совпали с реальностью, и в этом виновата ваша компания. Клиент ждет поддержки и подтверждения того, что имеет право на гнев. «Я понимаю, как это обидно, вы сильно разочарованы», – проговорите чувства клиента, чтобы ослабить их.
Берите ответственность. Вы представитель компании и отвечаете за ее провал. Клиенту нужен тот, с кем можно поделиться, потому что злиться на безликую компанию нет никакого смысла. «Мы виноваты, простите нас. Но я здесь чтобы помочь и исправить эту ситуацию. Что скажете, если мы сделаем так…».
Решите проблему. С рассерженными клиентами фактическое исправление займет скорее всего десятую часть всего процесса поддержки. Заменить товар или оформить возврат – пять секунд. Убедитесь, что удалось исправить эмоциональное состояние клиента.
Напоследок напомню универсальное правило: в любой непонятной ситуации используйте логику и исходите из интересов клиента.
Оцените пожалуйста нашу статью
Знаем, что такое клиентский сервис
Раз в две недели будем присылать интересное и полезные материалы про клиентский сервис – выпуски подкаста, кейсы и обновления системы. Вы не против?
Знаем, что такое клиентский сервис
Раз в две недели будем присылать интересное и полезные материалы про клиентский сервис – выпуски подкаста, кейсы и обновления системы. Вы не против?
Практические советы о клиентском сервисе, которые работают
Подборки статей на все случаи жизни
- /
- /
Что такое CJM
Customer Journey Map (CJM), или Карта пути пользователя — инструмент, основанный на исследованиях человеческого опыта, который помогает этот самый опыт проанализировать. Это один из форматов сбора исследовательской информации, который отражает сценарий пользователя: шаги, эмоциональные реакции, время, ключевые цитаты.
Впервые подход карты пути пользователя был сформулирован и применен в 1998 году компанией OxfordSM (ранее Oxford Corporate Consultants). Компания начала широко использовать подход в своей работе, в том числе в проектах с правительством Великобритании. Именно тогда впервые было опубликовано описание этого подхода.
CJM применяется в дизайн-мышлении на этапе фокусировки для поиска явных пробелов, разрывов и «болей» (gaps) в сценарии пользования продуктом или услугой. Шаг за шагом мы анализируем путь пользователя, выявляем болевые точки и возможности для улучшения опыта. А затем упаковываем результаты глубинных интервью в Карту пути пользователя. Она помогает увидеть весь путь пользователя целиком и сразу выцепить «провалы» в сценарии — «боли», которые команде проектировщиков необходимо будет «вылечить», чтобы создать сервис или продукт, улучшающий жизнь пользователей.
Этот инструмент также идеально работает для визуальной демонстрации проблем заказчику или руководству (или любому представителю компании), уверенному, что их сервис прекрасно работает. Карта пути пользователя хороша именно тем, что на ней сразу видно, сколько цитат находится «внизу» (то есть на уровне негативных эмоций). Рука сама невольно тянется к стикерам с этими цитатами, чтобы забрать их, вчитаться в них и начать думать о том, как исправить этот негативный опыт.
Так выглядит один из вариантов пустого шаблона классической Карты пути пользователя:
Из чего состоит CJM
Это история опыта пользователя, поделенная на этапы. Попросите пользователя рассказать о том, с чего он начал, что случилось потом и как закончилась история. Дополнительно можно фиксировать время и вывести это в отдельную составляющую Карты пути пользователя. В таком случае, спрашивайте, как много времени пользователь потратил на то или иное действие, сколько времени ему потребовалось для решения задачи.
Фиксируйте точные цитаты, именно словами самого пользователя. Важно помнить, к какому из этапов относится цитата, чтобы верно расположить ее на Карте пути пользователя.
Для составления CJM важно, что чувствовал пользователь в тот или иной момент. Спрашивайте о его чувствах, ощущениях, эмоциях.
А вот так выглядит один из вариантов заполненного шаблон CJM:
Слева — ось эмоций, снизу — ось времени. На нижней оси прописаны этапы. На голубых стикерах — цитаты, каждая из которых соответствует определенному этапу и эмоциям. Конечно, цитат на каждом этапе может быть больше, чем одна. Однако чаще всего это означает, что вы можете поделить этап на еще несколько подэтапов.
Визуально шаблоны могут отличаться. Есть и более сложные шаблоны CJM, в которые могут быть включены следующие элементы:
- Задачи, которые пользователь хочет решить на том или ином этапе.
- Ожидание от сервиса.
- Барьеры, которые испытывает пользователь на том или ином этапе.
- Идеи по улучшению, которые помогут устранить барьеры.
- Наблюдения исследователей.
Как составить CJM
- Проведите глубинное интервью с пользователем. Наполнение на каждом из этапов зависит от информации, которую вам удалось получить от пользователя во время интервью или наблюдения. Поэтому обязательно продумайте, что будете спрашивать у респондента (составьте «Гайд интервью»).
- Фиксируйте яркие цитаты пользователя для каждого этапа. Так будет легче понимать, что и почему вызывает эмоции у пользователя.
- Распечатайте карту CJM в формате А0, разместите на стене или флипчарте, чтобы всей команде было удобно с ней работать. Либо используйте онлайн-платформу, такую как Miro.
- Используя шаблон «Карта пути пользователя», составьте пошаговый сценарий его действий на основе проведенного интервью. Отмечайте временные отрезки: это могут быть часы и минуты или ключевые этапы (до, вовремя, после). Разместите их на нижней части шаблона CJM, вдоль кривой времени.
- На каждом этапе (на каждой точке контакта) размещайте стикеры с цитатами — характерными эмоциональными реакциями. Наполнение на каждом из этапов зависит от информации, которую вам удалось получить от пользователя во время интервью или наблюдения.
- Проведите кривую, соединяя все эмоции на каждом этапе, чтобы четко увидеть, где случились «взлеты», а где «падения».
На примере ниже представлена Карта пути туриста, которому необходимо добраться из аэропорта в гостиницу, из кейса лаборатории Wonderfull.
На этом примере как раз представлен визуально немного другой шаблон CJM, однако все основные составляющие сохранены: этапы, время, цитаты, эмоции.
Композитная Карта пути пользователя
По итогам проекта у исследователей могут появиться сотни (без преувеличения) CJM. Точное их количество зависит от количества проведенных глубинных интервью. Как же презентовать их заказчику? Для этого составляются композитные CJM — карты пути пользователя, составленные на основе схожего опыта нескольких пользователей. Легче всего составить композитный CJM на основе Персона-моделей (или Персон). Это созданный на основе реальных людей персонаж, который обладает своими поведенческими особенностями. Другими словами, персона — это описание одной из групп пользователей с их отличительными потребностями, задачами, жизненными сценариями и ситуациями. Персона собирается на основе проведенных качественных и, возможно, количественных исследований.
Для композитного CJM характерно также выделение в отдельную составляющую KPI — для понимания, на какие показатели влияет опыт пользователя.
CJM начинается с исследования
Сама по себе работа над Картой пути пользователя начинается за один шаг до ее составления — с найденных историй, исследования пользовательского опыта. Именно пользователь приведет команду разработчиков к финальному продукту, через свои истории, через ответы на вопросы: ЧТО происходит? ПОЧЕМУ так происходит? В каком КОНТЕКСТЕ это происходит? Карта пути пользователя — следующий шаг после исследований. Шаблон, который помогает кластеризовать найденную во время исследований информацию.
Больше всего для исследования пути пользователя подходит глубинное интервью. Но могут использоваться и другие методы исследований, такие как наблюдение, например, запись экрана пользовательской сессии, usability тестирование, последовательный опрос на этапах пользовательского пути.
Для составления пути пользователя мы можем исследовать как широкий опыт решения какой-либо задачи, так и опыт использования отдельного функционала конкретного продукта. Это зависит от бизнес-задач, которые мы пытаемся решить. Хотим создать новый продукт — смотрим широко. А если хотим улучшить функционал или часть продукта — исследуем путь пользователя конкретного функционала.
Широкий опыт решения задачи
Широкий фокус помогает взглянуть на опыт за рамками продукта, получить много гипотез. Мы должны будем копать в совершенно разные, порой, даже в противоположные стороны, изучать все мелкие аспекты пользовательского опыта, потребностей, шагов их решения, результатов и последствий. Из этих находок мы возьмем в Карту пути пользователя истории респондентов и их наблюдения. Это поможет найти глубинные инсайты и сфокусировать дальнейшую работу.
Для изучения опыта лучше подходит метод глубинных интервью. Чтобы обеспечить максимальную пользу от интервью следуйте 3 правилам:
- Фокусируйтесь на жизненной истории человека, изучайте ее.
- Задавайте открытые вопросы.
- Используйте «5 почему?».
Изучайте глубоко следующие 5 элементов хорошей истории:
- Пользователь: узнайте о пользователе разные детали, «Чем вы занимаетесь?», «Что для вас важно в решаемой задаче?».
- Сюжет: «Расскажите, какую задачу вы решаете сейчас?», «Как это было в прошлый раз?».
- Контекст: «С чем вам приходится взаимодействовать?», «А где вы решаете эту задачу?».
- Неожиданные сведения о пользователе: копайте глубже, используйте «5 почему».
- Невербальные сигналы: Какие эмоции испытывает респондент во время разговора?
Текущий продукт, продукт конкурента
Изучение пути пользователя конкретного продукта используется, когда нужно найти зоны улучшения продукта. Тестирование продукта — это тоже исследование. Мы снова обращаемся к пользователю, следим за его реакцией и записываем его цитаты, идеи и пожелания. Мы можем составить Карту пути пользователя по итогам тестирования, и в ней будут детальные истории взаимодействия пользователя с продуктом. Нам это необходимо, чтобы получить инсайты и наметить итерации в разработке, понять, как нам надо доработать продукт.
Для этой задачи можно использовать как интервью, так и наблюдение, так как есть конкретный объект взаимодействия пользователя. Можно использовать и комплексные методы, подразумевающие как наблюдение, так и интервью, например usability тесты — наблюдаем и спрашиваем. В некоторых случаях, когда пользовательские шаги четко определены и определен список возможных проблем, можно сразу использовать и количественные метод, опрос. Количественный метод нужен для приоритезации проблемных зон или определения ключевых вариантов пути пользователя. Часть задач, например, определение ключевых путей пользователя, выявления точек завершения пользовательских сессий до целевого действия, можно выявить с помощью аналитики продукта.
На этапе разработки продукта или сервиса также можно проводить тестирования, проверять насколько правильно реализован Service Blueprint (карта сервисного сценария), искать зоны его улучшения или изменения. В данном случае используются аналогичные подходы, как и с тестированием существующего продукта. Нужен лишь более менее работающий прототип, с которым возможно обеспечить взаимодействие пользователя.
Что делать после составления CJM
После того, как вы составили CJM, переходите к следующему инструменту фокусировки — Карте разрывов (Gap Map). Посмотрите на Карту пути и выделите разрывы пользовательского сценария: несоответствие между интуитивным представлением пользователя о хорошем сервисе или продукте и его реальным опытом. Обычно это просто список с развернутым описанием разрыва, который можно записать в табличку с двумя колонками: «Ожидание» и «Реальность».
Причем, важны не только «отрицательные» разрывы, когда случился негативный опыт, но и «позитивные», когда пользователь ничего особенного не ожидал, а получилось круто. Ведь вам важно будет спроектировать сервис или продукт таким образом, чтобы такой разрыв был уже не случайностью, а стал частью вашего продукта. Это поможет превосходить ожидания пользователей.
CJM и Service Blueprint
Иногда CJM (Карта пути пользователя) путают с Service Blueprint (Карта сервисного сценария). Customer Journey Map — это фактический путь клиента по сервису, а может быть, путешествие между разными сервисами и каналами, в которых участвует и ваше предложение. Service Blueprint — карта спроектированного вами на основе этого клиентского пути (его проблем и возможностей), новое сервисное решение. После того, как мы фиксируем текущий опыт пользователя с помощью CJM, мы сможем сгенерировать новые идеи по улучшению и спроектировать новый сервисный сценарий, который как раз и ляжет в канвас «карты сервиса», какой она должна быть. Прочитайте подробнее о том, как перейти от CJM к Service Blueprint.
Советы и подсказки
- Важно помнить, что Карта пути пользователя не является целью сама по себе, а играет важную промежуточную роль в поиске понимания текущего опыта пользователя, барьеров в этом опыте и возможных решений по его улучшению.
- Не делайте Карту пользовательского опыта слишком сложной. Она должна рассказывать простую историю, чтобы сосредоточить внимание на потребностях пользователя.
- Работайте с шаблоном, висящим на стене (реальной или виртуальной), чтобы все члены команды могли видеть CJM и внести свой вклад в улучшение существующего опыта.
- Создавайте Карту пути для каждого пользователя, которого вы исследовали. Так вы сможете находить закономерности и сравнивать опыт разных людей.
125315, г. Москва, Ленинградский проспект 68, стр. 2, 3 этаж
+7 (495) 648 78 20
client@tiburon-research.ru
По материалам сайта www.blog.staveapps.com
Платформа ServiceNow может прекрасно справляться с задачей управления обслуживания клиентов (CSM). Вот только ни один инструмент, каким бы совершенным и технологичным он ни был, не поможет вам, если не вкладывать усилия и знания в персонал и процессы. Мы расскажем о шести лучших сценариях обслуживания клиентов, которые точно пригодятся в работе!
1. Как сказать клиенту, что вам необходимо больше времени, чтобы решить его проблему
Каждый всегда хочет получить результат немедленно, но, к сожалению, не всегда это реалистично и возможно. Если вы не можете решить проблему клиента прямо сейчас, очень важно дать прозрачный и точный прогноз ожидания, а также описать процесс выполнения.
Вот как следует сообщать клиенту, что вам требуется дополнительное время:
- «Я прошу прощения, но мне необходимо еще несколько минут, чтобы решить эту проблему. Вы согласны немного подождать, пока я ищу лучшее решение? Если вы спешите, я позвоню или напишу вам, когда все будет готово».
2. Как передать клиента другому специалисту
Никто не любит, когда решение его вопроса передают от одного специалиста другому, но иногда вы понимаете, что другой человек или отдел гораздо лучше справится с конкретной проблемой. Такой перевод проблемы может быть истолкован клиентом как «плохие новости», поэтому важно быть максимально деликатным.
Попробуйте вот такой хороший вариант:
- «(Имя клиента), мой коллега (Имя коллеги) из отдела (Название отдела) является большим экспертом в этом вопросе, чем я. Если вы не возражаете, я переадресую ваш вопрос ему. Я уже рассказал ему о сути проблемы, и вам не придется ничего объяснять заново».
3. Когда вы не можете решить проблему
В целом такой ситуации быть не должно, но иногда клиент оказывается неправ. Возможно, его вопрос был адресован вам по ошибке или он не совсем понимает, в каком направлении вы работаете и оказываете поддержку. Когда отказ в решении проблемы действительно оправдан, предлагаем такие варианты ответа:
«Сэндвич из комплимента» – начните с комплимента клиенту, затем сообщите плохие новости, завершите беседу также комплиментом.
- «Мы ценим, что вы обратились к нам с этой проблемой, однако мы ничего не можем сделать, чтобы решить ее. В знак благодарности мы предлагаем вам скидку на следующий заказ».
«Эскалация» – иногда клиенты обращаются с проблемой, которая должна быть решена на более высоком уровне. Чтобы избежать таких обращений в будущем, найдите время и предупредите о ней своего руководителя.
- «Босс, я многократно получаю жалобы на пользовательский интерфейс в последней версии приложения, необходимо собрать отзывы для отдела R&D».
4. Как признать, что вы были неправы
Плохие новости не становятся лучше со временем. Если вы допустили ошибку, лучше как можно скорее признаться в ней и показать, что у вас есть план как ее исправить и решить первоначальную проблему клиента.
Вот что нужно сказать клиенту, когда вы неправы:
- «(Имя клиента), прошу прощения. Я допустил ошибку. Мы исправим ее немедленно, но до полного решения вашей проблемы может потребоваться (число) часов/дней. Мы будем держать вас в курсе решения проблемы и обещаем, что больше такого не повторится. Еще раз приносим свои извинения».
5. Общение с рассерженным клиентом
Все мы сталкивались с рассерженным и недовольным клиентом, который расстроился из-за своей проблемы и вымещает недовольство на представителя службы поддержки клиентов. Возможно, некоторые из нас и сами были такими клиентами… Общение с рассерженным клиентом – настоящее искусство, но лучше всего помнить «правило пяти»:
1. Извиниться.
2. Быть кратким.
3. Повысить приоритет.
4. Не воспринимать ситуацию лично.
5. Сопереживать клиенту.
- «Мне очень жаль, что у вас возникла эта проблема. Я понимаю, как вы расстроены, и я решу ее в первую очередь».
6. Ответ клиенту, даже если решения проблемы еще нет
Если вы сказали клиенту, что позже сообщите о процессе решения проблемы, вы должны сделать это в течение 24 часов, даже если проблема еще не решена и вам просто надо сообщить, что ничего не изменилось.
Вот хороший вариант разговора:
- «Здравствуйте. Я просто хотел сообщить вам о процессе решения вашей проблемы. Я все еще работаю над ней, но не имею окончательного решения. Я постараюсь решить ее как можно скорее и сразу сообщу вам об этом».
Эти простые сценарии позволят специалистам вашей службы поддержки клиентов преодолеть сложные ситуации при работе с заказчиками, а всю техническую часть (регистрацию обращений, базу данных клиентов, перенаправление запросов и другие функции) вы можете доверить платформе ServiceNow.
Уже сейчас вы можете обратиться к специалистам компании «ИТ Гильдия» – официальному сертифицированному партнеру ServiceNow – и задать им любые вопросы, связанные с установкой, настройкой и эксплуатацией платформы.
Подписывайтесь на блог компании «ИТ Гильдия» – официального сертифицированного партнера ServiceNow, чтобы следить за новыми статьями, которые позволят вам достигнуть успеха, внедряя платформу.
Слово «дизайн» у многих ассоциируется исключительно с визуализацией: дизайн сайта, дизайн приложения. А сама профессия дизайнера — с творческими поисками. Но перевод понятия design включает и «разрабатывать», и «проектировать», и «конструировать». Именно на этом сосредоточены сервис-дизайнеры, и вот в чём преимущества такого подхода.
Что выигрывает бизнес при привлечении сервис-дизайнеров
Специфика работы сервис-дизайнеров в том, чтобы созданные продукты и решения были не просто визуально привлекательными, но и функциональными. На первом плане всегда задачи бизнеса и потребности пользователя. Такой подход требует своей методологии — её этапы мы и рассмотрим ниже.
Первый этап: определитесь со стратегией
Начало работы похоже на сеанс психотерапии: нужно понять запрос, провести ревизию ресурсов, наметить курс движения. Вопросы адресуются владельцу бизнес-процесса, и чем честнее ответы, тем отчётливее вырисовывается результат и путь к нему.
На первом этапе нужно задать стратегические вопросы владельцу бизнес-процесса
Спецпроект
За оценку ресурсов также отвечает дизайнер. Можно сэкономить время и начать сразу проектировать, проверяя свои решения в боевых условиях. А можно взять время на исследования, анализ и тестирование ― это будет дольше, но надёжнее. Как говорится, «Быстро, качественно, дёшево ― выбирайте любые два».
Результат первого этапа напоминает закрытые гештальты: не осталось ничего недосказанного, недопонятого, недоделанного. Владелец бизнес-процесса получает сформулированные гипотезы о том, как решить поставленную задачу.
Плюс дизайнеров, привлечённых со стороны, ― свежий взгляд. Многие боятся доверить внутреннюю кухню людям извне, но именно это на этапе исследований и требуется ― независимая и квалифицированная оценка. Иногда заказчик хочет сделать редизайн сервиса, потому что упали продажи и нужно привлечь клиентов. Но на поверку оказывается, что проблема не во внешнем виде, а в тарифной сетке продуктов, которую пользователи не понимают.
Для сбора «анамнеза» иногда используют брифование. Однако этим инструментом нужно пользоваться аккуратно, чтобы не смазать картину лечения. Дело в том, что на старте у участников процесса мало данных о рынке, пользователе, его потребностях. Кроме того, взгляд на конечный продукт не откалиброван ― участники процесса могут по-разному представлять себе результат. Поэтому стратегия «Мы заполняем бриф ― вы рисуете» выглядит хорошо только в корпоративных чатах.
Есть два случая, когда бриф особенно полезен. Первый ― заказчик «расписывается кровью» под своими желаниями. Он всё обдумал и честно заполнил бриф. Второй случай ― заказчик не уверен в том, чего хочет, но готов подумать. Вопросы для него служат своеобразной дорожной картой. Если серьёзно, многое зависит от продуктовой культуры компании. К сожалению, мало кто может похвастаться системным подходом, без которого невозможна постановка задач и распределение ролей.
Эффективный инструмент для быстрой генерации и валидации пользовательских сценариев ― воркшопы. Они сложнее брифования в плане организации, но заметно результативнее. Суть в том, что стейкхолдеры, исполнители, консультанты и пользователи под руководством модератора ищут общие знаменатели: в чём проблема, как её решить, кого привлечь. В отличие от брифа обратную связь дает каждое действующее лицо, а не только тот, в чьи руки попал документ с вопросами.
Второй этап: визуализируйте клиентский путь
Ко второму этапу мы приступаем, имея на руках валидированные гипотезы. Теперь их нужно верифицировать, то есть подтвердить. Для этого выстраиваем схему процесса: как пользователь из заданной точки А попадает в нужную нам точку Б. Путь пользователя, который выполняет конкретную задачу, называется user flow.
Он состоит из конкретных действий, которые пользователь предпринимает, чтобы выполнить сценарий. Чтобы составить карту этого сценария ― визуализировать клиентский путь, мы используем инструмент Service Blueprint («карта сервиса», «сервисный сценарий»).
Именно сервисный сценарий формирует скелет интерфейса. Он может охватывать как какую-то отдельную функцию, так и целый продукт. Возвращаемся к тому, что дизайнеру нужно не «просто нарисовать», а именно спроектировать, смоделировать процесс. Если это приложение сервиса для доставки, необходимо пройти путь от заказа товара до его получения.
Путь пользователя может проходить не только в цифровом пространстве. Например, один из сценариев регистрации на Госуслугах подразумевает подтверждение личности в центре обслуживания. Дизайнер должен предусмотреть, как пользователю найти этот центр ― на карте, в списке, через строку поиска.
Один из сервисов такси перед выпуском расширения обратился к нам, чтобы протестировать два своих приложения ― историческое и новое, а также сравнить их с двумя основными конкурентами. Мы определили 19 сценариев, которые нужно было проверить для каждого из четырёх приложений.
Некоторые сценарии мы тестировали, не выходя из дома: проверили скорость загрузки, общение с поддержкой и другие события. Этим мы занимались днём, а по вечерам наша команда садилась в такси и исследовала сценарии в полевых условиях: мы ездили из точки А в точку Б, катались по кругу, проверяли разницу между экономом и VIP, отказывались от заказов до старта и посреди поездки. В итоге наши наблюдения и выводы из них легли в отчёт на 122 страницы.
Для каждого сценария команда написала вывод о том, где сервис реализован удобнее и как его можно улучшить в приложении заказчика. Для наглядности составили сводную таблицу и добавили рекомендации. Например, весьма полезным оказался бы чат с водителями или возможность заказа такси с разных аккаунтов из одного приложения.
Третий этап: разработайте визуальный концепт
На этапе визуализации мы тиражируем пользовательские сценарии ― user flows ― на три–четыре экрана, которые отправляются в разработку. Это может быть главный экран приложения, либо несколько экранов, показывающие фичи сервиса, либо кликабельный прототип. Задача ― проиллюстрировать бизнес-процесс, согласно key visual («ключевому визуальному образу»).
Если раньше работа шла над тем, что будет за кулисами нашего бизнес-процесса, то сейчас речь идёт о «видимом» дизайне. Некоторые заказчики особенно ревностно относятся к визуалу. Чтобы согласование не перешло в многомесячное противостояние, лучше ограничить круг лиц, принимающих решение.
На этом этапе мы должны объединить тренды и лучшие практики с продуктом заказчика. Особенно важно, чтобы руководители доверяли нанятым исполнителям. Важно разграничить компетенции и путём обсуждения прийти к единому мнению, единой визуальной концепции.
Нередко появляются пограничные, или edge кейсы. Это проблема или ситуация, которая возникает только при нестандартном рабочем параметре: изменении логики, появлении новых данных и так далее. Например, мы визуализируем процесс доставки из федеральной сети магазинов. Выясняется, что какой-то регион не входит в зону доставки. Значит, нужно спроектировать пул экранов, которые видят пользователи из этого «выключенного» региона: что делать, если доставка недоступна?
Четвёртый этап: масштабируйте свою идею
Спроектированные бизнес-процессы с утверждённым визуалом масштабируются на весь продукт и отправляются в разработку. Если речь идёт о доработке имеющегося продукта, можно протестировать новый функционал на ограниченной аудитории. Например, обновлённый дизайнерами сервис доставки увидят 5% пользователей, а остальные 95% будут пользоваться старым сервисом ― до тех пор, пока функционал не пройдёт боевое крещение. Эта стратегия называется soft launch, дословно «мягкий запуск». Если решение создаётся с нуля, итерации зависят от продукта, рынка и других факторов.
Такой подход ― апробирование трансформации на отдельном бизнес-участке ― важная часть методологии Agile. Короткие итерации, или спринты, позволяют оперативно накапливать данные для совершенствования продукта. А значит, ошибки не столь критичны: fail early, fail often, fail cheap («ранний провал, частый провал, дешёвый провал»). Важный момент ― на протяжении всего проекта дизайнеры, разработчики и представители бизнеса должны работать вместе. Скорость требует включённости всех участников процесса.
Разумеется, не все и не всегда работают по Agile. Иногда у заказчика есть ресурсы только на дизайн, а на разработку появятся только через полгода. Так или иначе нужно будет вернуться к проекту и снять метрики.
Пятый этап: согласуйте с заказчиком
На первом этапе мы выбрали фичи для первой итерации разработки продукта. Часть из них протестировали и реализовали, но в бэклоге, как правило, ещё остаются гипотезы для проверки. В конце цикла разработки мы обсуждаем с заказчиком, что делать дальше ― возвращаться к этим гипотезам, формулировать новые или сосредоточиться на поддержке продукта.
Важно оценить не только как работает новая функция или насколько жизнеспособен продукт, но и контекст рынка. Нужно понять, появились ли новые данные, можно ли как-то улучшить процесс. Разумеется, всё это при участии стейкхолдеров.
Финальное согласование завершает цикл, но промежуточный аудит присутствует на каждом из этапов. Важно всегда синхронизироваться с владельцем бизнес-процесса или продукта в ожиданиях, обмениваться мнениями, по возможности привлекать специалистов из других отраслей. Кроссдисциплинарный подход открывает новые ракурсы. Знания и компетенции различных специалистов: маркетологов, копирайтеров, PR-менеджеров позволяют грамотно распределять ресурсы и получать новый взгляд на выбранный курс движения.
Вывод
Дизайнер, безусловно, может «просто нарисовать». Например, когда стоит задача создать новые иконки для приложения. Но задача, как правило, масштабнее ― создать или усовершенствовать само приложение. Его нужно спроектировать, протестировать, доработать. И повторить этот цикл несколько раз.
Поэтому чаще всего дизайнер ― это не художник, а архитектор. Нужно на берегу сверить ожидания и убедиться, что видение результата у заказчика и исполнителя совпадает.
Этапы, о которых мы рассказали, так или иначе проходит практически любая команда при разработке или обновлении продукта. Безусловно, особенности вашего продукта или бизнеса могут внести коррективы. Для нас такой фреймворк ― это система ориентиров, а для вас может стать каркасом для создания собственной методологии.
Источник фото на тизере: John Anvik on Unsplash
Рекомендуем:
- Спецпроект «Digital-инструменты для управления бизнес-процессами»
- Кто такой сервис-дизайнер и где на него обучиться
- Антитренды в веб-дизайне: оставьте это в прошлом
- Каждому своя коммуникация: как создавать рекламные сообщения, учитывая характер ваших клиентов
- Зачем дизайнерам дружить с аналитикой
Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.
-
Сценарий проблемного бизнес-процесса организации работы по обслуживанию заявки клиента
Итак,Важным для моей дипломной работы
процессом, сценарий которого изображается
на рисунке8, является
обслуживание клиента, принесшего свою
технику на ремонт или обслуживание.
Этот процесс охватывает весь персонал
ООО «Мика-Сервис».
Рисунок
8. – Сценарий работы сервисного
центра ООО «Мика-Сервис»
Опишем
сценарий.
Клиент
При
возникновении неисправности в
оборудовании, которое использует клиент,
он обращается в наш сервисный центр.
Когда
менеджер-приемки оповещает клиента о
готовности техники к выдаче, клиент
приходит в салон и производит оплату,
если таковая требуется, и забирает
технику.
Менеджер
приемки
При
обращении клиента менеджер приемки
производит предварительную диагностику
неисправности – уточняется, состоит
ли оргтехника на гарантийном обслуживании,
и подлежит ли эта техника с ее неисправностью
гарантийному ремонту.
Если
клиент согласен с условиями ремонта
или обслуживания, например может
возникнуть отказ в гарантийном
обслуживании и ремонт будет платным,
то менеджер приемки регистрирует заявку
в специальном программном обеспечении,
установленном на его ПК.
Затем
менеджер приемки выдает клиенту квитанцию
о том, что его техника принята на
обслуживание или ремонт, а саму технику
отдает сервис-инженеру соответствующего
профиля.
Когда
сервис-инженер возвращает технику после
ремонта, менеджер приемки оповещает
клиента и готовит технику к выдаче.
Клиенту
выдается счет на оплату, если случай не
гарантийный, либо ставится отметка в
гарантийный талон, техника возвращается.
Если
техника не подлежит ремонту, то
производится ее возврат клиенту с
соответствующей отметкой в программе.
Сервис-инженер
Полученная
техника диагностируется сервис-инженером,
определяется характер поломки и ее
причины. В некоторых ситуациях возможен
отказ от гарантийного ремонта, о чем
менеджер приемки должен оповестить
клиента (на сценарии этого не показано,
так как это довольно редкий случай).
Когда
выясняется характер неисправности,
сервис-инженер определяет необходимы
ли ему ЗИП. Если ремонт может быть
осуществлен без замены деталей, то
сервис-инженер приступает к устранению
поломки. В обратном случае, сервис-инженер
оформляет менеджеру склада заявку, в
которой указывает необходимые ЗИП.
После их получения, выполняется устранение
неисправности и техника передается
менеджеру приемки, который должен
вернуть ее клиенту.
Менеджер
склада
Менеджер
склада получает от сервис-инженера
заявку на ЗИП, если у него в наличии
имеется необходимые детали, то он выдает
их сервис-инженеру с соответствующей
записью в журнале.
Если
необходимые ЗИП отсутствуют на складе,
то менеджер склада подает заявку
офис-менеджеру, который пишет письмо
по электронной почте поставщикам ЗИП.
Как
только поступает ЗИП от поставщиков,
менеджер склада выдает ее сервис-инженеру
для использования
Офис-менеджер
Если
к офис-менеджеру поступает заявка на
ЗИП от менеджера склада, то он приступает
к переговорам с поставщиками о покупке
необходимых деталей. Переговоры ведутся
по электронной почте. После согласования
сделки осуществляется ее оплата и
ожидается поступление ЗИП