11 сентября 2026 г. · Maksim Shchegolev

Автоматизация обработки заявок в amoCRM и Битрикс24

Модель обработки заявок не зависит от того, какая у вас CRM. Приём и нормализация значений, склейка дублей, одно состояние жизненного цикла, один ответственный и один таймер работают одинаково в amoCRM и в Битрикс24. Разница между ними всплывает в 2 местах: в обработке ошибок интеграции и в том, кто владеет справочниками полей.

Хотите проверить это на своём сайте? Запустите бесплатную проверку видимости в ИИ, она занимает десять секунд и не требует почты.

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

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

Сразу две оговорки. Жанр «какая CRM лучше» тут не разбирается: обе системы рабочие, у вас уже куплена одна из них, и вопрос стоит не о выборе, а о настройке. И здесь нет ни одного маршрута по кликам. Названия разделов и расположение настроек в обеих системах меняются от обновления к обновлению, поэтому конкретику сверяйте с официальной документацией amoCRM и Битрикс24, а из статьи забирайте модель.

Одним предложением

Модель обработки заявок не зависит от того, какая у вас CRM: приём и нормализация значений, поиск дублей до назначения ответственного, этапы как список разрешённых переходов, владение полями, записанный приоритет правил распределения и задача со сроком. amoCRM и Битрикс24 дают этой модели разную форму, но не меняют ни один её слой.

Что в модели обработки заявок не зависит от вашей CRM

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

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

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

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

Приём заявки и нормализация значений до попадания в систему

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

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

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

Поиск дублей и привязка к компании до назначения ответственного

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

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

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

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

Этапы сделки как разрешённые переходы, а не как ярлыки

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

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

Отсюда три следствия, одинаковых для amoCRM и Битрикс24.

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

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

Третье. Держите этап жизненного цикла и этап сделки как два разных поля. В Битрикс24 разделение сущностей лида и сделки частично делает это за вас, в amoCRM разделение придётся описать полями. В обоих случаях попытка сложить «кто это для нас сейчас» и «какое действие следующее» в один статус даёт воронку, которой никто не верит.

Из международных систем ту же логику показывает документация HubSpot по автоматизации воронки заявок, где запись двигает вперёд зафиксированная попытка связи и ответ покупателя, а не решение менеджера. Продукты разные, принцип один: движение следует за доказательством.

Чем цифровая воронка отличается от бизнес-процесса

Это самый частый вопрос при переходе между системами, и обычный ответ («в amoCRM цифровая воронка, в Битрикс24 бизнес-процессы») неверен. Правильное сопоставление другое.

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

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

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

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

Какие поля обязательны в карточке заявки и кто ими владеет

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

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

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

Распределение заявок: где настраивается правило и что делать, когда правил больше одного

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

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

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

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

Задачи, сроки и напоминания как механика норматива времени ответа

Норматив времени ответа (SLA) существует в CRM в единственной форме: задача со сроком и то, что происходит, когда срок нарушен. Определения таймеров, точки старта и остановки, порядок эскалации и отчётность принадлежат гайду про скорость ответа на заявку. Здесь механика, общая для двух систем.

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

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

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

Квалификация: что решается до CRM и что внутри неё

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

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

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

Заявки из Telegram, WhatsApp и звонков как отдельные источники событий

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

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

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

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

Что делать, если заявка не дошла до CRM

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

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

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

Где заканчиваются встроенные возможности обеих систем

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

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

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

Порядок внедрения на базе, где уже накоплен беспорядок

Все инструкции по настройке написаны для чистой системы. В реальности вы приходите в базу, где три воронки с этапом «Новая», половина сделок без источника, справочник источников на сорок значений и два робота, которые спорят за ответственного. Порядок работ в такой ситуации отличается от порядка работ на пустом месте.

1. Сначала измерить, потом трогать. Выгрузите за представительный период сделки, контакты и компании, включая записи без ответственного. Посчитайте: сколько записей дублей, сколько без источника, сколько без ответственного, сколько зависло на этапе дольше нормы. Это ваша отправная точка и единственный способ потом доказать, что стало лучше. Как провести такой разбор целиком, описано в гайде про аудит входящего потока.
2. Заморозить рост беспорядка. Отключите создание новых значений справочников свободным текстом и остановите неконтролируемый импорт. Пока источник можно набрать руками, любая чистка это работа против конвейера.
3. Написать определения. Список этапов с доказательством входа, список разрешённых переходов, таблица владения полями, определение каждого значения справочника. Это текст, а не настройки, и он согласуется с продажами и маркетингом, а не только внутри операционной роли.
4. Свести справочники. Сопоставьте сорок унаследованных значений источника с новым коротким списком. Старые значения помечайте выведенными из оборота, но не удаляйте: удаление значения переписывает прошлогодние отчёты.
5. Почистить дубли выгрузкой. Нормализуйте ключи вне системы, разделите точные совпадения и нечёткие кандидаты, посчитайте оба списка. Точные сливайте по своим правилам с обратимым журналом, нечёткие отправляйте в очередь ручной проверки со сроком.
6. Выключить старую автоматизацию. Разберите существующих роботов и правила по одному. То, что не имеет владельца и не срабатывало последние месяцы, выключается. Наслоение старых и новых правил даёт поведение, которое невозможно объяснить.
7. Включить приборы до правил. Внешний идентификатор события, ограниченные повторы, очередь необработанных событий и отчёт по доле успешных записей должны работать до того, как заработает первое новое правило.
8. Добавлять правила по одному. Один переход за раз, затем прогон сценариев проверки. Пять правил, включённых в один день, дают неделю разбирательств.
9. Пилот на одном канале. Две недели одна смена и один канал, разбор исключений на регулярной встрече, и только потом расширение.

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

Что проверить до запуска и что смотреть каждый месяц

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

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

Про срочность стоит помнить контекст, который старше обеих систем. Ещё в 2011 году Harvard Business Review насчитал на 2 241 американской компании медиану первого ответа порядка 42 часов у тех, кто отвечал вообще. Исследование старое, описывает одну выборку и другой рынок, поэтому читайте его не как ориентир по цифре, а как описание того, насколько плохо бывает, когда потоком никто не управляет. Механика с тех пор не изменилась: ничто в карточке не заставило человека ответить к конкретному сроку.

Тревожный признак и что делать дальше

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

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

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

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

Цены