Три виручки за один місяць
У таблиці замовлень інтернет-магазину є скасовані замовлення, відмови від посилок і повернення. Питання «яка виручка за вересень» не каже, що з ними робити. Тому на одному й тому самому файлі можна отримати три різні числа, і жодне з них не буде помилкою арифметики:
Набір згенеровано кодом, числа умовні. «Без скасованих» включає відмови й повернення: гроші за них або не надійшли, або повернулися покупцю.
Різниця між першим і третім числом — 160 358 грн, або 17,7% понад фактичну виручку. Якщо асистент мовчки підсумував усі рядки, ви отримали число на 17,7% більше, ніж заробили, і воно виглядає так само переконливо, як правильне.
Модель не знає, які статуси у вашій обліковій системі означають «гроші отримано». Це знає лише власник або бухгалтер. Тому перевірка відповіді починається не з моделі, а з питання.
Умовний набір замовлень
Щоб показати розбіжності на числах, а не на словах, ми згенерували кодом умовний набір: 1 500 замовлень магазину одягу, взуття й товарів для дому за липень–вересень 2026 року. Набір вигаданий, збіги з реальними магазинами випадкові. Його можна завантажити у форматі CSV і перевірити на ньому свій асистент.
| Колонка | Що в ній |
|---|---|
| order_id | Номер замовлення. Одне замовлення може мати один, два або три рядки |
| date | Дата замовлення, РРРР-ММ-ДД |
| customer_code | Код покупця замість імені й телефону |
| channel | Сайт, маркетплейс або соцмережі |
| payment | Картка або накладений платіж |
| status | Виконано, скасовано, відмова (посилку не забрали), повернено |
| category, sku | Категорія й артикул товару |
| qty, unit_price, discount_pct | Кількість, ціна за одиницю, знижка у відсотках |
| line_total | Сума рядка після знижки, грн |
| unit_cost | Собівартість одиниці, грн |
Контрольні суми набору: 2 208 рядків, 1 500 унікальних замовлень, 2 778 одиниць товару, загальна сума рядків 3 044 536 грн. За статусами: 1 262 виконаних, 86 скасованих, 58 відмов і 94 повернення. Ці числа знадобляться для перевірки нижче.
П'ять питань і еталонні відповіді
Кожне з п'яти питань звучить звично для власника магазину. У кожному є місце, де коротке формулювання допускає дві-три відповіді. Еталон пораховано кодом на всьому наборі.
| Питання | Що в ньому неоднозначне | Відповіді на умовному наборі |
|---|---|---|
| 1. Яка виручка за вересень? | Які статуси рахувати | 1 068 816 грн усі рядки; 1 007 314 грн без скасованих; 908 458 грн лише виконані |
| 2. Який середній чек за квартал? | Ділити на рядки чи на замовлення | 1 392,78 грн на рядок; 2 042,82 грн на замовлення (виконані) |
| 3. Яка категорія найкраща? | За виручкою, прибутком чи маржею | Виручка: взуття, 1 092 907 грн. Валовий прибуток: одяг, 312 084 грн. Маржа: аксесуари, 58,3% |
| 4. Яка частка повторних покупців? | Частка людей чи частка замовлень | 49,8% покупців зробили два виконані замовлення і більше; на них припадає 82,9% виконаних замовлень |
| 5. Який канал дає найбільше повернень? | Кількість чи частка, від усіх чи від відправлених | За кількістю: сайт, 66 відмов і повернень. За часткою від відправлених: маркетплейс 12,6%, соцмережі 12,5% |
Кілька пояснень до таблиці.
Середній чек. Якщо поділити суму на кількість рядків, а не замовлень, середній чек виходить у 1,47 раза меншим: 1 392,78 грн замість 2 042,82 грн. Причина в тому, що 1 262 виконані замовлення займають 1 851 рядок. Таку помилку легко не помітити, бо обидва числа правдоподібні. Що робити із самим середнім чеком — у статті про середній чек.
Найкраща категорія. Взуття дає найбільшу виручку, але найменшу маржу, 24,7%. Одяг заробляє на 41 697 грн більше валового прибутку при меншій виручці. Валовий прибуток тут — виручка мінус собівартість товару, без доставки, комісій і реклами. Як дорахувати решту — у статті про юніт-економіку інтернет-магазину.
Повторні покупці. 49,8% і 82,9% — відповіді на різні питання. Перше каже, скільки людей повернулися. Друге — яку частку роботи магазину роблять ті, хто повернувся. Для рішення про програму лояльності потрібне друге.
Канали. Маркетплейс і соцмережі відрізняються на 0,1 відсоткового пункту. У соцмережах 208 відправлених замовлень, тож одне замовлення важить там 0,48 пункту. Різниця менша за одне замовлення, і висновку «соцмережі кращі за маркетплейс» з неї не зробити. Просіть асистента показувати поруч із відсотками кількості, з яких їх пораховано.
Як сформулювати запит
Неоднозначність знімається в самому питанні. До запиту варто додати п'ять речей:
- Період з межами. «З 1 по 30 вересня 2026 року включно, за датою замовлення».
- Статуси. «Рахуй лише статус "Виконано"». Якщо статусів у вашій системі десяток, перелічіть ті, що означають отримані гроші.
- Одиниця рахунку. «Середній чек — сума виконаних замовлень, поділена на кількість унікальних order_id».
- Спосіб розрахунку. «Покажи формулу для таблиці або код, яким рахував».
- Контрольні суми спершу. «Перш ніж відповідати, напиши кількість рядків, кількість унікальних замовлень і суму колонки line_total у всьому файлі».
Приклад запиту до умовного набору:
У файлі замовлення за липень–вересень 2026 року. Один order_id може мати кілька рядків. Спершу напиши: кількість рядків, кількість унікальних order_id, суму line_total. Потім порахуй виручку за вересень за датою замовлення лише для статусу «Виконано» і середній чек як суму line_total виконаних замовлень, поділену на кількість унікальних виконаних order_id. Покажи код або формули, якими рахував.
Чому «готові промпти для аналізу даних» тут мало допомагають, ми розбирали в статті про промпт під бізнес-задачу: визначення виручки й статусів у шаблон не вписати, вони свої в кожному магазині.
Як перевірити відповідь
Правило просте: асистент рахує, людина звіряє з числом, яке порахувала сама іншим способом. Для цього не потрібно перераховувати все — досить трьох контрольних сум і одного вибіркового числа.
- Кількість рядків, замовлень і загальна сума збігаються з вашими?Порахуйте їх у таблиці самі: кількість заповнених рядків, кількість унікальних номерів замовлень і суму колонки з сумою. На умовному наборі це 2 208, 1 500 і 3 044 536 грн. Ні → асистент прочитав файл не повністю або не так; далі не читайте
- Асистент показав формулу або код?Без них не видно, які рядки він включив. Якщо формули немає, попросіть її окремим повідомленням. Ні → відповідь не перевірити; не використовуйте її для рішень
- У формулі ті статуси й той період, які ви назвали?Подивіться на умову фільтра: чи немає там «Скасовано», чи межа періоду 30 вересня, а не 1 жовтня. Ні → поправте запит, а не число
- Одне число збігається з вашим ручним розрахунком?Візьміть одну категорію або один тиждень і порахуйте фільтром чи зведеною таблицею. Так → відповіді можна довіряти в межах цього файла й цих визначень
Для другого кроку в таблиці зазвичай досить однієї формули на зразок SUMIFS(сума; статус; "Виконано"; дата; ">=2026-09-01"; дата; "<=2026-09-30"). Назви функцій і роздільник аргументів залежать від програми й мовних налаштувань.
Перевірка контрольних сум займає кілька хвилин і відсікає найнебезпечніший випадок: коли асистент прочитав лише частину файла або неправильно розпізнав колонки й упевнено рахує далі.
Які колонки прибрати перед завантаженням
Для п'яти питань вище не потрібна жодна колонка, за якою можна впізнати покупця. Код покупця замість імені дає ту саму частку повторних покупців. Перед завантаженням вивантаження з CRM чи адмінки магазину:
| Колонка | Що зробити |
|---|---|
| Ім'я, прізвище, телефон, email | Видалити; якщо потрібні повторні покупці — замінити кодом |
| Адреса, відділення, номер накладної | Видалити; для аналізу за регіонами лишити область або місто |
| Коментар покупця, нотатки менеджера | Видалити: там часто трапляються телефони й особисті подробиці |
| Реквізити оплати, частина номера картки | Видалити завжди |
| Собівартість і закупівельні ціни | Лишити лише на тарифі, де дані не використовують для навчання моделі |
Які дані можна давати ШІ-асистенту на різних тарифах, ми розбирали окремо в статті про дані для ШІ-асистента.
Наша позиція
Використовуйте ШІ-асистента для аналізу таблиці продажів як швидкий калькулятор із поясненнями, а не як джерело визначень. Визначення виручки, середнього чека й повторного покупця записуйте один раз, вставляйте в кожен запит і перевіряйте кожну відповідь трьома контрольними сумами. Так асистент економить час на формулах і зведених таблицях, а рішення не залежить від того, як він зрозумів коротке питання.
Позиція не діє, якщо у вас уже є звіт в обліковій системі, де ці визначення зафіксовані й перевірені бухгалтером: тоді ставити ті самі питання асистенту нема сенсу, а розбіжність між двома джерелами доведеться пояснювати окремо. Вона також не діє для таблиць, де в колонці суми змішано валюти чи суми з ПДВ і без нього: таку таблицю спершу треба привести до одного виду, інакше контрольна сума збіжеться, а виручка — ні.
Перевірено 10 листопада 2026 року: усі числа в статті перераховано кодом на умовному наборі з 1 500 замовлень, згенерованому для цієї статті. Моделі ШІ на наборі не запускалися, тож стаття не оцінює точність конкретних асистентів, а показує, де одна таблиця дає кілька правильних відповідей.