Следующий шаг в amoCRM: как контролировать сделки без задач и просрочек

Откройте свою воронку продаж прямо сейчас. Посмотрите на сделки, которые висят больше недели. Сколько из них имеют конкретную задачу с датой? У скольких есть понятный следующий шаг — не «ждём ответа», а действие: позвонить, отправить, встретиться?

В большинстве отделов продаж заметная часть сделок в воронке не имеет следующего шага. Карточки заведены, статусы расставлены, суммы посчитаны. Но по самим сделкам не видно главного: что должно произойти дальше, кто за это отвечает и когда. Менеджеры говорят «клиент думает». Руководитель смотрит на воронку и не может отличить живую сделку от мёртвой.

Эта статья — про то, как выстроить в amoCRM правило, при котором активная сделка не живёт без следующего шага: без действия, срока и ответственного. Разберём, как выглядит проблема, как её быстро проверить в своей воронке и какие настройки помогают закрепить правило в ежедневной работе.

Следующий шаг в amoCRM — это конкретное действие по сделке с датой и ответственным: позвонить, отправить КП, уточнить решение, назначить встречу, согласовать условия.

Чтобы правило работало, в CRM должны быть:

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

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

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

Сделка без задачи — это сделка без будущего действия. Формально она находится в воронке, у неё есть этап, сумма и ответственный. Но никто не обязан ничего сделать по ней в конкретный день и время. Менеджер может считать её «в работе», хотя фактически по ней ничего не запланировано.

Для руководителя это означает три вещи.

Во-первых, сумма в воронке перестаёт отражать реальность. Руководитель видит «5 миллионов на этапе переговоров», но не видит, что половина этих сделок не двигалась две недели и по ним нет ни одного запланированного действия.

Во-вторых, искажается прогноз продаж. План на месяц кажется выполнимым, пока воронка раздута сделками, которые давно остыли. Правда вскрывается в конце месяца, когда что-то менять уже поздно.

В-третьих, сделка может неделями висеть под фразой «клиент думает» — и никто не заметит момент, когда клиент уже всё решил. Не в вашу пользу.

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

• после звонка не назначен следующий контакт — менеджер вернётся к клиенту, «когда вспомнит»;
• после отправки КП нет follow-up — клиент остаётся один на один с предложением;
• клиент остывает, потому что пауза затянулась;
• менеджер переключается на новые заявки — они горячее и проще;
• руководитель узнаёт о проблеме, когда сделка уже потеряна.

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

«Клиент думает» — это не следующий шаг. Это отсутствие управленческого действия.

Клиент действительно может думать: сравнивать предложения, согласовывать бюджет, ждать решения руководства. Это нормально. Ненормально другое — когда вместе с клиентом «думает» и менеджер: не назначил дату следующего контакта, не уточнил, когда будет решение, не запланировал напоминание.

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

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

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

У следующего шага всегда есть три элемента:

1. Действие — что именно нужно сделать.
2. Дата или срок — когда это должно произойти.
3. Ответственный — кто это сделает.

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

В amoCRM носителем следующего шага является задача по сделке: у неё есть тип действия, срок и исполнитель. Поэтому контроль следующего шага на практике — это контроль задач: их наличия, осмысленности и выполнения в срок.

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

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

Собственники часто объясняют зависшие сделки людьми: «менеджеры ленивые», «не дожимают», «нет мотивации». Иногда это правда. Но чаще проблема в том, что в процессе нет правила — и тогда зависать будут сделки даже у добросовестных менеджеров.

Как это выглядит без правила следующего шага:

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

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

Проверка занимает 15–20 минут и не требует аналитика.

1. Откройте активную воронку продаж.
2. Отфильтруйте сделки старше 7 дней.
3. Проверьте, есть ли у каждой такой сделки активная задача.
4. Посмотрите, есть ли у задачи будущая дата.
5. Откройте просроченные задачи.
6. Пройдитесь по этапам «КП отправлено», «Переговоры», «Согласование», «Думает» — там обычно скапливаются зависшие сделки.
7. Посчитайте долю сделок без будущего действия — хотя бы примерно.
8. Отдельно посмотрите задачи, которые переносились несколько раз: формально они есть, фактически сделка стоит.
9. Откройте 10 случайных сделок и проверьте: понятно ли по каждой, что будет дальше.

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

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

Как это выглядит в логике воронки:

• новая заявка → связаться сегодня;
• КП отправлено → проконтролировать решение через 2 дня;
• встреча проведена → зафиксировать следующий шаг;
• согласование → уточнить статус до конкретной даты.

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

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

Какие поля чаще всего имеют смысл:

• источник заявки;
• услуга или направление;
• дата следующего контакта;
• результат контакта;
• причина отказа;
• сумма;
• ЛПР или контактное лицо, если в сделке участвует несколько людей.

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

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

Что контролировать:

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

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

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

Возможные варианты реализации:

• фильтр по сделкам без задач в списке сделок;
• дашборд с отдельным показателем;
• регулярный отчёт руководителю;
• уведомление РОПу при появлении таких сделок;
• отдельный список контроля, который разбирается на планёрке.

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

Настройки сами по себе правило не создают — его создаёт договорённость, которую настройки поддерживают.

