Компания продаёт услуги по подписке и периодическому обслуживанию. Два источника выручки: новые клиенты, которых надо найти и убедить, и текущие, которым надо продлевать. Оба работали плохо, но по разным причинам.
Пришли с тремя запросами сразу: «обзвон непонятно как идёт», «продления забываем» и «отчёты живут в Google Таблицах». Мы предложили не делать всё одновременно — и это оказалось правильным решением.
Как это было устроено
Холодная база лежала в таблице на несколько тысяч строк. Менеджеры брали куски, звонили, ставили отметки в своих колонках. Что происходило дальше — зависело от аккуратности конкретного человека.
Повторные продажи держались на памяти. У услуг был период — месяц, квартал, год, — и кто-то должен был помнить, что подходит срок. Иногда помнили. Клиент, о котором забыли, просто не продлевал, и это считалось нормальным оттоком.
Отчёты собирались в Google Таблицах: выгрузка, формулы, сводная. Каждую неделю руками.
Платежи из 1С в CRM попадали с задержкой — когда бухгалтерия находила время переслать список.
Из чего складывалась проблема
Обзвон не был процессом. Он был активностью. Нельзя было ответить, сколько контактов обработано, какая конверсия, по каким причинам отказывают. Отметки в таблице стояли, но у каждого менеджера своя система обозначений.
Повторные сделки зависели от памяти. Не было механизма, который сам скажет «у этого клиента период заканчивается через две недели». Продление происходило, если менеджер вспоминал или если клиент сам приходил.
Отчёты устаревали в момент создания. Таблица собиралась в понедельник по данным пятницы, обсуждалась в среду. Решения принимались по картине недельной давности.
Оплаты приходили с опозданием. Менеджер звонил клиенту с напоминанием об оплате, которая уже поступила три дня назад. Это неловко и повторялось регулярно.
Во что это обходилось
Самое дорогое — потерянные продления. Клиент, который не продлил не потому, что недоволен, а потому, что о нём забыли, — это выручка, которую компания уже заработала и отдала. Точную цифру назвать не берусь, но в бизнесе с периодическими услугами такие потери обычно исчисляются десятками процентов от базы.
Второе — впустую потраченный обзвон. Без учёта результатов невозможно понять, что работает: какой скрипт, какой сегмент базы, какое время звонка. Компания звонила много и не становилась от этого умнее.
Третье — управление вслепую. Отчёт недельной давности не позволяет реагировать, он позволяет только констатировать.
Что мы сделали
Разбили работу на три независимых направления и запускали по очереди. Каждое давало результат само по себе, не дожидаясь остальных.
Направление первое — обзвон как процесс. Завели смарт-процесс со стадиями: в очереди, дозвон, разговор состоялся, отказ, интерес, передан в продажи. У записи есть ответственный, результат, причина отказа и дата следующего касания.
Контакты из базы распределяются между менеджерами. Отказ фиксируется с причиной из списка, а не свободным текстом — иначе аналитики опять не получится. Отложенный интерес автоматически возвращается в работу через заданный срок.
Появилось то, чего не было: конверсия по базе, по менеджеру, по причинам. Стало видно, что один сегмент базы даёт вдвое больше отклика — и звонить стоит по нему.
Направление второе — рекуррентные сделки. Настроили автоматическое создание сделки на продление по наступлению периода. У клиента в карточке — дата окончания текущего периода; за оговорённое время до неё система сама создаёт сделку, назначает ответственного и ставит задачу.
Забыть теперь можно только сознательно: сделка есть, она на доске, она попадает в отчёт по просрочкам.
Направление третье — отчётность и платежи. Синхронизировали оплаты с 1С: проведённый платёж приходит в CRM и двигает сделку. Google Таблицы заменили BI-отчётами по данным CRM — воронка, обзвон, продления, платежи. Обновляются сами.
Чего это стоило
Около 80 часов и два месяца, но не подряд: между направлениями были паузы, пока команда осваивала предыдущее.
Сложнее всего пошёл обзвон — и не по технической части. Менеджеры сопротивлялись: раньше отметки в таблице были их личным делом, теперь результат каждого звонка виден. Это нормальная реакция, и лечится она не настройками, а разговором о том, зачем это. Помогло то, что вместе с контролем они получили и удобство: не нужно искать, кому звонить, система сама подаёт следующий контакт.
Второе — качество базы. В таблице оказалось много неактуального: закрытые компании, старые номера, дубли. Чистили перед загрузкой, часть отсеялась.
Третье — определение периода для рекуррентных сделок. Выяснилось, что у разных услуг он считается по-разному: где-то от даты оплаты, где-то от даты начала обслуживания. Пришлось разбирать по типам услуг.
Что из этого вынести
Три задачи в одном проекте — обычно плохая идея, но здесь они делились чисто, и это спасло. Если бы делали всё сразу, первый результат появился бы через два месяца. При поэтапном запуске обзвон заработал через три недели, и дальше команда уже видела смысл в остальном.
И про продления. Автоматическое создание сделки по периоду — примитивная механика, дешёвая в настройке. Из всего проекта она принесла больше всего денег просто потому, что закрыла потерю, которую компания годами считала естественным оттоком.