Автоматизация отдела продаж: как настроить процесс и перестать терять заявки

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

Что именно автоматизируют в отделе продаж

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

• Фиксация обращений. Заявка с сайта, звонок, письмо, сообщение в мессенджере попадают в CRM как элемент — лид или сделка — с источником и датой.
• Распределение. Новое обращение получает ответственного по заранее заданному правилу, а не по тому, кто первым заметил.
• Движение по этапам. Переход сделки на следующую стадию сопровождается действиями: письмо, счёт, задача, уведомление.
• Коммуникации. Шаблонные письма и сообщения, напоминания о следующем контакте.
• Документы. Формирование счёта, договора, коммерческого предложения по данным карточки.
• Отчётность. Сводка по воронке, менеджерам, причинам отказов.

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

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

Где отдел продаж теряет деньги: диагностика до настройки

Прежде чем что-то настраивать, стоит зафиксировать текущее состояние. Диагностика отвечает на вопрос, что автоматизировать первым, и даёт точку сравнения после запуска. Без неё невозможно понять, стало ли лучше.

Что смотрят:

• Сколько обращений пришло за период по каждому каналу и сколько из них оказалось в CRM. Расхождение — это потерянные на входе заявки.
• Сколько открытых сделок не имеет запланированного следующего шага. Сделка без задачи — кандидат на «забыли».
• Сколько времени сделки проводят на каждой стадии. Долгая стадия — либо узкое место, либо сделки там «висят» без работы.
• Есть ли у каждой сделки ответственный и заполнен ли источник обращения.
• Какие причины отказов указывают менеджеры и совпадают ли они с тем, что видно по переписке и звонкам.

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

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

Роботы, триггеры и бизнес-процессы: из чего состоит автоматизация в Битрикс24

В CRM Битрикс24 автоматизация строится на нескольких инструментах. Разберём их по назначению: путаница между ними — частая причина неработающих сценариев.

Роботы: действия по стадии

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

Триггеры: реакция на действие клиента

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

Переменные, константы и отладчик

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

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

Отдельно стоит упомянуть дизайнер бизнес-процессов. В нём можно добавить действия, которых нет в интерфейсе роботов, — например, цикл для повторяющихся операций. Важная деталь: если робота отредактировали в дизайнере или добавили туда действие, дальнейшие изменения возможны только в дизайнере, пока добавленное действие не удалено. Это влияет на то, кто и как будет сопровождать сценарий дальше.

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

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

Какие сценарии автоматизируют первыми

Порядок важен: сначала то, что останавливает потери, потом удобство, потом аналитика.

1. Сбор обращений со всех каналов в CRM. Пока канал не подключён, заявки из него не существуют для системы, и никакая работа менеджеров их не вернёт. 2. Распределение новых обращений по ответственным. Правило должно быть однозначным: при равных условиях заявка не должна «зависать» между двумя менеджерами. 3. Обязательный следующий шаг по каждой сделке: задача с датой. Это самый дешёвый способ перестать терять тёплые обращения. 4. Воронка, отражающая реальный процесс продажи, а не абстрактные «этапы». Стадии должны соответствовать ключевым вехам сделки, а не только действиям менеджера. 5. Базовые уведомления: клиенту — подтверждение получения заявки, менеджеру — напоминание о сроке. 6. Отчёт по конверсии стадий и по нагрузке на менеджеров. Он нужен не для контроля ради контроля, а чтобы видеть, где процесс встаёт.

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

Сравнение вариантов: что выбрать под свою ситуацию

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

Порядок работ: с чего начать автоматизацию отдела продаж

Работы идут от процесса к настройке, а не наоборот.

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

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

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

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

Учебный пример: настройка обработки заявок

Учебный пример. Данные условные.

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

Что делают.

1. Сверяют число обращений по каналам с числом карточек в CRM за прошлый период. Находят, что один канал не создаёт карточки автоматически. 2. Подключают этот канал к CRM и проверяют создание карточки тестовым обращением. 3. Настраивают распределение: новая заявка попадает к менеджеру по правилу, а не в общий список. 4. На стадии «Новая заявка» ставят робота, который создаёт задачу «Связаться» с датой и отправляет клиенту подтверждение. 5. На стадии «Предложение» настраивают триггер на переход по ссылке из письма: при клике сделка переходит на следующую стадию и менеджер получает уведомление. 6. Прогоняют обе цепочки в отладчике на тестовой сделке и смотрят пошаговый результат. 7. Вводят константу с ролью руководителя для уведомлений о зависших сделках.

Как проверяют результат. Через согласованный период смотрят: сколько обращений пришло по каждому каналу и сколько карточек создано; у скольких открытых сделок есть задача со сроком; сколько сделок прошло стадию «Новая заявка» за сутки; сколько сделок не двигалось дольше заданного срока. Сравнивают с состоянием до настройки. Если расхождение по каналам осталось — проблема на входе, а не в работе менеджеров.

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

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

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

Ограничения и типичные ошибки

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

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

Что дальше

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

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