Таблиця план-факт, яку власниця вела руками: тепер вона рахується сама і зʼясувала, чому цифри не сходились

Власниця бізнесу щодня відкриває одну таблицю: скільки продали вчора, хто з менеджерів у плані, чи встигаємо на місяць, скільки повернулося. Таблицю хтось має заповнювати. Щовечора, руками, з CRM.

Ручна таблиця живе своїм життям. Формули копіюються з місяця в місяць, план змінюється, а поріг у форматуванні лишається старим. І коли цифри «не сходяться з CRM», ніхто не знає, хто правий.

Тепер таблиця заповнюється сама. А її перевірка по ходу пояснила, чому цифри розходились, - і виявилось, що праві були обидві сторони.

Проблема: таблиця, якій довіряють, але яку ніхто не перевіряє

Продажі йдуть через дірект в Instagram, у кожної менеджерки свій KPI. Звіт у CRM показує не те й не так, як звикла дивитися власниця, тому паралельно ведеться своя таблиця. І саме вона стає джерелом рішень.

Як автоматизація це вирішує

Ми не підключали таблицю напряму до CRM. У CRM жорсткий ліміт звернень, який вона ділить з обміном з обліковою системою, і зайве навантаження зачепило б склад. Тому між ними стоїть проміжна ланка.

Замовлення складаються у власну копію бази, історія підтягується один раз, далі щогодини оновлюється лише поточний місяць. З копії рахується все: продажі по днях і по менеджерках, одиниці, середній чек, кількість одиниць у чеку, повернення, виконання плану, проєкція на кінець місяця. Готові цифри записуються в нову Google-таблицю з тим самим виглядом і кольорами, до яких звикла власниця.

Стару таблицю ми не чіпали. Поки цифри не зійшлися, вона велася паралельно - як страховка, а не як додаткова робота.

Ключова ідея: «зафіксовано» і «актуально» - це дві різні правильні цифри

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

Ручна таблиця - це знімок у день продажу. CRM - живий стан сьогодні. Праві обидві. Тому в таблиці тепер три колонки: зафіксовано, актуально і різниця між ними. План і KPI менеджерок рахуються від зафіксованого, як і було заведено. А різниця стала окремою метрикою, якої раніше не існувало: скільки продажів «сипеться» після оформлення.

Що знайшлося в ручній таблиці

Звірка з автоматикою - це ще й аудит ручних формул. У таблиці знайшлося три різні уявлення про денний план одночасно. Кольорове форматування підсвічувало виконання за порогом, що лишився від місяця з іншим планом, - на третину вищим за реальний. Формула «мало бути» ділила план на 31 день у 30-денному місяці. А за всю історію виконання плану порівнювалось з одним і тим самим планом, хоча плани по місяцях різнилися майже вдвічі.

Що це дало бізнесу

Щоденна частина таблиці більше не потребує жодного ручного введення. Історія з січня перерахована заднім числом за правильними планами кожного місяця - понад 28 тисяч замовлень, і за березень розбіжність із ручною таблицею власниці склала 0,09%. Зʼявилися аркуші, яких раніше не було: підсумки по місяцях, матриця менеджерок по місяцях, проєкція на кінець місяця.

Разом із цим проявилась річ, яку ручна таблиця ховала: у березні повернень у CRM більше, ніж замовлень. Схоже, у момент, коли CRM почали вести коректно, старі замовлення масово закрили відмовою. Це не помилка розрахунку, а стан даних, і тепер він підписаний у таблиці, щоб на ньому не будували висновків.

Чесно про межі. Дві колонки - кількість діалогів і конверсія з діалогу в продаж - поки лишаються ручними: у CRM діалоги рахуються інакше, ніж бачить їх власниця, і потрібне калібрування під її фільтр. Повернення за перші місяці року недостовірні через стан CRM, а не через розрахунок.

Як це влаштовано всередині

Сервіс на FastAPI з APScheduler, основа взята з уже працюючого щоденного звіту продажів для іншого клієнта. Клієнт CRM з повторами й пагінацією, віконна логіка Київ і UTC з урахуванням переходу на літній час, ідемпотентність запуску.

Кілька технічних деталей, без яких цифри б не зійшлися. API CRM не вміє фільтрувати за датою закриття, тому береться ширша вибірка за датою оновлення і фільтрується вже в сервісі. Дата оновлення в CRM не змінюється при зміні оплати чи відповідального менеджера, тому вікно поточного місяця періодично перечитується повністю. Білий список менеджерів довелось замінити на чорний: із білим історія січня-липня показувала лише двох людей, бо частина менеджерів тоді ще працювала, а зараз уже ні.

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

Кому це підходить

Бізнесу, де власник чи керівник продажів веде свою таблицю паралельно з CRM, бо звіт CRM показує «не те». Особливо там, де у менеджерів є план і KPI, а продажі йдуть через месенджери й соцмережі.

Ознака, за якою легко перевірити, чи це про вас: якщо щовечора хтось переносить цифри з CRM в Excel, а на питання «чому в CRM інша сума» відповідають «ну, там щось змінилось», - так, це про вас.

Автоматизація таблиці - це ще й перший за довгий час аудит формул, яким усі довіряли просто тому, що вони завжди там були.