Неподходящая заявка или отказ после обсуждения: как разделить причины
Храните качество заявки и результат её обработки в разных полях. Сначала проверьте соответствие заранее согласованным критериям, затем отдельно запишите, чем закончились переговоры. Подходящий запрос может завершиться отказом, а непроверенный — остаться без ответа. Ниже — дерево решений и примеры, которые помогут одинаково классифицировать такие ситуации в таблице или CRM.
Разделите три решения, которые часто попадают в один статус
Менеджер отправил предложение, клиент выбрал другого исполнителя, и запись получила статус «некачественный лид». На совещании это выглядит как проблема рекламы. Но запрос мог полностью соответствовать услугам компании: обсуждение остановилось уже при выборе подрядчика. Объединённый статус скрывает этот момент.
Первое решение — что за запись поступила: самостоятельное коммерческое обращение, повтор по существующей задаче, тест, спам или сообщение другого типа. Второе — подходит ли задача по принятым критериям. Третье — что происходит с её обработкой и чем она завершилась. У каждого решения своё основание и время.
Для качества достаточно трёх значений: «подходит», «не подходит», «не оценена». Для обработки нужны собственные состояния: уточняем, обсуждаем, готовим предложение, ждём решения, отложено, закрыто. У закрытой записи отдельно укажите результат и причину. Если требуется, факт оплаты храните своим полем.
Единица оценки в этой статье — отдельная задача клиента, по которой возможно самостоятельное решение о заказе. Один человек может обратиться с разными задачами. Два сообщения по одному проекту дополняют общую запись. Постоянный номер связывает переписку, оценку и результат.
В CRM названия полей могут отличаться. Например, HubSpot отдельно описывает этап жизненного цикла контакта и вложенные статусы лида. Предлагаемая ниже схема — рабочая модель для вашей команды; её следует сопоставить с устройством используемой системы, прежде чем менять автоматизации.
Запишите критерии до того, как узнаете результат переговоров
Критерий должен проверяться по доступному факту. «Серьёзный клиент», «приятный разговор» и «скорее всего купит» сотрудники понимают по-разному. Укажите, какое условие обязательно, чем оно подтверждается и что делать, если сведений пока нет.
| Обязательное условие | Подтверждение | Если данных нет |
|---|---|---|
| Задача относится к предлагаемым работам | Нужен корпоративный сайт; ведение соцсетей в этом примере не входит в услуги | Уточнить задачу; оставить оценку открытой |
| Обсуждается конкретный коммерческий проект | Клиент описал бизнес и назначение будущего сайта | Запросить контекст проекта без предположений о намерениях |
| Определён контакт для обсуждения задачи | Получен ответ от человека, участвующего в подготовке проекта | Продолжить согласованный порядок связи |
Это условия учебного примера, а не действующие правила Salestudia или универсальный стандарт. В выбранной модели свободное время команды, окончательное согласование цены и заключение договора учитываются позднее. Студия может оценить задачу как подходящую, даже если сейчас не может взять её в работу.
Если минимальный бюджет, территория или обязательный срок действительно ограничивают вашу услугу, включите их в собственное определение заранее. Запишите границу и способ проверки. Известный бюджет ниже заранее установленного минимума и отказ от конкретной сметы после обсуждения могут означать разные ситуации.
Для необязательных сведений оставьте отдельные поля. Например, неизвестный срок запуска не должен автоматически давать отрицательную оценку, если он не входит в критерии. Сотрудник фиксирует пробел и следующий вопрос, сохраняя различие между отсутствующим фактом и установленным несоответствием.
Присвойте правилам версию и дату начала применения. Укажите ответственного за их смысл. Новый сотрудник должен суметь оценить заявку по документу, а спорный случай — передать человеку, который может уточнить правило.
Пройдите дерево проверки и остановитесь на первом обоснованном решении
Начинайте с типа записи, затем проверяйте обязательные условия. Подтверждённого нарушения одного обязательного критерия достаточно для отрицательного решения. Если нарушения не установлены, но часть обязательных сведений отсутствует, оценка остаётся открытой. Это позволяет не ждать недостающий бюджет по запросу на услугу, которую компания точно не оказывает.
Сначала установите, является ли сообщение самостоятельным коммерческим обращением. Проверенный дубль свяжите с основной записью; тест и спам учтите отдельно. Для сомнительного сообщения назначьте уточнение. Нельзя объявлять письмо спамом только из-за короткого текста или незнакомого имени.
Для коммерческого обращения спросите: есть ли уже подтверждённое несоответствие обязательному условию? Если да, запишите конкретный критерий и факт. Если нет, проверьте полноту остальных обязательных сведений. При полном соответствии поставьте «подходит» и сохраните дату подтверждения; при пробеле — «не оценена» и недостающий вопрос.
Дальнейшее предложение, ожидание, заказ или отказ записывайте в обработку и результат. Возвращайтесь к оценке качества, когда появились новые факты о самой задаче или обнаружена ошибка. Само отсутствие продажи такой проверки не заменяет.
Сравните шесть пограничных случаев
Продолжим пример студии сайтов с критериями Q1. Все обращения, реплики и результаты в таблице вымышлены. Здесь проверяется логика решений; это не статистика Salestudia и не оценка реальных клиентов.
| Случай | Оценка качества | Обработка или результат | Основание |
|---|---|---|---|
| Q-101: клиент просит ежемесячно вести соцсети | Не подходит | Закрыто: услуга вне предложения | Задача известна и нарушает первый критерий |
| Q-102: сайт подходит, после сметы клиент прямо отказался из-за цены | Подходит | Закрыто без заказа: цена | Условия Q1 подтверждены; причина отказа названа клиентом |
| Q-103: задача проверена, после предложения клиент перестал отвечать | Подходит | После завершения попыток связи — закрыто без заказа; мотив неизвестен | Подтверждение качества есть; объяснения отказа нет |
| Q-104: сообщение «нужен сайт», уточнения остались без ответа | Не оценена | После завершения попыток связи — закрыто; связи нет | Обязательные сведения не получены |
| Q-105: подходящий проект, но студия не может выделить команду | Подходит | Отказ компании: нет ресурсов на нужный период | Ограничение возникло на стороне исполнителя |
| Q-106: подходящий проект перенесён на следующий квартал | Подходит | Отложено; назначена согласованная дата контакта | Клиент сообщил о переносе; окончательного отказа нет |
Q-103 и Q-104 особенно легко объединить по признаку «не отвечает». Но в первом случае качество уже проверили, а во втором ещё не собрали факты. Способ завершения обработки может совпасть; история квалификации останется разной.
Для Q-105 полезно зафиксировать, кто прекратил обсуждение: клиент, компания или обе стороны. Иначе отчёт покажет будто рынок приносит неподходящие заявки, хотя реальное ограничение — загрузка команды. Это повод обсуждать сроки и доступную мощность, сохраняя исходную оценку задачи.
Для Q-106 договоритесь о следующем действии и дате пересмотра. Бессрочное «подумает» без подтверждения клиента и ответственного сотрудника не создаёт понятного плана. Отложенные записи стоит просматривать отдельно от окончательно закрытых.
Отделите известную причину от предположения менеджера
Результат «заказ не состоялся» бывает известен, даже когда мотив клиента остаётся неизвестным. В таком случае сохраните оба факта. Удобная догадка о высокой цене не становится подтверждённой причиной только потому, что клиент перестал отвечать после расчёта.
Для причины записывайте основание: сообщение клиента, проверенное ограничение услуги или установленный сбой обработки. Гипотезу сотрудника храните отдельно с соответствующей отметкой. В отчёте по подтверждённым причинам она не должна попадать в одну группу с прямым ответом клиента.
Начните с короткого справочника: задача вне услуг, неподходящая территория, отказ по цене, несогласованный срок, нет ресурсов компании, проект отменён, выбран другой исполнитель, связаться не удалось, причина неизвестна. Это пример набора для обсуждения; лишние и пересекающиеся пункты уберите под свой процесс.
Разделите справочник причин несоответствия и справочник причин завершения обсуждения. Для каждой причины добавьте описание и пограничный пример. В Pipedrive, например, предусмотрены заранее заданные причины проигрыша сделки и дополнительный комментарий. Такая комбинация удобна и в простой таблице: короткий код помогает группировать записи, пояснение сохраняет обстоятельства.
Когда причин несколько, выберите основную по согласованному правилу и сохраните дополнительные отдельно. «Клиент назвал цену основной причиной, а срок — дополнительной» точнее, чем случайный выбор одного слова. Не распределяйте неподтверждённые мотивы принудительно ради заполненности диаграммы.
Сохраняйте решение о качестве при изменении результата
В карточке нужен текущий результат проверки, а в истории — последовательность решений. Записывайте номер заявки, прежнее и новое значение, время, автора, версию критериев и основание. Ссылка на рабочую переписку обычно полезнее переноса личных сведений клиента в ещё одну свободную заметку.
| Дата | Зафиксированное событие | Качество после события | Обработка или результат |
|---|---|---|---|
| 21 сентября | Получен первоначальный запрос | Не оценена | Уточнение задачи |
| 22 сентября | По итогам ответа подтверждены условия Q1 | Подходит; подтверждено 22 сентября | Подготовка предложения |
| 24 сентября | Отправлено предложение | Подходит | Ожидание решения |
| 28 сентября | Клиент сообщил, что цена не подходит | Подходит | Закрыто без заказа; причина — цена |
Если обнаружилась ошибка, исправьте оценку и сохраните объяснение. Например, сотрудник отметил соответствие, перепутав коммерческий запрос с письмом соискателя. История должна показывать ошибочное решение и его исправление. Исправленную ошибку нельзя продолжать считать достоверно пройденной квалификацией только ради сохранения красивого числа.
Изменение самой задачи оформляйте иначе. Клиент сначала обсуждал сайт, затем попросил самостоятельную услугу вне предложения. Уточните, продолжение ли это прежнего проекта или новый запрос; сохраните связь записей. Реальное изменение обстоятельств отличается от того, что первоначальная отметка была неверной.
Проверьте, что выбранный инструмент хранит нужную историю. HubSpot позволяет просматривать прошлые значения свойства, время и источник изменения. Но наличие истории поля не заменяет согласованных правил подсчёта: отчёт ещё должен понимать, какие решения действительны и какие были исправлены.
Показывайте качество и результат разными показателями
Возьмите одну группу заявок по дате первого обращения и укажите, на какую дату смотрите состояние. Не делите заказы от старых переговоров на новые обращения этой недели. Сначала определите состав группы, исключённые тесты и дубли, затем считайте результаты.
Учебный расчёт: за выбранный период поступило 20 самостоятельных коммерческих обращений. На дату отчёта 12 подходят, 5 не подходят, 3 ещё не оценены. Технические записи уже исключены. Доля подтверждённо подходящих среди всех обращений — 12 / 20 = 60%. Среди оценённых — 12 / 17 ≈ 70,6%. У этих показателей разные знаменатели, поэтому названия должны их прямо различать.
Отдельно покажите 3 / 20 = 15% неоценённых обращений. Если их скрыть, высокая доля соответствия среди проверенных может выглядеть как характеристика всей входящей группы. По ещё не проверенным записям этого вывода сделать нельзя.
Из 12 подходящих запросов в примере 3 завершились заказом, 4 закрыты без заказа, 2 отложены и 3 продолжают обсуждаться. Текущая доля заказов среди квалифицированных — 3 / 12 = 25%. Это состояние на дату отчёта: часть группы ещё открыта, окончательный результат неизвестен.
Если четыре проигранных обсуждения задним числом объявить неподходящими, подходящих останется восемь. Тогда доля качества среди всех обращений искусственно снизится до 40%, а доля заказов среди оставшихся подходящих вырастет до 37,5%. Ни реклама, ни работа менеджера от переименования не улучшились. Изменился состав сравниваемых групп.
Исправления фактических ошибок должны попадать в расчёты с пояснением пересмотра. Смена правил оценки требует отдельного обозначения версии. В обоих случаях сохраняйте возможность объяснить, почему число в повторном отчёте отличается от ранее опубликованного.
Меняйте критерии с новой версией и понятной границей
Компания может добавить услугу, изменить территорию работы или минимальный объём заказа. Новые правила полезны для текущих решений, но они не действовали всегда. Запишите дату начала, затронутые критерии и порядок работы с незавершёнными обращениями.
Допустим, студия из примера начала вести соцсети. Заявка Q-101 была неподходящей по прежней версии Q1. При возобновлении обсуждения её можно оценить по Q2 и записать новое решение. В отчёте за первоначальный период должно быть понятно, какие правила применялись тогда.
Если нужен ретроспективный расчёт по Q2, сделайте его отдельным представлением и обозначьте как пересчёт по новым критериям. Для записей без необходимых исторических сведений сохраните неопределённость. Не подставляйте текущие сведения вместо того, что было известно в момент обращения.
До применения новой версии разберите несколько сложных случаев с сотрудниками, которые принимают заявки. Пусть они независимо выберут оценку и основание. Расхождение поможет найти неясную границу: например, что считать самостоятельным новым запросом или достаточным подтверждением бюджета.
Затем проверьте списки значений, обязательные поля и автоматические переходы. Изменение документа с критериями не гарантирует, что CRM перестала ставить старую оценку. Назначьте владельца правила и сохраните примеры согласованных решений рядом с его описанием.
Передавайте в рекламу уже согласованный смысл этапа
Google Ads различает qualified lead — лид, дополнительно квалифицированный вне рекламной системы, — и converted lead — достижение выбранного этапа конверсии. Название второй категории само по себе не означает оплату. Компания должна определить, какое подтверждённое событие стоит за каждым используемым этапом.
Сначала согласуйте оценку в рабочем процессе, затем связывайте её с передачей данных. Иначе одна и та же отметка будет означать у одного сотрудника подходящую задачу, у другого отправленную смету, у третьего состоявшуюся продажу. Технически успешная передача этого противоречия не исправит.
Потеря сделки после корректной квалификации и ошибочная запись о квалификации требуют разных решений. В первом случае появился новый коммерческий результат. Во втором нужно исправлять недостоверные данные и проверять последствия уже выполненной передачи. Конкретный порядок зависит от используемой интеграции.
На Salestudia.de есть отдельное техническое продолжение: как связать подтверждение в CRM с событием и действием-конверсией Google Ads, сохранить время и проверить передачу. Переходите к нему после того, как команда одинаково классифицирует пограничные случаи.
Внедрите правило на небольшой группе обращений
Начните с недавних запросов, по которым сохранилась переписка. Выберите и успешные, и проигранные обсуждения, а также несколько неясных случаев. Цель первого прохода — добиться одинакового решения по одним и тем же фактам.
После первого разбора исправьте неясные определения и назначьте ответственного за спорные записи. Когда правила устойчиво работают в таблице, их проще перенести в CRM и использовать в аналитике. Хороший результат — по каждой записи можно восстановить принятое решение и назначить подходящее действие.
Salestudia помогает связать обращения с сайта, работу с заявками и измерение результата. Начать можно с разбора ваших текущих статусов и нескольких обезличенных пограничных случаев.
- Определите самостоятельную заявку и порядок работы с дублями.
- Согласуйте обязательные критерии, подтверждения и версию правил.
- Разделите качество, обработку, результат и причину завершения.
- Для неопределённой оценки укажите недостающий факт и следующий шаг.
- Разберите расхождения между сотрудниками на конкретных примерах.
- Проверьте, что отказ не стирает подтверждённую квалификацию, а ошибка корректно исправляется.
- В отчёте покажите неоценённые обращения, состав группы и дату состояния.
Официальные и профильные ссылки
Эти материалы дают контекст для данных, правил и рекомендаций на странице.
- HubSpot — Use contact and company lifecycle stages Источник проверен: 03.10.2026
- Pipedrive — Lost reasons Источник проверен: 03.10.2026
- HubSpot — View a record’s property history Источник проверен: 03.10.2026
- Google Ads — About qualified leads and converted leads Источник проверен: 03.10.2026
Удобнее написать напрямую?
Коротко укажите компанию, рынок и задачу — так разговор будет предметнее.