Cборная солянка. Часть 2

По инструментам. По инструментам мы на самом деле используем не такие популярные инструменты, это 3CX и ливтех (?). На самом деле на рынке есть лучше как бы варианты. Но для нас, что важно было в самом начале, мы взяли 3СХ, потому что можно было брать трубку где угодно. Это было актуально 4 года назад, но не сейчас. Самое важное у нас - самописный CRM, когда мы на самом деле делали сервис, но по крайней мере не знали про юздеск. И поэтому мы писали свою CRM ку. Здесь есть много споров как лучше поступить. Но у нас она своя. Но что самое важное, у нас выгружается своя аналитика полностью из своей CRMки. Она не выгружается как какая-то история готовая, мы ее потом докручиваем, сами анализируем, пока что руками, но тем не менее. Самое главное, что цифры вылетают. На чем вообще у нас строится аналитика. Мы на самом деле не очень-то смотрим на nps, потому что она какая-то пространная для нас метрика. NPS это метрика продукта на самом деле, но не метрика уровня сервиса. Да, может быть, метрикой уровня сервиса, это например, CSI+NPS, но никак не просто NPS. Поэтому мы поступили следующий образом, мы анчали мерить вообще все метрики по-разному в разных каналах коммуникации. То есть, например. Я говорю, что у нам НПС такой-то. Но на самом деле это ни о чем не говорит. Это может лишь означать, что в 90% обращений на 1 линии все хорошо. Но когда речь доходит до тех.поддержки там начинается какой-то кошмар. И вы никогда не узнаете об этом, если будете смотреть напросто один какой-то общий НПС. На наш взгляд должны быть разные метрики в разных каналах коммуникации. То есть мы знаем, например, как отвечают наши врачи в текстах. Как например отвечает наша тех.поддержка на телефоне. Как отвечает оператор в сообщениях в вотсапе. И все это в разных каналах коммуникации. И мы делим метрики по трем категориям.
По объему. Сколько входящих сообщений, сколько исходящих. Просто чтоб мы понимали, каков масштаб бедствия.
Деньги. Помимо денег, которыми просто меряется сколько стоит обслуживать этот канал коммуникации, эту линию. Мы еще считаем всякие компенсации, все инструменты по каждому каналу коммуникации. То есть какой объем на каждом из каналов, сколько он стоит. Или сколько мы с него зарабатываем.
Уровень качества. Внутри уровня качества у нас два подразделения. Это то, которое считает просто базовые показатели типа SLA и так далее. Просто базовые истории. И качество это уже CSR, это уже после каждого обращения, чтоб мы понимали как у нас конкретный Иванов отвечает в тексте. И что самое важное.
У нас все сходится в свой собственный контроль качества, который вырос у нас внутри органически. Так получилось, что нам просто надо было посадить на контроль качества и мы выбрали студентку 3 курса из стоматологического универа и она неплохо справлялась. А потом на второй месяц оказалось, что она еще увлекается питоном. И это оказалось нам вообще на руку, потому что она взяла и автоматизировала просто половину работу. Она автоматизировали так, что мы смогли находить все типичные ошибки, мы смогли быстро достаточно считать SLA просто автоматом. Мы смогли нормально подсчитывать утилизацию и плюс она помогла нам сделать прогнозную модель нагрузки. Поскольку мы продает В2В и продаем в большие компании, нам например в один день может подключиться там 7000 человек по всей стране совершенно разным контингентом. Есть один плюс, мы знаем об этом заранее, но не больше, чем за неделю. И поэтому мы сделали такую моделью, которая помогает нам именно посчитать нам что будет, если к нам резко добавиться столько-то человек. Именно поэтому мы держим утилизацию не в нормальных коридорах 85-90, а на уровне 75, просто чтобы иметь хоть какой-то запас. Да, у нас достаточно много работает врачей и это на самом деле для нас сложность. Если у вас работают какие-то специалисты, которые заточены на что-то именно спецы, то это конечно сложно. Потому что нужно понимать, что хедхантер в этом плане хорош, но не так эффективен как хотелось. Поэтому мы используем массу каналов, мы уже попробовали. Мы участвуем на ярмарке вакансий, на разных мероприятиях, мы врываемся во всякие группы вконтакте, например, студентов, которые закончили в 18-17 году и так далее. Плюс мы ведем всякую диджиталку. То есть здесь прям полноценные продажи со своими метриками, со своим маркетингом, который позволяет нормально хайрить и иметь достаточно постоянные поток. Ценности корпоративные у нас это открытость, забота, развитие. Вам это будет не так интересно. Но внутри у нас это более конкретно описано. Но что самое главное. нам кажется, что скриптами невозможно закрыть все подряд. Тем более в медицине и в страховании. У вас куча кейсов, которые выпадают за стандартный флоу. мы решили поступить проще, мы взяли и ввели просто 3 ценности. Развитие это касается врачей и это просто для врача мастхэв. А вот открытость и забота - это то, что касается сервиса. И это нам очень сильно помогло, когда мы это сделали. Например, у нас был случай, когда у нас один из пациентов с нашей российской страховкой застрял на бали без связи и только с чатом. И причем у него было подозрение на малярию, а малярия это достаточно суровое заболевание. И мы его оттуда вытаскивали из чатов, потом он прилетел в Россию и мы ему организовали инфекционную больницу и так далее. Дело в том, что я в этот момент был в отпуске и это делал просто врач особо ни с кем не советуясь. Он просто воспользовался ценностями, которые разделял и сделал все правильно. Не по скрипту, но просто понимая как нужно сделать. Поэтому на наш взгляд ценности и вижн - то что прям нужно. Если на самом деле просто описать как мы действовали по этапам. Вообще, нам кажется, что в бизнесе есть всего 4 важные функции: люли, деньги, процессы, айти. Когда мы стоили сервис, первое, что мы сделали - починили людей. То есть мы сделали достаточно регламентированный хайринг с тестированиями, с нормальные процессами отбора и так далее. Второе - мы инвестировали в онбординг и обучение. Мы просто на вордпрессе собрали бесплатный портал, который отдали на ведение в поддержку, они там сами дальше собирают сайт как конструктор. Но что самое главное - мы туда можем быстро класть все новости, и нововведения в сервисе, и то какие там графики работы и все что угодно. Бонусы, все что есть - все на портале. Полноценная внутренняя соцсеть без разработки вообще. Что еще мы сделали, это сбор аналитики. У нас все отталкивается от аналитики. Запустили работу с претензиями. В любом нормальном сервисе есть претензии и это факт. У нас есть претензии не просто которые отбивают клиента и помогают быстро решить запрос. У нас претензии строятся таким образом, что все претензии строятся как "тип, тема, подтема". И все это превращается в такое в дерево. Например, мы знаем, что столько-то пациентов жалуются на врачей, которые нагрубили. Или вот столько-то пациентов жалуются на нашего оператора, который не сработал быстро. Это прям все потом превращается в дерево, по которому мы потом анализируем где у нас больше всего горит, где больше всего проблем. Причем анализирует больше всего это как раз-таки продукт, который достаточно быстро понимает куда нужно бросить больше внимания. И потом они уже сами приходят с сервиса ну-ка расскажите подробнее а че вот тут происходит. Но на самом деле, мне кажется, хороший сервис - это не то, чтобы реальность совпадало с ожиданиями или превалировала. Мне кажется, хороший сервис это про людей…

