Процессы CRM системы это движение объекта по стадиям и правила, которые срабатывают на каждом переходе. Не документооборот компании и не регламент отдела, а именно жизненный цикл лида, сделки, счёта и смарт-процесса внутри базы. В REST-справочнике Битрикс24 эти объекты пронумерованы явно: метод crm.stagehistory.list принимает entityTypeId со значениями 1 (лид), 2 (сделка), 5 (старый счёт), 31 (новый счёт) и числовой идентификатор пользовательского типа для смарт-процесса, например 130. Всё, что двигается по стадиям и имеет историю переходов, и есть процесс CRM.
Процесс компании описывает, кто с кем согласует и кто подписывает. Процесс CRM описывает, при каком событии карточка меняет стадию, кто становится ответственным и что система делает сама. Ниже: стадии лида и сделки, триггеры и роботы на переходах, распределение и сроки, а также то, что ломается при переносе живых продаж в конструктор.
Что считать процессом CRM системы, а что нет
Рабочее определение: процесс CRM это связка из четырёх элементов. Объект (лид, сделка, счёт, смарт-процесс). Набор стадий с фиксированным порядком. События, которые двигают объект между стадиями. Действия на входе в стадию.
Проверка простая. Возьмите любую стадию и ответьте: какое событие переводит карточку сюда, кто за неё отвечает, что система делает сама при входе. Есть все три ответа, стадия описана. Нет, её рано автоматизировать.
Жизненный цикл лида: от источника до квалификации
Лид это обращение, про которое пока неизвестно, покупатель ли это. Его задача одна: дожить до квалификации и превратиться в сделку либо отвалиться с зафиксированной причиной.
На входе фиксируется источник. amoCRM в тарифной таблице перечисляет каналы автоматического создания сделок: мессенджеры, веб-формы, Google-таблицы, онлайн-чат, веб-парсер, телефония, сканер визиток, email. Битрикс24 держит те же каналы через контакт-центр и Маркетплейс, где по данным страницы CRM собрано 6 360+ интеграций. Источник не украшение карточки: без него не считается стоимость лида по каналу и не работает распределение по признаку.
Второй обязательный элемент это контроль дублей. amoCRM выносит его отдельной строкой тарифа как «контроль дублей по источникам», в REST-справочнике Битрикс24 под это отведён раздел «Поиск и обработка дубликатов в CRM». Без дедупликации один клиент растёт в три карточки, и отчёт по конверсии становится выдумкой.
Третий элемент это лимит. В amoCRM количество открытых сделок ограничено тарифом: 500 на пользователя на Базовом, 1000 на Расширенном, 3000 на Профессиональном. Незакрытые мусорные лиды съедают этот лимит буквально. Стадия «отказ» с обязательной причиной нужна не для красоты отчёта, а чтобы база не упёрлась в потолок.
Жизненный цикл сделки: стадии, семантика и обязательные поля
Сделка отличается от лида тем, что у неё есть исход. Любая стадия относится к одной из трёх семантических групп: в работе, успех, провал. Отчёт по воронке считается по этим группам, поэтому две финальные стадии («оплачено» и «отказ») обязаны быть в каждой воронке.
Поля тоже конечный ресурс. В amoCRM количество дополнительных полей ограничено аккаунтом: 100 на Базовом, 200 на Расширенном, 400 на Профессиональном. Отсюда дисциплина: поле заводится, только если оно участвует в условии перехода, в отчёте или в шаблоне документа. Поле «для истории» это будущий мусор, который придётся чистить руками.
Технологии автоматизации бизнес процессов внутри воронки
Технологии автоматизации бизнес процессов в CRM раскладываются на слои, и путать их дорого.
- Триггер. Событие снаружи карточки, которое переводит объект на другую стадию. Заявка с формы, входящий звонок, оплата, ответ в мессенджере. В документации Битрикс24 сказано прямо: если для объекта настроен триггер, он переводит объект на другую стадию или в другой статус.
- Робот. Действие, которое выполняется при входе на стадию: задача, письмо, смена ответственного, счёт. Робот не решает, когда сработать, за это отвечает стадия.
Внешний слой описан методами. Готовый webhook-триггер вызывается методом crm.automation.trigger: берётся значение code из URL триггера «Отследить входящий вебхук» и параметр target для целевого объекта, например DEAL_25. Приложение регистрирует и запускает собственные триггеры группой crm.automation.trigger.add, .list, .delete, .execute. Запуск процесса по шаблону выполняется методом bizproc.workflow.start.
У внешнего слоя есть жёсткие рамки, и они определяют архитектуру процесса. В облачном Битрикс24 один REST-запрос должен выполниться не дольше 60 секунд, иначе прерывается по таймауту. Интенсивность считается по алгоритму Leaky Bucket: на всех тарифах, кроме Энтерпрайз, счётчик уменьшается на 2 в секунду при пороге блокировки 50, на Энтерпрайз это 5 в секунду при пороге 250. Превышение возвращает статус 503 и код QUERY_LIMIT_EXCEEDED. Отдельно считается ресурсоёмкость: накопленное время метода учитывается в 10 одноминутных корзинах, при превышении приходит статус 429 и код OPERATION_TIME_LIMIT.
Из этих цифр следует практика. При устойчивых 2 запросах в секунду за сутки проходит 172 800 запросов, и это весь бюджет на выгрузки, синхронизацию с 1С и массовые пересчёты. Поэтому разовые операции по всей базе выносят на ночь и режут на страницы, а срочные события отдают триггерам, которые стоят один запрос на карточку.
CRM система: управление ответственными и распределение лидов
CRM система управление продажами держит на одном допущении: у карточки в каждый момент ровно один ответственный. Как только ответственных двое или ноль, процесс останавливается тихо, без ошибки в интерфейсе. Рабочих схем распределения три, и выбирать нужно одну на воронку.
- По очереди. Лиды раздаются менеджерам по кругу. Подходит однородному потоку, где заявки примерно равны по сложности.
- По нагрузке. Следующий лид уходит тому, у кого меньше открытых сделок. Требует дисциплины закрытия, иначе накопитель мусора получает премию в виде пустой очереди.
- По признаку. Регион, продукт, язык, сумма. Самая устойчивая схема, но признак должен заполняться до распределения: на форме или в триггере, а не менеджером после звонка.
SLA на стадиях: чем меряют сроки и откуда берут данные
Три метрики закрывают контроль процесса.
- Время до первого касания. От создания лида до первой активности менеджера. Ставится жёстким числом, например 15 минут в рабочее время, и проверяется роботом на первой стадии.
- Время на стадии. Сколько карточка провисела в конкретном статусе. Нормируется по каждой стадии отдельно, единого норматива на воронку не бывает.
- Доля просроченных. Отношение карточек, вышедших за норматив, ко всем прошедшим стадию за период. Единственная из трёх метрик, которую есть смысл выносить на дашборд руководителя.
Источник данных для второй и третьей метрики один: история переходов. Метод crm.stagehistory.list возвращает записи о движении по стадиям для лидов, сделок, старых и новых счетов и смарт-процессов, работает в скоупе crm и доступен любому пользователю.
Глубину анализа ограничивает тариф. В amoCRM хранение расширенной истории составляет 1 месяц на Базовом, 6 месяцев на Расширенном и 1 год на Профессиональном. Сравнение «август к августу» на младшем тарифе физически невозможно, поэтому выгрузку истории во внешнее хранилище закладывают заранее.
Автоматизация продаж: сценарии, которые окупаются первыми
Автоматизация продаж начинается с трёх-четырёх переходов, где теряются деньги. Ниже связки на штатных инструментах.
| Стадия | Событие (триггер) | Действие на входе | Что меряем |
|---|---|---|---|
| Новый лид | Заявка с формы, звонок, сообщение в мессенджер | Назначить ответственного по правилу, поставить задачу на звонок, отправить подтверждение клиенту | Время до первого касания |
| Квалификация | Заполнены обязательные поля признака | Создать сделку в профильной воронке, закрыть лид | Доля лидов, дошедших до сделки |
| Счёт | Смена стадии | Сформировать счёт, отправить клиенту, запланировать напоминание | Срок оплаты |
| Оплата | Входящий вебхук от банка или платёжного сервиса через crm.automation.trigger | Перевести сделку в «успех», поставить задачу на исполнение | Доля оплат без ручного подтверждения |
Что ломается при переносе процесса продаж в CRM
Список ошибок повторяется от проекта к проекту и почти не зависит от вендора.
- Стадия описывает действие менеджера, а не состояние сделки. «Позвонить» это задача, а не стадия. Стадия отвечает на вопрос «где сейчас клиент», а не «что делает сотрудник».
- Нет события перехода. Карточка двигается «когда менеджер решит». Такую воронку невозможно ни автоматизировать, ни измерить.
- Обязательные поля введены после запуска. Половина базы остаётся без признака, отчёты по сегментам не собираются, а массовое дозаполнение упирается в лимит запросов.
- Роботы навешаны пачкой на одну стадию. Пять писем и три задачи при входе превращают карточку в шум, и менеджер перестаёт читать уведомления.
- Тестирование на боевой базе. Ошибка в условии рассылает клиентам чужие письма. Проверка делается на тестовой карточке и на одной стадии за раз.
- Интеграция без учёта лимитов. Синхронизация, которая ломится в API постоянным потоком, получает 503 и QUERY_LIMIT_EXCEEDED, часть событий теряется, и никто этого не замечает неделями.
Соберём процесс в CRM так, чтобы он не развалился через месяц
Опишем воронки и стадии, настроим триггеры, роботов и распределение, подключим внешние системы с учётом лимитов REST и передадим схему с документацией. Работаем с Битрикс24 и amoCRM.
Где процесс выходит за пределы воронки CRM
Воронка держит линейный путь клиента и плохо держит остальное. Признаков выхода за её пределы три: в процессе участвуют сотрудники, у которых нет своих сделок; нужен ответ «согласовано или нет» с возвратом на доработку; ветки идут параллельно и процесс ждёт их все.
Технически граница видна по методу запуска. Пока процесс живёт на стадиях, он собирается триггерами и роботами. Как только требуется отдельный шаблон, запускаемый вызовом bizproc.workflow.start или вручную сотрудником, это уже не воронка, а конструктор процессов, и настраивается он по другим правилам. Разбор этого контура вынесен в отдельный материал: автоматизация бизнес-процессов в Битрикс24.
Тарифные лимиты, в которые упирается процесс
Процесс проектируют под тариф, а не наоборот. Цифры на 22 августа 2026 года по официальным страницам вендоров. Скидка 35% у Битрикс24 действует при оплате за год, у amoCRM акционные цены заявлены до 1 сентября.
| Параметр | Битрикс24 | amoCRM |
|---|---|---|
| Стартовый платный тариф | Базовый: 2 490 ₽ в месяц, со скидкой 35% 1 619 ₽, 5 пользователей, 1 ТБ | Базовый: 599 ₽ за пользователя |
| Средний | Стандартный: 6 990 ₽, со скидкой 4 544 ₽, 50 пользователей, 5 ТБ | Расширенный: 1 199 ₽ по акции до 1 сентября, далее 1 299 ₽ |
| Старший | Профессиональный: 13 990 ₽, со скидкой 9 094 ₽, 100 пользователей, 10 ТБ | Профессиональный: 1 699 ₽ по акции, далее 1 799 ₽ |
| Открытые сделки | Отдельной строки с лимитом открытых сделок в тарифной таблице нет | 500 / 1000 / 3000 на пользователя |
| Триггеры автоматизации | Строка «Роботы и триггеры» есть в тарифной таблице, значение зависит от тарифа | Расширенный: 100 на аккаунт, Профессиональный: без ограничений |
| Лимит API | 2 запроса в секунду при пороге 50, на Энтерпрайз 5 при пороге 250 | 50 запросов в секунду на аккаунт и 7 на одну интеграцию |
Бесплатный тариф Битрикс24 даёт неограниченное число пользователей и 25 ГБ диска: хватает, чтобы описать воронку и проверить гипотезу о стадиях. Энтерпрайз начинается с 33 990 ₽ в месяц, со скидкой 22 094 ₽, и в него переходят ради лимитов API и объёма базы.
Чек-лист готовности процесса к переносу в CRM
Невыполненный пункт это переделка через месяц.
- Стадии названы состояниями клиента, а не действиями менеджера.
- Для каждого перехода записано событие, которое его вызывает.
- У каждой стадии один ответственный и одно правило назначения.
- Есть финальные стадии успеха и провала, у провала обязательная причина.
- Норматив времени задан по каждой стадии отдельно, числом в минутах или днях.
- Поля заведены только под условия, отчёты и шаблоны документов.
- Посчитана нагрузка на API: сколько карточек в сутки и сколько внешних вызовов на карточку.
- Назначен владелец процесса, который правит настройки и ведёт историю изменений.
Пять вопросов до входа в конструктор
- Сколько стадий в воронке и по какому событию карточка проходит каждую из них?
- Кто становится ответственным на первой стадии и что происходит, если этот человек в отпуске?
- Какой норматив времени на самой длинной стадии и кто получает уведомление о его нарушении?
- Сколько внешних систем пишут в CRM и укладываются ли они в 2 запроса в секунду?
- Где хранится история переходов глубже, чем позволяет тариф?
Частые вопросы
Чем триггер отличается от робота
Триггер это внешнее событие, которое переводит объект на другую стадию или в другой статус. Робот это действие, которое выполняется при входе на стадию. В REST-справочнике Битрикс24 они разведены явно: триггеры живут в разделе crm.automation.trigger.*, запуск процессов по шаблону в разделе bizproc.workflow.start.
Сколько запросов к CRM выдержит интеграция
В облачном Битрикс24 устойчивая интенсивность составляет 2 запроса в секунду с порогом блокировки 50, на Энтерпрайз 5 в секунду с порогом 250. При 2 запросах в секунду за сутки проходит 172 800 запросов. Превышение возвращает статус 503 и код QUERY_LIMIT_EXCEEDED. В amoCRM базовое ограничение составляет 50 запросов в секунду на аккаунт и 7 запросов в секунду на одну интеграцию, расширение лимита продаётся отдельным пакетом.
Как измерить, где сделки застревают
Через историю переходов. Метод crm.stagehistory.list возвращает записи о движении по стадиям для лидов (entityTypeId 1), сделок (2), счетов (5 и 31) и смарт-процессов. Фильтр поддерживает модификаторы >=, <= и @, поэтому выборку за период по нужным стадиям собирают одним вызовом.
Сколько воронок заводить
Отдельная воронка нужна, когда набор стадий отличается минимум на две позиции: разные продукты, услуги или сегменты клиентов. Битрикс24 называет это мультиворонками. Если отличие сводится к одному полю, хватит фильтра и одной воронки.
Что мешает автоматизации сильнее всего
Незаполненные обязательные поля и открытые мусорные карточки. В amoCRM количество открытых сделок ограничено тарифом (500, 1000 или 3000 на пользователя), а дополнительных полей в аккаунте бывает 100, 200 или 400. Процесс, который не закрывает отказы и плодит поля, упирается в лимит раньше, чем в бюджет.
