Booking event apa saja yang sebaiknya masuk CRM (dan yang tidak)

Kenapa booking system tidak harus menjadi CRM?

Booking system dan CRM menjawab pertanyaan yang berbeda. Booking system menjawab: jam berapa slot kosong, staf mana yang tersedia, dan apa status booking sekarang. CRM menjawab: siapa orang ini, apa riwayatnya dengan bisnis Anda, dan di tahap mana dia dalam pipeline. Saat satu produk memaksa menjawab keduanya, salah satu jawabannya dangkal.

Artikel Mekari Qontak "10 Aplikasi Booking Salon Terbaik untuk Jadwal Reservasi" (terbit 20 Juli 2026, dicek 12 September 2026) menempatkan Mekari Qontak satu daftar dengan Fresha, Booksy, dan Calendly, sementara halaman harga Qontak menjual CRM WhatsApp mulai Rp2.000.000 per bulan (lihat Sumber). Pembagian di artikel ini: booking system memegang slot, status, dan deposit; CRM memegang contact, activity, deal, dan ticket. Keduanya bertukar data lewat event, bukan lewat satu database bersama.

Termilo mengikuti pembagian itu: setiap perubahan status booking mengirim satu event bertanda tangan ke URL yang Anda daftarkan; kiriman yang gagal dicoba ulang otomatis, paling banyak enam percobaan. Pipeline, skor lead, dan kampanye tetap di CRM. Batas ini ada di halaman software booking untuk SaaS dan hub software booking untuk bisnis jasa.

Apa tujuh event booking dan kapan masing-masing terkirim?

Tujuh event mengikuti siklus booking: menunggu (held), terkonfirmasi (confirmed), lalu selesai (completed), batal (cancelled), atau tidak hadir (no_show).

Dalam mode Setujui otomatis, booking.created dan booking.confirmed dikirim berurutan dengan id event yang sama; bedakan keduanya dari nama event, bukan dari id saja. Event pembayaran tidak termasuk dalam tujuh event ini. Struktur body, header tanda tangan, dan aturan retry ada di dokumentasi webhook.

Bagaimana memetakan event ke contact, activity, deal, dan ticket?

Empat objek CRM yang paling umum: contact (orang), activity (interaksi bertanggal), deal (peluang bernilai uang), dan ticket (pekerjaan yang harus ditindaklanjuti). Peta di bawah menunjukkan perubahan pada tiap objek.

Event mana yang wajib dan mana yang opsional?

Wajib berarti tanpa event itu riwayat pelanggan di CRM salah; opsional berarti event itu hanya memperkaya data.

• Wajib: booking.confirmed. Satu-satunya event yang memastikan pertemuan benar-benar terjadwal; bila hanya boleh memilih satu, pilih ini.
• Wajib: booking.cancelled dan booking.no_show. Tanpa keduanya, CRM menampilkan pelanggan yang tampak setia padahal tiga kali tidak datang.
• Wajib: booking.completed. Pemicu follow-up: ulasan, kontrol berikutnya, atau penawaran lanjutan, yang dijalankan CRM, bukan Termilo.
• Opsional: booking.created. Berguna bila Anda memakai persetujuan manual atau deposit dan ingin melihat permintaan yang menunggu.
• Opsional: booking.rescheduled dan booking.expired. Keduanya hanya memperbarui activity yang ada. Lewati bila CRM Anda tidak menampilkan jam pertemuan.

Saring event di sisi langganan, bukan di CRM. Endpoint yang dibuat dari dashboard menerima semua event; untuk membatasi daftarnya, buat langganan lewat tool create_webhook di MCP dengan eventFilter, misalnya booking.confirmed dan booking.cancelled (MCP untuk agen AI).

Bagaimana menghindari duplikasi contact?

Duplikasi contact muncul karena kunci pencocokan yang salah, bukan karena event tiba dua kali. Setiap event membawa data pelanggan minimum: id pelanggan Termilo, nama, dan email. Pelanggan mengisi nama dan nomor WhatsApp; email opsional. Bila email diisi, pelanggan menerima email konfirmasi. Alamat email itu ikut dalam event; nomor WhatsApp tersimpan di Termilo, tetapi tidak ikut.

1. Jangan jadikan id pelanggan Termilo sebagai kunci contact. Setiap booking dari halaman booking publik membuat catatan pelanggan baru, sehingga satu orang dapat memiliki beberapa id.
2. Cocokkan contact berdasarkan email bila event membawanya; ubah ke huruf kecil dan buang spasi dulu.
3. Bila email kosong, baca detail booking lewat API dengan id booking dari event; jawabannya memuat nomor telepon pelanggan. Cocokkan nomor itu dalam format internasional (referensi API).
4. Simpan id booking Termilo di activity, bukan di contact; activity yang harus unik per booking.
5. Pakai upsert berdasarkan email atau nomor telepon bila CRM Anda mendukungnya; bila tidak, cari dulu, lalu buat contact hanya saat hasil pencarian kosong.

Duplikasi activity adalah masalah lain: event yang sama dapat tiba dua kali karena pengiriman at-least-once; cara menanganinya ada di artikel webhook booking idempotent. Istilah tenant, layanan, booking, dan customer ada di konsep dasar.

Bagaimana memulai dengan satu webhook uji?

Mulai dari satu endpoint dan satu event. Lengkapi peta setelah event pertama stabil selama seminggu.

1. Siapkan satu URL HTTPS di sisi Anda yang menerima POST dan membalas 2xx dalam 10 detik. Simpan dulu, proses belakangan.
2. Di dashboard Termilo, buka menu Developer, pilih Webhooks, lalu tekan Tambah endpoint. Isi URL endpoint, lalu tekan Simpan endpoint.
3. Salin signing secret yang tampil sekali di dialog Endpoint berhasil ditambahkan, lalu simpan di penyimpanan rahasia server Anda.
4. Buat satu booking uji dari halaman booking Anda sendiri. Buka Riwayat pengiriman di halaman Webhooks; setiap pengiriman tercatat dengan kode status dan jumlah percobaan.
5. Verifikasi tanda tangan dari body mentah, lalu proses hanya booking.confirmed sebagai contact dan activity. Balas 2xx untuk event lain tanpa memprosesnya.
6. Tambahkan booking.cancelled, booking.no_show, dan booking.completed satu per satu. Uji dari menu Booking dengan aksi Batalkan, Tidak hadir, dan Tandai selesai.
7. Bila satu pengiriman gagal, perbaiki endpoint lalu tekan Retry pada baris itu atau Kirim ulang di halaman detailnya; tidak perlu membuat booking baru.

Bila agen AI yang menyiapkan integrasi, tool send_test_webhook di MCP mengirim satu kiriman uji bertanda tangan tanpa data booking.