Работа в CRM Битрикс24: как собрать карточку сделки, в которой менеджер ведёт клиента

Работа менеджера в CRM Битрикс24 идёт в карточке сделки: слева поля с данными о клиенте и заказе, справа таймлайн с историей звонков, переписки, дел и смены стадий. Карточка работает, когда звонки, чаты и письма попадают в таймлайн сами, у каждой сделки в работе есть запланированное дело, а поля на стадиях заполняются из источника или проверяются обязательностью. Ниже разбираем, как мы собираем такую карточку на внедрении и где теряется то, что менеджер сделал мимо неё.

Из чего состоит карточка сделки

У каждого элемента CRM в Битрикс24 есть карточка. Левая часть — поля, сгруппированные в разделы: о клиенте, о заказе, о доставке. Поля бывают системные, их нельзя удалить, только скрыть, и пользовательские, которые создаются под процесс компании. Правая часть — таймлайн.

Сверху карточки стадии воронки. Сменить стадию можно кликом по её названию, и запись об этом попадает в таймлайн. Там же кнопки звонка, письма, SMS, приглашения клиента в мессенджер и создания документа по шаблону: коммерческое предложение подтягивает данные клиента и реквизиты компании из карточки.

На бумаге набор полный. В работе менеджер пользуется им частично: звонит с мобильного, пишет в личный мессенджер, договорённость держит в голове, а в карточку заходит сменить стадию перед планёркой. Через месяц сделку передают другому человеку, и таймлайн показывает три смены стадии и ни одного разговора. Карточку мы собираем так, чтобы вести клиента через неё было проще, чем мимо неё.

Что такое таймлайн в Битрикс24

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

Из таймлайна видна и история смены стадий: кто и когда перевёл сделку и на какую стадию. Когда нужно разобраться, почему сделка зависла, мы начинаем с него.

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

Звонки, чаты и заявки попадают в таймлайн сами

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

Звонки. Если телефония подключена к порталу и менеджер звонит из карточки или с номера, привязанного к сотруднику, запись разговора оказывается в таймлайне. Звонок с личного телефона в сделку не попадёт. Если звонки не доходят до сделок при подключённой телефонии, причина обычно в настройке номеров или маршрутизации. Её мы разбираем при подключении IP-телефонии к CRM.

Чаты. Мессенджеры и соцсети подключаются к порталу через открытые линии в разделе CRM → Клиенты → Контакт-центр. Чат-трекер — механизм, который определяет клиента по базе CRM и сохраняет переписку в его карточке, даже если человек пишет из разных каналов. Он включён по умолчанию во всех подключённых каналах, выключить его может администратор или сотрудник с правом на настройку открытых линий. Для нового клиента линия может сама создать лид или сделку с историей переписки и источником. Если клиент уже есть в CRM, его чат уходит ответственному за карточку.

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

Заявки с сайта. CRM-форма создаёт элемент с заполненными полями. Главная работа здесь в том, чтобы источник и рекламные метки доезжали до сделки: без них не посчитать, какая реклама приносит продажи.

Поля: заполняет система, обязательность страхует

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

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

Первая группа заполняется из источника. Источник сделки и метки берутся из формы или открытой линии, телефон и имя — из звонка или чата, сумма — из товаров в сделке или из счёта, номер договора — из шаблона документа. Менеджер эти поля не трогает. Если значение приходит не из стандартного канала, его проставляет робот «Изменить элемент», когда сделка попадает на стадию.

Вторая группа — то, что знает только менеджер после разговора: потребность, бюджет клиента, причина отказа. Здесь без ручного ввода не обойтись, поэтому работает обязательность на стадии: менеджер не переведёт сделку дальше, пока не заполнит поле. Настраивается это в карточке: шестерёнка у поля → «Настроить» → «Обязательное на стадии» и выбор стадий. Обязательность в сделках настраивается для каждой воронки отдельно, и опция доступна не во всех лицензиях. Если стадию меняет автоматика, нужное значение мы записываем тем же роботом, который двигает сделку, и не полагаемся на проверку при ручном переходе.