То же с продавцом. С продавцом мы взяли формат бизнес-игры. Сделали также на руководителя и на продакта 12 команда, 5 заданий, 6 - инициатива от каждой команды. Пошли по пути самого мерча. То есть если с покупателями все понятно, все мы покупатели. То как работает продавец у нас в основном ну мало кто знает. Только те, кто участвует непосредственно в работе с мерчантами знает как вообще выглядит кабинет и какой у них путь. соответственно захотелось в эту историю погрузить всех и мы сделали прям по пути мерчанта. Создали тесовый магазин, загрузили фиды и дальше все должны были уже определенное задание. Склад свой настраивать, загружать товары, загружать разными способами. И соответственно комплектовать заказ и отдавать заказ курьеру. Соответственно что здесь нужно учесть при запуске такой истории - то же самое поддержка руководства компании. Ну это маст. Дальше протестировать игру несколько раз, чтобы не было каких-то багов и каких-то технических моментов. У нас пару раз было. Посчитать время прохождения каждого задания, следить за таймингом, учесть технические особенности системы. Если вдруг там что-то что нужно знать. На встрече должен присутствовать эксперт. желательно, чтобы игру проходиои сотрудники, не знающие процессов. У нас проходили все, но все-таки ребята, которые знали процесс, они в основном наблюдали. Были конечно, но в основном наблюдали, так интереснее. Продумать заранее кто и в какие сроки будут реализовывать инициативы. Здесь мы уже получили с наших предыдущих опыт, поэтому заранее договорились с продактами и у нас уже был выделен ресурс и в принципе даже уже во время игры у нас инициативы загружались в продакт и он уже начинал с ними работать. Обратная связь была с сразу и соответственно это важно. В этот раз мы учли наши ошибки, инфополе у нас было. Было общее собрание, мы наградили победителей нашей бизнес-игры, рассказали про игру и тем самым вовлекли коллег тоже в эту историю. Отдельно мы проводили исследование, опрос внутри сотрудников. Все 100% ответивших у нас захотели еще участвовать в таких экспериментов. очень понравилась эта история с точки зрения понимания и видения коллег. Но и соответственно понимания того как это вообще работает. Даже те люди, которые не участвуют в процессах. По результатам 7,6 новых инициатив у нас разработаны и приоритезированы бэклог. По продавцу в 5 раз сокращены сроки обращений, изменены маршруты SLA, и в пилоте запуск горячей линий пока еще у нас считается кейс, но я надеюсь в ближайшее время запустим. Это про то, что у нас нет голоса для продавцов, у нас только тикетная система. Соответственно мы хотим, чтобы была горячая линия срощенная для мерчантов. Потребность такая есть.

