кейс 02LIVE · ПРАЦЮЄ У КЛІЄНТА

Telegram-бот, який прибрав дзвінки з бронювань дитячого кафе

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

Термін: ~2 тижні до продакшну · ~3 тижні до передачі власникам
Стек: Python · aiogram 3 · SQLite · SQLAlchemy async · APScheduler · Telethon e2e · pytest · systemd
Виконавець: Forge Logic

723автотести у фіналі — на старті було 49

~2 тиж.від першого рядка коду до продакшну

3ролі: клієнт, персонал, адмін

42живі e2e-сценарії прямо через Telegram — на старті 8

157знахідок першого аудиту коду → 8 фаз рефакторингу

16фаз розробки й доробок

0:30

Що боліло

Бронювання йшли дзвінками й повідомленнями. Ніхто не бачив повну картину зайнятості. Два великих свята з орендою всього кафе могли накластися на один час.

Майстер-класи часто скасовували через недобір дітей. Бажаючі записувались, але про набір групи їх ніхто вчасно не сповіщав.

Вимоги клієнта

Без окремого сайту й домену на старті, лише Telegram.
Ціни й пакети власниця має міняти сама, без програміста.
Тон бота — теплий, бо аудиторія — батьки з дітьми.

Рішення

Бот має три незалежні «входи» за роллю. При старті він визначає, хто пише: адмін, персонал чи клієнт. Кожен бачить лише своє меню.

Клієнтсвята, майданчик, майстер-класи, столики, «Мої бронювання»

Персоналрозклад на сьогодні, позначки візитів; вхід за кодом-запрошенням

Адмінпакети, ціни, аніматори, розсилки, статистика

БОТ · AIOGRAM 3

Визначення роліодна функція на вході — кожен бачить лише своє меню

Меню роліобробники кнопок лише викликають сервіси

Сервісний шарціни, перевірка зайнятості, валідація — в одному місці

ДАНІ Й ФОН

SQLiteодин файл на диску; стан діалогів теж тут

Планувальникнагадування за добу, вітання з днем народження

Журнал збоївпомилка з будь-якого шару — адміну в Telegram

Схема бота: Telegram → визначення ролі → меню ролі → сервісний шар → SQLite; планувальник читає ту саму базу

Клієнтська частина. Бронювання майданчика, свята, майстер-класу, столика. Реєстрація дня народження дитини. Кабінет «Мої бронювання» і «Мої дані». Контакти з посиланням на карту.
Панель персоналу. Бронювання на сьогодні й найближчі дні, позначки «виконано» / «не прийшов», QR-код бота для ресепшену. Доступ — через одноразовий код-запрошення від адміна.
Адмінка. Редагування пакетів, цін, майстер-класів, аніматорів і столиків. Перегляд і скасування бронювань. Розсилка новин тим, хто погодився. Статистика. Журнал збоїв.
Сервісний шар стоїть між меню і базою даних. Тут живе вся бізнес-логіка: ціни, перевірка зайнятості, валідація вводу. Обробники кнопок лише викликають ці функції. Так одне правило не дублюється в чотирьох місцях.
База даних — SQLite. Це один файл на диску, без окремого сервера. Для одного кафе цього достатньо. Тестова база повністю ізольована.
Планувальник запускає задачі за розкладом: нагадування за добу до бронювання і щорічні привітання дітей з днем народження.

Історія розробки

feat(core)#01

Старт і перший робочий бот

Що сталось: у власниці не було готового бачення, як це має працювати.

Як вирішили: розробили ТЗ, пройшли всі болючі етапи, визначились із функціоналом і підготували скелет.

fix(animators)#02

Аніматор не може бути на двох святах

Що сталось: аніматор може бути лише на одному святі одночасно, навіть якщо кафе не орендоване цілком. Перша версія вибору змушувала обрати всіх аніматорів або скасувати бронювання.

Як вирішили: вибір по кожному місцю окремо, з кнопкою «Не обирати». Зайнятих на цей час аніматорів у списку просто немає.

fix(roles)#03

Кожна роль — тільки своє меню

Що сталось: адмін і персонал бачили клієнтське меню разом зі своїм.

Як вирішили: єдина функція визначає роль при вході. Кожна роль бачить тільки свою панель.

ops(audit)#04

Аудит і рефакторинг

Що сталось: після десятка фаз накопичився технічний борг. Аудит знайшов 157 проблем.

Як вирішили: вісім фаз рефакторингу. Чотири критичні знахідки — усі про гонки даних — закрито окремою фазою.

fix(state)#05

Старі меню після перезапуску сервера

Що сталось: після перезапуску сервера в адміна накопичувались старі меню. Бот тримав стан діалогів лише в оперативній пам’яті.

Як вирішили: переніс стан діалогів у ту саму SQLite-базу. Тепер він переживає перезапуск, і бот прибирає свої старі повідомлення.

fix(notify)#06

Сповіщення про нові бронювання не доходили адміну

Що сталось: сповіщення про нові бронювання не приходили адміну.

Як вирішили: логіка сповіщень дивилась лише на власницю й персонал. Виправлено.

Макет Mini App

На основі робочого бота зробив клікабельний макет Telegram Mini App: ті самі сценарії, але з візуальним календарем, картками й одним екраном замість ланцюжка повідомлень.

Головна — Назва кафе, імена й аніматори в макеті вигадані, ціни умовні. Логіка кроків — з робочого бота.

Вибір пакету — Назва кафе, імена й аніматори в макеті вигадані, ціни умовні. Логіка кроків — з робочого бота.

Уроки

Зелені тести не означають хороший UX. Майже всі незручності знайшов живий прохід, а не 700+ автотестів.
Коміти між фазами. Кожна нова фіча чіпала ядро даних, і без точки відкату один невдалий прогін коштував би дня.
Скоуп росте сам. Бот бронювання за тиждень став CRM з трьома ролями. Пауза «пожити з продуктом» дала б більше, ніж ще одна фіча.

Результат

Бот працює на сервері як системна служба з автоперезапуском.

Клієнти бронюють свята, майданчик, майстер-класи й столики.
Персонал бачить розклад і відмічає візити.
Адмін керує цінами й отримує збої в Telegram.