Где и почему продавцы «не дожимают» клиентов и упускают сделки? Найти ответы помогает работа с CRM. Прописав в этой системе все этапы продаж, можно понять, на какой конкретно стадии сделка срывается. И устранить затем причины неудач. Как работает такой подход, в рамках проекта «Бери и делай» рассказывает Александр Мельнов, руководитель отдела маркетинга и продаж в компании «Эмонс Экспедиция».
— Наша компания занимается международными грузоперевозками.
Прежде чем начну, задам несколько вопросов:
- Кто из вас уже использует какую-либо CRM-систему?
- Кто уже выбрал CRM и планирует использовать в ближайшем будущем?
- А кто до сих пор не понимает, чем она может помочь продавать больше?
Если сравнивать, то компании, которые не используют CRM, все еще работают на паровом двигателе. Они, конечно, двигаются вперед, но медленно.
Бизнес-стиль: Показатели Статуса
А вот бизнесы, которые используют эту систему, работают на электрических, современных движках.
Топливо бизнеса — это лиды. То есть потенциальные клиенты, которых мы хотим заполучить и которые обращаются в вашу компанию.
Чтобы работать с клиентами эффективно, предлагаю разработать некие инструкции. И в этом поможет такой простой инструмент, как статусы в CRM-системе. Давайте разберемся, что это такое.
Что такое статус в CRM
В CRM статус — это этап, на котором сейчас находится общение с клиентом. Завоевание потенциального клиента мы для себя условно разбиваем на некие стадии, определенные статусы, которые должны пройти. Их название мы назначаем сами.
Вот факторы, которые надо учесть при формировании статусов лидов.
1. Длительность продажи. Безусловно, протяженность этапов, которые будет проходить ваш потенциальный клиент, в каждой компании своя. В нашей, к примеру, длительность продажи составляет от 1 месяца до 2 лет.
2. Рынок, на котором вы работаете. Я не имею в виду продажи в B2B или B2C, я говорю о конкретном рынке тех товаров и услуг, на котором вы работаете.
Статусы обработки лида рынка транспортных услуг будут сильно отличаться от статусов обработки клиентов на рынке подержанных авто, например.
3. Характеристика, свойства товара. Мы продаем транспортно-логистические услуги, иными словами доставку груза из точки А в точку Б. Если бы мы продавали подержанные автомобили, то, вероятнее всего, в наших статусах был бы такой, как «Тест-драйв». То есть клиент опробовал данное авто, и мы можем «дожимать» его на принятии решения.
После того как вы определитесь, по каким стадиям будут проходить потенциальные клиенты, мы переходим к оформлению значений этих статусов. Надо прописать конкретные виды работ, которые должен осуществить продавец на каждом этапе.
Статусы малого бизнеса в Израиле #израиль #адвокат #бизнес
Отмечу, что помимо промежуточных статусов (те, что ведут к цели), мы также должны назначить и результативные статусы: «Стал клиентом», «Некачественный клиент», «Банкрот».
Статус назначен — что дальше?
Итак, мы назначили статусы для наших потенциальных клиентов, дали точные указания нашим продавцам, что делать. А дальше мы переходим к анализу. И в нашем распоряжении такой сильный инструмент аналитики, как воронка. В нашем случае это воронка по проработке лидов.
Она не просто наглядно демонстрирует распределение клиентов по стадиям процесса покупки, но и позволяет легко определить, на каких этапах происходит потеря потенциальных клиентов. Следовательно, можно выявить причины этих потерь, сделать выводы о качестве работы продавцов, где нужно — приложить больше усилий. Не только спрогнозировать потенциальные потери, но и предотвратить их.
Воронка лидов
Каждый наш созданный статус — определенный срез в воронке. Если мы с вами видим, что на статусе «Презентация» (продавец высылает информацию о компании) идет самая большая потеря потенциальных клиентов, то либо у нас презентация не совсем продающая и пора ее менять, либо наши продавцы где-то «чудят». Таким образом мы можем разобрать весь наш процесс взаимодействия с лидами и выявить слабые стороны.
Основные этапы (статусы) в коммерческих предложениях
Подытожим: мы установили статусы потенциальным клиентам, «озадачили» продавцов, дав им точные инструкции, что надо делать на каждом из этапов проработки клиента. Определили с помощью воронки слабые места в работе с лидами и устранили их.
Сейчас поговорим о статусах на таком важном этапе, как формирование коммерческого предложения.
Если вы планируете продавать услуги, то рассмотрение ценового предложения растягивается на какой-то временной отрезок. Значит, мы должны этот процесс как-то контролировать и учитывать. И что самое главное, получать обратную связь.
Какие могут быть статусы в предложениях? Такой вопрос мы себе задавали при внедрении CRM-системы. Точно так же, как и в работе с лидами, многое зависит от вашей специфики.
- У нас в сфере грузоперевозок информация, полученная от клиента, называется «Запрос». Вот мы и не стали долго гадать и назвали одну из стадий нашего КП «Запрос»
- Этой стадии предшествует стадия «Черновик», поскольку клиент не всегда сходу может сказать все параметры услуги. И наши продавцы вынуждены уточнять информацию
- После стадии «Запрос» у нас следует статус коммерческого предложения «Отправлено». То есть продавец выслал КП и ему необходимо связаться с клиентом для получения обратной связи. Опять же, мы видим, что на каждой из стадий есть последовательность действий для продавца
- Далее может быть статус «На доработке», когда клиент изменил исходную информацию
- Статус «Закрытие сделки»
Как и со статусами в лидах, мы делаем табличку и назначаем каждому статусу конкретные задачи, которые должен выполнить продавец: статус, значение, что нужно сделать.
На стадии финального, логического завершения нашего КП — закрытие сделки — важно обратить внимание на формирование в CRM отрицательных статусов. Поясню на примере. Мы долгое время исследовали наиболее частые причины срыва сделки в компании. Распространенные ответы клиентов: дорого, большие сроки поставки, не подошли условия оплаты. В итоге, сформировав отрицательные статусы, вы будете видеть, сколько предложений закрыто со статусом «Дорого» или сколько предложений закрыто со статусом «Не подходящие условия оплаты».
Зачем это надо? В нашей компании таким образом мы закладываем основу для снятия аналитики продаж. По определенному периоду работы собираем статистику по каждому продавцу:
- Сколько предложений закрыто с результатом «Дорого»
- Сколько с результатом «Не подходящие условия оплаты». И так по всем статусам
Далее мы смотрим на удельный вес, который занимают эти результаты в общем количестве предложений. И делаем соответствующие выводы. Либо продавец не умеет обрабатывать возражения клиентов и надо его обучать, либо действительно наши услуги/товары не совсем конкурентны в текущий период времени. И мы начинаем искать альтернативы.
Такой подход помогает нам улучшить качество наших продаж, снимая статистику с каждого месяца. В компании разработаны лимиты: к примеру, предложения с результатом «дорого» не должны превышать 30% от общего числа КП.
А так ли нам нужны все клиенты?
Еще один небольшой лайфхак, который можно использовать при помощи статусов, — отказ от клиентов. Мы, как транспортная компания, просчитываем много запросов как от действующих заказчиков, так и от потенциальных. И если заниматься этими расчетами постоянно, это отнимает много времени. Поэтому мы установили лимиты отрицательных исходов предложений.
Если лиду было сделано 5 коммерческих предложений и все с результатом «Дорого», мы можем приостановить обработку такого лида. Или меняем ответственного менеджера.
Точно так же и с действующими клиентами. Если мы видим, что сделки постоянно закрываются с формулировкой «дорого», значит либо что-то у нас «барахлит», либо у клиента, к примеру, изменилась политика ценообразования. И он ищет самый дешевый транспорт.
Вывод прост: в продажах время на вес золота. Если тратить его впустую, то хорошего результат добиться будет крайне сложно.
- Зачем компаниям нужен бюджет на ошибки — простой пример
- Бери и делай! Эта компания долго пыталась заработать миллионы на попкорне — и вот чего добилась
Источник: probusiness.io
Внедрение JIRA Software #3. Описание статусов и бизнес-процессов
Данная статья относится к циклу статей, которые помогут вам внедрить JIRA SOFTWARE в организации.
Описание бизнес-процесса
Бизнес-процесс — это жизненный цикл запроса, который состоит из статусов и переходов. Рассмотрим на примере:
Статус – это этап, на котором в определённый момент находится запрос.
Переход – это путь, по которому может быть перемещён запрос из одного статуса в другой. Названию перехода соответствуют кнопки перехода запроса в карточке самого запроса.
Созданный бизнес-процесс запроса привязывается к конкретному проекту. Существует несколько подходов использования бизнес-процессов в проектах JIRAЖ
— создать универсальный бизнес-процесс и использовать его во всех проектах;
— создать для каждого проекта JIRA свой бизнес-процесс;
— использовать смешанную схему из первого и второго метода.
Также надо помнить, что у каждого типа запроса в JIRA, в рамках одного проекта, может быть свой бизнес-процесс. К примеру, запрос живёт по одному бизнес-процессу, а ошибка по другому бизнес процессу, т.е. каждый тип запроса в проекте может иметь свой бизнес-процесс.
Выбор бизнес-процесса
Кто внедряет JIRA впервые, тот сталкивается с проблемой построения бизнес-процесса и не знает, из каких статусов и переходов бизнес-процесс собирать.
Рассмотрим с вами бизнес-процессы, которые многократно обкатаны в моей практике. В дальнейшем вы можете их модифицировать под свои нужды. Ниже рассматриваются бизнес-процессы для запросов, с которыми работают разработчики, тестировщики, аналитики. Запросы более высокого уровня, которые решаются и контролируются на уровне менеджеров и руководства, будут иметь другой бизнес-процесс.
Бизнес-процесс для запроса типа «Задача», «Улучшение», «Доработка», «Подзадача»:
Бизнес-процесс для запроса типа «Ошибка»:
Категории статусов
 | «К выполнению» — это некий пул, в котором находятся запросы, ожидающие, когда их возьмут в работу (анализа, уточнения, реализации…) |
 | «В работе» — запрос, находящийся в данном статусе, находится на текущий момент в работе (анализируется, реализовывается, тестируется…) |
 | «Выполнено» — это конечный статус. Запрос в этом статусе уже реализован, протестирован и закрыт. |