Основная часть вообще обработки инцидентов вообще во всей нашей команде, не только в саппорте, во всем облаке, это таймлайны. Во-первых, клиент просит эти таймлайны присылать, во-вторых нам самим эти таймлайны составлять полезно. Таймлайн это порядок событий что когда произошло. Вот мы заметили инцидент, вот поступила первая жалоба, вот мы сообщили дежурному сервиса, еще через 2 минуты он взял это в работу, какие показатели мониторингов были в какой момент. Прям вот по минутам. Мы не всегда это делаем самостоятельно как саппорт, нам часто помогают индициент-менеджеры. Это отдельный человек в команде, который дежурит, и если на случай что-то сломалось, он вступает в свои обязанности и начинает менеджерить этот процесс. Находить ответственных, убеждаться, что поддержка сделала коммуникацию пользователю, убеждаться, что разработчики чинят, что они должны чинить, убедиться, что бизнес команда в курсе что происходит. Такой подробный таймлайн при крупных иницентах мы даже публикуем в блоге и присылаем клиентам, которые просят. В кратком виде присылаем всем обязательно. "мы вот сегодня в 16:00 заметили, в 16:05 починили, у вас в это время могло что-то лагать". Этот же таймлайн нам помогает после того, как все кончилось, понять мы вообще хорошо отработали или нет. Как только мы выяснили подробности, мы обязательно напишем пользователям еще раз. Первые два письма могут быть в одном письме, если мы сразу поняли что не так. Если мы не сразу поняли, прошел час, лучше еще раз написать и сказать "ребята, мы нашли че случилось, проблема вот в этом сервисе, в этой конкретной настройке, мы уже чиним, починим через час".
Дальше мы начинаем проводить постмортем. Постмортем - это анализ того, что произошло. Анализ того, что мы сделали хорошего, что мы сделали не очень, не очень быстро, не очень качественно пока обрабатывали инцидент, сколько это заняло времени обязательно, потому что в том самом инциденте большом, мы после него как раз много сделали выводов. И нам явно стало понятно где мы тормозим. Например, мы очень долго собирали списки пользователей, которые пострадали, чтобы с ними связаться. Не сразу было понятно что происходит. Мы очень долго пытались достучаться до нашей команды пиара, а нам вообще можно это говорить, или нельзя. Как нам написать так, чтобы нам это еще сверху не прилетело. В каких-то местах это помогает команде разработки почему они где-то со своей стороны затормозили, долго катили релиз или что-то еще. Обязательно на постмортеме мы обсуждаем что делать в будущем чтоб такого не происходило. Что делать, чтобы заметить проблему раньше. Возможно какие-то дополнительные мониторинги настроить, дополнительные лампочки, которые будут загораться тогда, когда в этом месте конкретно что-то идет не так. Возможно что-то, что может нам помочь очистить конкретно это место, чтобы в нем вообще не происходило проблем. Не просто мы их замечали раньше, их вообще не было. Обсуждаем мы сначала всей командой, потом разработчики между собой обсуждают какие-то нюансы, саппорт внутри себя обсуждаем. Как быстро составлять текст, может быть где-то заранее можно перевод каких-то шаблонов кусков сделать, какие-то приветствия, потому что мы пишем на двух языка: на русском и английском сразу. Также мы обсуждаем как быстро мы смогли скоммуницировать с теми, кто прям сам написал, создали тике, как быстро мы им написали, потому что они самые активные, они больше всего ждут ответа, они будут пинать до последнего пока они не получат всю подробную информацию. Постмортем это полезно.
Давайте я еще раз пройду по всем пунктам, которые проговорила. Их немного, но они все прям полезные использовать их в работе и попробовать их применить у себя. Я не заявляю, что это какая-то истина в первую инстанции. Ну вот то, что работает у нас, оно работает.
Самый важный пункт - перестать нервничать. Это звучит наверное сложнее, чем сделать. Ну просто возьми и перестань злиться ну в чем проблема действительно. Не совсем это так работает, но поверьте это того стоит. Потому что чем холоднее голова, тем быстрее можно прокоммуницировать. Тем лучше мы объясним пользователям что не так, что происходит с их работой, с их усилиями которые они вложили в какой-то проект, которые они у нас разместили, это важно. Потому что они заплатили деньги инженеру, инженер сел и потратил неделю своей работы, чтобы развернуть что-то в облаке, а оно взяло и упало.
Обязательно оценить насколько оно плохо, где сломалось, сколько людей пострадали, как сильно они пострадали, нужна ли компенсация, когда это все починится, как долго оно будет лежать и прочее. Обязательно коммуницируем с пользователями по всем нашим шагам. Чем прозрачнее наши шаги как компании, тем им будет спокойнее и понятнее, что происходит с их ресурсами. ТО есть это обязательно написать, когда мы сами заметили "да, ребят, мы в курсе, ну да сломалось, жалко, вот сейчас сидим в поте лица и занимаемся". Это прям вот так. Написать когда мы понял что пошло не так конкретно с деталями "сломалось вот это, конкретная вещь сломалась, мы вот над ней прям щас работаем, вот такой-то релиз будет выкачен через час чтобы это починить". И когда все кончилось, все выдохнули, можно по желанию написать письмо с результатами, подробным таймлайном что происходило. И обязательно рассказать людям что вы сделали, чтобы такого больше не повторялось. Это люди любят. Это во-первых полезно. А во-вторых, это нужно, потому что потерять доверие клиента очень легко. Н уда, поломки случаются, но это не значит, что нужно посыпать голову пеплом, и всячески стрессовать. Чем подробнее вы объясните, тем лучше вас поймут. И люди понимают, что поломки случаются, они не совсем злые.
Подробности инцидента. Таймлайны составляем, четко прописываем каждый шаг. Похоже на бюрократию, но на деле это буквально пол секунды "я заметил первый тикет от юзера, записал себе, 15:03 где-нибудь в любой форме". Потом это будет довольно легко в конце на постмортеме соблать единый таймлайн и понять что когда происходило.
Постмортем. Проанализировать вместе со всеми, что произошло, где сломалось, что мы делали, как мы делали. Что сделали хорошо и быстро, что сделали плохо. тут медленно, ут ошиблись, тут приняли неправильное решение. Эти вещи нужно обязательно проговаривать. И чем конструктивнее будет критика, тем лучше. Эмоции тут тоже лишнии. Обычно если кричат на разработчиков, что они что-то сломалось, они начинают зажиматься и всячески защищаться. Виноват не человек, виновата ситуация, мы не виним людей за какие-то факапы, которые у нас случаются. Глупо перекладывать вину на человека. Тут скорее группа факторов, включая то, как устроена система, какая документация, какие у него инструменты есть, какая атмосфера была, что вот сегодня конкретно происходило.
Постмортем можно публиковать на сайте, людям это нравится. Мы вот эти пункты поняли не сразу, не сразу получилось нормально. Несколько раз мы тренировались в таких больничных условиях. Но сейчас это работает хорошо, потому что у саппорта есть четкий план, он спокойно сидит, "а ну факап, хорошо, щас будем работать" и быстро начинаем обрабатывать.

