Бизнес / Продажи и воронка

Скорость обработки заявок

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

Опубликовано: 2 июня 2026 г.Обновлено: 2 июня 2026 г.

Формула

Processing\ Speed=\frac{Processed\ Requests}{Time}

Обозначения

Processing Speed: количество заявок, обработанных за единицу времени, заявки/час
Processed Requests: число заявок с завершенным первичным разбором, заявки
$Time$: длительность периода обработки, часы

Условия применения

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

Ограничения

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

Подробное объяснение

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

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

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

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

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

Как пользоваться формулой

Определите период, сегмент, канал или объект расчета, чтобы все входные данные относились к одной управленческой задаче.
Соберите исходные величины: Processed Requests, Time; проверьте единицы измерения и источник каждой величины.
Исключите дубли, отмененные операции, тестовые записи и незавершенные события, если они не входят в принятое правило учета.
Подставьте значения в формулу, сохраните промежуточное вычисление и округлите только итоговый результат.
Сравните результат с планом, прошлым периодом, нормативом или соседней метрикой и отдельно запишите возможное ограничение расчета.

Историческая справка

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

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

Историческая линия формулы

Формула «Скорость обработки заявок» принадлежит прикладной традиции управления продажами и CRM-аналитики. Ее корректнее связывать с развитием воронок, SLA и единых статусов лидов, чем с одним автором. Смысл задают определения этапов, период, канал и правило исключения дублей.

Пример

Дано: за 24 рабочих часа команда завершила первичную обработку 168 заявок. Нужно найти скорость обработки. Подстановка: 168 / 24 = 7 заявок/час. Ответ: 7 заявок/час. Проверка: единицы согласованы, потому что числитель и знаменатель относятся к одному периоду и одной базе наблюдений; итог выражен как заявки/час. Если использовать другой период, другой статус события или смешать деньги с количеством операций, результат нельзя сравнивать с этим примером. Управленческий вывод: число показывает не всю картину бизнеса, а конкретный срез, который нужно читать вместе с планом, динамикой и качеством исходных данных.

Частая ошибка

Частая ошибка - считать принятые заявки обработанными. Входящий статус фиксирует появление обращения, а скорость обработки требует завершенного первичного действия. Еще одна ошибка - сравнивать периоды, где изменились канал, SLA, статусная модель или правило дублей: воронка начинает описывать другой процесс. Итог лучше считать по исходным числам без раннего округления и смотреть рядом с соседним этапом воронки.

Практика

Задачи с решением

Прямой расчет

Условие. Для показателя «Скорость обработки заявок» даны значения из примера. Выполните подстановку и найдите итог.

Решение. 168 / 24 = 7 заявок/час

Ответ. 7 заявок/час

Проверка базы расчета

Условие. Почему показатель «Скорость обработки заявок» нельзя сравнивать между двумя периодами, если в одном периоде изменили правило отбора данных?

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

Ответ. Сравнение корректно только при одинаковом периоде, сегменте, единицах и правиле учета.

Дополнительные источники

Salesforce: Sales Metrics Guide
HubSpot: Sales Pipeline and Lead Management Metrics
OpenStax Introduction to Business: selling and customer relationships

Связанные формулы

Бизнес

Конверсия MQL в SQL по воронке продаж

$MQL\ to\ SQL\ Conversion=\frac{SQL}{MQL}\cdot100\%$

Конверсия MQL в SQL показывает, какая доля маркетинговых лидов прошла согласованные критерии продаж и стала рабочими SQL. Метрика помогает проверить качество входящего потока и стык маркетинга с продажами, если статусы CRM и период отбора зафиксированы заранее.

Бизнес

Конверсия SQL в выигранную сделку

$SQL\ to\ Deal\ Conversion=\frac{Won\ Deals}{SQL}\cdot100\%$

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

Бизнес

Среднее время ответа менеджера

$Average\ Response\ Time=\frac{\sum Response\ Time_i}{N}$

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

Бизнес

Доля просроченных лидов в работе

$Overdue\ Leads\ Share=\frac{Overdue\ Leads}{Total\ Active\ Leads}\cdot100\%$

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