Комментарии 18
Спасибо. Очень подробная выкладка ваших действий. Хотя у меня все же остался вопрос. Почему же вы взяли еще раз этого клиента? Я конечно понимаю, причины разные могут быть. Просто мне не совсем ясно зачем брать проблемного клиента снова. В моем представлении работа с такими выходит себе дороже.
Деньги.
Получается, что затупили :)
Суть в том, что в первый раз клиент к нам попал потому что не была налажена жёсткая модерация поступающих лидов. Сейчас такая модерация есть, но для нас этот лид выглядел так, что к нам пришёл уже наш клиент, с которым мы работали. Подумали, что про его «заскоки» мы уже знаем и справимся с ними, но переоценили себя и недооценили клиента.
Суть в том, что в первый раз клиент к нам попал потому что не была налажена жёсткая модерация поступающих лидов. Сейчас такая модерация есть, но для нас этот лид выглядел так, что к нам пришёл уже наш клиент, с которым мы работали. Подумали, что про его «заскоки» мы уже знаем и справимся с ними, но переоценили себя и недооценили клиента.
Буду рада фидбеку, не стесняйтесь задавать вопросы!
Не подпускайте клиента к командеПо-моему, это должен быть первый пункт по умолчанию, если, конечно, вы не «дружите компаниями».
Плюс я бы добавил общение только по электронной почте, по крайней мере, с новыми или такими проблемными клиентами, потому что в случае разборок никакие чаты и разговоры ни к чему не прилепить. Это помогает логировать все задания/решения/изменения/требования и т.д. Например, можно было спокойно сослаться на скрин дизайна при обнаружении на нем новых элементов — хорошо, что вы сделали резервную копию. Плюс написание письма позволит еще раз продумать сообщение.
По-моему, это должен быть первый пункт по умолчанию, если, конечно, вы не «дружите компаниями».
Иногда подход с общим чатом действительно здорово облегчает задачу: мы пилим мобильные приложения для e-commerce, и в таких проектах часто бэкэнд на стороне клиента, да и логика фильтраций-каталогов-корзин у многих мудреная, и лишнее звено искажения информации в виде менеджера порсто ни к чему.
Сейчас мы проверяем клиентов на старте и понимаем, что наши клиенты классные и коммуникацию с командой им доверить можно.
общение только по электронной почте, по крайней мере, с новыми или такими проблемными клиентами
Здесь соглашусь в пункте «логировать изменения чертовски важно». У нас на уровне процессов выстроено так: коммуникация в чате (потому что это быстрее в разы), но обязательное дублирование договоренностей по email или в basecamp. И в договоре прописано, что изменения фиксируются там. С любыми клиентами, иначе никак.
Интересная статья. Какие будут Ваши действия, если истеричный клиент это постоянный и основной клиент компании, который снабжает всеми проектами? Каким образом можно аккуратно наладить работу с ним не доводя до расторжения всех контактов?
Мне кажется, что в этой ситуации дешевле направить усилия на поиск новых клиентов, а не на выправление ситуации с конкретно этим («пожалуйста, а давайте вы не будете нам по ночам писать и криворукими называть», так что ли?).
Потому что при прочих равных плохой клиент всегда обходится дороже, на него уходит больше рабочего времени ваших сотрудников: на коммуникацию, чтобы понять а что вообще нужно, на поплакать под душем, на поиск нового места работы.
Если отказаться от сотрудничества совсем-совсем-совсем никак, то нужно устанавливать четкие правила и приучать клиента. Для клиента такие правила аргументировать пользой: «вы же сами понимаете, что если мы будем брать в работу несформулированную задачу, то потратим больше времени на то, чтобы разобраться, что вообще делать. Поэтому задачи берем в работу только после того, как она выглядит так: 1, 2, 3… Это сэкономит ваши деньги».
Самим эти правила тоже нужно выполнять: если сказать клиенту, что вы не отвечаете на сообщения по ночам, а потом продолжить отвечать, то ничего не получится.
Кстати. Может оказаться, что такой клиент работает с вами как раз потому, что на вас можно наорать и вы все быстро пойдете делать. Поэтому когда появятся какие-то правила, вы ему разонравитесь и он и так уйдет. ¯\_(ツ)_/¯
Потому что при прочих равных плохой клиент всегда обходится дороже, на него уходит больше рабочего времени ваших сотрудников: на коммуникацию, чтобы понять а что вообще нужно, на поплакать под душем, на поиск нового места работы.
Если отказаться от сотрудничества совсем-совсем-совсем никак, то нужно устанавливать четкие правила и приучать клиента. Для клиента такие правила аргументировать пользой: «вы же сами понимаете, что если мы будем брать в работу несформулированную задачу, то потратим больше времени на то, чтобы разобраться, что вообще делать. Поэтому задачи берем в работу только после того, как она выглядит так: 1, 2, 3… Это сэкономит ваши деньги».
Самим эти правила тоже нужно выполнять: если сказать клиенту, что вы не отвечаете на сообщения по ночам, а потом продолжить отвечать, то ничего не получится.
Кстати. Может оказаться, что такой клиент работает с вами как раз потому, что на вас можно наорать и вы все быстро пойдете делать. Поэтому когда появятся какие-то правила, вы ему разонравитесь и он и так уйдет. ¯\_(ツ)_/¯
Была подобная проблема с олним из клиентов, я был зелен и неопытен, слепо выполнял хотелки клиента, проработав 1 год я ушел. Ваши советы в точку.
Наблюдения показывают, что для успокоения некоторых клиентов достаточно принести кого-то из команды в жертву даже понарошку
Здесь упал со стула. А если потом клиент испортит репутацию жертвенного агнца, получив таким образом подтверждение от его менеджера в некомпетентности работника? Есть также большая вероятность, что клиенту это жертвоприношение понравится и он захочет еще жертв. Интуитивно чувствую, что это неправильное решение.
Есть небольшое упражнение, которое показывают вначале каждого тренинга про переговоры. Ставят друг напротив друга двоих и дают задачу сдвинуть оппонента с места. Побеждает всегда не тот, кто сильнее давит, а тот, кто делает шаг назад.
Когда клиент орет и называет вас мудаками, то с точки зрения спортивных переговоров вести с ним диалог нельзя: он на эмоциях, доказать ему, что на самом деле никто не мудак, невозможно — никакие доводы не воспринимаются.
Если продолжать давить, что мы молодцы, то клиент разбесится еще больше: с его-то точки зрения это не так, поэтому вы не только мудаки, но еще и врете. Допускать такого нельзя.
Поэтому я делала «шаг назад» и говорила:
— так, а почему вы считаете, что мы мудаки? Потому что нашли в первой сборке баги, которых не было в отчете от QA? Вы правы, это неприятно. Несмотря на то, что в первых сборках обычны баги, нашему QA стоит вносить в отчет даже мелкие недочеты. Мы с ним серьезно поговорим, чтобы такого больше не повторялось.
С точки зрения клиента это было жертвоприношение. Репутация команды при этом не страдала, никто никого не опускал.
НО! Есть важное примечание, которое нужно было добавить в статью:
1. Когда я подыгрывала и делала жертвоприношение, разговор всегда шел о поведении наших сотрудников, а не об их компетенциях или личности.
Хорошо: да, наш сотрудник не внес баг, в следующий раз стоит вносить даже такие баги. Я с ним поговорю, чтобы вносил.
Плохо: у нас невнимательный тестировщик, поэтому не внес.
2. Как только разговор переходил на личности, ни о каких «шагах назад» разговор даже не шел. Пример:
— вы что там, считать вообще не умеете?
— выражайтесь корректно, пожалуйста. Мы умеем считать. Если вы будете допускать такие выражения, то у нас не получится сотрудничества.
Вывод: если внедрять этот совет, то нужно быть внимательным и думать головой. Но если думать, то он классно работает.
Когда клиент орет и называет вас мудаками, то с точки зрения спортивных переговоров вести с ним диалог нельзя: он на эмоциях, доказать ему, что на самом деле никто не мудак, невозможно — никакие доводы не воспринимаются.
Если продолжать давить, что мы молодцы, то клиент разбесится еще больше: с его-то точки зрения это не так, поэтому вы не только мудаки, но еще и врете. Допускать такого нельзя.
Поэтому я делала «шаг назад» и говорила:
— так, а почему вы считаете, что мы мудаки? Потому что нашли в первой сборке баги, которых не было в отчете от QA? Вы правы, это неприятно. Несмотря на то, что в первых сборках обычны баги, нашему QA стоит вносить в отчет даже мелкие недочеты. Мы с ним серьезно поговорим, чтобы такого больше не повторялось.
С точки зрения клиента это было жертвоприношение. Репутация команды при этом не страдала, никто никого не опускал.
НО! Есть важное примечание, которое нужно было добавить в статью:
1. Когда я подыгрывала и делала жертвоприношение, разговор всегда шел о поведении наших сотрудников, а не об их компетенциях или личности.
Хорошо: да, наш сотрудник не внес баг, в следующий раз стоит вносить даже такие баги. Я с ним поговорю, чтобы вносил.
Плохо: у нас невнимательный тестировщик, поэтому не внес.
2. Как только разговор переходил на личности, ни о каких «шагах назад» разговор даже не шел. Пример:
— вы что там, считать вообще не умеете?
— выражайтесь корректно, пожалуйста. Мы умеем считать. Если вы будете допускать такие выражения, то у нас не получится сотрудничества.
Вывод: если внедрять этот совет, то нужно быть внимательным и думать головой. Но если думать, то он классно работает.
Вроде, все по делу. Несмотря на определенное количество «очевидностей», новичкам должно очень помочь.
Дважды встречался с подобными клиентами, есть пара отличий/модификаций:
1. Совместный слак разработчиков с такими клиентами статистически намного чаще приносит больше вреда, чем пользы, поэтому лучше туда добавить только тимлида (для важных срочных вопросов) или самого дружелюбного/стрессоустойчивого (кроме менеджера), кто будет обрабатывать подобные запросы;
2. Защищать команду путями из разряда «мы накажем виновного/проведем серьезный разговор» сработает не больше ~2-3 раз. Клиенту не нужно быть гением, чтобы понять, что здесь что-то не так;
3. Оценивать задачи на проекте с багажом 5 команд разработки — тыканье пальцем в небо. Особенно в первые месяцы (хотя, думаю, это вам очевидно).
Лайк за резервную копию фигмы и отсеивание багов, дислайк за жертвоприношение.
Дважды встречался с подобными клиентами, есть пара отличий/модификаций:
1. Совместный слак разработчиков с такими клиентами статистически намного чаще приносит больше вреда, чем пользы, поэтому лучше туда добавить только тимлида (для важных срочных вопросов) или самого дружелюбного/стрессоустойчивого (кроме менеджера), кто будет обрабатывать подобные запросы;
2. Защищать команду путями из разряда «мы накажем виновного/проведем серьезный разговор» сработает не больше ~2-3 раз. Клиенту не нужно быть гением, чтобы понять, что здесь что-то не так;
3. Оценивать задачи на проекте с багажом 5 команд разработки — тыканье пальцем в небо. Особенно в первые месяцы (хотя, думаю, это вам очевидно).
Лайк за резервную копию фигмы и отсеивание багов, дислайк за жертвоприношение.
Да, советы местами очевидные. Но практика показывает, что вот это вот все понятно на берегу, а когда на тебя клиент орет и отжимает твою команду, то сходу выкинуть установку «клиент всегда прав» сложновато. Вот мемес на эту тему.
А кто-то не знает, что клиент не всегда прав.
А кто-то не в курсе, как дорого стоит рекрутинг.
А кто-то что-то еще.
А потом все поувольнялись, а менеджер даже не в курсе, что именно пошло не так и что ответственный за увольнения именно он, а не «клиент сложный попался» или «а че такого взяли вообще».
Про общий слак писала выше: мы верим в людей и в 99% случаев они это оправдывают. Часто такой метод все упрощает. Конкретно в этом кейсе общий слак не случился, к счастью.
Про метод «поиск виновного» тоже согласна. Это нужно делать очень аккуратно и четко видеть грань, где ты охлаждаешь клиента, а где уже подставляешь коллегу. Я эту грань всегда видела.
Про п.3 неистово плюсую. Было давно, молодые и горячие — конвертировали эту ошибку в опыт.
А кто-то не знает, что клиент не всегда прав.
А кто-то не в курсе, как дорого стоит рекрутинг.
А кто-то что-то еще.
А потом все поувольнялись, а менеджер даже не в курсе, что именно пошло не так и что ответственный за увольнения именно он, а не «клиент сложный попался» или «а че такого взяли вообще».
Про общий слак писала выше: мы верим в людей и в 99% случаев они это оправдывают. Часто такой метод все упрощает. Конкретно в этом кейсе общий слак не случился, к счастью.
Про метод «поиск виновного» тоже согласна. Это нужно делать очень аккуратно и четко видеть грань, где ты охлаждаешь клиента, а где уже подставляешь коллегу. Я эту грань всегда видела.
Про п.3 неистово плюсую. Было давно, молодые и горячие — конвертировали эту ошибку в опыт.
Ох, Клиент узнается с лету и подтверждается по одной цитате. Очень здорово, что вы отказались в итоге от общего слэка.
С точки зрения не-выгорания: я была на проекте недолго, но прессинг со стороны Клиента действительно был постоянный, вместе с позицией "начальства", в худшем смысле. Но было понятно, что у Клиента — бизнес, зависящий от приложения, люди на зарплате, и скорее всего то, что мы от них слышали — это агрессия не столько в сторону исполнителя, сколько в сторону рисков с ним связанных. Мне казалось, что Клиент боится недоконтролировать, не выносит собственные ошибки, старательно себя накручивает, в общем целый микс из гиперответственности за всех и все.
Эмоционирование с заламыванием рук доставалось, конечно, менеджеру и команде, но первопричина была вовсе не в пропущенном баге и это, в общем-то, снижало накал — помнить и напоминать, что катастрофа сейчас в голове клиента разворачивается, а не объективно на проекте. И убрать команду, чтобы она этого не видела лишний раз — по-моему, отлично.
В этот раз дело даже наверное не в отсутствии общего слэка, а в стратегическом решении: договорились, что раз доверия нет, то и помочь мы не сможем: это будет какая-то помощь через сопротивление, очень неправильная.
Большинство трагедий было в голове клиента и наших косяков было объективно мало (а те, что были, можно было разрешить разговорами, если бы мы обсуждали что-то, а не «я сказал — вы делайте»), поэтому решение не работать — самое экологичное, что можно было сделать по отношению друг к другу.
Большинство трагедий было в голове клиента и наших косяков было объективно мало (а те, что были, можно было разрешить разговорами, если бы мы обсуждали что-то, а не «я сказал — вы делайте»), поэтому решение не работать — самое экологичное, что можно было сделать по отношению друг к другу.
«это будет какая-то помощь через сопротивление, очень неправильная» — да, думаю, так и было бы. Но раз на какое-то время работа продолжилась, вы экономили свой эмоциональный ресурс (:
«Я сказал — вы делайте», и при этом «я сказал, как посчитал нужным, а вы поймите, что я имел в виду и в полном объеме». Подвижки у Клиента, вроде, были, но незначительные. Это по-прежнему патовые отношения, если сравнивать потери и общий выхлоп.
«Я сказал — вы делайте», и при этом «я сказал, как посчитал нужным, а вы поймите, что я имел в виду и в полном объеме». Подвижки у Клиента, вроде, были, но незначительные. Это по-прежнему патовые отношения, если сравнивать потери и общий выхлоп.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сложные клиенты: как защитить от них свою команду