Описание статусов
 | Пул запросов, которые надо проанализировать и отправить в разработку. В данный статус запрос попадает при создании нового запроса. Также в данный статус запрос попадает из статуса «Уточнение». |
 | Если в описании запроса недостаточно информации для реализации или для исправления, то запрос переводят в данный статус, говоря этим, что ему нужна дополнительная информация и в комментариях поясняет, что ему требуется предоставить. В данный статус запрос переводит тот, кто занимался анализом запроса. |
 | В данном статусе запрос находится в работе у сотрудника, у которого запросили уточнение. В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данном статусе запрос находится в работе у сотрудника, который проводит анализ запроса. В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данный статус запрос попадает после анализа и принятия решения о реализации описанных в запросе требований или исправлении описанной ошибки. В данный статус запрос переводит тот, кто занимался анализом. |
 | В данном статусе запрос находится в работе у сотрудника, который занимается реализацией требований (ведёт разработку). В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данный статус запрос попадает после реализации, для того чтобы провести ревью кода. В данный статус запрос переводит тот, кто занимался реализацией (разработкой). |
 | В данном статусе запрос находится в работе у сотрудника, который занимается ревью кода. В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данный статус запрос попадает после того, как проведено ревью кода и реализация или код соответствуют определённым требованиям. В данный статус запрос переводит тот, кто занимался ревью кода. |
 | В данном статусе запрос находится в работе у сотрудника, который занимается тестированием реализации. В данный статус запрос переводит сотрудник, который взял запрос в работу. |
 | В данный статус переводится запрос, который не может быть протестирован, пример: наличие блокирующих тестирование ошибок, не настроена для тестирования тестовая среда. В данный статус запрос переводит тот, кто занимался тестированием. После исправления блокирующих факторов запрос снова переводится в «Тестировать». |
 | В данный статус запрос переводится, если тестируемый/проверяемый функционал не реализован или реализован не в полной мере. В данный статус запрос переводит тот, кто занимался тестированием или проверкой реализации. Также в данный статус запрос может быть переведён из других статусов, если это предусмотрено. |
 | В данный статус запрос переводится после успешного прохождения тестирования. В данный статус запрос переводит тот, кто занимался тестированием. На моей практике у ошибок данный статус не вводился, так как все ошибки отдаются на откуп отделу тестирования. |
 | В данном статусе запрос находится на проверке у заказчика доработок/улучшений. В данный статус запрос переводит сотрудник, который взял запрос в работу. На моей практике у ошибок данный статус не вводился, так как все ошибки отдаются на откуп отделу тестирования. |
 | Запрос в определённый момент может быть отклонён, к примеру, если отменены требования на реализацию или запрос не является ошибкой. В данный статус запрос переводит тот, кто принял решение об отмене/отклонении запроса. Создатель запроса изучает вопрос и возвращает запрос в работу или закрывает его. |
 | В данный статус запрос переводит сотрудник, который работал с запросом на предыдущем шаге, который был до шага «Закрыто». Запрос, находящийся в данном статусе, уже не может быть взят в работу, однако, при необходимости, создаём клон запроса, и работает с копией. |
