Здравствуйте, Ксения!
Благодарю Вас за столь быстрый ответ на мое сообщение!
Человек, работающий на конвейере (т.е. выполняющий типовое действие) по определению допустит меньше ошибок, чем человек, постоянно переключающийся с одной операции на другую.
Ваши опасения срывов на стыках между сотрудниками вполне понятны, но, к счастью НЕ оправданы. Почему?
Потому, что нужно опасаться НЕ стыков между сотрудниками, а стыков между функциями. Разделяя сотрудников функционально, стыки НЕ образуются, они лишь выявляются, становясь очевидными. Когда сотрудник выполняет множество разнородных функций, стыки также присутствуют, но они размыты и потому НЕ видны.
Совершенно согласна со всем вышеизложенным. Теперь давайте подробнее рассмотрим функции нашего «звонящего» менеджера и попробуем определить так ли уж они разнородны:
1. Непосредственно сам телефонный звонок – выход на целевого клиента (в нашем случае это лицо, принимающее решение по вопросам рекламы и маркетинга), построение разговора по речевому модулю;
2. Запись информации о результатах звонка в базу. Мы записываем всю информацию о компании, полученную при разговоре, и отдельно комментарии, прозвучавшие в разговоре касательно нашего вида рекламы. Также по результатам звонка «звонящий» менеджер назначает следующий контакт (звонок или встречу) и иногда задачу – например «подготовить необходимую информацию»;
3. При необходимости: отправка информации клиенту. Осуществляется иногда прямо в процессе звонка (если клиент готов сразу же принять факс) а в основном единоразово - в конце рабочего дня производится рассылка информации по E-mail;
Если я правильно понимаю, то функция «запись информации» у нас с Вами схожа, с той лишь разницей что Ваш менеджер ведет рукописные записи в журнале, а наш – сразу же вносит их в базу. В данном случае функция одна, а журнал и база выступают всего лишь инструментом для ее выполнения. Если же рассматривать ее на уровне операций, то здесь я особой разницы тоже не вижу: Вашему сотруднику необходимо переключаться для того, чтобы внести запись в журнал, нашему – для того, чтобы сделать запись в базу.
>> 2. Если звонящий сотрудник не работает с базой – он не имеет возможности в процессе звонка восстановить всю историю общения с клиентом, а такая необходимость у нас возникает регулярно – когда звонили, когда отправили информацию, какие именно документы отправляли, на какой адрес и пр. Разве что вся эта информация у Вас опять выносится в журнал…
Да, Вы совершенно правы. Для упрощения можно ввести условные обозначения. И оператору БД удобнее вносить, и менеджеру несложно восстановить всю историю общения с клиентом.
Условные обозначения и сокращения у нас вовсю используются при работе, но как только с их помощью воссоздать всю картину? А что делать, если история общения длится на протяжении нескольких месяцев? А если за этот период «звонящий» общался с несколькими сотрудниками компании или же отправлял разные документы? У нас каждый разговор начинается с краткого ознакомления с историей общения – это не занимает много времени: пока набирается телефонный номер достаточно просто пробежать глазами чтобы восстановить всю картину – и сразу же становится ясно на какой стадии идет общение и в каком русле следует вести разговор и т.д. Я не совсем представляю себе как это все возможно вынести в журнал даже с использованием условных обозначений…
>> 3. Не совсем понятно, каким образом назначаются вторичные контакты («дожим») и встречи ходящим менеджерам.
У менеджера есть стандарт на соблюдение определенной периодичности звонков (например, вторичный контакт должен состояться не позже чем через N дней после первичного). Этот срок также вносится в БД, а по факту наступления дня “Х” в БД автоматически формируется отчет “ контакты/встречи на ….(дата)”.
Хм… Стандарт на периодичность звонков? А как в таком случае обрабатываются ситуации, когда срок вторичного контакта устанавливает сам целевой клиент?
У нас в речевой модуль добавлена конструкция «Могу я Вам перезвонить? Когда это будет удобно?» - таким образом, клиент САМ соглашается на повторный звонок и оговаривает период. Зато следующий контакт начинается с очень краткой истории общения и конструкции «Мы с Вами договаривались о…», что существенно увеличило результативность вторичных контактов.
А ходящие менеджеры у Вас работают с базой?
А в чем Вы видите разницу между звонящим и ходящим менеджером в данном случае?
В том, что ходящий менеджер получает компанию уже с историей. В данном случае основная функция базы – качественно передать информацию о компании «ходящему», чтобы он смог должным образом подготовиться к встрече.
Кроме того, в большинстве своем на первой встрече цикл продажи не заканчивается, и у «ходящего» начинается уже своя история работы с клиентом. А это и звонки, и встречи, и задачи – их же нужно назначать, делегировать и следить за своевременным исполнением.
>> Каким образом в таком случае решается проблема дублирования телефонных номеров?
Ксения, благодарю Вас за ссылку – я уже читала это обсуждение. Еще раз перечитав я не нашла там ответа на вопрос о дублировании телефонных номеров.
>> До начала работы с общей базой данных у нас регулярно возникали ситуации "А вы нам уже звонили".
Да, Вы правы. Такие ситуации имеют место быть. Но здесь нет ничего страшного. Ведь Клиенты и сами часто понимают, что у них а) холдинг, куда входит несколько юр. лиц, б) юр. название компании одно, а рекламируются они под другим.
Одни клиенты понимают, у других это вызывает негативные эмоции… Кроме того, я не вижу ничего хорошего в том, что звонящий менеджер делает повторные звонки тем более, что этого можно легко избежать.
>> более того: бывало даже "А мы с вами уже работаем" :)
Здесь, конечно, ситуация немножко иная. Нужно “прошерстить” свою БД. Но опять же не вижу здесь особой проблемы.
Все верно: МЫ проблему дублирования телефонных номеров решили методом предварительной проверки на наличие номера в базе. Но у нас звонящий менеджер работает с базой, а у вас – нет.
Эти мои вопросы возникли в связи с тем, что Получает информацию как в электронном, так и в бумажном виде. То есть, "до звонка" структурирование информации производится минимально. [Редакция]
>> Мы эту проблему решили следующим образом: перед тем как сделать звонок, менеджер проверяет телефонный номер на наличие его в базе данных.
Можно проверять Клиента а) в БД по нескольким критериям (и тел., и ФИО), б) (если есть возможность) в Internet.
Мм-м… Можно. А зачем? Для решения проблемы дублирования телефонных номеров достаточно произвести поиск в базе только по номеру. Или Вы это предлагаете в связи с какой-то другой задачей?
>> Кроме того, мы храним в базе и пустые контакты – дабы в следующий раз по ним не звонить, или же звонить осознанно.
Не вижу противоречия. Мы тоже так делаем.
Это была цитата из моего ответа на реплику Редакции: А если заранее обрабатывать все источники, а потом звонить - то это приведет к лишней работе (обработаются и пустые контакты, которые не попадут в базу).
Во-первых, определитесь, он действительно НЕ успевает ИЛИ это лишь его эмоциональные высказывания. Пусть через бумагу пропишет почему НЕ успевает. Проверьте, возможно, он НЕ всегда ходит только по Клиентам, возможно, он у одного Клиента проводит от часа до двух, возможно, что-то еще.
Он действительно НЕ успевает. Я об этом могу судить лично, а не только по его высказываниям.
Все дело в том, что удачная встреча (с заказом) тянет за собой серию контактов (звонков, e-mai’ов, встреч) и задач (подготовить коммерческое предложение, рассчитать медиа-план, записать ролик и пр.). И если задачи еще как-то можно переадресовать, то контакты закреплены за ним – ведь не навязывать же клиенту с первой же встречи кучу сотрудников... Что бы Вы могли посоветовать в этом случае?
Подзадача 1: Хорошо, что встреч много, но из них много пустых (что НЕжелательно).
Определимся с терминами. Пустая встреча – это НЕ та, которая “НЕ выстрелила” сразу, т.е. Клиент ничего не заказал, но является потенциальным. Пустой встречей будем называть встречу с НЕцелевым Клиентом.
Такие встречи тоже могут возникнуть. Например, когда звонящему менеджеру ставится задание, во что бы то ни стало, договориться с Клиентом о встрече. Менеджер начинает просить и “уламывать” НЕцелевого Клиента встретиться “ну, просто так”.
Но ведь на этапе обзвона у менеджера не всегда есть возможность заранее определить нецелевого клиента, разве что тот сам в разговоре не объяснит почему он нецелевой. Прозвонка ведется по целевым сегментам, но часто случается, что приезжающий на встречу менеджер видит, что этот конкретный клиент - нецелевой. Тем не менее, я бы не сказала что это наша подзадача.
Подзадача 2: Из всех встреч достаточно много хороших.
Решение 2 подзадачи 2: Нельзя ли перевести очную презентацию Вашего товара/услуги в заочную форму (т.е. по телефону)?
На начальной стадии у нас именно так все и происходило, но оказалась, что наш рекламоноситель не понятен большинству клиентов и заочной презентации по телефону плюс информационных материалов недостаточно для получения заказа. Намного эффективнее оказался подход, при котором звонящий менеджер в нескольких словах описывает суть этого вида рекламы (если возникают вопросы - отвечает на них) и предлагает встречу с нашим менеджером, на которой клиент может более подробно узнать о рекламоносителе, его особенностях и примерах сотрудничества.
Решение 3 подзадачи 3: Составьте типовые маршруты движения Ваших “ходоков”. Можно предварительно разбить город по районам.
Что в данном случае означает понятие «типовые маршруты»?
Мы уже ставили задачу оптимизации маршрутов ходящего менеджера, т.к. зачастую бывает, что в течение дня ему приходится ездить в противоположные районы города. Сейчас у нас стандартный промежуток между встречами 2 часа – чтобы оставалось время на дорогу, хотелось бы уменьшить его за счет зонирования, т.е. назначения встреч в определенном районе города. Пока на примете есть три варианта решения этой задачи:
1. «Повесить» эту функцию на звонящего менеджера, чтобы при получении согласия на встречу, он узнавал адрес клиента и вилку времени, брал тайм-аут для согласования расписания «ходока» а потом перезванивал клиенту и уже определенно назначал встречу;
2. Озадачить этим «ходока». При этом «звонящий» должен узнать адрес клиента, а согласовывать время будет уже «ходок»;
3. Программный. Было бы идеально, если бы при внесении адреса (улицы) клиента в базу программа бы выдавала расписание «ходока» в тот день, когда у него уже назначена встреча в этом районе. В этом случае звонящий менеджер мог бы предложить встречу согласно этому расписанию «ходока».
У первых двух вариантов есть общий недостаток – клиенту далеко не всегда нравятся подобные длительные согласования, и мы используем их исключительно по мере возможности, когда звонящий менеджер по разговору чувствует, что это будет уместно.
Третий вариант требует временных и материальных вложений для разработки, плюс я пока не совсем уверена в том, что звонящий менеджер сможет быстро осуществлять эту проверку без ущерба для качества звонка. Хотя некоторая информация – телефон, E-mail – сейчас свободно вносится в процессе разговора.
Какая из вышеперечисленных подзадач у Вас?
Скорее всего – Задача 2. Будем увеличивать число ходящих менеджеров. Планируем того "ходока", что есть сейчас, оставить для работы с VIP клиентами, а на текучку взять нового менеджера. Пока таким образом.
С уважением,
Катерина