Таблиця для обліку замовлень: готовий шаблон і коли він перестає працювати
Таблиця — нормальний перший інструмент. Вона безкоштовна, зрозуміла й не потребує нічого вивчати. Проблема не в тому, що таблиця погана, а в тому, що момент, коли вона перестає справлятися, настає непомітно: спочатку вона економить час, потім починає його забирати.
Які колонки потрібні насправді
Типова помилка — завести двадцять колонок «щоб було». Половина лишиться порожньою, і таблиця стане неприємною для заповнення. Робочий мінімум такий:
- Дата, клієнт, Instagram, телефон. Нік потрібен окремо від імені: шукати замовлення ви будете саме за ним.
- Товар, кількість, ціна, сума. Суму рахує формула, а не ви.
- Статус оплати й спосіб. Окремо, бо «оплачено частково передоплатою» — це два різні факти.
- Місто, відділення, номер ТТН. Три поля, з яких потім складається накладна.
- Статус замовлення. Найважливіша колонка: узгоджено → оплачено → зібрано → відправлено → завершено.
- Нотатки. Куди йде все, що не вліземо в структуру: «просила не дзвонити до 18», «чекає на розмір».
У Google Таблицях відкривається через Файл → Імпортувати. Розділювач — крапка з комою.
Три формули, які варто додати одразу
- Сума — множення кількості на ціну, щоб не рахувати в голові й не помилятися на нулі.
- Підсумок за період — сума по колонці за місяць. Саме це число знадобиться і для розуміння обсягів, і для звітності.
- Підсвітка застряглих — умовне форматування, яке фарбує рядок, коли статус «узгоджено», а дата старша за три дні. Це найкорисніша річ у всій таблиці: саме там лежать замовлення, які майже ваші.
Останню варто налаштувати одразу, бо вона єдина працює за вас. У Google Таблицях це Формат → Умовне форматування → Власна формула, а сама умова для рядка, що починається з другого:
=І($N2="Узгоджено"; СЬОГОДНІ()-$A2>3)
Де N — колонка статусу замовлення, A — дата. В англомовному інтерфейсі це AND і TODAY. Діапазон застосування — весь рядок, щоб фарбувався він цілком, а не одна клітинка.
Де таблиця починає ламатись
Перелічую чесно, бо кожен із цих пунктів настає непомітно.
Подвійне введення. Домовились у Direct — переписали в таблицю. Кожне замовлення ви оформлюєте двічі, і саме на другому разі виникають помилки в адресах і сумах.
Таблиця не знає про переписку. У рядку написано «чекає підтвердження», а чи відповів клієнт — треба йти дивитися. Два вікна, між якими ви ходите весь день.
Двоє людей одночасно. Google Таблиці витримують спільну роботу, але не мають поняття «хто за це відповідає». З'являється клас помилок «я думав, ти вже відправив».
Історія клієнта. Щоб побачити, що людина замовляє втретє, треба фільтрувати за ніком. На практиці цього не робить ніхто, і постійні покупці лишаються невпізнаними.
ТТН руками. Номер із кабінету перевізника копіюється в таблицю, адреса з таблиці — у кабінет. Це найдорожча рутина: кілька хвилин на кожну посилку плюс ризик переплутати відділення.
Ознаки, що ви вже переросли
- Заповнення таблиці відкладається «на ввечері» — і ввечері згадується не все.
- Ви шукаєте замовлення пошуком по сторінці частіше, ніж дивитесь у список.
- З'явилася друга таблиця «для складу» або «для повернень».
- Ви не можете назвати відсоток викупу, не сівши рахувати спеціально.
- Помилки в накладних трапляються не раз на місяць, а щотижня.
Три пункти з п'яти — уже сигнал. Не тому, що таблиця погана, а тому що ви робите руками роботу, яку робить система.
Що змінюється, коли облік перестає бути окремим файлом
Головна проблема таблиці не в її можливостях, а в тому, що вона стоїть поруч із роботою, а не всередині неї. Замовлення народжується в переписці, а живе в іншому вікні — і весь час, який ви заощадили на структурі, ви витрачаєте на перенесення даних між ними.
У Ridna замовлення створюється прямо з чату: клієнт, сума, статус, оплата й ТТН лежать там, де відбувається розмова. Ті самі колонки, що й у шаблоні вище, тільки заповнювати їх удруге не треба.