Розробка звітів з воронки замовлень 1С-Бітрікс

Чому воронка замовлень — ключова метрика e-commerce?

Магазин отримує 500 замовлень на день, але виконується лише 320. Куди зникають решта 180? На якому етапі — «Новий», «Підтверджено», «Зібрано», «Передано в доставку» — відбувається найбільший відсів? Без звіту по воронці замовлень відповісти на це питання можна лише вручну, перебираючи замовлення в адмінці. Це неприйнятно при масштабі від кількох сотень замовлень на день. Замість ворожіння по стрічці дій ви отримуєте точну картину кожного етапу — з цифрами та відсотками.

Ми, команда сертифікованих бітрікс-розробників з 5+ років досвіду, пропонуємо розробку звітів по воронці замовлень під ключ. Оцінимо ваш проєкт за 1 день і підготуємо дорожню карту. У результаті ви отримаєте дашборд, який покаже, де втрачаються замовлення і скільки грошей це коштує бізнесу.

Модель статусів замовлення в Бітріксі

Статуси зберігаються в таблиці b_sale_status. Кожне замовлення має поточний статус (STATUS_ID в b_sale_order), а історія переходів фіксується в b_sale_order_change — таблиці з полями ORDER_ID, TYPE, DATA, DATE_CREATE, USER_ID.

Проблема: b_sale_order_change зберігає всі зміни замовлення у формалізованому вигляді, не лише зміну статусу. Записи зі зміною статусу мають TYPE = 'ORDER_STATUS_CHANGED'. З поля DATA (JSON) вилучаємо старий і новий статус.

Типова ланцюжок статусів e-commerce:

N (Новий) → P (Підтверджено) → A (Зібрано) → G (Передано кур'єру) → F (Виконано) → D (Скасовано) 

Нетипові переходи (повернення, повторне відкриття) теж фіксуються і важливі для аналізу.

Як побудувати воронку по статусах замовлень?

Воронка — це підрахунок кількості замовлень, що пройшли через кожен статус, та конверсії переходу між сусідніми етапами. Метод через історію змін з віконними функціями в 3 рази точніший за простий груповий запит по поточних статусах.

SQL-запит з віконними функціями:

WITH status_transitions AS ( SELECT o.ID AS order_id, o.DATE_INSERT, s.SORT AS status_sort, s.ID AS status_id, ROW_NUMBER() OVER (PARTITION BY o.ID ORDER BY oc.DATE_CREATE) AS transition_num FROM b_sale_order o JOIN b_sale_order_change oc ON oc.ORDER_ID = o.ID JOIN b_sale_status s ON s.ID = JSON_EXTRACT(oc.DATA, '$.STATUS_ID') WHERE oc.TYPE = 'ORDER_STATUS_CHANGED' AND o.DATE_INSERT >= NOW() - INTERVAL 1 YEAR ), max_status AS ( SELECT order_id, MAX(status_sort) AS max_reached_sort FROM status_transitions GROUP BY order_id ) SELECT s.ID AS status_id, s.SORT, (SELECT COUNT(*) FROM max_status ms WHERE ms.max_reached_sort >= s.SORT) AS orders_reached, LAG((SELECT COUNT(*) FROM max_status ms WHERE ms.max_reached_sort >= s.SORT)) OVER (ORDER BY s.SORT) AS prev_count FROM b_sale_status s WHERE s.TYPE = 'O' ORDER BY s.SORT; 

Конверсія кожного етапу = orders_reached / prev_count * 100%. Наприклад, якщо до статусу «Підтверджено» дійшли 450 з 500 — конверсія 90%, втрата 10% — це замовлення, скасовані до підтвердження.

Альтернативний підхід — через поточні статуси. Простіше, але менш точно: SELECT STATUS_ID, COUNT(*) FROM b_sale_order WHERE DATE_INSERT >= ... GROUP BY STATUS_ID. Показує розподіл замовлень за поточним статусом, але не враховує динаміку — замовлення, що пройшло всі етапи і виконане, не видно в проміжних статусах.

Час обробки на кожному етапі

Друга найважливіша метрика воронки — скільки часу замовлення проводить у кожному статусі. Розраховується як різниця DATE_CREATE між сусідніми записами в b_sale_order_change.

SELECT status_id, AVG(time_in_status) AS avg_minutes, PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY time_in_status) AS median_minutes, PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY time_in_status) AS p95_minutes FROM ( SELECT order_id, status_id, EXTRACT(EPOCH FROM (next_transition - transition_time)) / 60 AS time_in_status FROM transitions_with_next ) sub GROUP BY status_id; 

