При управлении командой в 2-3-5 человек почти все строится на логике, адекватности и хороших отношениях. Как только команда вырастает и в ней оказываются десятки ребят, плавно стекающихся в сотни, проверенные приемы перестают работать, но где в экспресс-режиме брать новые, не всегда очевидно. Набивать шишки — бесспорно удел сильных, но лучше обмениваться опытом.

Я вспомнила топ собственных ошибок и просчетов, которые в разное время допускали я или мои тимлиды, немного порефлексировала и объединила все в один список.

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

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

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

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

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

Заодно и рабочие сценарии сразу найдете и не придется оправдываться за кривое ТЗ.

Уберите любой из пунктов и все пропало. Особенно это касается задач, которые вы делегируете подчиненным или коллегам. За примером далеко ходить не придется, достаточно представить две ситуации:

Бонус:

• Успеешь?/Комфортный срок?/Берешься? — любое уточнение не для галочки. Очень рекомендую получать полноценное согласие от сотрудника, потому что дедлайн для него в том числе и если вы просто спустите задачу, не уточнив, а способен ли он вообще закончить в такие сроки, то спойлер: в проигрыше останется не Петя.

• Если вы при этом не уверены в компетенции сотрудника или знаете, что он может стоически молчать и буксовать, назначьте промежуточную встречу до дедлайна, чтобы обсудить результаты.

• Если менеджер не успевает, уточните, что его тормозит и с чем нужна помощь: ему может не хватать, например, времени или экспертизы, а сказать об этом вовремя сам он не сможет.

Про постановку про SMART ничего не пишу, потому что это о другом.

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

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

В идеальном мире все ваши действия приводят к какому-то результату для команды и компании. Чтобы этот результат был осязаемым, понятным и управляемым, его надо замерять. Правило простое: замерьте, измените, замерьте снова.

Решили обучить операторов грамотности? Замерьте, что было до обучения, а затем то, что стало после. Если ничего не изменилось, это точно не стоит практиковать дальше, не изменив формат или содержимое курса.

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

Хотите дарить каждому клиенту букет роз по пятницам? Разделите клиентов на две группы... Ну, в общем вы поняли.

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

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

Бонус: не придется по сто раз рассказывать коллегам, которым вдруг понадобилось узнать, как у вас все работает — они смогут найти всю информацию сами.

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

Класть все 10 метрик в одну корзинку не нужно. Разделяйте, каскадируйте, властвуйте. Каждая метрика должна оказаться у ребят, которые на нее непосредственно влияют (непрозрачная и недостижимая схема KPI убьет вашу команду быстрее, чем твердое печенье и невкусный кофе). Так, 10 показателей могут превратиться в 12 или 15 (например, один большой SLA у вас состоит из 2 более узких), но как только вы раскидаете это по ответственным, это размажется всего до 2-3-4 показателей на группу.

Спасибо эволюции!

Если ваша команда получает премию за выполнение таргета по SLA на скорость 1 ответа клиенту, операторы могут легко хакнуть показатель, отправляя пустое приветствие, а потом пропадая на полчаса. Так, контрметрикой для этого показателя может стать, например, SLA решения вопроса, который отразит, насколько быстро клиенту реально помогли, а также показатель качества решения и FCR, которые в целом служат хорошими противовесами ко многим скоростным показателям.

Посмотрите на свои текущие KPI для команд: можно ли их чем-то сбалансировать на благо клиентов?

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

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

Из каждого такого похода стоит выносить конкретные проекты, которые помогут команде быть эффективнее, а клиентам — счастливее.

Вы можете вложиться в самую топовую тикетную систему на рынке, а потом с удивлением обнаружить, что половиной фич и полезных инструментов операторы не пользуются. Причины могут быть разные: забыли, не научили, привыкли по-другому, научили да не так, и так далее.

Вот напоминалка, что делать:

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

• Периодически подсматривайте (вот когда в поля пойдете, тогда и подсмотрите как раз), как этим богатством пользуются ваши операторы.

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

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

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

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

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

Так как вы по умолчанию для меня адекватны, то я, конечно, не пишу о том, что есть немало случаев, когда только приватная беседа и уместна, но тут вы и сами поймете, когда куда выносить сор.

Если что-то пошло не так и ваши показатели рискуют вот-вот пробить историческое дно, а вы в это время не спите по ночам и думаете, как бы спасти всех и вся, но никому ничего не говорите, потому что «тогда они подумают, что я не справляюсь и у меня все вышло из-под контроля», вы совершаете большую ошибку, о которой очень пожалеете (всегда мечтала это кому-нибудь сказать).

То же самое касается задач, которые не двигаются с мертвой точки, потому что злополучный мяч давно не на вашей стороне, но сторона не шевелится или вам не дают ресурсы, а может быть не работают привычные системы. Что бы ни случилось, отвечать за результат все равно придется вам и отговорки из категории «ну а что я, я вот Васе уже сто раз напомнил, а ему хоть бы хны, что я тут могу поделать!» перестают работать примерно тогда же, когда вы перемещаетесь с позиции исполнителя на позицию руководителя (и не важно, какого масштаба).

Вот простая шпаргалка по эскалациям и обнародованию проблем, которая спасет вас от панических атак и приступов отчаяния:

• Предупредите своих руководителей и руководителей смежных команд, которых это может задеть, о том, что есть проблема (степень нагнетания в предупреждении должна пропорционально расти, если это потенциальное падение очень важного показателя или срыв такого же по важности проекта).
  ⁣
• Убедитесь, что все, кто должен был, увидели/услышали это и в курсе всего происходящего.
  ⁣
• Опишите, какие последствия ожидают отдел, если проблема не будет устранена.
  ⁣
• Четко опишите, что вы уже сделали и к какому результату это привело.
  ⁣
• Напишите, чего вам не хватает для решения этой проблемы.
  ⁣
• Запросите помощь и продолжайте просить до тех пор, пока ее не получите, даже если в какой-то момент вам покажется, что это говорит о вас как о плохом руководителе (спойлер #2: нет, потому что плохим руководителем вы окажетесь тогда, когда будете молчать о проблеме, а потом вскроется, что уже две недели как она портит жизнь клиентам).
  ⁣
• Если помощь не приходит, финально обозначьте, что без пунктов А, Б, и В вы не сможете ничего сделать и ответственность за это придется в равной степени разделить всем причастным — продолжать борьбу отныне можно с предельно чистой совестью.

Хуже провала по неосмотрительности может быть только тот провал, что канул в Лету и о нем никто не узнал. Как только вы обретете силы смотреть своим ошибкам в лицо, жить станет проще, а новый опыт будет даваться менее болезненно.

Возьмите за правило анализировать то, что пошло не по плану и закончилось провалом. Начать ретро для любой ошибки можно с самого простого:

• Что конкретно привело к такому результату? Какие действия, факторы, решения, обстоятельства.

• Что можно было дополнительно сделать, чтобы минимизировать потери и урон?

• Что должно измениться, чтобы эта ошибка не повторилась?

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

Любите себя, оберегайте клиентов ❤️

Есть чем поделиться? Изумительно, вам сюда! Присылайте интересные кейсы с решениями и свои истории радушному фидбэк-боту в Телеграм: @ilovecustomers_bot