Подвохи масштабирования
Когда перед менеджером стоит задача решить какую-то конкретную проблему, есть как минимум два (ну хорошо, больше, конечно, но эти важные) стандартных пути, которыми пойти. Каждый из них подходит для разных целей, но мы их часто путаем и получаем не то, на что рассчитывали.
Пример
Вы владеете службой такси и клиенты жалуются на то, что водители плохо знают город.
🍩 Решение #1: выдать каждому водителю по карте и ввести еженедельные тестирования по знанию города. Неуспешных штрафовать, успешных мотивировать — на ваш вкус, второе эффективнее.
🍩 Решение #2: снабдить каждую машину системой навигации.
И то, и другое решает задачу — клиент попадает из точки А в точку Б по оптимальному пути и доволен. Но есть нюанс.
При решении #1:
- Увеличиваются расходы отдела
- Эффект наступает не сразу, а в долгосрочной перспективе
- Эффект напрямую зависит от человеческого фактора и есть риск не добиться желаемого результата, потому что какие-то водители так и не научатся навигации (не могу их осуждать)
- Если водитель уходит, инвестиции сгорают и все начинается сначала
- Если машина одна, а водителей несколько, то затраты из первого пункта растут еще больше
Это плохо масштабируемая история, если смотреть на нее с точки зрения роста компании. При парке в 10 машин с водителями вы сможете результативно работать с каждым. Как только их станет в два, три, пять раз больше, расходы на обучение будут больше, а эффективность из-за большого потока и текучки — ниже.
Решение #2 при этом будет стоит немного дороже на первоначальном этапе, но:
- Риски в виде человеческого фактора минимальны, потому что водитель может не знать город, но все равно выполнять задачу, потому что работу по навигации за него делает софт
- Если вас штат растет в х5, 10, 20 раз, расходы и риски не растут — вы просто оснащаете новую машину уже купленным софтом
- Водители уходят, а софт и ныне там
- Вывод новых сотрудников ускоряется
Пример, более близкий к клиентскому сервису:
Не хватает мощностей на качественный ассессмент работы менеджеров с клиентскими заявками. У вас 1000 заявок в день и только 3 менеджера QA, которые не могут на 100% покрыть все аспекты оценки (например, они не «чувствуют» общий тон и снижают баллы за несущественные вещи, несмотря на то, что в целом заявка была обработана хорошо, клиент доволен и благодарит саппорт).
🍩 Решение #1:
Нанять новых ассессоров с нужной экспертизой или проводить обучение для текущих (дорого, плохо масштабируется, результат зависит от конкретных людей).
🍩 Решение #2:
Изменить чеклист, с которым работают менеджеры, убрав из него ненужные детали и добавив нужные метрики в обобщенном варианте + добавляем оценку самого клиента.
Например, мы убираем мелочи типа снижения оценки за необращение по имени, вводим новый пункт «выполнение бизнес-процессов» в процентах + закладываем сюда CSAT. Ну, а если вы шикуете, то еще и нейронки добываете для прослушки слов-паразитов, хезитации и прочего легко вычленяемого непотребства.
Так, качество мы оставляем на откуп клиентов (и это честно, потому что результат всей нашей работы это довольный клиент, а не ассессор), а вот контролем качества смотрим, как саппорт справляется с точки зрения бизнеса.
Картина получается более объективной, косты на содержание контроля качества не растут.