Привет. Я у себя в мастерской давно заметил одну вещь: заявка чаще теряется не на этапе продажи, а в первые минуты после контакта. Человек написал, интерес есть, а дальше начинается суета — данные кусками, карточка пустая, менеджер занят, кто отвечает первым непонятно. Поэтому я люблю схему, где ассистент встречает лид, быстро проверяет базу, задаёт несколько нормальных вопросов, собирает контекст и уже потом кидает менеджеру задачу с готовой картинкой. В этой статье покажу, как это собрать, какие вопросы реально работают, где ставить правила эскалации и что именно должно прилетать менеджеру, чтобы он не копался в чате, а сразу шёл в разговор.
Что получаем на выходе: меньше пустых диалогов, выше скорость реакции на заявку, чище карточки в CRM и меньше ручной рутины на первом касании.
- Зачем вообще эта схема нужна
- Как схема работает по шагам
- Какие вопросы задаёт ассистент
- Когда надо сразу подключать менеджера
- Что писать в задаче менеджеру
- Частые косяки и как я их чиню
- Что в итоге внедрять первым
Зачем вообще эта схема нужна
Смысл тут простой: ассистент не играет в великого продавца, а делает первую полезную работу. Он проверяет, не дубль ли это, хватает ли контактов, понятен ли запрос, есть ли срочность, кто будет общаться дальше и на каком этапе человек сейчас. Это и есть нормальная квалификация лида. Когда входящих заявок уже больше десятка в день, такая штука снимает с менеджера самую рваную часть дня: бесконечные “здравствуйте, уточните, а что именно вам нужно?”.
Мне эта логика нравится ещё и тем, что она хорошо дружит с живым бизнесом. Неважно, прилетел лид с сайта, из формы, из мессенджера или из чат-бота — схема одинаковая: поймали обращение, собрали минимум фактов, оценили приоритет, завели карточку, поставили задачу, зафиксировали следующий шаг. Если хотите посмотреть, как такие штуки собираются в систему шире, рядом по смыслу лежат готовые схемы автоматизации и материал про системную работу с потоком заявок.
Главная мысль: ассистент нужен не ради вау-эффекта, а ради скорости, структуры и понятного следующего действия.
Как схема работает по шагам
Я обычно собираю этот сценарий как конвейер из шести этапов. Ничего космического тут нет, но именно связка шагов даёт результат.
Шаг 1. Поймать лид и привести данные к нормальному виду
Первое, что делаем, — забираем обращение из формы, чата, Telegram-бота или CRM и нормализуем поля. Имя, телефон, почта, источник, текст запроса, время обращения, канал связи. На этом же этапе полезно сразу смотреть дубли: тот же номер, та же почта, тот же username, похожий текст заявки. Я много раз видел, как команда радуется “росту лидов”, а потом выясняется, что треть потока — это повторы и догоняющие сообщения. На эту тему у меня всегда рядом лежит проверка на повторы; если хотите глубже копнуть, полезен разбор про дубли заявок в автоматизации.
Шаг 2. Проверить, что запрос вообще живой
Тут ассистент делает быструю первичную фильтрацию. Есть ли контакт? Похоже ли сообщение на реальный интерес? Нет ли там пустого “алло” или набора случайных символов? Уже на этом уровне можно отрезать мусор, тестовые отправки и половину хаоса, который потом забирает время у отдела продаж.
Шаг 3. Задать 3–7 уточняющих вопросов
Вот тут многие ломают механику: либо ассистент задаёт один вопрос и толку ноль, либо устраивает собеседование на полчаса. Я держу правило — только минимальный набор, который реально влияет на следующий шаг. Хорошая автоматизация обработки лидов строится на коротком маршруте: узнать задачу, понять срочность, оценить объём, собрать контакт и не потерять контекст. Если вопрос не помогает выбрать менеджера, приоритет или формат следующего касания, выкидываем его.
Шаг 4. Оценить лид по правилам и смыслу
Сейчас лучше всего работают гибридные схемы. Часть логики жёсткая: заполнен телефон, есть имя, понятен канал, нет дубля, попадает в нужную услугу, укладывается в ваш минимальный чек. А часть логики оценивает ассистент: насколько конкретно человек описал задачу, есть ли признаки горячего интереса, просит ли он расчёт, демонстрацию, созвон или старт работ. Такая связка обычно даёт куда более ровный результат, чем голая нейросеть или одни только правила.
Шаг 5. Поставить задачу менеджеру
Когда лид прошёл проверку, ассистент создаёт задачу в CRM или таск-менеджере. И вот здесь я всегда ворчу: задача должна быть не “Новый лид, свяжитесь”, а нормальная карточка действия. Кто клиент, что хочет, что уже ответил, какой приоритет, какой канал предпочитает, что обещано в следующем касании. Если поток идёт из мессенджера, рядом хорошо ложится автоматическая обработка заявок из Telegram, а если менеджеру нужен вариант сообщения под рукой — полезен сценарий с черновиками ответа в Telegram-боте.
Шаг 6. Зафиксировать контрольную точку
После постановки задачи схема не должна растворяться в воздухе. Я люблю ставить таймер контроля: если менеджер не взял задачу в работу за N минут, система напоминает, повышает приоритет или кидает уведомление старшему. А если в диалоге есть высокий чек, мутная формулировка или риск неверной интерпретации, лучше включать контроль человека. Для этого рядом по смыслу очень подходит материал про ручную проверку ответов ИИ.
Промежуточный вывод: схема работает не потому, что “умная”, а потому что каждый шаг готовит следующий.
Какие вопросы задаёт ассистент
Теперь к самому вкусному. Какие уточняющие вопросы клиенту стоит давать ассистенту? Я собираю их по слоям. Не надо задавать всё подряд каждому лиду. Пусть ассистент идёт ветками: задал один вопрос, понял ответ, выбрал следующий.
Базовый слой
- Что именно хотите получить? Тут вынимаем саму задачу, а не общий шум.
- Для себя или для компании? Помогает понять контекст и формат разговора.
- Когда хотите стартовать? Срок — это быстрый индикатор температуры лида.
- Как с вами удобнее связаться? Чат, звонок, почта — менеджеру потом легче не промахнуться.
Квалифицирующий слой
- Какой объём задачи или проекта? Нужен хотя бы порядок цифр.
- Что для вас сейчас самое важное при выборе? Цена, скорость, надёжность, сопровождение, кастомизация.
- Что уже пробовали или с кем общались раньше? Тут часто вылезает реальная боль клиента и ожидания от нового подрядчика.
- Кто будет принимать итоговое решение? Не для давления, а чтобы менеджер входил в разговор уже понимая, кто принимает решение.
Слой на горячий интерес
- Нужен расчёт, пример решения или короткий созвон? Это уже почти следующий шаг.
- Есть ли дедлайн или дата, к которой всё должно работать? Приоритет сразу становится понятнее.
- Нужно ли подготовить предложение на конкретный объём? Если да — менеджер заходит в диалог уже собранным.
Ключевой момент тут такой: ассистент не должен лезть в допрос. Его задача — собрать минимум, который ускоряет менеджера. Для одних ниш хватит трёх вопросов, для других нужно шесть или семь. Я обычно начинаю с короткой версии, смотрю, где у команды потом не хватает данных, и только после этого докручиваю ветки.
Нормальный ориентир: если после ответов менеджер понимает, кому звонить, зачем звонить и с чего начинать разговор, значит вопросы собраны правильно.
Когда надо сразу подключать менеджера
Есть миф, что ассистент должен довести диалог чуть ли не до счёта. На практике это редко нужно. Я предпочитаю рано отдавать лида человеку, если вижу хотя бы один из этих сигналов:
- Высокий чек или нестандартная конфигурация. Тут важнее гибкость, чем автоматический скрипт.
- Лид уже просит коммерческое предложение, расчёт или демонстрацию. Значит интерес конкретный, тянуть не надо.
- Человек раздражён, пишет рвано или явно ждёт живого контакта. Ассистент тут только собирает факты и передаёт диалог дальше.
- Вопрос упирается в нюансы услуги. Менеджер или эксперт быстрее снимет сомнения.
- Есть несколько участников со стороны клиента. Значит нужен человек, который удержит контекст встречи.
У меня правило простое: чем выше риск потери сделки из-за лишнего круга переписки, тем раньше должен включаться менеджер. Ассистенту не надо геройствовать.
Что писать в задаче менеджеру
Вот тут кроется половина успеха. Хорошая постановка задачи менеджеру — это уже почти готовый старт разговора. Я обычно зашиваю в задачу такой набор полей:
- Кто обратился: имя, контакт, канал, источник.
- Что хочет: короткая выжимка запроса в одну-две строки.
- Что уже выяснил ассистент: сроки, объём, ключевой критерий выбора, формат связи.
- Оценка лида: горячий, тёплый, на уточнение, сомнительный.
- Почему стоит брать в работу сейчас: дедлайн, интерес к расчёту, запрос на созвон, повторное обращение.
- Что сделать следующим шагом: написать в чат, позвонить, отправить бриф, согласовать встречу.
- Срок реакции: например, взять в работу за 15 минут.
Отдельно советую добавлять короткий саммари блока “что уже было в диалоге”. Менеджер не должен читать двадцать сообщений, чтобы понять, о чём речь. Одного абзаца обычно хватает: кто человек, что ему нужно, почему обратился сейчас и какое действие логично следующим.
Если у вас рядом работает сценарий с автоматическим формированием предложений, классно стыкуется и автоформирование КП из шаблона. Тогда менеджер получает уже не пустой лид, а почти готовую основу для ответа.
Частые косяки и как я их чиню
Я таких схем насобирал уже прилично, и косяки там повторяются как под копирку.
Косяк 1. Ассистент задаёт слишком много вопросов
Лечится жёстко: оставляем только те вопросы, которые реально влияют на маршрут лида. Всё остальное — в корзину или на этап после первого контакта менеджера.
Косяк 2. Нет правил на дубли
В итоге один и тот же человек создаёт две-три карточки, а менеджеры начинают бегать друг за другом. Лечится дедупликацией по телефону, почте, username и временной близости сообщений.
Косяк 3. Задача ставится, но в ней пусто
Это классика. Формально автоматизация есть, по факту менеджер всё равно делает первичную квалификацию вручную. Лечится шаблоном задачи и обязательными полями.
Косяк 4. Ассистент слишком рано обещает лишнее
Я всегда ограничиваю его роль: собрать вводные, подтвердить следующий шаг, передать человеку. Оценки по срокам, цене и составу работ — только там, где у вас это правда можно давать автоматически.
Косяк 5. Нет обратной связи от менеджеров
Схему надо докручивать по живым сделкам. Раз в неделю смотрим, где не хватило контекста, какие ответы лидов оказались пустыми, какие ветки тормозят диалог, и правим логику. Иначе сценарий быстро превращается в красивую, но глухую коробку.
Мой рабочий подход: сначала запуск на коротком маршруте, потом донастройка по фактическим разговорам, а не по фантазиям в блокноте.
Что в итоге внедрять первым
Если делать по-умному, начните не с огромной махины, а с базового сценария. Поймать лид, проверить контакт, задать три ключевых вопроса, создать карточку, поставить задачу менеджеру, напомнить о сроке реакции. Уже на этом уровне автоматизация входящих заявок начинает экономить время и снижать потери на старте.
Дальше уже наращиваете мясо: оценку приоритета, ветвление по услуге, проверку дублей, саммари диалога, черновик ответа, контроль человека на спорных кейсах. Так схема остаётся живой, а не бетонной.
Я бы сформулировал итог так: ассистент проверяет лид не ради модной вывески, а ради того, чтобы менеджер включался в разговор уже с нормальным контекстом. Когда в задаче есть суть запроса, сроки, формат связи и следующий шаг, конвейер начинает ехать ровно. А когда этого нет, команда снова живёт в режиме “кто вообще должен этим заняться?”.
Так что если хотите собрать рабочую схему, начинайте с простого маршрута: лид → проверка → уточняющие вопросы → оценка → задача менеджеру → контроль реакции. Это тот случай, когда даже маленькая автоматизация очень быстро ощущается руками.