Как оценивать результат работы всей компании? Внедрение «Битрикс24» не только для продаж

В основном предприниматели сталкиваются с проблемами в продажах. Они пытаются разобраться, что же происходит у продавцов, но продавцы на всё имеют своё мнение, и в результате не получается объективной оценки. Для перевода из субъективной оценки в объективную (в цифры) требуется всё свести в единую систему. Поэтому заводят CRM.

Об этом давайте сегодня поговорим.

Кто-то выбирает амоcrm, кто-то нишевые решения, кто-то Битрикс 24, но это покрывает только отдел продаж. Продавцы продают товар или услугу, а как проходит процесс выполнения обязательств никто не знает, это происходит уже где-то за скобками.

А что дальше будет с продажей?
Сколько раз после первой продажи покупал клиент?
Изменилась ли стоимость покупки в процессе работы с клиентом?

В новом проекте мы заметили такую же сложность. В целом компания работает хорошо, продаёт хорошо, но что с заказчиком происходит дальше уже ведётся в целом наборе таблиц и чатов т.к. процесс работы вынесен за пределы CRM.

Если в реальном примере, то продажа идёт в Битрикс, а процесс продажи ведется в гугл таблицах. В саму таблицу записывается вся необходимая информация при работе с проектом. Передача информации между исполнителями проекта происходит в чатах мессенджеров, по этому реализация очень не прозрачна.

В любом проекте мы начинаем с общей схемы. Для этого всегда нас выручает сервис Miro. В нём уже большой багаж наработок по внедрению:

В новом проекте планируем связать всё что есть в компании.

В отделе продаж есть несколько направлений работы:

С этим в целом понятно. Делим воронки по направлениям и создаём воронки исполнения обязательств. Получаем вот такую схему для отдела продаж:

После этого детализируем все интеграции с рекламными системами, отчётами, аналитикой и базами ретаргетинга.

В отделе продаж мы отделили этап продажи от этапа реализации и выделили отдельную воронку для апсейлов тому же клиенту. Теперь нам требуется определить с кем, и кто взаимодействует при выполнении заказа. Для себя мы выбрали путь собеседований. Простроив график совещаний с каждым отделом, начали описывать кто чем занимается. Получилось 12 отделов при работе с заказом.

Мы шли по взаимосвязи с отделом продаж. т.е. при обсуждении узнавали кто, что готовит для отдела продаж или для выполнения проекта.

Например: для выполнения заказа продавцу требуется оценить перевозку материалов, техники или нужно арендовать технику. В компании есть особые люди для этого.

А логисту требуется ответ от отдела эксплуатации по свободным автомобилям или ресурсам.

В поисках точек соприкосновения отделов и распутывая клубок находили людей, функции которых даже для руководителей были сюрпризом. В результате получили огромную схему взаимосвязей.

Одни продают, другие ищут технику, третьи обслуживают и выдают технику, пятые сопровождают всё документами, следующие оплачивают подрядчиков, седьмые собирают оплату с клиентов… В общем как пчёлки трудятся на общее благо. При этом информация ходит из уст в уста, в переписках, в общем понять кто, что сделал и когда это было достаточно сложно.

Поняв взаимосвязи и описав информацию, которая ходит между отделами мы принялись за пилот.

По сути, задача выглядела так:
Каждый отдел работает над своим кусочком проекта и при этом видит необходимые водные для выполнения своих задач. Мы нашли решение для этого.

Давайте рассмотрим первую версию пилота.

Представим, что у нас пришла заявка на перевозку трактора. Я как продавец узнаю вводную информацию от клиента, описываю её в сделке, а после этого мне надо получить оценку стоимости от логиста (который подберёт технику, оценит работу по перевозке или использует собственную технику). Описав вводные для логиста, передвигаю сделку в статус «Оценить».

При передвижении в оценку создаётся вторая сделка (дочка) в воронке логистов. При этом в сделке у продавца прописывается дочка и её статус.

В воронке логистов появляется сделка, связанная со сделкой в отделе продажи и логист принимает её в работу. Он ищет подрядчика или просчитывает стоимость использования собственной техники. После определения себестоимости логист передвигает сделку на согласование.

В этот момент у продавца сделка передвигается в статус «оценка готова» т.е. логист всё оценил и можно сообщить заказчику стоимость и сроки. При этом у нас есть вся информация в основной сделке и часть информации в сделке для логистов. Теперь отделы работают каждый со своей частью и при этом вся информация копится в единой сделке.

В результате мы знаем:

А руководитель видит общую картину происходящего.

Посмотрев пилот мы с заказчиком убедились в работоспособности общей идее. Продумав детали, мы усложнили пилот!

Теперь понятно, что логист с продавцом могут выполнять заказ или продажу работая по отдельности, но сохраняя информацию в системе. Но!

У логистов есть постоянные подрядчики или единоразовые запросы. Каждый раз логист идёт за информацией в телефонную книжку, в записи гугл док или обзванивать новых подрядчиков. После этого отвечает продавцу, и новая заявка повторяет этот процесс. Напрашивается база подрядчиков за всю историю с ценами, оценками качества и пометками. Итого получаем справочники, которые заполняются при каждой оценке проекта и хранятся как база данных по подрядчикам.

Мы сделали второй пилот и он проходит обкатку уже самими отделами. О деталях я расскажу в следующий раз. Да и в целом после пары функциональных пилотов перенесём всю схему взаимодействий, но уже понятно, что отделы могут совместно работать над проектами.

Отделять отдел продав в CRM от всех компании не нужно. Можно и нужно настроить взаимосвязи с остальными отделами. После этого вы всегда сможете разобраться в ходе проекта от продажи и до закрытия обязательств.

Кто участвовал в проекте, над чем он работал, какую информацию давал, сделали ли выплаты подрядчикам, как отработали подрядчики на проекте, сколько техники было задействовано, на сколько увеличился чек при реализации, а самое главное связать это всё с источником первого обращения заказчика в компанию.