Если вы работаете с большим числом клиентов, то вам наверняка знаком вопрос «Кто из клиентов давно не приходил?».
Он настолько же типичен насколько типична и попытка ответить на него по-простому: а давайте найдем всех клиентов, которые ничего не покупали последние столько-то дней. В общем, не такой уж и плохой вариант и у него даже есть название — RFM-анализ, ну, точнее, это — часть RFM-анализа.
Однако, если клиентов много, а вы предлагаете некое разнообразие услуг и (или) товаров, то упомянутый подход будет весьма грубым. Почему? Потому что паттерны поведения разных клиентов отличаются. Соответственно, регулярность их взаимодействия с вами так же будет разной. Допустим, если вы продаете расходные материалы, то потребность различных покупателей в вашей продукции разнится в зависимости от интенсивности их деятельности. Да и при сопоставимой интенсивности стратегия закупки может отличаться, что сказывается на периодичности закупки. Те же соображения относятся и к услугам и к иным товарным категориям.
Для примера, я приведу графики распределения задержек между сделками для трех произвольных клиентов оптовой компании.
Эта диаграмма соответствует средней задержке в 30 с половиной дней (стандартное отклонение — 12.2).
Здесь отображена активность со средним разрывом в 11.1 дней и стандартным отклонением — 7.8 дня.
А этот клиент — наша радость. Сделки в среднем через 3.2 дня и стандартное отклонение 1.8 дня.
Стало быть, нам необходим какой-то инструмент, позволяющий оценить регулярность обращения конкретного клиента в прошлом и на основании этого знания спрогнозировать период, в течении которого он должен бы вернуться. И, если, он таки не вернулся, начать беспокоиться.
Попробуем развить идею. Для этого понадобится решить несколько вопросов:
- определить события, которые следует трактовать как факт клиентской активности
- собрать статистику таких событий по каждому клиенту за какой-то ретроспективный период времени
- определить фактор, который позволит унифицировать категоризацию текущего состояния задержки активности каждого конкретного клиента.
- классифицировать всех клиентов в соответствии с фактором, определенном в предыдущем пункте.
Собственно, этот шаг является финальным в смысле сформулированной проблемы.
То есть, как только мы классифицировали всех наших клиентов, мы знаем какие клиенты находятся в состоянии нормальной активности, кто задержался (и, наверное, надо бы его подтолкнуть к действию), кто безнадежно затянул взаимодейстие с нами (вероятно, про них уже можно забыть).
Теперь чуть больше деталей по пунктам, перечисленным выше.
События, трактуемые как клиентская активность. Мы вынуждены их четко специфицировать, поскольку в ERP/CRM-системах с каждым клиентом может быть связано значительное число транзакций, многие из которых избыточны в контексте нашей задачи. Скажем, одна продажа может включать в себя цикл [заказ-отгрузка-оплата]. Для одной услуги салона красоты сгодится формула [запись-подтверждение-услуга-кассовый чек]. То есть, то, что трактуется фактом клиентской активности должно быть определено в терминах системы управления бизнесом, которую вы используете. Так в приведенных выше примерах, фактами активности могут быть транзакции отгрузки и оказания услуги. Но не обязательно: кто-то может решить, что таковыми являются заказ или запись на услугу, либо, событие оплаты товара или услуги. Здесь важно то, чтобы вы не учитывали и оплату и отгрузку одновременно, поскольку в таком случае получится, что единственный факт активности будет учтен дважды.
Как только мы определились с интерпретацией факта клиентской активности, можем приступать к фазе сбора статистики. Математика здесь самая незамысловатая. Зададим некоторый ретроспективный период времени (квартал, год, 3 года, в зависимости от того как давно вы учитываете бизнес-транзакции и насколько важны для вас старые данные).
За заданный период для каждого клиента соберем все транзакции, трактуемые как его активность. Далее, посчитаем статистические характеристики ряда разрывов между событиями в днях. Нам пока не понадобится ничего сложнее, чем средняя величина разрыва (E) и стандартное отклонение (σ). На приведенных выше диаграммах я именно эти параметры распределения и указал.
Теперь мы в плотную подошли к фактору оценки задержки клиентской активности.
Мы будем измерять задержку активности конкретного клиента в количестве N стандартных отклонений (σ), отличающих текущую задержку в днях (D) от средней величины задержки (E).
N = (D — E) / σ
Так как E и σ являются свойствами конкретного клиента, то мы можем унифицировать клиентов через фактор N. То есть, мы определяем, что если задержка клиента превышает, скажем, 5, то это значит что надо начать беспокоиться.
Прелесть в том, что этот фактор будет одинаково приемлем и для клиента, который заходит раз в неделю, и для того, который наведывается ежемесячно.
Давайте я еще раз проговорю то, чего мы добились. Если бы мы получили отчет о клиентах, кто не приходил в последние 30 дней с целью идентификации тех, кому надо позвонить и напомнить о том, что мы не закрылись, то в этот отчет попадут те, кто не приходил уже больше года и те, кто приходит раз в 32 дня и собирался завтра вас навестить (ну и те, кто приходит раз в неделю, но перестал ходить). И менеджеру придется детально разбираться со строками отчета, дабы не тратить время и силы на тех, на кого их тратить еще не пришло время и на тех, кому звонить уже бесполезно.
Имея наш замечательный и несложный фактор, унифицирующий паттерны поведения различных клиентов, мы запросим у нашей ERP/CRM-системы отчет о клиентской активности и получим, в частности, список клиентов, которые не давали о себе знать в течении числа дней, характерных конкретно для каждого из них. Кроме того, мы увидим всех клиентов, которые взаимодействуют с нами активно и регулярно (почему бы их не поощрить?), а так же тех, кто уже безнадежен (слишком долго не давали о себе знать, причем, это «слишком долго» характерно только для этих клиентов, ибо для иных может означать, что они скоро ожидаются).
Уточним еще один важный момент. Для того, чтобы вся наша конструкция заработала, понадобится определить где-то в конфигурации 4 граничных параметра. Два параметра задают задержки в унифицированных единицах σ, и служат маркерами для отличия тревожной задержки от регулярной и безнадежной задержки от тревожной. Два других параметра комплиментарны первой паре и применяются в аварийной ситуации, когда по клиенту нет приемлемой статистики. Эти аварийные параметры определяют те же самые границы, но в старых добрых днях.
Опишем все 4 параметра чуть более формально:
- Значение Nd, при превышении которого считается, что клиент задержался с визитом
- Значение Nh, превышение которого означает, что клиент безнадежно давно нас не навещал
- Аварийное значение Dd — задержка в днях, превышение которой трактуется как задержка визита. Применяется при отсутствии статистики по клиенту.
- Аварийное значение Dh — задержка в днях, превышение которой трактуется как безнадежная задержка визита. Применяется при отсутствии статистики по клиенту.
Описанная методика имеет еще пару ценных следствий:
- одновременно мы теми же средствами получаем поименный список новых клиентов (если зададим период, за который следует анализировать появление таковых)
- так как для нашего анализа мы периодически собираем и сохраняем статистику активности клиентов, то нам несложно будет получить анализ на любую дату и, более того, быстро построить и отобразить динамику изменения состояния активности клиентской базы
Далее, на рисунке приведен примерный вид отчета об активности клиентов. Я не стану занудствовать и перечислять колонки, просто отмечу, что статус клиента относительно фактора задержки активности можно видеть по цветовому индикатору (клиенты, по которым нет данных вообще, удалены из списка). Новый клиент здесь отмечен кружочком (выделенная строка).
В качестве заключения замечу, что описанный подход, в некотором смысле синтезирует техники Recency и Frequency из RFM-анализа и оставляет (M)onetary на рассмотрение другим инструментам.
Ах, да. Чуть не забыл: все описанное имплементировано в open-source ERP/CRM системе OpenPapyrus. Но идея достаточно проста и, надеюсь, доступно мной изложена для того, чтобы легко можно было бы реализовать ее в любой иной системе.