Як створити застосунок для бронювання: слоти, доступність, нагадування та передоплата

Щоб створити застосунок для бронювання, потрібні чотири речі, що працюють разом: список того, що можна забронювати (послуги, кімнати, персонал), правила доступності кожного з них, процес бронювання, який пропонує лише справді вільні слоти, і приватний вигляд, де бізнес керує надходженнями. Конструктор застосунків на базі ШІ може за кілька хвилин створити робочу першу версію з короткого опису; справжня робота полягає у визначенні правил — тривалість слоту, буфери, скасування, часові пояси — і в перевірці, що подвійні бронювання неможливі.

Почніть з того, що для вас означає «бронювання»

Застосунки для бронювання зовні схожі, але всередині сильно відрізняються. Спершу дайте відповіді на такі запитання:

• Що бронюється? Послуга (стрижка), людина (репетитор), ресурс (конференц-зал, корт, фургон) або місце на занятті (йогу з 12 місцями).
• Скільки це триває? Фіксовано для кожної послуги чи обирає клієнт?
• Хто надає послугу? Одна людина, кілька співробітників зі своїм графіком чи ніхто (кімната)?
• Що відбувається після бронювання? Миттєве підтвердження чи запит, який схвалює власник?
• Чи є гроші? Безкоштовно, оплата на місці, передоплата чи повна попередня оплата?

«Запросити час, власник підтвердить електронним листом» створити значно простіше, ніж «миттєве бронювання з перевіркою календарів трьох співробітників і передоплатою». Обидва варіанти правильні — оберіть той, який справді потрібен для першої версії.

Що потрібно застосунку

Дані

Зберігання часу завершення для кожного бронювання, а не лише часу початку, значно спрощує перевірку перетинів.

Сторінки

• Публічні: список послуг, вибір слоту, форма бронювання, сторінка підтвердження та посилання на скасування або перенесення.
• Приватні (власник або персонал): розклад на сьогодні, майбутні бронювання, можливість заблокувати час відпустки та налаштування послуг і годин.

Права доступу

Клієнти мають бачити лише вільні або зайняті слоти — ніколи імена інших клієнтів. Персонал може бачити лише свій розклад; власник бачить усе. Запишіть це, адже від цього залежить, чи потрібні вхід і ролі. У нашому посібнику про додавання входу до застосунку розглянуто варіанти.

Складні частини та як із ними працювати

Подвійні бронювання

Класична помилка: двоє людей завантажують сторінку, обидва бачать вільні 10:00 і обидва бронюють цей час. Виправлення — перевірити ще раз на сервері під час збереження бронювання і відхилити його, якщо щось тепер перетинається. Попросіть це явно:

Під час збереження бронювання повторно перевір на сервері, що для того самого співробітника немає підтвердженого або очікуючого бронювання, яке перетинається із запитаним часом (включно з буфером). Якщо таке є, відхили бронювання й покажи повідомлення «Цей час щойно зайняли — будь ласка, оберіть інший».

Потім перевірте це двома вікнами браузера.

Часові пояси

Зберігайте кожен час в UTC і конвертуйте його для відображення. Вирішіть, часовий пояс якої сторони показувати на сторінці бронювання — зазвичай бізнесу для послуг на місці та клієнта для онлайн-дзвінків — і позначте це на сторінці. Перевірте бронювання під час переходу на літній час.

Буфери, попередження та обмеження

Поширені правила, які варто визначити заздалегідь: буфер між записами, мінімальний термін попередження («не бронювати менше ніж за 2 години»), як далеко наперед можна бронювати і денний ліміт. Кожне з них — одне речення в запиті; якщо їх пропустити, ШІ сам обере значення за замовчуванням.

Скасування та неявки

Дайте кожному підтвердженню посилання на скасування з унікальним токеном, щоб клієнтам не потрібен був обліковий запис. Визначте вікно для скасування, чи повертаються передоплати, і покажіть цю політику до оплати.

Нагадування

Нагадування електронною поштою або SMS потребують чогось, що працює за розкладом («кожні 15 хвилин надсилати нагадування про бронювання, що починаються через 24 години»). Перевірте, як ваш конструктор і хостинг працюють із запланованими завданнями. Якщо вони не підтримують це, використайте зовнішній планувальник, який викликає ендпоінт вашого застосунку, або надсилайте лист із підтвердженням із доданим запрошенням до календаря, щоб календар клієнта сам нагадав йому. Про сторону провайдера див. як надсилати листи з вашого застосунку.

Передоплата та платежі

Типовий шаблон зі Stripe:

1. Клієнт обирає слот; застосунок створює очікуване бронювання, яке утримує слот на короткий час (скажімо, 15 хвилин).
2. Застосунок перенаправляє клієнта на Stripe Checkout для передоплати.
3. Stripe надсилає вашому застосунку сповіщення через webhook після успішної оплати; бронювання стає підтвердженим.
4. Якщо оплати не відбулося вчасно, очікуване бронювання спливає і слот звільняється.

