bober-bbq-bot/docs/TODO.md

TODO — ідеї на майбутнє

Не заплановані задачі, а бэклог ідей, які варто розглянути пізніше, якщо буде запит від замовника. Нічого звідси не потрібно робити зараз.

CRM-можливості (система зараз — "CRM-lite" для одного закладу)

Вже є: картка клієнта з історією замовлень (/admin/customers), розсилка всім клієнтам (/admin/broadcast), статистика (повторні клієнти, топ-товари, виручка), промокоди з умовами, два рівні доступу адмінки (admin/manager, bober_bbq/admin/authz.py). Чого немає — і що можна додати точково, без переробки системи, якщо знадобиться:

1. Нотатки по клієнту — вільне текстове поле на картці клієнта (/admin/customers/<id>) для приміток персоналу ("любить гострий соус", "просив передзвонити"). Найпростіша реалізація: нова таблиця customer_notes (customer_telegram_id, text, created_by, created_at) або просто TelegramUser.admin_note текстове поле.
2. Теги/сегменти клієнтів (напр. «VIP», «неактивний 30+ днів», «часто скасовує») — для фільтрації в /admin/customers і, головне, для розсилки не всім одразу, а конкретному сегменту.
3. Сегментована розсилка — зараз /admin/broadcast шле повідомлення всім клієнтам одразу (за винятком walk-in/гостей, вже виключені). Додати фільтр за сегментом/тегом, датою останнього замовлення, типом замовлень (тільки доставка/самовивіз) тощо.
4. Гнучкіші ролі персоналу — зараз лише admin (повний доступ) і manager (без частини налаштувань/постачальників). Можна додати, напр., роль «лише перегляд замовлень» для кухні/офіціантів без доступу до налаштувань і фінансів.
5. Розсилка поза Telegram (email/SMS) — зараз єдиний канал сповіщень і розсилки — Telegram-бот; клієнт без Telegram (гість, див. docs/API.md) розсилку взагалі не отримує. Додавання email вимагає SMTP-налаштувань і поля email на замовленні/клієнті; SMS — окрема вартість, раніше свідомо відхилено замовником.
6. Воронка/ліди — якщо колись знадобляться попередні заявки (наприклад, для кейтерингу чи корпоративних замовлень) окремо від звичайного меню — зараз такого етапу немає, кожне замовлення одразу є фінальним.
7. Глибша аналітика — LTV клієнта, retention/cohort-графіки, динаміка по днях тижня/годинах. Зараз /admin/statistics дає зведені цифри за період, без часових рядів чи прогнозів.

Технічні TODO

• Postgres-бекапи — див. docs/DEPLOYMENT.md, розділ "⚠️ TODO перед реальним переходом: автоматичні бекапи не підтримують Postgres".

Пакування для інсталяції новим клієнтам

Зараз є provision_client.sh — автоматизує розгортання нового клієнта, але тільки на вже підготовленому Linux VPS (python3.11, nginx, certbot, nodejs мають бути встановлені вручну заздалегідь, крок 1 docs/DEPLOYMENT.md). Це не самодостатній "пакет для інсталу".

• .deb-пакет — розглянули й відхилили. Дебіан-пакети добре підходять для "поставив і забув" софту без інтерактивного налаштування. У нас навпаки: кожному клієнту потрібен свій домен, Telegram bot-token, назва закладу, TLS-сертифікат і збірка фронтенду (npm run build) — усе це довелось би тягнути через незручні debconf-запитання і postinst-скрипти, які по суті дублювали б provision_client.sh, тільки жорсткішим і складнішим у підтримці способом.
• Docker / Docker Compose — обраний напрямок. Multi-service (бот + вебапка + nginx, за потреби Postgres) + конфігурація через .env — саме для цього Compose і придуманий, і працює на будь-якому Linux (і навіть Windows через WSL), а не лише Debian/Ubuntu з apt. Мінус: не відчувається "нативним" для адміна, який звик до apt install — але оновлення/відкат/перенесення на інший сервер значно простіші, ніж з .deb.
• Обсяг роботи, якщо братись: Dockerfile для Flask-застосунку й бота (спільний образ чи два окремих — треба вирішити), окремий крок збірки webapp/ (multi-stage build, щоб не тягнути node в прод-образ), docker-compose.yml зі змінними з .env, і окремо подумати про TLS (Let's Encrypt всередині контейнера чи залишити nginx+certbot на хості, як зараз).