Активные продажи: 1000 страниц практического опыта

Именно поэтому одной из обязательных граф в нашей таблице была ЦКГ — целевая клиентская группа.

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

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

Иван — телефон.

Сергей — телефон.

Андрей — телефон.

Владимир — телефон.

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

Поэтому хорошая клиентская база должна сохранять не только контактные данные, но и контекст.

Графа ЦКГ решает первую часть этой задачи. Увидев напротив имени слово «собственник», «прораб», «смежник», «архитектор» или «застройщик», менеджер сразу понимает, в каком качестве познакомился с человеком и какую потенциальную роль тот играет в системе продаж.

Это важно потому, что с разными группами мы работаем совершенно по-разному.

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

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

При этом ЦКГ ни в коем случае не заменяет историю работы с человеком.

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

Всё это должно находиться в истории общения, к которой мы ещё вернёмся отдельно.

ЦКГ отвечает на более простой вопрос:

«Кто этот человек для нашей системы продаж?»

И этого уже достаточно, чтобы значительно быстрее ориентироваться в большой базе.

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

Если менеджер после каждого разговора тратит десять минут на заполнение карточки из пятидесяти параметров, возникает разумный вопрос: система помогает ему продавать или он уже работает на систему?

У нас подход был значительно проще.

Нужно понимать, кто этот человек.

Нужно знать, что происходило в отношениях с ним.

Нужно понимать, когда и зачем необходимо связаться снова.

Для организации огромной части ежедневной работы этого уже достаточно.

Поэтому сама ЦКГ не является рейтингом клиента. Это особенно важно не путать.

Нельзя сказать:

«Собственник — категория номер один, прораб — номер два, смежник — номер три».

Это не уровни ценности, а разные типы контактов с разной логикой работы.

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

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

Поэтому категория клиента и его текущий приоритет — две разные вещи.

ЦКГ показывает, кто перед нами.

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

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

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

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

«Сергей — телефон».

«Андрей — телефон».

«Владимир — телефон».

И дальше приходится звонить человеку примерно так:

— Здравствуйте. Вы почему-то есть у нас в базе. Напомните, пожалуйста, кто вы?

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

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

Именно поэтому клиентскую базу я никогда не воспринимал как личную телефонную книжку продавца.

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

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

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

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

Кто этот человек?

Какую роль он играет в нашей системе продаж?

Что между нами уже происходило?

Что необходимо сделать дальше?

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

Именно с него начиналась ежедневная работа менеджера с сотнями, а со временем и тысячами контактов.

7.2. План следующего звонка — основа работы с базой

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

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

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

Допустим, сегодня 10 марта. Клиент говорит:

— Ворота мне понадобятся примерно через три месяца.

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

С этого момента не нужно каждую неделю открывать его строку и размышлять:

«Может быть, уже пора позвонить?»

Мы договорились с человеком о следующем контакте. Наступит нужная дата — база сама вернёт его менеджеру.

Другой клиент говорит:

— Давайте весной. Сейчас я этим заниматься не буду.

Само слово «весной» слишком неопределённое, поэтому желательно немного уточнить:

— Хорошо. А когда примерно лучше вернуться к этому вопросу — в марте, апреле?

Если клиент отвечает, что ориентировочно в апреле, менеджер фиксирует это и ставит соответствующий план.

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

Дальше работает сортировка.

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

База сама формировала значительную часть текущей работы.

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

Получалась очень простая последовательность:

позвонил → поговорил → записал результат → договорился о следующем действии → поставил новую дату.

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

Так клиент мог находиться в базе месяцами и даже годами, не теряясь из активной работы.

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

— Ворота буду ставить через два месяца.

Через два месяца менеджер звонит:

— Как у вас дела? Мы договаривались вернуться к вопросу ворот.

А клиент отвечает:

— Слушай, мы задержались с фасадом. Давай ещё через два месяца.

В этом нет ничего необычного. Не нужно возмущаться:

— Но вы же обещали два месяца назад!

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

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

Представим две записи.

Первая:

«Клиент думает».

Вторая:

«Заканчивают забор. После установки столбов нужно вернуться к вопросу откатных ворот. Договорились созвониться 15 мая».

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

Вторая запись отвечает на эти вопросы значительно лучше. Наступает 15 мая, клиент появляется в работе, менеджер читает предыдущий комментарий и понимает причину звонка.

Поэтому следующий контакт нельзя назначать случайно.

Плохой вариант выглядит так:

— Хорошо, я вам как-нибудь позвоню.

Менеджер кладёт трубку и самостоятельно решает:

«Поставлю через месяц».

Почему именно через месяц?

Непонятно.

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

Например:

— Когда вы примерно планируете вернуться к вопросу ворот?

— Думаю, месяца через два.

— Хорошо, давайте тогда я примерно через два месяца сам вам позвоню.

