FynexСкільки днів посилка лежить на відділенні: екран, якого не було в CRM
CRM показує дату створення замовлення, а не скільки посилка вже чекає клієнта. Менеджери відкривали кожну картку. Тепер у них один екран: хто в пріоритеті, коли почнеться платне зберігання і де CRM розійшлась із перевізником.
- Усі посилки, що чекають клієнта, повертаються або по яких не додзвонились, на одному екрані з кольором пріоритету
- Дні рахуються від фактичного прибуття на відділення за даними перевізника, а не від дати замовлення
- Уже в перший день 59 із 259 замовлень у статусі «чекає на відділенні» виявились такими, яким дзвонити не треба: посилку вже забрали або вона повертається
- Щоночі звірка з перевізниками знаходить десятки посилок, які фактично вже на відділенні, хоча CRM досі пише «в дорозі»
Екран працює з 23 вересня 2026. Скільки посилок він повертає з дороги назад до клієнта, фіксується на даних наступних тижнів, тому тут поки лише те, що видно з першого дня.
Посилка доїхала до відділення і чекає. Кілька днів безкоштовно, далі клієнт починає платити за зберігання, а потім вона їде назад. Зворотну доставку оплачує магазин, а продукти не завжди можна повернути в продаж.
Щоб цього не сталося, менеджер має вчасно подзвонити. Але спершу він має зрозуміти, кому. А CRM у списку показує дату створення замовлення, а не скільки днів посилка вже лежить. Тож менеджер відкриває картки по одній.
Тепер у відділу продажів є один екран, де ця відповідь готова.
Проблема: у CRM немає відповіді на найпростіше питання
«Скільки днів посилка лежить на відділенні?» Питання звучить так, ніби відповідь десь поруч. Насправді її немає ні в списку замовлень, ні у фільтрах.
📅 Не та дата
- Фільтр CRM - за датою створення замовлення
- Замовлення тижневої давності могло приїхати вчора
🔍 По одній картці
- Скільки лежить - видно лише всередині замовлення
- Сотні замовлень у статусі - години на перегляд
🤥 Статус бреше
- Посилку вже забрали, а в CRM «чекає»
- Посилка вже на відділенні, а в CRM «в дорозі»
Третя причина найпідступніша. Менеджер дзвонить людині, яка посилку забрала ще минулого тижня, - і виглядає так, ніби магазин не знає, що відбувається з його замовленнями. А посилка, яка насправді вже лежить, у список «чекає» просто не потрапляє.
Як автоматизація це вирішує
Кожні пʼятнадцять хвилин сервіс збирає всі замовлення в трьох станах: чекає на відділенні, повертається, не вдалося звʼязатися. Для кожного питає перевізника, що з посилкою насправді. І складає один список, відсортований за тим, кому дзвонити першим.
Ключова ідея: правду про посилку знає перевізник, а не CRM
Дні рахуються від моменту, коли посилка фактично прибула на відділення, за даними самого перевізника. Якщо перевізник каже «видано» або «повернення», а CRM досі пише «чекає», замовлення потрапляє в окрему групу: клієнту дзвонити не треба, треба виправити статус.
А щоночі сервіс робить зворотну перевірку: проходить замовлення, які CRM вважає «в дорозі», і питає перевізника, чи не приїхали вони вже. Такі посилки зʼявляються в списку з позначкою «CRM відстає» ще до того, як статус оновиться.
Що дістається людині
Менеджерка обирає себе - і бачить лише свої замовлення. Поруч із кожним дата прибуття, дата початку платного зберігання (найсильніший аргумент у розмові з клієнтом) і журнал дзвінків, видимий усім. Натиснула «подзвонила», залишила коментар - колега не набере тій самій людині вдруге.
Що це дало бізнесу
Перше, що показав екран, - масштаб розбіжності між CRM і реальністю. У день запуску в статусі «чекає на відділенні» було 259 замовлень, і 59 з них насправді вже не чекали: посилку забрали або вона повертається. Більшість - старші за два тижні, давній залишок, який ніхто не бачив, бо шукати його треба було по одній картці.
Нічна звірка щоразу знаходить десятки посилок, які фактично вже на відділенні, хоча CRM досі вважає їх «в дорозі». Раніше вони потрапляли в поле зору менеджера із запізненням на дні.
Екран не навантажує CRM, скільки б людей його не відкрили: менеджери дивляться на копію даних у сервісі, а сам сервіс робить кілька запитів до CRM за оновлення.
Чесно про межі. Екран не дзвонить і не пише клієнтам сам - нагадування клієнтам робить окремий сервіс, про який є кейс «Хвіст замовлення». Тут інструмент для людини, яка має подзвонити. Відстеження Укрпошти чекає окремого ключа доступу, тож для неї дні поки рахуються від зміни статусу в CRM. І скільки посилок екран повертає до клієнтів, покажуть наступні тижні.
Як це влаштовано всередині
Наступний розділ пояснює, як система влаштована. Якщо вас цікавить лише результат, його можна пропустити - нижче є розділ про те, кому це підходить.
Сервіс на FastAPI з APScheduler, сторінка на Jinja2 без зовнішніх залежностей, зі світлою й темною темою і нормальним виглядом на телефоні. Власна сторінка входу з сесією на підписаній cookie і обмеженням невдалих спроб.
Власний журнал переходів - не надмірність. Він дає незалежну відповідь на питання, скільки в середньому посилка лежить на відділенні, і не залежить від того, як і коли в CRM переставляють статуси. З цього ж журналу видно, які замовлення виходять зі статусу без дзвінка, а які - після.
Імена менеджерів беруться із самих замовлень у CRM, жодних ручних списків, які треба підтримувати. Коли в команді зʼявляється нова людина, вона зʼявляється і на екрані.
Кому це підходить
Магазинам, які відправляють через відділення перевізників, особливо з післяплатою: кожна посилка, що поїхала назад, - це дві оплачені доставки і втрачений продаж. І відділам продажів, де менеджери обдзвонюють посилки, але список «кому дзвонити» складають вручну.
Ознака, за якою легко перевірити, чи це про вас: якщо на питання «скільки посилок зараз лежить на відділенні понад пʼять днів» ніхто не може відповісти без години роботи з CRM - так, це про вас.
Найдешевший продаж - той, що вже доїхав до клієнта. Треба лише вчасно побачити, що він там чекає.
Потрібне схоже рішення?
Опишіть задачу - підберу архітектуру під ваш бюджет і дані.