В какой-то момент мы поняли, что мы дошли до определенного предела экспертизы сотрудников и пора посмотреть по сторонам, какие есть еще варианты. Было 2 варианта: сделать свой собственный колл-центр или возможно поискать что-то еще дополнительно.
Почему нужны были вообще изменения. Потому что скайэнг растет в 3 раза каждый год. Клиентская база, мы открываем новые направления, новые предметы (помимо английского уже есть математика, мы обучаем взрослых, детей, корпоративных клиентов, клиентская база растет семимильными шагами). Мы не можем растить также штат поддержки. Плюс, мы поняли, что со временем трафик клиентов холодает и это нормально и удерживать клиентов становится все сложнее. И те усилия, что мы вкладываем в развитие команды, в мотивацию, в ачивки и все прочее - уже не работает. И соответственно, нам нужно что-то, что-то новое, что может нас взбодрить и сможет улучшить наши показатели. Такие как например, ретеншен, или интенсивность занятий, частота занятий. Какие у нас были варианты. Ну, все просто, можно было просто пойти аутсортиться, можно было что-то автоматизировать, или можно было совместить. Мы выбрали конечно же совместить. И сначала мы как стартап, мы думали ща вообще быстренько за месяц все запилим и побежим. Мы побежали. Даже за месяц. С момента выбора подрядчика, поставщика услуг, аутсорса до первого звонка у нас прошло 30 дней и я очень этим горжусь. Я думаю, что те, кто запускали аутсорс, знают о том, что это супер быстро. Это Включило в себя все: выбор площадки, обучение, тестирование, набор группы, настройка аналитики и запуск. Но в процессе мы поняли, что есть моменты, которые мы не учли. Нам казалось, что это все неважно и это все можно потом сделать. О них я чуть позже расскажу. Про автоматизацию было тоже самое. Мы подумали, ну окей, какой у нас самый процесс, который мы ходим автоматизировать, вот где у нас больше всего поддержки. В процессе обучения языку есть такой важный процесс подбора преподавателя. С точки зрения бэка, самой компании этот процесс происходит так, что в нем участвуют минимум 3 специалиста, 3 звена цепи. И это сопровождается кучей согласований и действий. И мы решили боже мой как просто автоматизировать. Давайте автоматизировать, чтобы человек сам выбирает себе преподавателя. Вот сейчас у нас 30% автоматизировано, с мая. И все мы это начали делать одновременно, а че ждать-то, мы же бежим впереди всех. Надо делать все, мы одновременно запускаем аутсорс, одновременно запускает автоматизацию и сидим ждем. Потому что это почти как а/б тест только без теста. Потому что запустили мы просто сразу все.
Что мы поняли в итоге. Мы поняли, что самое главное - процесс, который вы можете автоматизировать или улучшить, будь то аутсорс, будь то автоматизация какого-либо действия, должен делать человек, который с этим работает. Как сделали мы. Мы сказали окей, у нас есть специалист по подбору преподавателей, пожалуйста, опиши свой процесс. Он его описал, мы это отдали в разработку. Разработка посмотрела, поняла половину, сделала. В итоге что мы получили, ничего мы не получили. Потом мы подумали, ну что же не так. И сами пошли посмотреть на процесс, посмотрели, описали. Сравнили свое описание с описанием сотрудников, у нас не было ни одного повторяющегося пункта, отдали на разработку, разработка снова сделала. Что мы в итоге получили, опять не то. Потом мы позвали клиента и прокастдевили его. "Какой ты хочешь вообще, вот если бы ты сам себе выбирал преподавателя?", клиент набросал третий вариант. Но вариант клиента совмещает 2 варианта и хоть как-то был реалистичным. Отдали в разработку, разработка сделал и в итоге все это заняло у нас 6 месяцев. Поэтому описывать процесс должен тот, кто работает с ним каждый день, но не линейный сотрудник. Описание линейного сотрудника важно для понимания чего хочет сотрудник, работая с процессом. Описание, которое может сделать специально выделенный под это бизнес-аналитик, который знает структуру разработки, знает структуру процессов остальных. Он вам даст совершенно другой взгляд на это. И тогда вам не придется самим описывать процесс, клиента к этому привлекать. Кастдев конечно важен безусловно. Но бизнес-аналитики - супер крутые люди и они действительно классно делают свою работу.
Второй момент, аналитику нужно привлекать с самых первых ваших шагов. Причем это должен быть ваша аналитика, если у вас в отделе есть аналитик - привлекайте его. Как сделали мы при запуске аутсорса и в чем мы очень сильно нафакапили. Мы пришли и спросили ребята у вас есть аналитик, "да", о круто, все. Потом мы начали получать какие-то отчеты, ну ладно вроде норм. Потом когда мы через 3 месяца начали считать результаты, что да, у них есть статистика, они нас не обманули, да, она хорошая, только мы с нашей ее слинковать не можем. И мы потратили еще месяц на то, чтобы это сделать. И в итоге только спустя 4,5 месяца мы подвели итоги, вместо 3 месяцев. Пока разбирались в аналитике. Поэтому привлекайте аналитиков с первого дня. Это супер важно. Потому что аналитик знает ваши данные, погружается в данные партнера или нового процесса. Он может сделать сразу отчетность и указать на определенные недостатки процесса.
Третье - автоматизировать нужно только толстые низко висящие фрукты. Это тоже очень прикольная идея, потому что когда все начинают заниматься автоматизацией, они начинают заниматься автоматизацией просто всего. Нет. Мой вам совет, возьмите то что действительно частое и долгое. То есть те процессы, на которые тратится уйма времени и обязательно уйма людей, людских сил. И автоматизируйте их. Не надо пытаться автоматизировать все, вы не автоматизируете все нормально. Вы будете как волк в советской игре бегать туда сюда пытаться поймать баги, потому что они обязательно будут.
И самое главное, последнее, аутсор реально хорош в продажах. Здесь я хочу рассказать про тот кейс, который мы испробовали. У нас есть такой процесс как реактивация клиентов, которые перестали заниматься по какой-то причине. Мы взяли эту базу клиентов и полностью отдали на прозвон аутсорсу. Через 3 месяца, когда мы смотрели результаты, процесс реактивации у аутсорса был выше в несколько раз, че у своих собственных сотрудников, которых мы мотивировали, вдохновляли, вместе прослушивали звонки. Чтоб вы понимали, с аутсорсом мы вообще не работали практически. Ну то есть мы им отдали скрипт, чуть-чуть прослушали звонки, чуть-чуть направили, дали базу, сказали все вот звоните, будут вопросы - спросить на горячей линии. Да, аутсорс дороже, но в итоге они экономят. Выгода составила 50% с учетом того, что сотрудник аутсорса в 2,5 раза дороже внутреннего сотрудника. Его эффективность просто зашкаливает. И я это говорю не просто эффективно о том, что они базу быстро автодайлером перебирают. А о том, что они умеют реально круто продавать. Ищите своего аутсорс партнера, обязательно ездите на площадки, смотрите на команды, давайте тестовые задания. Аутсорс реально круто продает. И это мой не первый аутсорс и с каждым разом я все больше убеждаюсь. Вы можете сколь угодно мотивировать свою команду, но люди, которые сидят в компании внутри, они более расслабленнее, чем ребята на аутсорсе, это факт. Особенно удаленная команда. Удаленная команда всегда будет продавать хуже, чем собственный колл-центр и чем аутсорс. Это те грабли, на которые мы наступали полтора года, веря в то, что мы можем добиться супер продаж на реактивации на удаленной команде. Мы верили в мотивацию, во вдохновение, в то что можно вселить чувство прекрасного и высокого. Ну в общем нет. 10 человек - да. А когда у вас команда реактивации 140 человек, ну попробуйте, я бы этот кейс с удовольствием обсудила.