Теперь у следующего звонка появилась причина.

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

— Александр, добрый день. Мы с вами разговаривали по воротам. Вы тогда сказали, что сначала хотите закончить забор и после этого вернуться к этому вопросу. Как сейчас продвигается строительство?

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

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

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

И здесь принципиально важно слово «действительно».

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

Позвонил и поговорил — фиксируем новый состоявшийся контакт.

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

База должна отражать реальность, а не создавать красивую статистику активности.

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

Например, клиент купил гаражные ворота, но говорит:

— Через несколько месяцев хочу заняться роллетами.

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

В нужный момент база снова поднимет его в работу.

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

Точно так же поступали с человеком, которому по какой-либо причине больше не требовалось звонить.

Но мы не удаляли его из базы.

Это принципиальное различие.

«Сейчас не нужно звонить» не означает «этого человека больше не существует».

Через несколько лет он может снова обратиться в компанию. Может начать строить другой объект. Его контакт может повторно прийти от прораба или смежника. Другой менеджер может встретить его на новой стройке. И тогда значительно полезнее увидеть старую историю отношений, чем создать новую запись так, будто компания никогда раньше с этим человеком не общалась.

Поэтому после сортировки неактуальные для текущей работы контакты просто уходили вниз.

Наверху находилась сегодняшняя работа.

Внизу сохранялась история отношений.

Благодаря этому одна и та же база одновременно выполняла две функции: сохраняла накопленную компанией информацию и формировала текущие действия менеджера.

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

У нас принцип был значительно проще:

отсортируй таблицу по плану следующего звонка и начинай сверху.

Отработал контакт — зафиксируй результат и поставь следующую дату.

Переходи к следующему.

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

Именно здесь дисциплина становится критически важной.

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

В результате ценная информация снова оказывается только в памяти.

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

В этот момент база постепенно превращается в хаос.

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

Отсортируй по плану звонка.

Начинай сверху.

Поговорил — зафиксируй результат.

Поставь следующую дату.

Иди дальше.

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

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

Для этого существует клиентская база.

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

Поэтому план следующего звонка для меня был не одной из многочисленных граф Excel. Фактически это был механизм, который превращал огромный список контактов в ежедневный рабочий инструмент.

Но одной даты недостаточно.

Можно утром открыть таблицу и увидеть:

«Сегодня позвонить Владимиру».

И совершенно не понимать, кто такой Владимир, что происходило раньше и зачем именно сегодня ему звонить.

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

Именно о ней пойдёт речь дальше.

7.3. История клиента: почему комментарии важнее формального статуса

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

У нас отдельной графы со статусом сделки не было, и это было осознанным решением.

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

Но как определить статус прораба, с которым компания работает несколько лет?

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

Какой у него статус?

«Переговоры»?

«Сделка»?

«Договор»?

«Закрыт»?

Ни один из этих вариантов нормально не описывает отношения с человеком.

То же самое происходит со смежниками, архитекторами и другими профессиональными контактами. Сегодня у человека может вообще не быть объекта, на котором требуется наша продукция, но это совершенно не означает, что отношения закончились. Через несколько месяцев он начнёт работать на новом доме, встретится с подходящим собственником и снова станет источником потенциального клиента.

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

Что сказал клиент?

Какая продукция его интересует?

Что уже обсуждали?

Что изменилось после предыдущего разговора?

Какие договорённости достигнуты?

Почему решили связаться снова именно в определённый момент?

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

В результате менеджер видел не одно слово, а реальную ситуацию.

Сравним две записи.

Первая:

«Статус: думает».

Вторая:

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

Через два месяца вторая запись будет несравнимо полезнее.

Слово «думает» почти ничего не объясняет. О чём человек думает? Почему пока не принимает решение? Что должно произойти до следующего разговора? Когда имеет смысл ему позвонить? Что менеджеру говорить во время этого звонка?

Нормальный комментарий восстанавливает контекст практически за несколько секунд.

Именно поэтому хорошая клиентская база должна в значительной степени заменять память менеджера.

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

Но через неделю появятся ещё десятки разговоров, через месяц — новые клиенты и объекты, а через несколько лет количество накопленных контактов может измеряться тысячами. Подробности неизбежно начинают смешиваться.

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

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

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

Причём фиксировать полезно не только сведения, непосредственно относящиеся к покупке.

Например, человек говорит:

— Я сейчас заболел, давайте вернёмся к этому позже.

Или:

— Уезжаю в отпуск на две недели. Позвоните после возвращения.

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

Когда через несколько недель менеджер звонит и спрашивает:

— Как себя чувствуете, уже выздоровели?

или:

— Как съездили в отпуск?

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

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

Другой важный элемент истории — источник контакта.

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

«Владимир от 104».

Это означало, что Владимир появился благодаря клиенту с соответствующим уникальным номером в базе.

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