У сделки в этой логике нет состояния «просто полежит». Есть три выхода: действие, закрытие или разбор. Когда команда принимает это правило, а руководитель регулярно по нему сверяется, воронка перестаёт накапливать балласт.

Контроль следующего шага — это не настройки ради настроек, а конкретная картина, которую руководитель открывает каждый день:

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

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

Как правильно. Следующий шаг — действие с глаголом, датой и целью: «Позвонить 15.01 в 14:00, уточнить решение по КП». Если менеджер может написать «перезвонить» без даты и цели — это не следующий шаг, а имитация следующего шага.

В чём проблема. Задача «Связаться с клиентом» закрыта, но контакта не было — или был, но без результата. Менеджер «прокликивает» задачи, статистика красивая, сделки стоят.

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

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

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

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

Как правильно. Минимум критичного: на большинстве этапов достаточно 2–3 обязательных полей — результат контакта, следующий шаг, дата. Остальное собирать по мере необходимости, а не «на всякий случай».

В чём проблема. Автозадачи и поля настроены, но руководитель не смотрит отчёты, не разбирает просрочки и не возвращается к правилу на планёрках. Через несколько недель команда понимает, что контроля нет, и всё возвращается «как привыкли».

Как правильно. Правило живёт в ежедневном управлении: руководитель регулярно смотрит сделки без задач, просрочки и переносы, разбирает их с командой и принимает решения. Настройки лишь делают эту работу быстрой. Более широкий разбор того, как умирают внедрения, — в статье ошибки внедрения amoCRM.

1. Доля сделок без активной задачи. Сколько сделок в активных этапах не имеют задачи с будущей датой. Хороший ориентир — чтобы такие сделки быстро выявлялись и попадали в разбор, а их доля устойчиво снижалась.
2. Доля просроченных задач. Отношение просроченных задач к общему числу. Рост показателя — сигнал: либо перегруз, либо правило начали обходить.
3. Количество переносов задач. Сколько раз задачи по сделке сдвигаются. Многократные переносы — маркер имитации работы или умирающей сделки.
4. Среднее время сделки без движения. Сколько дней сделка стоит без смены этапа и без выполненных действий. Помогает находить «кладбища» в воронке.
5. Скорость первого контакта. Время от появления заявки до первого действия менеджера. Прямо зависит от автозадач на старте и хорошо показывает, работает ли правило на самом горячем участке.

Смотреть метрики имеет смысл в динамике: разовый срез показывает масштаб проблемы, повторные срезы — приживается ли правило.

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

Что для этого важно:

• объяснить команде, зачем правило: сделки не теряются, бонусы считаются по реальной работе, меньше разборов «кто виноват»;
• убрать лишние поля и требования — оставить только то, что реально используется в управлении;
• показать пользу для менеджера: CRM напоминает, помогает не забыть клиента, снимает необходимость держать всё в голове;
• не запускать сразу двадцать обязательных требований — вводить правило поэтапно;
• первые недели разбирать реальные сделки на планёрках — на примерах правило усваивается быстрее, чем на инструкциях;
• не использовать правило только как повод для наказаний — иначе команда будет обходить систему, а не работать в ней.

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

1. Аудит текущей воронки.
2. Поиск сделок без задач и просрочек.
3. Настройка автозадач и обязательных данных.
4. Подключение каналов коммуникации, если они живут вне CRM.
5. Обучение команды правилам следующего шага.
6. Сопровождение запуска, чтобы правило прижилось.

В результате руководитель получает инструмент контроля: видно, где нет следующего шага, где просрочки и какие сделки требуют внимания. Контроль следующего шага — часть более общей задачи; как устроен весь процесс, разбирали в статье про внедрение amoCRM.

Два варианта, в зависимости от того, что показала самопроверка.

1. Если сделок без задач немного — настройте контроль самостоятельно по логике из этой статьи: автозадачи, обязательные поля, контроль просрочек, отчёт по сделкам без задач и правило для команды.
2. Если в воронке много сделок без задач, просрочек и непонятных статусов — начните с аудита.

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

amoCRM помогает закрепить это правило через задачи, обязательные данные, уведомления, фильтры и контроль просрочек. Но технической настройки мало. Руководитель должен использовать правило в ежедневном управлении: смотреть сделки без задач, просрочки, переносы и этапы, где клиенты застревают. Без этого любые настройки деградируют за несколько недель.

Это конкретное действие по сделке с датой и ответственным: позвонить в назначенное время, отправить расчёт до конца дня, уточнить решение по КП, назначить встречу с ЛПР. В amoCRM носитель следующего шага — задача по сделке. Запись без даты и цели — «перезвонить», «ждём» — следующим шагом не считается: её невозможно контролировать.

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

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

Через фильтры по сделкам и задачам, списки сделок, отчёты, настроенные дашборды или виджеты — конкретный набор зависит от конфигурации. Важно смотреть не только сделки совсем без задач, но и просроченные задачи, и задачи с многократными переносами: формально задача есть, фактически сделка стоит.

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

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

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

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

По динамике пяти показателей: доля сделок без активной задачи, доля просроченных задач, количество переносов, время сделки без движения, скорость первого контакта. Если сделки без задач быстро выявляются и попадают в разбор, просрочки разбираются, а переносы не накапливаются — правило живёт. Разовый срез показывает масштаб, повторные — приживаемость.