Комментарии 15
По моему мнению, стадия «Кто виноват» тоже нужна. Дело в том, что это, по сути, единственный способ найти какие-то ошибочные паттерны в поведении этих самых виноватых. Такие моменты часто требуют постоянного контроля и коррекции. Т.е., я считаю, не достаточно только, например, обучать персонал чему-то, но и контролировать, правильно ли поняли то, что давалось при обучении. И точечные корректировки тоже весьма полезны.
Ситуация, для наглядности:
От вас уходит клиент, которого вы ранее считали лояльным. Или даже усугубим — уходят клиенты массово.
Стадия первая: есть ли в этом проблема? Для нашего примера пускай будет «ДА».
Стадия вторая: клиентам не нравится, как с ними разговаривает акаунт-менеджер по телефону
Стадия третья: Кто виноват, а если точнее, от кого исходит проблема: акаунт-менеджер Степан.
Теперь можно выяснить почему Степан шлет прямым текстом всех клиентов.
Выясняется, что Степан не правильно трактовал рекомендацию высшего руководства: Переводить обращения с проблемами в русло «у нас все отлично» минимум на сутки после обращения (я с трудом представляю такое в нормальной работе, но тем не менее). Т.е. в нашем случае Степан просто говорил обратившимся клиентам «У нас все нормально, разбирайтесь сами!».
Далее идет решение: написать для Степана скрипты разговоров, по которым можно «морозиться», но при этом не вызывать у клиента возмущения и негатива. Научить Степана ими пользоваться. Проблема решиласть? Если «ДА», стандартизировать скрипты и раздать всем аккаунт-менеджерам.
Вобщем как-то так. Т.е. поиск виноватых я бы не выбрасывал. Просто делать это нужно цивилизовано, и помнить, для чего это делается: поиск источника проблемы с целью более глубокого понимания самой проблемы.
Ситуация, для наглядности:
От вас уходит клиент, которого вы ранее считали лояльным. Или даже усугубим — уходят клиенты массово.
Стадия первая: есть ли в этом проблема? Для нашего примера пускай будет «ДА».
Стадия вторая: клиентам не нравится, как с ними разговаривает акаунт-менеджер по телефону
Стадия третья: Кто виноват, а если точнее, от кого исходит проблема: акаунт-менеджер Степан.
Теперь можно выяснить почему Степан шлет прямым текстом всех клиентов.
Выясняется, что Степан не правильно трактовал рекомендацию высшего руководства: Переводить обращения с проблемами в русло «у нас все отлично» минимум на сутки после обращения (я с трудом представляю такое в нормальной работе, но тем не менее). Т.е. в нашем случае Степан просто говорил обратившимся клиентам «У нас все нормально, разбирайтесь сами!».
Далее идет решение: написать для Степана скрипты разговоров, по которым можно «морозиться», но при этом не вызывать у клиента возмущения и негатива. Научить Степана ими пользоваться. Проблема решиласть? Если «ДА», стандартизировать скрипты и раздать всем аккаунт-менеджерам.
Вобщем как-то так. Т.е. поиск виноватых я бы не выбрасывал. Просто делать это нужно цивилизовано, и помнить, для чего это делается: поиск источника проблемы с целью более глубокого понимания самой проблемы.
Посмотрите внимательно, я специально добавил шестую стадию — поиск виноватого на уровне начальника и ПОСЛЕ решения проблемы.
В вашем примере, Степан будет отбиваться руками и ногами, утверждая что всё делает по бумажке, и вообще нафиг вам такие невменяемые клиенты.
Но! Если вместо фразы «виноват Степан», вы скажете «при разговоре с клиентами нужно проявлять большую гибкость, например не посылать их сходу», то результат будет тот же, но без эмоций.
А уже тихонько после решения проблемы (если она оказалась решена, и клиенты уходили по этой причине) решить что дальше делать со Степаном
В вашем примере, Степан будет отбиваться руками и ногами, утверждая что всё делает по бумажке, и вообще нафиг вам такие невменяемые клиенты.
Но! Если вместо фразы «виноват Степан», вы скажете «при разговоре с клиентами нужно проявлять большую гибкость, например не посылать их сходу», то результат будет тот же, но без эмоций.
А уже тихонько после решения проблемы (если она оказалась решена, и клиенты уходили по этой причине) решить что дальше делать со Степаном
Кстати, вот ещё цепочки виноватых:
Виноват менеджер не давший Степану более точных указаний (как сказали — так и делал)
Виноват менеджер не провёвший должный инструктаж (так откуда я знал?!)
В отделе техподдержки «так принято» разговаривать с клиентами — «А чо я виноват, самый рыжий что-ли?!»
А теперь скажите честно — вам охота в этой цепочке копаться?
Виноват менеджер не давший Степану более точных указаний (как сказали — так и делал)
Виноват менеджер не провёвший должный инструктаж (так откуда я знал?!)
В отделе техподдержки «так принято» разговаривать с клиентами — «А чо я виноват, самый рыжий что-ли?!»
А теперь скажите честно — вам охота в этой цепочке копаться?
Есть мнение (не мое), что в «браке» (читай ошибках, просчетах, упущениях и т. д.) на 95% виновата система и лишь на оставшиеся 5% конкретные исполнители, работающие в ней. Но это так, замечание в сторону.
Сказать же я хотел, что, безусловно, можно лечить симптомы (бороться со следствиями, «тушить пожары») — тогда можно будет не копаться нигде кроме огромной (и все увеличивающейся) кучи этих самых симптомов.
Сказать же я хотел, что, безусловно, можно лечить симптомы (бороться со следствиями, «тушить пожары») — тогда можно будет не копаться нигде кроме огромной (и все увеличивающейся) кучи этих самых симптомов.
Я говорю не о том, что не нужно искать причину проблемы. Я говорю о том, что не нужно пытаться сделать кого то ответственным за возникновение этой проблемы.
Есть проблема? — Отлично, решаем, а кто её создал — решим потом. Кстати, иногда решение проблемы — уволить проблемного сотрудника. Даже не потому что он виноват, а просто потому, что взять нового будет проще, чем переучивать старого.
Это как пожар — когда он горит, то нужно сначала его потушить, а потом уже искать виноватых.
Есть проблема? — Отлично, решаем, а кто её создал — решим потом. Кстати, иногда решение проблемы — уволить проблемного сотрудника. Даже не потому что он виноват, а просто потому, что взять нового будет проще, чем переучивать старого.
Это как пожар — когда он горит, то нужно сначала его потушить, а потом уже искать виноватых.
Ну я не могу вам точно сказать, хочу я копаться или нет, но по личному опыту: из таких цепочик выстраивается бизнес-модель, которая, в частности, зачастую позволяет пережить один из опаснейших моментов развития бизнеса (проекта, продукта, не суть важно) — этап бурного роста. Если такой произойдет, конечно :)
В моем примере я не говорю о том, что необходимо возложить вину на Степана. Или на инструктора. Он действительно, как вы абсолютно резонно заметили, все лишь звено в какой-то цепочке. Вопрос насколько детально вы готовы рассматривать звенья цепочки — это уже вам на откуп, или на откуп ситуации (Мне неизвестны какие-то детерминированные способы это сделать. Хотя я не исключаю их существования.)
В отношении «когда глубже анализировать проблему — до или после решения» — тут тоже, считаю, однозначного решения нет. Я предпочитаю глубину выбирать по наитию, но искать сразу после возникновения проблемы, а не после решения. Если вернуться к примеру, то вот к чему может привести решение до анализа:
1) Клиенты уходят.
2) Им не нравится общение по телефону.
3) — 4.1) Предложить им скидку (ужасный, но вариант. Клиенты перестанут уходить, но прибыль снизится. А решение ли это?)
4.2) Предложить им общаться по емейлу (никак не решит проблему, т.к. по емейлу можно писать то-же самое, что и говорить в трубку + по емейлу сложнее делать ко-продажу, новое предложение, потому как минимум сложно отследить, правильно ли понял вас клиент. Проблема не решена + усугубление ситуации)
В моем примере анализ предшествует решению, что, по моему опыту, более «тру вей». Я не настаиваю, что у всех так. Более того пример — это вилами по воде. Реальные ситуации могут существенно отличаться. И в одно ситуации может быть лучше мой вариант, а в другой ваш. Или, что скорее всего, возникнет какой-то микс.
Но все это не отменяет главного — абсолютно безполезен поиск виновных только ради поиска. Без каких-то последующих дальнейших анализа и действий. Это абсолютно точно подмечено в статье и я полностью согласен с таким мнением.
В моем примере я не говорю о том, что необходимо возложить вину на Степана. Или на инструктора. Он действительно, как вы абсолютно резонно заметили, все лишь звено в какой-то цепочке. Вопрос насколько детально вы готовы рассматривать звенья цепочки — это уже вам на откуп, или на откуп ситуации (Мне неизвестны какие-то детерминированные способы это сделать. Хотя я не исключаю их существования.)
В отношении «когда глубже анализировать проблему — до или после решения» — тут тоже, считаю, однозначного решения нет. Я предпочитаю глубину выбирать по наитию, но искать сразу после возникновения проблемы, а не после решения. Если вернуться к примеру, то вот к чему может привести решение до анализа:
1) Клиенты уходят.
2) Им не нравится общение по телефону.
3) — 4.1) Предложить им скидку (ужасный, но вариант. Клиенты перестанут уходить, но прибыль снизится. А решение ли это?)
4.2) Предложить им общаться по емейлу (никак не решит проблему, т.к. по емейлу можно писать то-же самое, что и говорить в трубку + по емейлу сложнее делать ко-продажу, новое предложение, потому как минимум сложно отследить, правильно ли понял вас клиент. Проблема не решена + усугубление ситуации)
В моем примере анализ предшествует решению, что, по моему опыту, более «тру вей». Я не настаиваю, что у всех так. Более того пример — это вилами по воде. Реальные ситуации могут существенно отличаться. И в одно ситуации может быть лучше мой вариант, а в другой ваш. Или, что скорее всего, возникнет какой-то микс.
Но все это не отменяет главного — абсолютно безполезен поиск виновных только ради поиска. Без каких-то последующих дальнейших анализа и действий. Это абсолютно точно подмечено в статье и я полностью согласен с таким мнением.
Прекрасный скрипт для проработки проблемы. Как говорится: «Вашими бы устами...»
Осталось понять, как быть с тем, что люди в первую голову эмоциональны, а уже потом рациональны, а уж в случае стрессовой ситуации считанные единицы могут сохранять «холодную» голову и не перескакивать сразу к пункту 3, зацикливаясь на нем и только на нем…
Осталось понять, как быть с тем, что люди в первую голову эмоциональны, а уже потом рациональны, а уж в случае стрессовой ситуации считанные единицы могут сохранять «холодную» голову и не перескакивать сразу к пункту 3, зацикливаясь на нем и только на нем…
Продукт не успевает выйти в срок Случай самый серьёзный, так что, возможно, прийдёться кого-то и уволить
о дааа. и проблема сразу будет решена — продукт будет выпущен точно в срок
Ну почему никто не читает внимаааательно? :) Ну неужто я не писал, что разбор полётов ПОСЛЕ решения проблемы. Тоесть, когда продукт уже вышел — и мы точно поняли, что проблема в нашем архитекторе, притянувшем кучу ненужных наворотов, и тянущем их дальше — то да, уволив его мы ускорим разработку.
но «раз» и «если» проблема действительно «уже решена» — то нужно ли увольнять кого-то?
да, если мы хотим недопустить повторения проблем.
Не искать виноватого — не значит не устранять проблемы. Если проблема в архитекторе — то нам нужен новый (старый не виноват, просто он нам не подходит). Просто нужно понимать, что увольнение — это не всегда наказание — иногда это просто необходимость.
Не искать виноватого — не значит не устранять проблемы. Если проблема в архитекторе — то нам нужен новый (старый не виноват, просто он нам не подходит). Просто нужно понимать, что увольнение — это не всегда наказание — иногда это просто необходимость.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стадии решения проблемы