amoCRM в работе отдела продаж — от нового лида до результата сделки

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

Платформа строится вокруг воронок и каналов продаж, а центральным рабочим объектом остаётся карточка сделки. Это сильная специализация для отдела продаж, но не попытка заменить учёт, расписание или корпоративное управление проектами.

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

В amoCRM сделка — это рабочее досье на конкретную возможность продажи, а не универсальная карточка всего, что происходит с клиентом.

Официальная документация amoCRM описывает предметную область как набор связанных сущностей. Для руководителя важны пять из них.

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

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

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

В хорошем сценарии вместе с контактом в amoCRM попадают:

Идентификатор отправки нужен не для отчётности. Если сайт повторит запрос после сетевой ошибки, интеграция должна распознать повтор, а не создать две сделки. Вебхук, наоборот, сообщает внешней системе о событии в amoCRM. Официальная документация описывает подписку на вебхуки и форматы уведомлений, но конкретные лимиты и доступность необходимо проверять перед разработкой.

Входящая заявка может попасть в специальный статус «Неразобранное». В модели amoCRM это уже сделка в особом состоянии: менеджер принимает её и переводит в рабочий этап воронки либо отклоняет.

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

Официальная база знаний называет карточку сделки основным рабочим инструментом amoCRM. В левой части находятся поля сделки, контакта и компании, в правой — лента событий: письма, чаты, звонки, заметки, задачи и изменения.

Эта конструкция помогает ответить на три вопроса:

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

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

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

Поле «причина отказа» позволяет сравнить сделки, а комментарий объясняет нюанс. Только комментарий не группируется в отчёте, только справочник не сохраняет контекст.

При создании аккаунта в amoCRM есть стандартная воронка, которую можно менять под процесс. Компания определяет собственные этапы и при необходимости создаёт несколько воронок.

Для продажи клиентского портала этапы могут выглядеть так:

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

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

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

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

Плохая задача: «проработать клиента». Хорошая: «до 16:00 уточнить количество филиалов и назначить встречу с ИТ-директором». В первом случае сотрудник может считать задачу выполненной после любого звонка. Во втором понятен результат, который изменит карточку.

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

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

В amoCRM есть Digital Pipeline — цифровая воронка, в которой на этапах настраиваются автоматические действия. На дату проверки её настройка доступна с тарифа «Расширенный». Состав действий и условия доступа меняются, поэтому конкретную схему повторно проверяют перед внедрением.

Автоматизацию удобно оценивать через таблицу.

Автоматизация безопасна там, где событие однозначно, а ошибку можно увидеть и вернуть в ручную работу.

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

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

Перед разработкой нужен контракт данных:

API не решает эти вопросы — он лишь даёт технический способ выполнить согласованные операции. Особенно опасна двусторонняя синхронизация без владельца данных. Если сайт, amoCRM и учётная система могут независимо менять адрес компании, последнее сохранение случайно становится «истиной».

Для звонков и писем важна та же логика. Обмен с внешним каналом должен иметь понятный контракт, обработку повторов и журнал ошибок; эти вопросы раскрывает статья об API. amoCRM хранит коммуникацию рядом со сделкой, но не должна приписывать источник без устойчивой связи.

Доступ к данным через интерфейс и API учитывает права пользователя. Роли стоит строить по рабочим операциям: кто видит сделки отдела, кто меняет поля, кто экспортирует контакты, кто управляет интеграциями.

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

Если компания выбирает между CRM и платформой для сайта, полезно сразу развести задачи. 1С-Битрикс отвечает за управление сайтом и магазином, а amoCRM — за работу с обращениями и сделками; обмен между ними проектируют отдельно, а не предполагают по схожему названию.

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

Система менее естественна, если центральный объект — не сделка. Для интернет-магазина с тысячами заказов важнее статусы заказа, оплаты, доставки и возврата. Для сервисного бизнеса — расписание, сотрудники и доступные слоты. Для производства — спецификация, план выпуска и остатки. amoCRM может участвовать в таком контуре, но не обязана становиться источником всех данных.

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

Перед покупкой или перенастройкой возьмите реальный запрос и ответьте:

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

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

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

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

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