Кейс: Система керування бронюваннями

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

Лише два інструменти

Інструмент	Роль	Уявіть це як
Chat Claude (claude.ai)	Вирішує «що будувати» через діалог. Відповідає за проєктування/специфікацію	Планова нарада з вашим архітектором
Claude Code у VS Code	Бере готовий проєкт і фактично створює файли та пише код	Підрядник на об'єкті

Базовий робочий процес

Поспілкуйтеся з Chat Claude → отримайте специфікацію «що будувати»
Chat Claude перетворює цю специфікацію на аркуш інструкцій (TASK.md)
Передайте TASK.md у Claude Code у VS Code → він фактично це будує
Повідомте результат Chat Claude → отримайте наступний аркуш інструкцій
Повторюйте кроки 1–4, доки все не буде завершено

Типові речі для обліку залежно від типу бізнесу (відправна точка для інтерв'ю)

Коли вперше продумуєте систему бронювань, самого лише визначення «типу бізнесу» недостатньо, щоб зрозуміти, що саме потрібно обліковувати. На основі того, що фактично відстежують наявні системи бронювань (для ресторанів, для салонів), ось відправна точка для інтерв'ю.

Ресторани, ізакая тощо (модель керування столиками)

Кількість місць за столиком (наприклад, столики на 2, на 4 особи)
Розмір компанії та як він відповідає призначенню/комбінуванню столиків
Доступність за часовими проміжками (скільки столиків якого розміру вільні в певний час)
Записи щодо клієнтів: історія відвідувань, алергії, улюблені страви
Записи про неявки

Салони, фізіотерапевтичні клініки, медичні клініки тощо (модель розподілу персоналу/ресурсів)

Тривалість процедури, ціна та буферний час на підготовку/прибирання для кожної позиції меню послуг
Який співробітник може виконувати які послуги (призначення за навичками), робочий час, вихідні
Доступність місць/кабінетів для процедур як ресурсу
Записи про клієнтів (уподобання, використані продукти, алергії, історія процедур)
Буферний час між бронюваннями (час на підготовку до наступного)

Спільне для всіх типів бізнесу

Коли надсилати нагадування (за день до, за N годин до тощо)
Політика скасування та як обробляти лист очікування
Чи потрібна передоплата

Це лише орієнтовна відправна точка. Те, що вам справді потрібно, залежить від бізнесу та особливостей роботи вашого закладу, тому на Фазі 0 ми спершу запитаємо про тип вашого бізнесу, а потім разом визначимо конкретні пункти обліку на основі цього переліку.

Що змінюється, якщо створити базу даних (конкретний приклад)

На Фазі 1 ви вирішите: «створити нову спеціалізовану базу даних + сайт бронювань з нуля» чи «продовжити використовувати наявний Google Calendar як журнал бронювань». Для орієнтиру наведемо порівняння на прикладі гіпотетичної ізакая (20 місць, 4 столики) — що можна і чого не можна робити в кожному варіанті.

Лише інтеграція з Google Calendar

Що можна робити: вносити дату/час у календар, сповіщати бізнес через Discord
Чого не можна робити: автоматичний розрахунок доступності столиків, накопичення історії відвідувань, облік алергій/уподобань клієнтів, підрахунок частки неявок — жодне з детальних завдань обліку, перелічених у розділі «Типові речі для обліку залежно від типу бізнесу», недоступне (текст можна вписати в подію календаря, але потім його не можна шукати чи агрегувати)

Створення спеціалізованої бази даних + сайту бронювань

Усе перелічене вище стає доступним для пошуку та агрегації (наприклад, можна скласти список «клієнтів, які часто скасовували бронювання минулого місяця» або «клієнтів із зафіксованими алергіями»)
З іншого боку, це вимагає більше зусиль на створення та підтримку, ніж інтеграція з календарем

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

Загальний графік (шість фаз)

Фаза	Зміст	Використовуваний інструмент	Результат
Фаза 0	Інтерв'ю щодо вимог (тип бізнесу, деталізація бронювань, наявні інструменти, канали сповіщень)	Chat Claude	Аркуш вимог
Фаза 1	Визначення архітектури системи (новий сайт бронювань чи інтеграція з наявним календарем, вибір каналу сповіщень для клієнтів)	Chat Claude	План архітектури
Фаза 2	Створення касети (обов'язкові SKILL.md/WORKFLOW.md та окремий SPEC/soul.md)	Chat Claude	SKILL.md, WORKFLOW.md, SPEC/soul.md
Фаза 3	Реалізація (ітеративно)	Claude Code у VS Code	Робоча касета
Фаза 4	Тестування та перевірка	Обидва	Перевірена касета
Фаза 5	Доопрацювання та документація	Chat Claude	Готовий продукт + посібник користувача

Оскільки вихідні умови сильно різняться залежно від типу бізнесу, готового TASK.md, який пропускає інтерв'ю, не існує. Завжди починайте з інтерв'ю щодо вимог на Фазі 0.

Почніть зараз: стартовий промпт Фази 0

Просто вставте цей промпт як є в новий діалог із «Chat Claude» (claude.ai), щоб розпочати інтерв'ю щодо вимог на Фазі 0.

Я хочу створити інструмент керування бронюваннями + автоматичних сповіщень (skill cassette) для бізнесу, що приймає бронювання (ресторан, салон, фізіотерапевтична клініка, медична клініка тощо). Я новачок у програмуванні, тому хочу, щоб ви (Chat Claude) стали моїм партнером із проєктування/специфікації, а Claude Code у VS Code відповідав за реалізацію.

🔒

Решта доступна в повному посібнику після придбання T1.
(Повний текст, включно з детальними пунктами інтерв'ю Фази 0, логікою вибору каналу сповіщень та шаблонами аркушів інструкцій для Фази 1 і далі)

Придбати T1, щоб переглянути посібник →

Застереження та важливі примітки

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

Повний посібник із побудови

Детальні пункти інтерв'ю Фази 0, логіка вибору каналу сповіщень та шаблони аркушів інструкцій для Фази 1 і далі — повний виклад викладено на сайті-посібнику BALIA OS.

Переглянути повний посібник →

Дивіться інші практичні кейси

Інші кейси, створені за тим самим підходом — автооновлення сайту спільноти/фан-сайту, прогнозування перегонів на човнах, криптотрейдинг та інше — уже активні або в розробці.

Переглянути всі практичні кейси →

Практичний кейс:Система керування бронюваннями.