Вы уже сталкивались с проблемами при внедрении телефонных скриптов?
Я сталкивался неоднократно.
Какие именно и как их преодолеть, расскажу в этой статье и в видео.
Проблема 1: Скорость навигации.
Раньше мы проектировали скрипты сначала в MS Word (в блок-схемах), потом в XMind (в древовидных интеллект картах). Использовать такой скрипт в работе практически нереально. Потому что, даже если напечатать скрипт на бумаге, менеджеры не могут быстро находить все возможные варианты ответов, путаются и допускают ошибки.
Скрипт есть, скрипт хорош, но без многочисленных тренировок правильно его использовать не получается.
Решение простое: нужно проектировать скрипты так, чтобы в каждый момент времени менеджер видел только то, что нужно сказать клиенту и кнопки или ссылки с возможными вариантами ответа клиента.
Если отказаться от блочной схемы, то в MS Word и в HTML такое сделать вполне возможно, хоть и неудобно. Это первая причина, по которой мы решили сделать Скрипт Дизайнер.
Проблема 2: Скрипты нужно слушать.
Даже отличные скрипты нужно слушать. У меня было много случаев, когда менеджеры неверно выбирали варианты ответов, а иногда вообще игнорировали скрипт.
Система записи телефонных переговоров тоже не особо помогает. Признаюсь честно, слушать - долго, дорого и откровенно лень. Основное время уходит на выделение именно тех звонков, которые нужно слушать и еще столько же - на прослушивание гудков и “прохождение секретаря”.
В редких случаях выделяются отдельные “слухари”, обычно же система записи стоит и не используется. У руководителя практически никогда не находится времени на прослушку.
Это вторая причина, по которой мы решили сделать Скрипт Дизайнер. Ведь если менеджер идет по скрипту в специализированной программе, то программа всегда знает, сколько реплик было в разговоре и на каком узле завершился разговор.
Таким образом система записи голоса становится вообще не нужной. Руководитель в считанные секунды может получить отчет по работе со скриптом, увидеть и устранить узкие места, где ломается и плохо отрабатывается скрипт.
Проблема 3: Скрипты нужно дорабатывать быстро.
Мой коллега и друг, Дмитрий Ткаченко, в своей замечательной книге “Скрипты продаж” пишет, что ни один супер-пупер гуру-эксперт не может создать скрипт, который заработает с первого раза, даже он сам.
Именно поэтому менеджеры часто говорят: “Скрипты не работают”. Да, в этом они правы, на 100% скрипты не работают. Но практически любой скрипт можно быстро довести до 95-98% готовности.
Главное, дорабатывать скрипт быстро, сразу же “на лету”, во время внедрения и обкатки. Иначе, менеджеры будут упираться в неработающие сценарии, чувствовать себя в неловком положении, не зная, как вырулить из сложной ситуации (подсказки-то в скрипте нет!!!) и, в конечном итоге, саботировать работу по скрипту.
Даже через месяц может всплыть нечто, требующее доработки скрипта. И тут возникает новая проблема: разобраться в своем скрипте через 7 дней после перерыва не может даже сам создатель скрипта!!!
Забывается логика скрипта, путаются связи и переходы, возникают дубли. Иногда даже нет места, чтобы добавить несколько новых фраз. Доработка скриптов становится адом.
Это третья причина, почему мы решили сделать удобный конструктор скриптов Скрипт Дизайнер. Для облегчения жизни проектировщикам используются 3 тактики:
А) компоновка речевого модуля менеджера в один узел с различными вариантами ответа клиента (экономит место на экране в 5-10 раз)
Б) использование методики “лесенка” для проектирования скриптов
В) поиск по узлам и постоянная работа над улучшением эргономики редактора скриптов
Приглашаю обсудить пункты Б и В в нашей группе на FaceBook:
www.facebook.com/groups/ScriptDesigner/permalink/926029274191786/
www.facebook.com/groups/ScriptDesigner/permalink/839386822856032/
И, если Вы хотите узнать больше про внедрение скриптов, посмотрите, пожалуйста, видео, в котором я более подробно рассказываю про сложности внедрения скриптов
с живыми примерами и случаями из жизни:
