Лид ответил. Что дальше? Как не потерять интерес до продажи
Разбираю, как передать разговор менеджеру, сохранить обещания и согласовать следующий шаг. Условный пример переписки, карточка обращения и проверка зависших разговоров.
Представим: человек ответил на письмо, описал проблему и попросил показать, как её можно решить. Аутрич сработал. В CRM появилась запись, менеджеру отправили уведомление. Дальше разговор завис: один сотрудник считает, что передал лида, другой собирается разобраться позже, а потенциальный клиент ждёт обещанный пример.
Для меня именно здесь начинается проверка качества всей системы. Мало получить содержательный ответ. Нужно продолжить разговор так, чтобы человеку не пришлось заново объяснять свою задачу и напоминать о наших обещаниях.
В статье об AI-аутриче я разбирал путь от базы контактов к подтверждённому интересу. Теперь — следующий участок: что я предлагаю настроить между ответом лида и работой менеджера по продаже.
1. Сначала я разбираюсь, на что именно человек ответил
Фраза «пришлите информацию» может означать разное. Человеку нужен ответ на конкретный вопрос, материал для коллеги или просто возможность посмотреть предложение позже. Я сохраняю исходное сообщение и связываю его с тем письмом, на которое оно пришло.
Дальше полезно разделить три вещи: что человек сообщил, что мы предполагаем и чего пока не знаем. «У нас теряются заявки между сменами» — описание проблемы. «Готов внедрять систему в этом месяце» — уже предположение, если такого в переписке нет.
Первый ответ менеджера должен продолжать начатый разговор. Если попросили пример, я бы отправил подходящий пример. Если спросили о стоимости, объяснил бы, от чего она зависит и каких данных не хватает для оценки. Универсальная презентация и предложение сразу созвониться подходят далеко не к каждому вопросу.
При этом не стоит превращать ответ в анкету. На этом этапе мне важнее уточнить то, без чего нельзя сделать ближайший полезный шаг. Остальные вопросы могут подождать.
2. У разговора должен появиться конкретный ответственный
«Отправили в продажи» — слишком расплывчатая формулировка. Я хочу видеть сотрудника, который принял разговор и понимает, что должен сделать дальше.
Моё рабочее правило: до подтверждения приёмки за обращение отвечает тот, кто его передаёт. Если получатель недоступен, заранее нужен понятный маршрут к замещающему сотруднику. Иначе запись может числиться за менеджером, который даже не видел уведомление.
Вместе с обращением я передаю короткую сводку:
- что человек написал и где лежит исходная переписка;
- какую задачу обсуждаем и в какой роли участвует собеседник, если это известно;
- что мы уже пообещали и к какому сроку;
- какие вопросы остались открытыми;
- кто продолжает разговор и какое действие берёт на себя.
Сводка помогает быстро войти в тему, а ссылка на переписку позволяет проверить детали. Копировать во все системы весь разговор и лишние персональные сведения для этого не требуется.
Такой порядок можно поддержать обычными задачами в CRM. Например, в документации HubSpot у задачи предусмотрены ответственный, срок, заметки и связь с контактом, компанией или сделкой. Для меня важно, чтобы команда использовала эти поля по договорённым правилам. Само их наличие ничего не гарантирует.
3. Я отличаю внутреннюю задачу от договорённости с клиентом
Менеджер поставил себе напоминание позвонить в четверг. Это внутренний план. Клиент подтвердил звонок в четверг в определённое время — это договорённость. В карточке обращения эти состояния должны различаться.
То же относится к встречам: предложена, подтверждена, состоялась. Отправленное приглашение ещё не означает, что человек согласился участвовать.
Я стараюсь формулировать следующий шаг так, чтобы было понятно:
- что произойдёт и какую задачу это поможет решить;
- кто выполняет действие;
- когда оно должно произойти, с датой и часовым поясом при необходимости;
- что уже подтверждено второй стороной.
После содержательного разговора полезно отправить короткое резюме: что поняли, что осталось уточнить и о чём договорились. Такой приём описан и в материале Salesforce о процессе продаж. Своё практическое правило я формулирую просто: клиент должен иметь возможность поправить наше понимание до того, как мы начнём готовить решение.
4. Как это может выглядеть в переписке
Разберём условный пример — это учебная ситуация, а не история клиента или результат внедрения.
Представитель сервисной компании отвечает на письмо: «У нас обращения теряются при передаче между диспетчерами. Покажите, как можно видеть, кто принял заявку».
Здесь уже есть конкретный вопрос. Вариант ответа менеджера:
«Поняла: важно видеть, кто принял заявку при смене диспетчера. Подготовлю короткую схему передачи с ответственным и сроком. Подскажите, где сейчас фиксируются заявки — в CRM, таблице или переписке? Это поможет показать вариант ближе к вашей работе».
Допустим, собеседник ответил, что заявки ведут в таблице, и согласился получить схему до следующего дня. После приёмки менеджером карточка может выглядеть так:
- Запрос: видеть приёмку заявки при смене диспетчера. Исходное сообщение доступно по внутренней ссылке.
- Подтверждено: заявки ведут в таблице; собеседник согласился посмотреть схему.
- Пока неизвестно: объём обращений, полномочия собеседника, бюджет и срок возможного внедрения.
- Ответственная: Анна, менеджер; приёмка обращения подтверждена.
- Обещание: отправить схему до 20 октября 2026 года, 15:00 МСК. Дата в этом примере условная.
- Ближайшее действие: подготовить и отправить схему передачи заявки. Встреча пока не согласована.
Такая запись позволяет продолжить работу без догадок. После отправки схемы менеджер фиксирует выполненное обещание и предлагает обсудить вопросы. Подтверждённую встречу отмечает только после ответа собеседника.
Здесь нет гарантии продажи. Человек может понять, что решение ему не подходит, отложить задачу или отказаться. Но команда сможет отличить такой исход от ситуации, когда обещанный материал просто забыли отправить.
5. Где я подключаю AI и автоматизацию
В таком процессе AI полезен там, где нужно быстро разобрать текст: подготовить сводку переписки, выделить вопрос клиента, найти обещание или предложить черновик ответа. Рядом с выводом должна оставаться ссылка на исходное сообщение, чтобы сотрудник мог его проверить.
Проверку пустого поля «ответственный», просроченного срока или отсутствия задачи я обычно начал бы с простого правила. Для этого не обязательно привлекать языковую модель.
До отправки ответа человек проверяет смысл и обязательства: действительно ли мы можем назвать такую цену, подготовить материал к этому сроку или предложить нужную интеграцию. Предположение AI о бюджете не должно превращаться в подтверждённое поле CRM.
Полномочия помощника я бы расширял отдельно, после проверки конкретного сценария. Важно заранее определить, что он может записывать самостоятельно и когда обязан передать решение человеку. Этот принцип подробнее разобран в статье о границах AI-агента.
6. Как я замечаю зависшие разговоры
Для регулярного разбора мне полезнее короткий список обращений, требующих действия, чем общее количество открытых карточек.
| Что видно в карточке | Что нужно проверить или сделать |
|---|---|
| Ответственный назначен, приёмка не подтверждена | Уточнить, кто реально продолжит разговор; при необходимости передать заместителю. |
| Срок обещанного действия прошёл | Проверить исполнение. Если обещание нарушено — сообщить об этом и согласовать новый срок. |
| Переписка идёт, следующего шага нет | Выяснить, какого ответа или решения не хватает для движения дальше. |
| Встреча отмечена, подтверждения клиента нет | Уточнить статус и не учитывать её как согласованную или состоявшуюся. |
| Карточка давно открыта без новых сведений | Разобраться: пауза, отказ, отсутствие ответа или забытая задача; зафиксировать основание. |
Напоминания тоже должны учитывать контекст. Если человек попросил вернуться к вопросу в следующем месяце, ежедневная цепочка писем нарушает договорённость. Если отказался от дальнейшего общения, автоматическое продолжение нужно остановить.
При молчании я бы начал с проверки собственного обещания: отправили ли нужный материал, ответили ли на вопрос, понятен ли предложенный шаг. После этого — уместное короткое напоминание. Число попыток и момент остановки команда определяет заранее с учётом канала и ситуации. Бесконечная цепочка «напоминаю о себе» не заменяет причину продолжать разговор.
7. Что я предлагаю измерять
Я бы смотрел на время до первого содержательного ответа, долю обращений с принятым ответственным и число просроченных обещаний. Автоответ «ваше сообщение получено» полезен как подтверждение доставки, но в скорость содержательного ответа я его не включаю.
Для долей нужно явно задавать знаменатель. Например: из всех обращений, переданных в продажи за неделю, сколько принято ответственным на момент проверки. Для сравнения недель стоит давать обращениям одинаковое время на обработку. Свежая запись и разговор месячной давности находятся в разных условиях.
Норматив реакции я предлагаю выбирать под команду, канал и рабочие часы. Универсальное обещание отвечать за несколько минут бессмысленно, если выполнять его некому. Лучше договориться о выполнимом сроке и видеть нарушения.
Следующий шаг — разбирать причины остановки: задача не подходит, решение отложено, нет ответа, не выполнено наше обещание. Эти причины требуют разных действий. По одному числу закрытых карточек их не увидеть.
Для меня хорошо организованная работа после ответа выглядит так: человек получает ответ по существу, менеджер принимает контекст, договорённости фиксируются, а зависший разговор становится заметен. Начать можно с небольшой выборки свежих обращений и трёх вопросов: кто продолжает разговор, что мы уже обещали и какой следующий шаг подтверждён? Если на них трудно ответить, это и есть первый участок для настройки.