Studi Kasus: Sistem Manajemen Reservasi

Notifikasi ke pihak bisnis (Discord) dan notifikasi ke pelanggan (WhatsApp, SMS, LINE, dll.) melalui jalur yang secara fundamental berbeda. Dalam studi kasus ini, kami memilah perbedaan tersebut pada tahap wawancara awal sebelum masuk ke tahap desain.

Hanya Dua Alat

Alat	Peran	Anggap sebagai
Chat Claude (claude.ai)	Menentukan "apa yang akan dibangun" melalui percakapan. Menangani sisi desain/spesifikasi	Sesi perencanaan dengan arsitek Anda
Claude Code di VS Code	Mengambil desain final dan benar-benar membuat file serta menulis kode	Kontraktor di lapangan

Alur Kerja Dasar

Berdiskusi dengan Chat Claude → dapatkan spesifikasi "apa yang akan dibangun"
Chat Claude mengubah spesifikasi tersebut menjadi lembar instruksi (TASK.md)
Serahkan TASK.md ke Claude Code di VS Code → ia benar-benar membangunnya
Laporkan hasilnya kembali ke Chat Claude → dapatkan lembar instruksi berikutnya
Ulangi langkah 1–4 hingga selesai

Hal-Hal Umum yang Perlu Dikelola Berdasarkan Jenis Bisnis (Titik Awal untuk Wawancara)

Saat pertama kali memikirkan sistem reservasi, hanya menentukan "jenis bisnis" saja tidak memberi tahu Anda apa yang sebenarnya perlu dikelola. Berdasarkan apa yang benar-benar dilacak oleh sistem reservasi yang sudah ada (untuk restoran, untuk salon), berikut adalah titik awal untuk wawancara.

Restoran, Izakaya, dll. (Model Manajemen Meja)

Jumlah kursi per meja (misalnya meja untuk 2 orang, meja untuk 4 orang)
Jumlah rombongan dan bagaimana hal itu dipetakan ke penempatan/kombinasi meja
Ketersediaan berdasarkan slot waktu (berapa banyak meja dengan ukuran tertentu yang kosong pada waktu tertentu)
Catatan sisi pelanggan: riwayat kunjungan, alergi, menu favorit
Catatan ketidakhadiran (no-show)

Salon, Klinik Fisioterapi, Klinik Medis, dll. (Model Alokasi Staf/Sumber Daya)

Durasi perawatan, harga, dan waktu jeda persiapan/pembersihan untuk setiap item menu layanan
Staf mana yang dapat melakukan layanan tertentu (penempatan berbasis keahlian), jam kerja, hari libur
Ketersediaan kursi/ruang perawatan sebagai sumber daya
Catatan pelanggan (preferensi, produk yang digunakan, alergi, riwayat perawatan)
Waktu jeda antar pemesanan (waktu yang dibutuhkan untuk mempersiapkan pemesanan berikutnya)

Umum untuk Semua Jenis Bisnis

Kapan mengirim pengingat (sehari sebelumnya, N jam sebelumnya, dll.)
Kebijakan pembatalan dan cara menangani daftar tunggu
Apakah deposit diperlukan

Ini hanyalah titik awal sebagai referensi. Apa yang sebenarnya Anda butuhkan bervariasi tergantung bisnis dan cara toko Anda beroperasi, jadi pada Fase 0 kami akan terlebih dahulu menanyakan jenis bisnis Anda, lalu menggunakan ini sebagai dasar untuk menentukan bersama item-item spesifik yang perlu dikelola.

Apa yang Berubah Jika Anda Membangun Database (Contoh Konkret)

Pada Fase 1, Anda akan memutuskan antara "membangun database khusus + situs reservasi baru dari nol" atau "tetap menggunakan Google Calendar Anda saat ini sebagai buku besar reservasi." Sebagai titik referensi, berikut perbandingan menggunakan contoh hipotetis sebuah izakaya (20 kursi, 4 meja) — apa yang bisa dan tidak bisa dilakukan dengan masing-masing opsi.

Hanya Integrasi Google Calendar

Yang bisa dilakukan: menempatkan tanggal/waktu pada kalender, memberi notifikasi ke pihak bisnis melalui Discord
Yang tidak bisa dilakukan: perhitungan otomatis ketersediaan meja, mengakumulasi riwayat kunjungan, mencatat alergi/preferensi per pelanggan, menghitung tingkat ketidakhadiran — tidak satu pun manajemen detail yang tercantum di "Hal-Hal Umum yang Perlu Dikelola Berdasarkan Jenis Bisnis" dapat dilakukan (Anda bisa menulis teks ke dalam acara kalender, tetapi tidak bisa mencarinya atau mengagregasinya nanti)

