Регламент обработки заявок в amoCRM: готовый шаблон для отдела продаж

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

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

Короткий шаблон регламента

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

Шаг 1. Определите точку начала обработки

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

Разделите как минимум три времени:

1. время от создания заявки до назначения ответственного;
2. время от создания заявки до первой реальной попытки контакта;
3. время до следующего запланированного действия, если клиент не ответил сразу.

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

Шаг 2. Назначьте одного владельца каждого действия

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

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

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

Шаг 3. Опишите результат первого контакта

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

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

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

Шаг 4. Настройте эскалацию по исключениям

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

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

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

Шаг 5. Разделите оперативный контроль и разбор причин

Оперативный сигнал отвечает на вопрос «что нужно исправить сейчас?». Еженедельный разбор отвечает на вопрос «почему это повторяется?». Эти процессы нельзя заменять друг другом.

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

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

Готовый текст правила для команды

Ниже базовый вариант, который можно перенести во внутренний документ и адаптировать под свои сроки:

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

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

Как автоматизировать проверку регламента

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

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

Подробнее различия между штатным потоком событий и точечными сигналами разобраны в материале про Telegram-уведомления amoCRM для руководителя.

Чек-лист перед запуском

• Для каждого источника определен момент начала отсчета.
• Установлен реалистичный срок назначения ответственного и первого контакта.
• Понятно, какое действие подтверждает обработку заявки.
• После контакта обязательна следующая задача или зафиксированная причина закрытия.
• Описана передача заявок между сменами и при отсутствии менеджера.
• Для каждого нарушения есть получатель, порог и конкретная реакция.
• Закрытые, тестовые и технические этапы исключены из оперативного контроля.
• Раз в неделю повторяющиеся отклонения разбираются как проблема процесса.

Итог

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