Стандартна ціна Stripe — відсоток плюс фіксована комісія за кожну успішну оплату карткою без щомісячної плати (станом на вересень 2026 року); ставки залежать від країни, тож перевірте сторінку цін Stripe для своєї. Використовуйте тестовий режим і тестові картки, доки все не запрацює. Наш посібник з додавання платежів описує це крок за кроком.

Перший запит, який працює

Створи застосунок для бронювання для Northside Barbers. Послуги: Стрижка (30 хв, $25), Підрівнювання бороди (15 хв, $12), Стрижка + борода (45 хв, $32). Два майстри, Сем і Алі, кожен працює від вівторка до суботи з 9:00 до 18:00. Клієнти обирають послугу, потім майстра або «будь-який майстер», і бачать лише вільні початки по 15 хвилин на наступні 14 днів, а також вводять ім'я, телефон і електронну пошту. Зберігай бронювання в базі даних, з буфером 10 хвилин після кожного запису, і повторно перевіряй доступність під час збереження, щоб запобігти подвійному бронюванню. Показуй сторінку підтвердження з посиланням на скасування. Власник має приватну сторінку зі списком бронювань на сьогодні та найближчих, може скасувати бронювання й заблокувати час. Час вказаний у місцевому часовому поясі майстерні. Чистий дизайн, орієнтований на мобільні пристрої.

У ньому названо послуги, персонал, години, правила та вигляд для власника — усе те, що ШІ інакше довелося б вгадувати.

Кроки побудови

1. Спершу основний процес бронювання. Послуги → слот → форма → збережене бронювання → підтвердження. Нічого іншого, доки це не працює на телефоні.
2. Вигляд для власника. Список на сьогодні, список майбутніх, скасування, блокування часу.
3. Захистіть сторінки власника. Додайте вхід, перш ніж вносити реальні дані.
4. Правила. Буфери, період попередження, горизонт бронювання, свята.
5. Електронна пошта. Підтвердження із запрошенням до календаря та посиланням на скасування.
6. Передоплата, якщо вона потрібна, спершу в тестовому режимі Stripe.
7. Перевірте крайні випадки. Два вікна, які бронюють той самий слот, бронювання через північ, дата переходу на літній час, скасоване бронювання, що звільняє свій слот.
8. Публікація. Потім зробіть власне реальне бронювання, перш ніж ділитися посиланням.

Типові помилки

• Перевірка доступності лише в браузері. Виглядає правильно, але все одно призводить до подвійних бронювань.
• Збереження місцевого часу без часового поясу. Працює, доки не переведуть годинники.
• Показ імен клієнтів у публічному календарі. Показуйте лише «вільно» або «зайнято».
• Створення графіків персоналу, бонусних балів і SMS у перший день. Запустіть основний процес, а потім додайте те, про що справді просять клієнти.
• Немає способу для власника заблокувати час. Перший лікарняний день призведе до неявок.

Коли краще Calendly (або подібний сервіс)

Якщо ви одна людина, яка ділиться доступністю для дзвінків, інструмент для запису важко перевершити. Станом на вересень 2026 року безкоштовний тариф Calendly охоплює один тип події, одне підключення календаря та індивідуальне планування з налаштовуваною сторінкою бронювання; платні тарифи додають більше типів подій і функції для команд. Такі інструменти підключаються до вашого наявного календаря одразу, тоді як власний застосунок потрібно створювати з цією функцією.

Створюйте власний застосунок, коли вам потрібні правила, яких ці інструменти не підтримують, кілька ресурсів для бронювання, ваш брендинг у всьому, бронювання, пов'язані з іншими даними (клієнти, замовлення, членство), або коли ви створюєте продукт для бронювання, який продаватимете іншим.

Створення в Mythex

В Mythex ви описуєте застосунок для бронювання в чаті, він будує його в живому попередньому перегляді та додає базу даних Postgres, коли бронювання потрібно зберігати. Сценарій сторінки бронювання у документації пропонує почати з форми запиту та адміністративного списку, а потім додати решту. Будьте реалістичні щодо того, що вбудовано, а що ви підключаєте самі: у Mythex немає вбудованої синхронізації календаря, SMS-нагадувань чи продукту для передоплати. Електронна пошта йде через вашого провайдера, передоплата — через ваші ключі Stripe, збережені як секрети проєкту (рецепт Stripe), а правила щодо подвійних бронювань і часових поясів ви визначаєте й перевіряєте самі, як описано вище.

Команда /test дозволяє агенту пройти процес бронювання в попередньому перегляді та повідомити, що не працює. Як стартовий запит спробуйте шаблони сайту для бронювання в барбершопі або застосунку для зустрічей, або перегляньте всі шаблони застосунків.

Запитання