Причины отказов в CRM: как составить справочник, которому можно доверять

Причина отказа и догадка менеджера

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

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

Известное обстоятельство и пояснение

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

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

Из чего состоит короткий рабочий справочник

В Битрикс24 можно создать несколько неуспешных финальных стадий. Эта возможность описана в инструкции по справочникам CRM.

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

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

У каждого пункта есть граница. «Не подходит состав услуги» выбирают при конкретном несоответствии задачи и предложения компании; «Не устроили условия» означает, что клиент назвал неприемлемое условие и его записали в пояснении. «Связь не установлена» сообщает о результате попыток контакта, а не о решении покупателя.

Заготовка списка и границы пунктов

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

Что писать рядом с выбранной причиной

Комментарий нужен там, где название оставляет слишком много вариантов. При отказе из-за бюджета полезно записать слова клиента и состав услуги, цену которой он обсуждал; при отказе по сроку — дату, к которой требовалось закончить работу, и предложенный компанией срок. Цифры берутся из разговора. Если клиент не назвал сумму, менеджер сохраняет известное ему объяснение, а поле бюджета остаётся пустым. Для дальнейшего разбора это полезнее, чем приблизительная сумма, происхождение которой новый сотрудник уже не сможет установить по переписке или записи звонка.

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

Копировать всю переписку необязательно. Достаточно существенной детали и ссылки на разговор внутри CRM, если она доступна участникам разбора. Лишние личные сведения или эмоциональные оценки человека не объясняют, почему закончилась продажа услуги, зато мешают следующему сотруднику быстро найти относящиеся к ней договорённости и слова клиента. Поэтому вместо «странный клиент» полезнее сохранить конкретное возражение, а если его не было — прямо отметить, что причина не выяснена.

Нет связи и технический дубль

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

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

Когда требовать заполнение и кто проверяет смысл

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

Я бы запрашивала причину при неуспешном завершении, а не в момент создания сделки: пока клиент ещё не принимал решения, требование выбрать отказ вынуждает продавца поставить случайное значение. При закрытии уже известно хотя бы основание прекращения работы, а вариант «Причина не установлена» позволяет закрыть карточку, не придумывая объяснение отказа.

Пробный разбор и приёмка

До включения обязательности полезен пробный разбор. Руководитель даёт сотрудникам несколько реальных карточек с доступной всем участникам историей и просит независимо выбрать причину. Затем сравнивают ответы. Если один и тот же разговор попадает в два пункта, участники объясняют выбор по определениям, а не по должности или стажу сотрудника. Я бы объединила причины, которые постоянно путают и которые приводят к одинаковому действию: дополнительная строка в отчёте не оправдывает путаницу при заполнении. Различия, за которыми стоит отдельное решение отдела, сохраняют и описывают точнее.

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

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

Кто и как меняет справочник

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

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

Выборка для контроля заполнения

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

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