Точка контакта с клиентом – самое наблюдаемое место, поэтому именно туда направляется первое управленческое решение. Но одна точка не может быть причиной устойчивой проблемы. Корень надо искать в управленческой модели. В этой статье рассмотрим три логики управления сервисом, и разберем, почему большинство компаний застревают в первых двух.
Три модели управления клиентским сервисом
Рынок застрял на первых двух моделях не по незнанию, а из-за иллюзии, что выбирать нужно между «люди или процессы?». Но правильный ответ где-то между. Пока вопрос поставлен так, третья модель остается невидимой. Разберем модели по порядку.
1. Сервис – это качество людей
Качественный сервис возникает там, где работают правильные люди: внимательные, искренние, умеющие действовать в моменте без скрипта. Их реакция живая, внимание направлено не на процесс, а на клиента. Эти вещи не формализуются, а идут от человека.
Управленческий язык этой модели узнается немедленно:
- «Мы ищем людей, которые горят сервисом».
- «Это не про скрипты – это про отношение».
- «Искренности нельзя научить».
Официант в ресторане роняет поднос рядом с годовалым ребенком. В зале возникает напряжение – ожидаемая реакция на инцидент. Но его первый вопрос не про посуду. Он обращается к родителям: «Ребенок не ушибся? Все в порядке?». Дальше – не по сценарию. Он приносит малышу еду, предлагает «обмен», через несколько минут ребенок уже сам тянет ему морковку. На вопрос «это в скриптах?» отвечает: «У меня двое племянников этого возраста». Такие вещи скриптом не задашь.
Здесь есть реальная ценность – живость, эмоциональная глубина, человеческое отношение. В правильном контексте такой сервис создает сильный персонализированный опыт. Это то, что превращает хороший сервис в выдающийся. Но только там, где база уже выстроена – надежность, предсказуемость, исполнение обещаний. Без этого живость и эмпатия становятся вежливым фасадом на фоне системных сбоев.
Иногда первая модель сервиса производит опыт, который невозможно описать регламентом. Именно поэтому в нее верят. Но это не масштабируется. Как только компания растет – открываются новые точки, меняется состав команды – результат перестает быть предсказуемым. Руководитель больше не может его гарантировать: он зависит от конкретного человека, его смены, его состояния в этот день. При открытии новой точки некого поставить носителем, и уровень не воспроизводится.
Реакция на сбой в этой модели всегда одна: найти лучшего человека. Уволить, заменить, провести беседу. Системные проблемы интерпретируются как проблемы людей, потому что других инструментов нет. Большинство компаний работают именно так. Это стартовая точка, из которой не выходят, пока кризис масштабирования не становится очевидным.
2. Сервис – это выполнение стандартов
Следующий шаг выглядит логично: если качество зависит от людей, а людей нельзя контролировать, нужно описать правильное поведение и контролировать его исполнение.
- Регламенты, сценарии, чек-листы.
- Обучение, аттестация, тайный покупатель.
- KPI на скорость, вежливость, соблюдение скрипта.
Модель обещает предсказуемость: один и тот же результат при разных людях, в разных точках, в любое время. Это дает повторяемость, снижает хаос, позволяет быстро выровнять минимальный стандарт в массовой среде.
Но здесь есть фундаментальная дисфункция. В нестандартной ситуации исполнитель либо действует наугад (регламента нет), либо нарушает стандарт. И это еще не главная проблема. Со временем сотрудник начинает оптимизировать поведение под метрику, а не под клиентский результат. Например, подразделение оценивается по скорости и по качеству персонализации одновременно. Каждая метрика рациональна отдельно, но в совокупности они могут формировать конфликт. Когда это происходит, сотрудник в точке контакта решает его каждый раз сам. Соблюдение процесса и получение результата – не одно и то же.
Модель создает иллюзию управляемости. После очередного цикла улучшений становится заметно: качество контакта выросло, но характер жалоб не изменился. Клиенты начали получать более вежливые объяснения тех же ограничений.
Даже в развитой модели этого типа появляются элементы гибкости: обучение, service recovery, диапазоны компенсаций, рекомендации для нестандартных ситуаций. Это необходимо, и это повышает качество исполнения. Но логика остается той же: компания старается заранее предусмотреть как можно больше ситуаций и описать для них решения. Простой тест: если ситуация новая, сотрудник сможет принять решение без инструкции? Если нет – это не гибкость, а расширенный набор инструкций.
В моей практике это самая распространенная модель, и самая устойчивая к изменениям. Она воспринимается менеджментом как финальная точка развития, и в этом ее главная ловушка. Видя ограничения первой модели, компании переходят ко второй. Видя ограничения второй модели, возвращаются назад – усиливают найм, обучают ценностям, работают с тоном и культурой. Все это нужно, но само по себе не удерживает результат, потому что держится на людях, а люди меняются.
Маятник качается между людьми и процессами. Вопрос «люди или система» – неверный. Потому что остается невидимой третья модель. Система определяет, что людям вообще возможно делать. Стандарт без управленческой логики – инструкция без принципа. Человек без системы – случайность, которая иногда срабатывает. Выбирая между людьми и процессами, компания остается внутри одной и той же архитектурной ошибки.
3. Сервис – это результат архитектуры решений
Третья модель начинается с другого вопроса: не «кто виноват в сбое» и не «какой регламент нарушен», а «какое условие сделало это поведение возможным или неизбежным?».
Вторая модель управляет действиями: что делать, в какой последовательности, с каким результатом. Третья модель управляет условиями, при которых действия возникают. Это не следующий уровень той же логики, это другой объект управления.
Сервис = (система задает рамку и дает инструменты) × (человек наполняет ее качеством).
Система не заменяет человека, а создает условие, при котором его качество реализуется предсказуемо, а не случайно.
Разница между моделями видна в артефактах. Вопрос «что делать» не возникает – возникает вопрос «в каких рамках я действую».
- В модели 2 артефакт – стандарт действия: «При жалобе на задержку – принести напиток, извиниться, доложить менеджеру». Сотрудник исполняет.
- B модели 3 артефакт – матрица полномочий: «Сотрудник вправе компенсировать неудобство в пределах установленного лимита без согласования, если сохранить отношения важнее, чем выполнить процедуру».
Это меняет природу управленческих разборов:
- В модели 2: «У нас упала скорость ответа у Ивановой – проведите беседу». Метрика – приговор сотруднику.
- В модели 3: «У нас упала скорость в часы пик – посмотрите матрицу полномочий: возможно, операторы зависают в ожидании согласования». Метрика – сигнал к изменению системы.
Источник качества – архитектура среды: как распределены полномочия, где точки принятия решений, какие варианты поведения система делает возможными, а какие – структурно затрудненными. Масштабируемость встроена в архитектуру, а не держится на контроле или надежде на правильных людей в правильном месте.
Почему бизнес застрял на первых двух моделях сервиса
Компаний, которые работают в логике третьей модели, значительно меньше, и дело не в осведомленности. Потому что управленческий инструментарий заточен под людей и процессы. Архитектура операционной модели требует другого уровня мышления: не управлять тем, что происходит, а проектировать то, что делает это возможным. Здесь большинство и стопорится.
Цена ошибки не очевидна сразу. Модель 2 не производит плохой сервис, а производит стабильно ограниченный. Инвестиции растут, жалобы не исчезают, просто становятся привычными. Это незаметно, пока не появляется конкурент с другой логикой.
Переход в модель 3 – смена операционной логики, а не ее улучшение:
- Для компаний в модели 1 – отказ от поиска «звезд» и проектирование среды, в которой хороший сервис перестает быть личной заслугой.
- Для компании в модели 2 – замена части контролей на управляемые полномочия.
Для принятия этого решения руководителям надо быть готовыми отказаться от иллюзии полной управляемости в пользу более устойчивой модели. Масштабирование требует не наращивания улучшений поверх существующей структуры. Оно требует пересборки управленческой логики. Пока компания работает с людьми и регламентами, она работает с последствиями. Но результат определяется тем, как в системе устроены решения. Компания получает тот сервис, который производит ее управленческая модель.
Также читайте:
а что и где можно посмотреть про методологию Маркова\марковский процесс по управлению вероятностью, но не для очень подготовленого человек в этой теме...
Спасибо за идею достаточно интересная модель по управлению вероятностностью для управления сделками,
Если просто и "с комфортом" - я бы рекомендовал это видео (можно субтитры включить, если нужно). Далее можно переходить к моделированию Монте-Карло, так называемые MCMC.
Там все реально интересно. Lumivero выкупила весь пакет софта, который около 30 лет является лидирующим на рынке. Но что-то осталось у других, CrystalBall из них оказывается наиболее простым в использовании.
Некоторое время назад я для студентов делал сравнительный анализ топовых систем на рынке - здесь.
Спасибо, всё по делу - насколько я могу оценить, не пользуясь одновременно всем из перечисленного.
Единственное замечание. При моделировании, тем более - в сложных случаях, нужно хотя бы примерно представлять себе, что является предпочтительным в процессе выбора из нескольких возможных вариантов. Если говорить о распределениях, должна быть хотя бы какая-то базовая теория, описывающая происходящее. И хорошо, если имеющиеся данные позволяют заранее что-то уточнить. Если этого знания изначально нет, то моделирование его не добавит.
На самом простом примере треугольного распределения, упомянутого в тексте по ссылке - первый вопрос о его форме для самопроверки. Какие основания считать, что это именно треугольное распределение с симметричным треугольником без сдвига к одной из крайних точек? Представим себе, что мы моделируем совместное распределение расписания в проекте с тысячами длительностей работ, для оценки каждого из них мы выбрали треугольное распределение.
Для меня это совсем не бытовая тема. В медицине, в частности, много задач, которые бессмысленно решать с помощью моделирования или регрессионного анализа, если базовая теория отсутствует.
Безусловно, понимание предметной области должно быть изначально, как и осознание границ допустимых значений.
При этом на практике в каждом из пакетов есть уже преднастроенные семейства распределений, которым можно "скормить" фактические данные. Это выглядит так: из исторических примеров выбираются наиболее показательные для предметной области ряды, после чего выделяются столбцы и запускается подбор параметров в цикле по десяткам распределений, качество подбора контролируется по ряду критериев (Андерсон-Дарлинг, Колмогоров-Смирнов и др.) одновременно. На основании метрик формируется по убывающей рекомендации по выбору эмпирического распределения. Одновременно оно накладывается на теоретическое с параметрами, полученными из данных обучения. Если эксперт согласен - он просто утверждает выбор.
Треугольное распределение зачастую бывает хорошей стартовой точкой, если ничего другого нет. Как только у эксперта "в голове" возникают идеи пошире - он может перейти к PERT'у, бета-распределению и проч.
Кроме того, центральная предельная теорема помогает: если мы накладываем факторы различной природы, их суперпозиция с учетом корреляции (пакеты также ее рассчитывают и позволяют задать) позволяет "прикинуть" реалистичность отклонений. В более сложных случаях (ModelRisk) можно сразу перейти к копульным оценкам и контролировать тяжесть хвостов.
Регрессионный анализ - это совсем базовая техника, но часто достаточная. Применительно к медицине иногда лучше работает кластерный анализ (в т.ч. в рамках самоорганизующихся карт (SOM) Кохонена), а также каузальный анализ для сложной динамики факторов (DEMATEL-методология).
Но, конечно, все зависит от конкретной решаемой задачи: лучше не "втискивать" модели под задачу, а шире посмотреть на задачу, после чего выбрать более подходящий класс моделей.
В моём примере выше с учётом уникальности проектов исторических данных обычно нет. Только некие - достаточно туманные - соображения о семействах распределений, которые могли бы иметь какое-то отношение к делу.
И даже такой подход может работать лучше, чем оценки без моделирования. По крайней мере, после некоторого времени, потраченного менеджером проекта на раздумья и на игру с цифрами, появляются новые ощущения. И оценки обычно сдвигаются вправо в сторону менее отптимистичных.
Да. Вопрос о форме треугольника.
Может, если такие идеи появятся. Это к слову о наличии базовой теории.
Целиком зависит от задачи. даже не вижу смысла углубляться в детали.
Совершенно верно. Связанная с этим проблема - качество используемых данных. Тут моделирование не поможет. С регрессионным анализом другие сложности, даже если базовая теория в каком-то виде существует.
Помню, как во время короны некоторые очень крупные производители не смогли вывести свои вакцины на рынок - клинические испытания не подтверждали статистически значимые различия между группами. А слишком увеливать размеры групп очень сложно.