Обработка заявок: регламент, SLA и экономика

Эффективность обработки заявок нельзя оценивать только по стоимости лида и скорости автоответа. Рабочая система должна показать, сколько стоит выигранная сделка, какие квалифицированные заявки нарушили SLA и было ли законное основание для каждого контакта. Ниже — методика из пяти контрольных точек, расчёт CPL → CPQL → стоимость победы и готовый регламент для отдела продаж.

Где заявки превращаются в расходы, хотя отчёты выглядят нормально

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

Масштаб разрыва показывает полевое исследование 114 входящих B2B-заявок 2026 года. Только одна компания отправила персонализированное письмо в течение пяти минут. Среднее время содержательного ответа составило 11 часов 54 минуты по электронной почте и 14 часов 29 минут по телефону, а позвонила только 31% выборки. Репрезентативного российского замера за 2025–2026 годы не найдено, поэтому эти значения нельзя выдавать за норму для рынка РФ.

Вторая проблема — состав потока. В массиве почти из 4 млн преимущественно B2B-форм 14,1% отправок были отклонены как спам, обращения с личной почты или контакты, не прошедшие критерии квалификации. Всего было дисквалифицировано 561 977 отправок.

Эти данные дают два проверяемых вывода:

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

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

Пять контрольных точек обработки входящей заявки

Обработка заявок — это не одно действие менеджера, а последовательность из пяти контролируемых этапов:

1. Приём. Обращение попадает в единую систему с временем поступления, каналом, содержанием и неизменным идентификатором.
2. Дедупликация. Система проверяет, не существует ли уже обращения или контакта с теми же реквизитами.
3. Квалификация. Заявка проверяется по правилам целевого сегмента, потребности, географии, чека и другим подтверждаемым критериям.
4. Маршрутизация. Квалифицированное обращение получает конкретного ответственного и место в его очереди.
5. Первый живой контакт. Сотрудник или AI-система начинает содержательный диалог, а не просто подтверждает получение формы.

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

Почему заявка и лид — не одно и то же

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

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

отправка формы → уникальная заявка → квалифицированная заявка → возможность продажи → предложение → выигранная сделка.

Так становится видно, где именно уменьшился поток: на дедупликации, квалификации, назначении ответственного или в работе менеджера.

Три времени, которые нельзя объединять в скорость ответа

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

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

Практическое правило: автоответ может информировать клиента, но не должен останавливать таймер назначения ответственного или первого живого контакта.

Цена квалификации: почему CPQL выше CPL минимум на 16,4%

CPL, или Cost per Lead, — стоимость одной заявки: все затраты на привлечение и приём потока, делённые на число заявок.

CPQL, или Cost per Qualified Lead, — стоимость квалифицированной заявки. Если бюджет не изменился, а часть потока была дисквалифицирована, CPQL рассчитывается так:

CPQL = CPL ÷ (1 − доля отсева)

При фактическом ориентире отсева 14,1% из исследования форм:

CPQL = CPL ÷ 0,859 = 1,164 × CPL.

Получается, что квалифицированная заявка стоит минимум на 16,4% дороже номинального CPL. Это нижняя граница: расчёт ещё не учитывает труд сотрудников, которые вручную проверяли нецелевые обращения.

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

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

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

Без этого невозможно отличить три принципиально разные ситуации:

• маркетинг привёл нецелевое обращение;
• правило автоматической квалификации ошибочно отклонило потенциального клиента;
• менеджер закрыл заявку, чтобы не нарушить свой SLA.

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

Маршрутизация: почему автоматизация не устраняет часы ожидания

Автоматическая передача заявки сокращает техническую задержку, но не гарантирует начало работы. В полевом исследовании 114 компаний среднее время ответа при наличии автоматической маршрутизации всё равно составляло 3 часа 32 минуты против почти 13 часов без неё.

Разрыв возникает после назначения:

заявка назначена → попала в очередь → сотрудник увидел уведомление → проверил контекст → выбрал канал → начал диалог.

Если SLA заканчивается в момент назначения, часы внутри этой цепочки остаются невидимыми.

Правила распределения должны разрешать конфликт приоритетов

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

Минимальный набор правил:

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

Вне рабочего времени нужен отдельный сценарий

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

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

Согласие на обработку данных и рекламный контакт по законам РФ

Юридический контроль должен происходить до звонка или рассылки, а не после жалобы. Конкретное основание обработки зависит от цели, содержания заявки и отношений с человеком; согласие является не единственным возможным основанием. Этот раздел описывает контрольные точки процесса и не заменяет правовой анализ конкретной формы.

Согласие нельзя прятать в общем тексте формы

С 1 сентября 2025 года часть 1 статьи 9 закона № 152-ФЗ требует оформлять согласие на обработку персональных данных отдельно от иной информации и документов, подтверждаемых или подписываемых человеком. Согласие также должно быть конкретным, предметным, информированным, сознательным и однозначным.

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

Для формы заявки безопаснее разделить как минимум:

• подтверждение отправки обращения;
• согласие на обработку персональных данных, если выбранное основание требует согласия;
• отдельное предварительное согласие на рекламные сообщения и звонки.

Ответ по заявке и реклама — разные коммуникации

Статья 18 закона № 38-ФЗ разрешает распространение рекламы по сетям электросвязи только при предварительном согласии адресата. Доказать наличие согласия должен отправитель. Автоматический набор номера без участия человека для распространения рекламы запрещён.

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