Стремитесь к тому, чтобы в бизнес-процессе у вас был один статус зелёного цвета, т.е. конечный статус запроса, который означает, что над запросом работы завершены.
В JIRA работают люди, которые имеют определённые роли. Рассмотрим, с какими статусами, какие роли работают.
Аналитик работает с запросами, которые находятся в статусах:
— Открыто
— Анализ
Разработчик работает с запросами, которые находятся в статусах:
— Открыто
— Анализ
— Сделать
— Реализация
— На ревью кода
— Ревью кода
— Переоткрыто
Тестировщик работает с запросами, которые находятся в статусах:
— Требует уточнения
— Уточнение
— Тестировать
— Тестирование
— Отклонено (если созданный тестировщиком запрос отклонён)
Если тестировщик является и заказчиком, то он может работать дополнительно с запросами, которые находятся в статусах:
— Проверить заказчику
— Проверяется
Заказчик работает с запросами, которые находятся в статусах:
— Проверить заказчику
— Проверяется
— Отклонено (если созданный заказчиком запрос отклонён)
Некоторых ролей может в организации и не быть или могут быть другие роли, которые работают с запросами в определённых статусах.
Переходы
Переход – путь по которому запрос может перемещаться с одного статуса в другой. На картинках переходы показаны стрелками. Если нет перехода связывающего определённые статусы, то и запрос не может быть переведён с одного статуса в другой. К примеру, согласно приведённым выше схемам мы не сможем перевести запрос из статуса «Реализация» в «Закрыто». Со статуса «Реализация» запрос может быть переведён в статус «На ревью кода».
Переходы мы создаём сами, однако при создании переходов надо учитывать, чтобы количество переходов было оптимальным, а также разумным. Я в своей практике если сомневаюсь в необходимости какого-либо перехода, то я с помощью JQL запроса в JIRA делаю выборку «сколько запросов за год (полгода) было перемещено по определённому переходу» и если получаю ничтожно малое количество запросов, то принимаю решение об удалении перехода, так как он никому практически не нужен. Пример JQL-запроса:
status changed from (Тестировать) to (Тестирование) during («2018-01-01 00:01», «2018-07-31 23:59»)
JQL-запросы — это отдельная тема, которая в данной статье рассматриваться не будет.
При создании бизнес-процесса выстраивайте статусы и переходы так, чтобы они хорошо читались. Взгляните на бизнес-процессы выше и сравните их со следующим бизнес-процессом:
Если кто-то попытается понять, из приведённой картинки, в какой статус запрос может быть переведён из определённого статуса, то у него возникнут с этим проблемы. Любой сотрудник может в запросе посмотреть бизнес-процесс, по которому живёт запрос, для этого необходимо находиться в карточке запроса:
В следующей статье мы будем создавать статусы и бизнес-процессы.
Предыдущая запись
Следующая запись
Ещё публикации из этой рубрики:
Установка ONLYOFFICE Docs и интеграция с NextCloud
Установка Transmission на FreeBSD
Установка Jellyfin на FreeBSD
Установка BookStack на CentOS
Установка Gitea на CentOS с помощью Snap
Установка PostgreSQL на FreeBSD
Последние записи
Установка ONLYOFFICE Docs и интеграция с NextCloud
Установка Transmission на FreeBSD
Встроенная в TrueNAS виртуальная машина не выходит в сеть
Копирование материалов разрешено только при наличии активной ссылки на первоисточник.
Источник: victorz.ru
Свойства процессов
Окно свойств процесса открывается нажатием на кнопку на панели инструментов Навигатора или Окна диаграммы.
Операции над объектами и атрибутами объектов
На вкладке Операции в Окне свойств процесса показывается список операций процесса над объектами деятельности и их атрибутами. В список попадают объекты стрелок, входящих и исходящих из процессов на диаграммах SADT, и объекты, связанные с процессами на диаграммах EPC или BPMN.
Цель данного механизма — описание жизненного цикла объектов и их атрибутов в бизнес-процессе. Например, для объектов справочника «Документы» этот механизм позволяет отследить жизненный цикл каждого документа и получить конкретизированный отчет по документообороту.
Для каждого процесса заполняется вид операции над объектом. Под видом операции над объектом понимается то, каким образом процесс воздействует на объект и его атрибуты. В программе предопределены следующие виды операций над объектами: создание, удаление, чтение, обновление и архивирование; виды операций над атрибутами: вставка, обновление, чтение, обнуление.
Виды операций над объектами и атрибутами хранятся в специальных расширяемых справочниках «Виды операций над объектами» (Главное меню → Справочники → Все справочники → Классы → Виды операций над объектами) и «Виды операций над атрибутами» (Главное меню → Справочники → Все справочники → Классы → Виды операций над атрибутами). Подробнее о работе с системными справочниками см. Справочники. При необходимости пользователь может добавить в них свой вид операции. Новый вид операции станет доступным после перезагрузки программы.
Выполняемые виды операций отмечаются на вкладке Операции в Окне свойств процесса (Рис. 1).
Внимание!
На вкладке Операции отображаются данные только сохраненных стрелок и связей. Если новая стрелка или связь добавлена на диаграмму и соединена с процессом, но диаграмма еще не сохранена, то объекты не будут показаны на вкладке Операции данного процесса.
Объекты деятельности в списке сгруппированы по типам стрелок, связанных с данным процессом: вход, выход, управление, механизм. Подробнее о стрелках см. Стрелки.
Если в процесс входят или выходят несколько стрелок с одним и тем же объектом, то задается воздействие на объект отдельно для каждой стрелки.
По гиперссылке Детализация, находящейся на вкладке Операции, открывается Окно свойств выделенной в списке строки. В открывшемся окне на вкладке Процессы на другом конце представлен список процессов на другом конце связи.
Если для объекта введено значение параметра «Атрибуты», то эти атрибуты будут показаны в списке «Атрибуты» под списком объектов. Для атрибутов также можно задать производимые над ними операции.
По заполненным данным можно получить отчеты по жизненному циклу объектов (см. Отчеты объектов деятельности).
Назначение показателей процессу
На вкладке Показатели в Окне свойств процесса отображается список назначенных показателей.
Заполнение списка «Показатели» в свойствах процесса осуществляется выбором из справочника, либо путем переноса:
показателя из иерархического справочника «Показатели» в Окно свойств процесса;
цели из иерархического справочника «Цели» в Окно свойств процесса. При этом с процессом ассоциируются все показатели выбранной цели, лишние показатели затем можно удалить.
Назначение процессу показателя также может осуществляться на вкладке Процессы в Окне свойств показателя. Подробнее о показателях см. Показатели.
Чтобы удалить назначенный показатель из списка, установите на него курсор, откройте контекстное меню и нажмите пункт меню Удалить выделенные строки. При этом в списке «Процессы» у этого показателя также будет удален выбранный процесс.
Статусы процесса
Статус процесса служит для отражения стадии, в которой находится работа над процессом (диаграммой процесса, параметрами процесса) и сам процесс. Возможные статусы процесса:
В работе − над процессом ведется работа;
Проект − процесс проходит согласование;
Рекомендован − процесс проходит утверждение;
Опубликован − процесс опубликован и обязателен для исполнения;
Архивирован − процесс архивирован и не действует.
Все статусы процесса отображаются в специальном списке «Статусы процесса» (Окно свойств процесса → вкладка Основные → вкладка Статусы процесса). У каждого процесса есть текущий статус, отображаемый в статусной строке Главного окна и в Окне свойств процесса в параметре «Текущий статус».
Изменение текущего статуса производится из Окна свойств процесса нажатием на кнопку в строке параметра. Откроется Окно свойств текущего статуса. Изменения текущего статуса сохраняются при сохранении процесса. Описание параметров, заполняемых в Окне свойств текущего статуса, приведено в статье Разработка системы менеджмента качества → Изменения статуса процесса.
Статусы процессов могут влиять на вывод информации об этих процессах в отчеты Business Studio. В отчетах, поставляемых вместе с Business Studio, во многие разделы информация выводится только по процессам, имеющим статусы из числа разрешенных для вывода в отчеты. Это необходимо для того, чтобы информация о процессах, которые, например, имеют статус «В работе», не попадала в регламентирующие документы для персонала. Перечень таких статусов задается на вкладке Статусы процесса для отчетов в Настройках для всех пользователей (Главное меню → Главная — Настройки для всех пользователей → вкладка Основные). Описание отчетов с указанием их разделов, в которых учитываются статусы процессов для отчетов, приведены в главах Отчеты процессов и Отчеты субъектов.
Внимание!
После сохранения изменений, выполненных на вкладке Статусы процесса для отчетов, всем пользователям, которые могут формировать отчеты в текущей базе данных, необходимо перезапустить Business Studio с этой базой данных.
Смена статуса
Для процесса и его подпроцессов рекомендуется регистрировать изменения статуса отдельно. Для операций процесса (в случае, если операции не являются подпроцессами) рекомендуется устанавливать статус такой же, как и у процесса.
Задать новый статус можно в Навигаторе с помощью пункта меню Сменить статус процесса… (Контекстное меню процесса → Совместная работа). Откроется Окно свойств нового статуса, параметры в котором заполняются на основе параметров из текущего статуса процесса. При этом параметр «Изменение» будет пустым, а в параметр «Дата» будет подставлена системная дата. Существует возможность при необходимости хранить для процесса несколько статусов с одной и той же датой, указывая время с точностью до секунды. Для этого требуется в Окне свойств нового статуса вывести на показ параметр «Время» с помощью пункта меню Настройка колонок (Окно свойств нового статуса → кнопка Действия → Настройка колонок) и задавать в нём при смене статуса значение, отличное от заданного по умолчанию.
После внесения изменений и закрытия Окна свойств статуса будет выдано сообщение о подтверждении смены статуса процесса. В случае подтверждения смены статуса в данном окне необходимо выбрать, для каких процессов будет произведена смена статуса. Выбор осуществляется из следующих пунктов:
Для текущего процесса — статус сохраняется только для текущего процесса;
Для текущего процесса и нижележащих процессов — статус сохраняется для текущего процесса и его непосредственных потомков;
Для текущего процесса и всех нижележащих процессов — статус сохраняется для текущего процесса и всех его потомков.
После подтверждения смены статуса процесса в качестве текущего статуса из списка статусов процесса будет выбран статус с наиболее поздней датой и временем.
Внимание!
Процессы со статусом «Опубликован» запрещено редактировать. Сначала нужно сменить статус процесса.
Историю изменений статусов можно просмотреть на вкладке Статусы процесса в Окне свойств процесса. Чтобы внести изменения в один из предыдущих статусов, необходимо открыть свойства выделенной строки с помощью соответствующего пункта контекстного меню. При смене статуса процесса в случае совпадения заданной комбинации даты и времени нового статуса с соответствующей комбинацией для одного из имеющихся статусов, в списке статусов из этих двух будет оставлена только одна строка, соответствующая последней смене статуса.
Удаление последнего созданного статуса
Существует возможность удалить последний созданный для процесса статус (имеется ввиду не дата в свойствах статуса, а фактическая дата его создания). Это можно сделать в Навигаторе с помощью пункта меню Удалить последний созданный статус (Контекстное меню процесса → Совместная работа).
Если при этом в списке статусов процесса (Окно свойств процесса → вкладка параметров Основные → вкладка Статусы процесса) есть только один статус, то он не будет удалён.
Источник: www.businessstudio.ru