Примерно летом, мы с нашим департаментом маркетинга и с нашими кофайндерами и с очень классным агентством по креативу задумали новую рекламную кампанию. Может кто-то видел людей, которые смеются, что продавать машину стоит в карпрайз, а не стоять ждать 2 часа покупателя под дождем. Это рекламная компания была довольно дружелюбной, такой фрэндли, направленная на высмеивание всяких разных способов по продаже автомобиле не в карпрайз и она задавала тон настроения для нашего бренда. Когда мы вышли с этим креативов, готовились к выходу, мы подумали, что неплохо бы подготовить и наш персонал, мы сделали это заранее, но возникла мысль, что то, как наш персонал общается с клиентами, должно отражать нашу рекламную коммуникацию. И хотя она будет временная, будет неплохо как-то это пролонгировать на локации. Потому что когда наш клиент приезжает к нам и видит эту рекламу, он ожидает увидеть веселого менеджера, доброжелательно настроенного. И мы подумали, что будет круто это сделать. И пришла в голову мысль задавать клиенту вопрос, очень нестандартный. "насколько удалось менеджеру поднять вам настроение в ходе визита?". Вы когда-нибудь слышали такой вопрос от компании, в которой вы получали сервисную услугу? такого вопроса я не смогла найти, чтобы кто-то задавал.И по-моему в России такой вопрос не задавал никто. Мы стали спрашивать у клиентов насколько менеджеры были доброжелательны и смогли улучшить настроение клиента и стали получать ответы. И делаем так уже 3 месяца, это совсем новая история, поэтому я хочу рассказать о ее итогах. Потому что она не просто новая, а дала нам и очень интересные результаты. Когда мы внедряли этот вопрос, когда я его сформулировала и когда мы рассказывали о нем, я слышала очень много комментариев, о том, что это не нужно делать, потому что это странный вопрос, непонятно как он должен поднимать настроение, потому что в него входит много всяких незнакомых вещей, которые пугают. Что бы вы сказали, если бы ваш директор по клиентскому сервису пришел к вам и сказал "давайте зададим этот вопрос нашим клиентам". Клиентов 7-8-9 тысяч мы опросим точно. 9 тысяч получат такой странный вопрос. Что бы вы сказали? Мой ген директор сказал, да Женя давай спросим. И мы спросили. Мы оцениваем этот индекс как NPS для того, чтобы нам просто было удобно. Так как мы его сами придумали, мы и шкалу оценок сделаем как мы хотим. Мы видим здесь, что среднее значение индекса выше, чем значение NPS и если посмотреть по непродавшим клиентам, оно тоже высокое. Оно имеет стабильно высокое значение. И мы знаем, что многие клиенты говорят, что действительно менеджер смог поднял настроение. Это все здорово, но что же это дает. Мне кажется, что все хотят, чтобы был какой-то индекс, который можно увязать с товарооборотом, выручкой, с выкупами в нашем случае. Или с какими-то вещами, которые влияют на деньги, на прибыль компании. И мы провели анализ о том, насколько собственно говоря наш новый индекс позитивности или смайл индекс оказывает влияние на конверсию для нашей бизнес модели. Когда клиент получает не очень хорошую цену. Мы видим, что по одной оси представлена цена, в данном случае это либо хорошая цена для клиента, либо не очень хорошая. Мы измеряем цену относительно большого объема ожиданий по цене и того, что дает рынок на определенный автомобиль, для того чтобы было понятно как эта история рассчитывается. А по второй оси смайл индекс, который может быть высокий или низкий. Делим все наши встречи на 4 квадрата, и видим, что есть менеджеры которые попадают в категорию, когда цена высокая , NPS нормальный, смайл индекс плохой. В этом случае клиент с очень высокой вероятностью и так продаст автомобиль, потому что цена высокая. Это очевидно. Эту категорию менеджеров, мы понимаем, что с ними тоже надо работать, но пока на нее давайте не смотреть, их около 20% таких сотрудников. А самая интересная категория, где цена за автомобиль не очень удачная получилась, но при это и смайлиндекс тоже получился не очень. Соответственно, конверсия, CR тоже невысокая, 34%. А теперь давайте посмотрим на тот квадрат, который выше. Здесь та же самая цена, то есть не меняются условия по цене для клиента, но с ним работают менеджеры, которые имеют высокий смайл индекс. И это дает нам возможность обеспечить конверсию на 4% выше. Для нас это очень значимое увеличение и конверсия в таком размере это наш таргет, это то значение, которое позволяет нам развиваться и мы крайне рады, когда так получается. Таким образом, нам удалось открыть инструмент, который позволяет нам теперь управлять поведением менеджера и при всех прочих равных условиях при не изменении цены, на которую менеджер, очевидно, не влияет, обеспечивать конверсию для бизнеса выше чем та, которая происходит в стандартном режиме, когда менеджер не старается, не собирается работать с клиентом доброжелательно и улучшать ему настроение.
Я хочу дать вам послушать несколько звонков, в которых как раз есть ответ на вопрос смог ли менеджер в ходе визита.
Уточните, смог ли менеджер поднять вам настроение в ходе вашего визита?
Я вам хочу сказать, если бы не менеджер, который там, я бы сразу развернулся и не ехал бы
Дадада, парень был очень хороший, нам очень понравилось, мы в полном контакте с ним были
Да, ваще прям, ну хорошо пообщались, посидели, потрындели как надо
Да, если честно отчасти благодаря менеджерам такая высокая оценка, потому что они действительно оч хорошие были
Абсолютно точно, Максим и Илья оба прекрасные парни, работают профессионально, дружелюбно