За нарушение требований к рекламе по сетям электросвязи для юридических лиц предусмотрен штраф от 300 тыс. до 1 млн рублей по части 4.1 статьи 14.3 КоАП РФ.

Что фиксировать при отправке формы

Чтобы связать согласие с конкретной заявкой, система должна сохранить:

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

С 1 июля 2025 года при сборе персональных данных граждан РФ запись, систематизация, накопление, хранение, обновление и извлечение должны выполняться с использованием баз данных на территории России, кроме предусмотренных законом исключений. До начала обработки оператор также должен проверить обязанность уведомить Роскомнадзор по статье 22 закона № 152-ФЗ.

Отдельный аварийный регламент нужен для инцидентов: часть 3.1 статьи 21 закона № 152-ФЗ устанавливает срок 24 часа для первого уведомления Роскомнадзора и 72 часа для передачи результатов внутреннего расследования.

Одностраничный регламент обработки заявок

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

Статусы и переходы

Рекомендуемая цепочка статусов:

получена → проверена → квалифицирована → назначена → контакт начат → возможность продажи → предложение → выиграна / проиграна.

Параллельные конечные статусы: дубль, дисквалифицирована с причиной, ошибка обработки, контакт запрещён.

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

Экономика процесса: от CPL до стоимости выигранной сделки

Полная стоимость выигранной сделки из входящего потока рассчитывается так:

(затраты на привлечение + приём + квалификацию + обработку) ÷ число выигранных сделок.

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

Упрощённый расчёт только по расходам на получение заявок можно сделать через конверсии стадий:

Стоимость победы = CPL ÷ (заявка → квалификация × квалификация → возможность × возможность → предложение × предложение → победа).

В отраслевом B2B-опросе 2025 года медианные переходы составляли 36%, 40%, 42% и 45%. Их произведение даёт около 2,7% выигранных сделок от исходного потока, а расчётная стоимость победы — около 36,8 × CPL.

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

Цена нарушения SLA рассчитывается отдельно:

просроченные квалифицированные заявки × разница конверсии между SLA-сегментами × маржинальный доход со сделки.

Цена ручной проверки мусора:

неквалифицированные формы × минуты проверки ÷ 60 × полная часовая стоимость сотрудника.

Что это значит для бизнеса

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

Ежедневно руководителю нужны:

• новые заявки по каналам;
• заявки без ответственного;
• нарушения SLA назначения и живого контакта;
• очередь технических ошибок;
• контакты без подтверждённого основания.

Еженедельно нужны:

• CPL и CPQL по каналам;
• конверсии между стадиями;
• причины дисквалификации и потерь;
• стоимость выигранной сделки;
• разница конверсии между заявками внутри и вне SLA;
• доля дублей и ошибочных автоматических решений.

Дополнительные практики собраны в разделах материалы по продажам и материалы по аналитике диалогов.

Что автоматизировать, а где оставить решение человеку

В первую очередь автоматизируются повторяемые и проверяемые операции:

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

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

Автоматическую приоритизацию нельзя обучать только на субъективных оценках менеджеров. Нужна обратная связь по фактическим исходам. В производственном A/B-тесте продолжительностью 160 дней на 16,5 млн заявок и 280 специалистах динамическое ранжирование увеличило накопленную конверсию на 4,7% и 8,7% в двух регионах. Верхние 10% рейтинга содержали 44,1% целевых заявок и конвертировались в 2,3 раза чаще ручной базовой линии. Это один отраслевой кейс, а не универсальный рыночный результат.

До выбора системы полезно сначала описать процесс и только затем сравнивать функции и стоимость AI-виджета для сайта. Иначе автоматизация закрепит существующие ошибки.

Шесть дефектов, из-за которых теряются заявки

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

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

Порядок внедрения за 14 дней

1. Выгрузить все источники заявок и назначить владельца процесса.
2. Зафиксировать определения заявки, квалифицированной заявки, возможности продажи и выигранной сделки.
3. Утвердить обязательные причины дисквалификации и потери.
4. Проверить формы, основания обработки данных, тексты согласий, локализацию баз и уведомление Роскомнадзора.
5. Настроить единый идентификатор, дедупликацию и историю событий.
6. Разделить время первого ответа, назначения и живого контакта.
7. Установить SLA для каждого этапа и правила эскалации.
8. Создать резервный маршрут для нерабочего времени и очередь ошибок.
9. Пересчитать CPL в CPQL и стоимость выигранной сделки.
10. Проверить на реальных обращениях, что повторные и пришедшие не по порядку события не создают дубли.
11. Запустить ежедневный контроль нарушений и еженедельный разбор причин потерь.
12. Только после стабилизации базового процесса включать автоматическую приоритизацию и сложные сценарии.

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

Вывод

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

Скопируйте шаблон регламента, подставьте собственные значения в формулы CPL → CPQL → стоимость выигранной сделки и отдельно посчитайте нарушения SLA. После этого можно посмотреть, как Excella принимает заявку, задаёт квалифицирующие вопросы, назначает ответственного и фиксирует согласие и время каждого этапа — без обещаний результата, на примере ваших обращений.

Автор материала

Максим Сивцев

Основатель и генеральный директор Excella

Все материалы автораПрофиль