Контроль и аналитика — FAQ

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

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

Для каждого типа проблемы задают свой приоритет. Критические заказы показываются первыми, менеджер видит не только заказ, но и причину, по которой система требует внимания. Такой подход — management by exception — описан в кейсе операционного контура клининга и в FAQ про заказы и заявки.

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

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

Заказ №1254 на этапе согласования 3 дня. Допустимый срок — 2 дня.

Дополнительно настраивают предупреждение до наступления просрочки. Похожий механизм нормативных сроков — в решении для управления отчётностью и в FAQ про заказы и заявки.

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

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

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

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

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

Важно смотреть не только среднее, но и медиану и долю заявок, обработанных дольше установленного срока. Нормативы реакции — в FAQ про CRM и работу менеджеров; сбор заявок из каналов с фиксацией времени — в event-CRM.

Сначала определяют действия, которые сотрудники регулярно выполняют вручную: перенос данных из письма в CRM, копирование заказа в 1С, проверка остатков, расчёт цены, формирование счёта, отправка уведомления, смена статуса, поиск аналога, создание документа, перенос между Excel-файлами.

Система фиксирует количество таких действий или рассчитывает их по истории заказов. За месяц можно увидеть: 720 заказов обработано, 1 430 ручных изменений статуса, 680 счетов сформировано вручную, 410 заказов повторно внесено в учётную систему, 260 раз менеджеры вручную проверяли остатки.

Полезно оценивать и затраченное время: если операция занимает 3 минуты и выполняется 2 000 раз в месяц, на неё уходит около 100 рабочих часов. Симптомы ручного труда — в интервью про Excel и Telegram; приоритеты автоматизации — в интервью про бизнес-процессы.

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

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

Если значительная часть заказов отменяется из-за отсутствия товара, проблема может быть в актуальности остатков, а не в работе отдела продаж — см. FAQ про склад и остатки. Сценарии отказа при подборе комплекта — в портале подбора автозапчастей.

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

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

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

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

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

Если один товар постоянно заменяется из-за отсутствия на складе, можно пересмотреть минимальный остаток или ассортимент. Замены при подборе комплекта — в портале подбора автозапчастей; актуальность остатков — в FAQ про склад и остатки.

Нагрузку оценивают не только по количеству клиентов или заказов. Один менеджер может вести 20 простых заказов, другой — 8 сложных проектов с большим количеством согласований.

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

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

Управленческий дашборд отвечает на конкретные вопросы руководителя, а не просто показывает большое количество графиков. Обычно достаточно нескольких групп показателей.

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

Просроченные заказы — 17. При нажатии руководитель получает список: ответственный, этап, срок, причина задержки, последнее действие.

Хороший дашборд позволяет перейти от показателя к конкретным заказам — аналитика сразу становится рабочим инструментом. Drill-down от метрики к объектам — в кейсе операционного контура клининга; календарь обязательств и статусы — в решении для управления отчётностью.