amoCRM как система контроля отдела продаж: где в данных видно, что менеджер теряет сделку

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

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

Где amoCRM показывает утечку бюджета поимённо

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

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

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

Просроченные задачи и след событий: маркер брошенной заявки

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

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

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

Этапы воронки работают только при однозначных переходах

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

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

От ручного поиска зависших сделок к автоматическому

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

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

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

Что эта система даёт потоку сделок

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

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