Причину отказа делаем списком и обязательной только на стадии провала. Свободный текст в этом поле через месяц превращается в «не берёт трубку», «дорого», «дорого!!», «передумал» и не группируется ни в какой отчёт.

Третья группа — всё остальное. Её скрываем из общего вида карточки: скрытое поле хранит данные и не мешает.

Один вид карточки для всех

Вид карточки в Битрикс24 настраивается тремя способами. Общий вид задаёт администратор, и все сотрудники видят одинаковый набор полей. «Мой вид карточки» каждый настраивает под себя, если в правах доступа у него есть «Разрешить свой вид карточки». Третий вариант — вид для выбранных сотрудников или отделов.

Для отдела продаж мы включаем общий вид и снимаем с роли менеджера право на свой вид карточки. Иначе каждый уберёт поля, которые ему мешают, и на планёрке выяснится, что поле, обязательное на следующей стадии, половина отдела никогда не видела. Отдельный вид делаем для смежных отделов: производству или доставке в сделке нужны адрес, сроки и состав заказа, условия оплаты им ни к чему. Как устроены сами права и роли, разбираем в статье права доступа в Битрикс24.

Дела: у каждой сделки в работе есть следующий шаг

Сделку без запланированного дела забывают первой. Дело в Битрикс24 — звонок, встреча или другое действие по клиенту, которое планируется из таймлайна сделки и видно в ней и в счётчиках CRM. Дела и задачи — разные сущности: дело относится к работе менеджера с клиентом, задача ставится в разделе задач и может быть привязана к сделке.

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

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

Руководителю удобен режим просмотра «Дела» в сделках. В нём шесть колонок по сроку ближайшего дела: просрочены, на сегодня, на этой неделе, на следующей неделе, больше двух недель и без дел. Если «Просрочены» и «Без дел» длиннее колонки «На сегодня», разговор на планёрке понятен без отчёта.

Задачи для коллег из карточки

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

Из таймлайна сделки ставится задача, и её статус, смена срока и исполнителя видны в той же карточке. Повторяющиеся поручения ставит робот на стадии: сделка перешла в «Согласование договора», юрист получил задачу, а робот «Изменить наблюдателей» добавил его в наблюдатели сделки. Менеджеру не нужно помнить, кого подключать, и пересказывать детали: у юриста перед глазами вся история.

Распределение заявок

Кто ведёт сделку, лучше решать до того, как менеджер откроет карточку. Робот «Изменить ответственного» на первой стадии назначает ответственного из списка сотрудников: по очереди, случайно или первого в списке. Он умеет пропускать отсутствующих по графику и тех, у кого закончился рабочий день. Для открытых линий есть своя настройка распределения.

Настройка короткая и экономит первые минуты после заявки, когда клиент ещё помнит, куда писал.

Как мы проверяем, что карточка работает

Через месяц после запуска мы открываем двадцать сделок, закрытых за месяц, успешных и проваленных вперемешку, и читаем таймлайн каждой глазами человека, которому эту сделку завтра передадут.

Хорошая сделка читается за минуту: заявка из формы с источником, звонок в первые полчаса, переписка в открытой линии, дело на перезвон, смена стадии после счёта, оплата. Плохая выглядит как три смены стадии подряд в пятницу вечером и пустое поле причины отказа, которое на стадии провала почему-то не было обязательным.

Дальше считаем то же на всём потоке. Через наборы данных BI Конструктора или выгрузкой по REST видно, сколько сделок прошло воронку без единого звонка и чата, сколько висело без дела дольше суток, у кого из менеджеров стадии перескакивают через одну. Эти цифры показывают, какая часть работы по-прежнему идёт мимо портала и где настройку нужно дожимать.

После такой настройки у менеджера в карточке остаётся работа, которую за него не сделает система: разговор с клиентом, пара полей после разговора, выбор следующего шага. Карточку мы собираем вместе с воронкой, правами и роботами на внедрении Битрикс24. Если портал уже работает и отдел ведёт клиентов мимо карточки, начинаем с аудита Битрикс24, а дальше доводим настройку в сопровождении.

Частые вопросы

Ответы на вопросы, которые нам чаще всего задают по этой теме.