Медіана важливіша за середнє. Одне замовлення, що зависло на тиждень, перекошує середнє. P95 показує «хвіст» — замовлення з аномально довгою обробкою.

Аналіз причин скасувань

Скасування — це витік з воронки. Звіт показує: з якого статусу відбулося скасування, хто скасував (клієнт/менеджер), причина (якщо заповнюється у властивостях замовлення).

Групування скасувань за етапом, на якому вони сталися, виявляє системні проблеми:

• Скасування на етапі «Новий» — клієнт передумав, дубль замовлення, тестові замовлення
• Скасування після підтвердження — товар закінчився на складі (проблема з залишками)
• Скасування після збірки — помилка в адресі, клієнт не виходить на зв'язок

Який метод розрахунку воронки точніший?

Метод на основі історії змін (з віконними функціями) дає повну картину проходження кожного замовлення за статусами. Він у 3 рази точніший, ніж групування за поточними статусами, оскільки враховує всі переходи, а не фінальний стан. Ми використовуємо його у 100% проєктів як базовий, а для оперативного контролю — простий зріз за поточними статусами.

Візуалізація воронки

Воронка відображається як горизонтальна або вертикальна діаграма зі зменшуваними секціями. Реалізація через Chart.js з плагіном chartjs-plugin-funnel або через SVG-генерацію на бекенді.

На дашборді розміщуємо:

• Funnel chart — візуальна воронка з відсотками конверсії
• Таблиця — деталізація: кількість, конверсія, середній час на етапі
• Line chart — динаміка конверсії по тижнях (тренд: покращується чи погіршується)
• Фільтри — період, менеджер, платіжна система, спосіб доставки

Експорт в Excel через PhpSpreadsheet з окремими аркушами: зведення воронки, деталізація по менеджерах, список скасованих замовлень з причинами.

Як налаштувати автоматичні алерти?

Звіт по воронці корисний не тільки ретроспективно. Налаштовуємо агент Бітрікса, який щогодини перевіряє:

• Конверсія «Новий → Підтверджено» за останню годину < 70% → сповіщення керівнику
• Середній час у статусі «Новий» > 1 година → сповіщення старшому менеджеру
• Кількість скасувань за день > 20% від замовлень → алерт

Ми гарантуємо, що алерти працюють без збоїв: тестуємо на реальних даних і налаштовуємо пороги під ваш бізнес.

Що входить у роботу

• Мапінг статусів і бізнес-логіки переходів
• Розробка SQL-запитів та ORM-вибірок для розрахунку воронки, часу та скасувань
• Візуалізація: дашборд з Chart.js (funnel, таблиця, line chart)
• Налаштування агентів та алертів з Telegram/Slack-сповіщеннями
• Експорт в Excel з деталізацією по розділах
• Документація та навчання співробітників роботі з дашбордом

Терміни розробки

Загальний термін — 1-2 тижні. Результат — дашборд, який показує, де втрачаються замовлення і скільки грошей це коштує бізнесу.

Зв'яжіться з нами для консультації — ми оцінимо ваш проєкт за 1 день. Замовте розробку звіту по воронці замовлень під ключ: гарантуємо точність до 95% проти 50% при ручному аналізі.