Membangun Database Khusus + Situs Reservasi

Semua hal yang tercantum di atas menjadi dapat dicari dan diagregasi (misalnya, Anda bisa membuat daftar "pelanggan yang sering membatalkan bulan lalu" atau "pelanggan dengan catatan alergi")
Di sisi lain, dibutuhkan lebih banyak usaha untuk membangun dan memeliharanya dibandingkan integrasi kalender

Aturan praktis: Jika volume reservasi Anda rendah dan Anda hanya ingin mencoba notifikasi terlebih dahulu, tidak masalah untuk memulai dengan integrasi kalender. Jika Anda ingin benar-benar menggunakan item manajemen khusus bisnis seperti riwayat kunjungan dan pelacakan alergi, Anda memerlukan database khusus.

Jadwal Keseluruhan (Enam Fase)

Fase	Konten	Alat yang Digunakan	Hasil
Fase 0	Wawancara kebutuhan (jenis bisnis, granularitas reservasi, alat yang sudah ada, saluran notifikasi)	Chat Claude	Lembar kebutuhan
Fase 1	Menentukan arsitektur sistem (situs reservasi baru vs. integrasi kalender yang sudah ada, memilih saluran notifikasi pelanggan)	Chat Claude	Rencana arsitektur
Fase 2	Membangun cassette (SKILL.md/WORKFLOW.md dan SPEC/soul.md khusus semuanya diperlukan)	Chat Claude	SKILL.md, WORKFLOW.md, SPEC/soul.md
Fase 3	Implementasi (iteratif)	Claude Code di VS Code	Cassette yang berfungsi
Fase 4	Pengujian dan verifikasi	Keduanya	Cassette yang terverifikasi
Fase 5	Penyempurnaan dan dokumentasi	Chat Claude	Produk jadi + panduan penggunaan

Karena asumsi sangat bervariasi tergantung jenis bisnis, tidak ada TASK.md siap pakai yang melewati wawancara. Selalu mulai dengan wawancara kebutuhan Fase 0.

Mulai Sekarang: Prompt Pembuka Fase 0

Cukup tempelkan prompt ini apa adanya ke percakapan baru dengan "Chat Claude" (claude.ai) untuk memulai wawancara kebutuhan Fase 0.

Saya ingin membangun alat manajemen reservasi + notifikasi otomatis (skill cassette) untuk bisnis yang menerima pemesanan (restoran, salon, klinik fisioterapi, klinik medis, dll.). Saya baru mengenal pemrograman, jadi saya ingin Anda (Chat Claude) menjadi mitra desain/spesifikasi saya, dengan Claude Code di VS Code yang menangani implementasinya.

🔒

Sisanya tersedia di panduan lengkap setelah membeli T1.
(Teks lengkap termasuk item wawancara Fase 0 secara detail, logika pemilihan saluran notifikasi, dan template lembar instruksi untuk Fase 1 dan seterusnya)

Beli T1 untuk Melihat Panduan →

Disclaimer dan Catatan Penting

Jika Anda mengirim pesan otomatis kepada pelanggan (pengingat kedatangan, pesan terima kasih, dll.), pastikan Anda mendapatkan persetujuan mereka pada saat pemesanan — bahwa "pesan otomatis akan dikirim setelah reservasi dikonfirmasi." Kami merekomendasikan untuk merancang sistem agar hanya mengirim ke reservasi yang persetujuannya telah dikonfirmasi.

Panduan Lengkap Pembangunan

Item wawancara Fase 0 secara detail, logika pemilihan saluran notifikasi, dan template lembar instruksi untuk Fase 1 dan seterusnya — tulisan lengkapnya tersedia di situs panduan BALIA OS.

Lihat Panduan Lengkap →

Lihat Studi Kasus Lainnya

Studi kasus lain yang dibangun dengan cara yang sama — pembaruan otomatis situs komunitas/fan, prediksi balap perahu, trading kripto, dan lainnya — sudah aktif atau sedang dalam pengerjaan.

Lihat Semua Studi Kasus →

Studi Kasus:Sistem Manajemen Reservasi.