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

Незнакомый аэропорт. Что в первую очередь посетители начинают искать прибывая в незнакомое место? В состоянии стресса мы пытаемся действовать инстинктивно, включая привычные паттерны, пытаемся действовать по знакомым сценариям.

И, по правде говоря, большинство из них работает:
➮ Найти зону регистрации
➮ Сдать багаж
➮ Найти зону вылета
➮ Пройти в самолет, занять свое место и дружно распевать Kum Ba Yah - Стандартные шаги, которые повторяются в любом международном аэропорту.

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

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

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

В результате все закончилось благополучно, моя спортивная подготовка позволила мне пробежать еще 1,5 км с ручной кладью до самого крайнего гейта и успеть до вылета. А если бы я был с детьми или пожилым человеком? Все, пиши пропало!

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

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

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

Для поиска слабых мест и разработки механизмов защиты от подобных ошибок мы используем концепцию Poka Yoke - защита от непреднамеренной ошибки. Создаем условия в сервисной модели, при которых клиент не сможет совершить ошибку, даже если захочет.

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

➮ Ошибка должна быть легко обнаружаема, вот, прям, совсем легко. То есть клиент или бизнес, в зависимости от того, кто выполняет действие должны увидеть, что ошибка возникла;
➮ Ошибка должна быть легко устранима, вот, прям, совсем легко на месте (руками или автоматикой);
➮ Если ошибка повторяется, то клиент должен иметь возможность о ней сообщить, иначе он унесет ее с собой и будет писать о ней этот гневный пост)