В предыдущей заметке была в общем описана проблематика такого описания, теперь сделаем для примера возможный вариант.
Предположим, что процесс у нас начинается с того, что маркетинг не просто подкинул лида, а даже уже предварительно договорился с ним о контакте. Предположим, что это звонок — не важно, по телефону, скайпу, другому мессенджеру или с использованием специализированного конференц-сервиса.
Т.е. стартовое событие — есть договоренность о контакте.
Следующим действием можно сразу сделать "позвонить клиенту", но можно и вначале "получить дополнительную информацию о клиенте". Почему это может быть нужно? Во-первых, хороший продавец все равно это сделает, так что вопрос не в том, делать или нет. Во-вторых, если мы вводим действие в описание процесса, то получаем возможность как-то его зафиксировать в системе. Например, продавец должен добавить ссылку на сайт клиента или на другие ресурсы, может при желании сделать предварительные примечания по клиенту, если это поможет в работе (а это полезная вещь, например, выписать обороты клиента, если это доступно, количество сотрудников, вид деятельности, характерные события и т.п. — это может здорово помочь при общении с клиентом).
Дальше уже можно действие "позвонить клиенту". Если делать это прямо из системы (CRM), то оно будет фиксироваться автоматически.
Далее следующим действием может быть, например, "сделать протокол контакта". Т.е. как бы короткое описание результатов, ключевых моментов, хода контакта и т.п. Делать это или нет — дело хозяйское, потребность в этом вырастает обычно с увеличением уровня сделок. Т.е. это на усмотрение менеджера.
Далее, если не успешно, то желательно оставить таки пометку (если не делается протокол) и запланировать следующее действие — или "поставить крест" на клиенте. Скажем, если произошла явная ошибка и компания никогда не станет клиентом, то лучше сразу это зафиксировать, с обоснованием и не планировать больше никаких действий (но оставить запись в базе, чтобы не повторять попыток в следующий раз).
Если контакт не удался, то можно перепланировать контакт. Если контакт состоялся, но сделки нет и перспективы не понятны, то запланировать какое-то следующее действие — или еще один созвон (если контакт согласен), или просто т.н. follow up, отправку потенциально полезной информации, к примеру, через какое-то время. В общем, это вопрос выбора маркетинговой тактики, но суть в том, что это можно и полезно запланировать, чтобы не полагаться на память продавцов, которые бывают склонны бросать неудачные варианты.
Далее может быть непредсказуемое количество контактов, от имейлов и созвонов до онлайн-презентаций и очных встреч, — обычно их вложить в какой-то жесткий алгоритм не представляется возможным. Да и незачем. Проще описать один цикл, затем отслеживать как действия продавцов в рамках этого цикла, так и количество клиентов в том или ином статусе.
Итого, получается примерно следующее:
Естественно, напоминаю, это всего лишь "костяк", это не может быть отражением реального хода дел — там ветвлений может быть гораздо больше. Их просто нет смысл все описывать, в этом прежде всего дело.
Само описание можно сделать как попроще, если нет желания фиксировать все эти моменты, так и более детально, если есть интерес к тому, чтобы описать еще что-то (например, возможные скрипты или маркетинговые действия).
В данном случае нам важно понять суть и принцип. К диаграмме можно сделать более подробные описания, по каждому пункту (в основном интересуют действия, конечно).
Для справки: мною использовалась BPMN (Business Process Model and Notation), уже ставшая де факто стандартом описания процессов.
Предположим, что документы готовит более подкованный в профильном смысле специалист, тогда (просто добавим для понимания) описание будет выглядеть так:
Еще немного усложним, добавив деталь по неудаче:
Какие можно взять показатели по данному процессу:
- сколько контактов,
- сколько контактов "с продолжением",
- сколько неудач,
- сколько сделок,
- сколько горячих лидов,
- и т.д.
Чем больше детализация процесса — тем больше можно "снимать" показателей. Главное, чтобы это было нужно и не усложняло работу продавцам.
Нюанс: мы тут никак не отмечали возможные скрипты, которые, например, могут уведомлять других сотрудников (хороший вопрос, а надо ли это, — ведь они при желании могут просто посмотреть отчетность, надо учитывать реальную потребность), отправлять автоматические ответы, формировать стандартные документы, отчеты и т.п.
Также был взят отдельно процесс продажи, который как бы продолжение процесса генерации лидов, — а это тоже интересный момент. Тут мы это не рассматривали, ограничиваясь просто рассмотрением самого принципа описания процессов, чтобы понимать, что может получиться в итоге.
Предположим, что процесс у нас начинается с того, что маркетинг не просто подкинул лида, а даже уже предварительно договорился с ним о контакте. Предположим, что это звонок — не важно, по телефону, скайпу, другому мессенджеру или с использованием специализированного конференц-сервиса.
Т.е. стартовое событие — есть договоренность о контакте.
Следующим действием можно сразу сделать "позвонить клиенту", но можно и вначале "получить дополнительную информацию о клиенте". Почему это может быть нужно? Во-первых, хороший продавец все равно это сделает, так что вопрос не в том, делать или нет. Во-вторых, если мы вводим действие в описание процесса, то получаем возможность как-то его зафиксировать в системе. Например, продавец должен добавить ссылку на сайт клиента или на другие ресурсы, может при желании сделать предварительные примечания по клиенту, если это поможет в работе (а это полезная вещь, например, выписать обороты клиента, если это доступно, количество сотрудников, вид деятельности, характерные события и т.п. — это может здорово помочь при общении с клиентом).
Дальше уже можно действие "позвонить клиенту". Если делать это прямо из системы (CRM), то оно будет фиксироваться автоматически.
Далее следующим действием может быть, например, "сделать протокол контакта". Т.е. как бы короткое описание результатов, ключевых моментов, хода контакта и т.п. Делать это или нет — дело хозяйское, потребность в этом вырастает обычно с увеличением уровня сделок. Т.е. это на усмотрение менеджера.
Далее, если не успешно, то желательно оставить таки пометку (если не делается протокол) и запланировать следующее действие — или "поставить крест" на клиенте. Скажем, если произошла явная ошибка и компания никогда не станет клиентом, то лучше сразу это зафиксировать, с обоснованием и не планировать больше никаких действий (но оставить запись в базе, чтобы не повторять попыток в следующий раз).
Если контакт не удался, то можно перепланировать контакт. Если контакт состоялся, но сделки нет и перспективы не понятны, то запланировать какое-то следующее действие — или еще один созвон (если контакт согласен), или просто т.н. follow up, отправку потенциально полезной информации, к примеру, через какое-то время. В общем, это вопрос выбора маркетинговой тактики, но суть в том, что это можно и полезно запланировать, чтобы не полагаться на память продавцов, которые бывают склонны бросать неудачные варианты.
Далее может быть непредсказуемое количество контактов, от имейлов и созвонов до онлайн-презентаций и очных встреч, — обычно их вложить в какой-то жесткий алгоритм не представляется возможным. Да и незачем. Проще описать один цикл, затем отслеживать как действия продавцов в рамках этого цикла, так и количество клиентов в том или ином статусе.
Итого, получается примерно следующее:
Само описание можно сделать как попроще, если нет желания фиксировать все эти моменты, так и более детально, если есть интерес к тому, чтобы описать еще что-то (например, возможные скрипты или маркетинговые действия).
В данном случае нам важно понять суть и принцип. К диаграмме можно сделать более подробные описания, по каждому пункту (в основном интересуют действия, конечно).
Для справки: мною использовалась BPMN (Business Process Model and Notation), уже ставшая де факто стандартом описания процессов.
Предположим, что документы готовит более подкованный в профильном смысле специалист, тогда (просто добавим для понимания) описание будет выглядеть так:
- сколько контактов,
- сколько контактов "с продолжением",
- сколько неудач,
- сколько сделок,
- сколько горячих лидов,
- и т.д.
Чем больше детализация процесса — тем больше можно "снимать" показателей. Главное, чтобы это было нужно и не усложняло работу продавцам.
Нюанс: мы тут никак не отмечали возможные скрипты, которые, например, могут уведомлять других сотрудников (хороший вопрос, а надо ли это, — ведь они при желании могут просто посмотреть отчетность, надо учитывать реальную потребность), отправлять автоматические ответы, формировать стандартные документы, отчеты и т.п.
Также был взят отдельно процесс продажи, который как бы продолжение процесса генерации лидов, — а это тоже интересный момент. Тут мы это не рассматривали, ограничиваясь просто рассмотрением самого принципа описания процессов, чтобы понимать, что может получиться в итоге.
No comments:
Post a Comment