DEV Community

Cover image for Membangun Sistem Pendaftaran Jamaah Umroh yang Siap Sinkron dengan Siskopatuh
Mightyblue
Mightyblue

Posted on

Membangun Sistem Pendaftaran Jamaah Umroh yang Siap Sinkron dengan Siskopatuh

Setiap PPIU skala UKM punya cerita yang sama. Data jamaah tersebar di grup WhatsApp, formulir kertas di laci, dan satu file Excel yang dipegang admin. Semuanya berjalan lancar sampai musim keberangkatan datang, lalu deadline input ke Siskopatuh menghantam. Sistem milik Kemenag ini bukan sekadar formalitas administratif — SISKOPATUH menggantikan sistem manual pelaporan umrah sejak 2019 dan menjadi syarat mutlak terbitnya Nomor Porsi Umroh. Tanpa data yang rapi, visa jamaah tertahan. Di titik inilah sistem pendaftaran jamaah umroh digital berhenti menjadi kemewahan dan berubah menjadi kebutuhan operasional.

Masalahnya bukan kurangnya niat. Masalahnya adalah asumsi bahwa sistem seperti ini butuh anggaran ratusan juta.

Padahal tidak.

Riset akademik sudah lama menyimpulkan hal serupa. Penelitian perancangan sistem informasi pendaftaran jemaah haji dan umroh berbasis website yang terbit di Jurnal CoSciTech menunjukkan bahwa sistem terstruktur meningkatkan efisiensi operasional, akurasi data, dan transparansi proses pendaftaran secara signifikan. Bukan karena teknologinya canggih — tapi karena data akhirnya punya satu sumber kebenaran. Kami mengangkat tema ini karena mayoritas artikel teknis di luar sana ditulis untuk startup dengan tim engineering lengkap, bukan untuk biro travel dengan dua orang admin dan satu laptop. Padahal justru di sanalah dampak digitalisasi paling terasa.


"Sistem terbaik bukan yang paling canggih, tapi yang paling jarang bikin admin panik jam sebelas malam."


1. Memahami Bentuk Masalahnya Sebelum Menulis Kode

Sebelum bicara stack teknologi, kita perlu jujur soal bentuk masalah sebenarnya. Kegagalan sistem di biro travel jarang disebabkan oleh performa server. Penyebabnya hampir selalu manusia, proses, dan data yang tidak konsisten.

Alur Nyata yang Terjadi di Lapangan

Alur pendaftaran jamaah umumnya seperti ini:

  • Calon jamaah bertanya via WhatsApp
  • Admin mencatat nama di buku atau Excel
  • Dokumen paspor dikirim sebagai foto, kadang buram
  • Pembayaran ditransfer, buktinya juga foto
  • Admin mengetik ulang semuanya ke Siskopatuh

Lima langkah, empat kali pengetikan ulang.

Setiap pengetikan ulang adalah peluang typo. Dan typo pada nama paspor bukan masalah kecil — itu bisa membatalkan visa.

Tiga Titik Kegagalan Paling Umum

Double entry. Satu jamaah didaftarkan dua kali karena dua admin merespons chat yang sama.

Data tidak lengkap. Paspor sudah masuk, tapi nomor dan masa berlakunya belum dicatat. Ketahuan H-14.

Tidak ada jejak audit. Ketika ada sengketa pembayaran, tidak ada yang tahu siapa mengubah apa dan kapan.

Ketiganya bisa diselesaikan tanpa infrastruktur mahal.


2. Arsitektur Low-Cost yang Masuk Akal untuk PPIU Skala UKM

Prinsip utamanya sederhana: jangan bangun apa yang bisa disewa, dan jangan sewa apa yang bisa gratis. Arsitektur di bawah ini dirancang untuk biro dengan volume 50–500 jamaah per tahun, dengan biaya bulanan yang realistis.

Komponen Inti

Lapisan Pilihan Low-Cost Alasan Teknis
Frontend Next.js / Astro di Vercel SSG untuk halaman paket, SSR hanya untuk form
Database Supabase (Postgres) Row Level Security bawaan, tier gratis memadai
Autentikasi Supabase Auth Role admin vs marketing tanpa kode tambahan
Penyimpanan dokumen Supabase Storage / Cloudflare R2 Egress murah untuk scan paspor
Notifikasi WhatsApp Cloud API Kanal yang memang sudah dipakai jamaah
Export Siskopatuh Generator CSV/XLSX terjadwal Sinkronisasi manual yang terkontrol

Kenapa Bukan Google Sheets Saja?

Pertanyaan wajar. Sheets memang cepat untuk memulai.

Tapi Sheets tidak punya constraint. Tidak ada yang mencegah dua baris dengan nomor paspor identik. Tidak ada tipe data yang memaksa tanggal ditulis konsisten. Dan begitu file dibagikan ke lima orang, riwayat perubahan menjadi kabur.

Postgres memberi Anda UNIQUE, CHECK, dan foreign key sejak hari pertama. Itu saja sudah menghapus separuh masalah.

Soal Idempotency

Ini bagian yang paling sering dilewatkan. Ketika jamaah menekan tombol "Daftar" dua kali karena koneksi lambat, sistem harus memperlakukannya sebagai satu pendaftaran.

Konsepnya dibahas dengan sangat rapi dalam artikel Build Resilient Systems with Idempotent APIs oleh Karishma Shukla di DEV Community. Intinya: kirimkan idempotency key unik dari klien, simpan di server, dan tolak permintaan duplikat dengan respons yang sama.

Untuk konteks umroh, key-nya bisa berupa kombinasi NIK, ID paket, dan timestamp yang di-hash.


3. Merancang Skema Data yang Ramah Siskopatuh

Kesalahan terbesar dalam membangun sistem pendaftaran jamaah umroh digital adalah merancang database menurut logika developer, bukan menurut format pelaporan yang nanti dibutuhkan. Akibatnya, saat waktunya export, semua field harus dipetakan ulang secara manual.

Balik urutannya. Mulai dari field yang diminta Siskopatuh, lalu rancang tabel Anda mengelilinginya.

Tabel Minimum yang Dibutuhkan

-- Jamaah: satu baris per individu, bukan per pendaftaran
CREATE TABLE jamaah (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  nik           CHAR(16) UNIQUE NOT NULL,
  nama_paspor   TEXT NOT NULL,
  no_paspor     VARCHAR(20) UNIQUE,
  paspor_expiry DATE,
  tempat_lahir  TEXT NOT NULL,
  tanggal_lahir DATE NOT NULL,
  jenis_kelamin CHAR(1) CHECK (jenis_kelamin IN ('L','P')),
  created_at    TIMESTAMPTZ DEFAULT now()
);

-- Pendaftaran: relasi jamaah ke paket keberangkatan
CREATE TABLE pendaftaran (
  id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  jamaah_id       UUID REFERENCES jamaah(id) ON DELETE RESTRICT,
  paket_id        UUID REFERENCES paket(id),
  idempotency_key TEXT UNIQUE NOT NULL,
  status          TEXT DEFAULT 'draft'
                  CHECK (status IN ('draft','verified','paid','departed','cancelled')),
  created_at      TIMESTAMPTZ DEFAULT now()
);
Enter fullscreen mode Exit fullscreen mode

Perhatikan nama_paspor yang dipisah dari nama panggilan. Ini bukan detail kosmetik — Siskopatuh dan sistem visa Saudi membaca nama sesuai paspor, bukan sesuai KTP.

Validasi di Level Database, Bukan Hanya Form

Validasi frontend bisa dilewati. Validasi database tidak.

Masa berlaku paspor minimal delapan bulan dari tanggal keberangkatan? Jadikan itu constraint, bukan sekadar pesan error di form.


4. Menghubungkan WhatsApp ke Sistem Tanpa Kehilangan Sentuhan Manusia

Banyak biro travel menolak otomatisasi karena takut kehilangan kehangatan komunikasi. Kekhawatiran itu sah. Solusinya bukan mengganti admin dengan bot, tapi membebaskan admin dari pekerjaan mengetik ulang.

Pola Hybrid yang Terbukti Bekerja

Alurnya menjadi:

  1. Jamaah tetap chat via WhatsApp seperti biasa
  2. Admin mengirim satu tautan formulir yang sudah ter-prefill nomor teleponnya
  3. Jamaah mengisi sendiri data paspor dan mengunggah dokumen
  4. Sistem memvalidasi dan mengirim notifikasi otomatis ke admin
  5. Admin melakukan verifikasi akhir — pekerjaan yang butuh mata manusia

Admin tetap hadir. Yang hilang hanya pengetikan ulang.

Notifikasi yang Tidak Mengganggu

Kirim pesan otomatis hanya pada tiga momen: konfirmasi pendaftaran diterima, pengingat dokumen kurang, dan konfirmasi keberangkatan.

Lebih dari itu, jamaah akan menganggapnya spam.


5. Panduan Implementasi Bertahap

Bagian ini disusun sebagai langkah praktis yang bisa dieksekusi dalam waktu sekitar delapan minggu, tanpa menghentikan operasional yang sedang berjalan. Setiap tahap menghasilkan sesuatu yang langsung bisa dipakai.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Membangun Sistem Pendaftaran Jamaah Umroh Digital untuk PPIU",
  "totalTime": "P8W",
  "estimatedCost": {
    "@type": "MonetaryAmount",
    "currency": "IDR",
    "value": "1500000"
  },
  "tool": [
    { "@type": "HowToTool", "name": "Akun Supabase" },
    { "@type": "HowToTool", "name": "Akun Vercel" },
    { "@type": "HowToTool", "name": "WhatsApp Business Cloud API" }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Audit field pelaporan Siskopatuh",
      "text": "Kumpulkan seluruh field yang wajib dilaporkan ke Siskopatuh dan jadikan sebagai spesifikasi skema database."
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Rancang skema database",
      "text": "Buat tabel jamaah, paket, dan pendaftaran dengan constraint UNIQUE pada NIK dan nomor paspor."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Bangun formulir pendaftaran publik",
      "text": "Buat formulir dengan validasi sisi klien dan server, termasuk idempotency key untuk mencegah pendaftaran ganda."
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Aktifkan penyimpanan dokumen",
      "text": "Konfigurasikan penyimpanan objek dengan akses terbatas untuk scan paspor dan bukti pembayaran."
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Terapkan role dan audit trail",
      "text": "Gunakan Row Level Security untuk memisahkan hak akses admin dan marketing, serta catat setiap perubahan status."
    },
    {
      "@type": "HowToStep",
      "position": 6,
      "name": "Bangun generator export",
      "text": "Buat fungsi export CSV atau XLSX yang formatnya sudah sesuai dengan kebutuhan input Siskopatuh."
    },
    {
      "@type": "HowToStep",
      "position": 7,
      "name": "Migrasi data lama dan uji paralel",
      "text": "Jalankan sistem baru berdampingan dengan proses lama selama satu siklus keberangkatan sebelum beralih penuh."
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Urutan Prioritas Jika Waktu Terbatas

Kalau hanya sempat mengerjakan tiga hal, kerjakan ini:

  • Skema database dengan constraint yang benar
  • Formulir yang diisi langsung oleh jamaah
  • Generator export sesuai format Siskopatuh

Sisanya bisa menyusul.


6. Keamanan Data Jamaah: Bagian yang Sering Diabaikan

Data yang dikelola sistem ini bukan data biasa. Ada NIK, nomor paspor, tanggal lahir, dan riwayat pembayaran. Kombinasi itu cukup untuk melakukan pencurian identitas. Sejak UU Perlindungan Data Pribadi berlaku, tanggung jawabnya juga tidak lagi sebatas etika.

Praktik Minimum yang Wajib

  • Enkripsi at-rest untuk kolom sensitif seperti NIK dan nomor paspor
  • Signed URL berumur pendek untuk akses scan dokumen, bukan tautan publik permanen
  • Row Level Security agar staf marketing tidak bisa membaca data pembayaran
  • Retensi terbatas — hapus scan dokumen setelah keberangkatan selesai diproses
  • Log akses yang mencatat siapa membuka data siapa

Jangan Simpan Bukti Transfer di Grup WhatsApp

Ini terdengar sepele tapi sangat umum. Foto bukti transfer yang mengandung nomor rekening jamaah tersimpan permanen di ponsel setiap anggota grup.

Pindahkan ke storage dengan akses terkontrol. Sekarang.


7. Mengukur Apakah Sistemnya Benar-Benar Bekerja

Sistem yang dibangun tanpa metrik hanya akan menjadi asumsi yang mahal. Ada beberapa angka sederhana yang bisa dipantau tanpa perlu tooling analitik yang rumit, dan semuanya berhubungan langsung dengan beban kerja admin.

Metrik Sebelum Digitalisasi Target Setelah Cara Ukur
Waktu input satu jamaah 15–25 menit Di bawah 5 menit Timestamp created_at vs verified_at
Tingkat data tidak lengkap 30–40% Di bawah 10% Query field NULL pada status verified
Duplikasi pendaftaran Beberapa per musim Nol Constraint UNIQUE yang tertolak
Waktu persiapan export 1–2 hari kerja Di bawah 1 jam Waktu eksekusi generator

Angka "sebelum" di atas adalah rentang yang lazim ditemui pada operasional manual; ukur baseline Anda sendiri sebelum membandingkan.


FAQ

Apakah sistem ini bisa terhubung langsung ke API Siskopatuh?

Saat ini Siskopatuh belum menyediakan API publik untuk integrasi pihak ketiga. Karena itu pendekatan yang realistis adalah menyiapkan data dalam format yang siap diunggah atau diinput, bukan sinkronisasi otomatis. Rancang generator export Anda agar mudah disesuaikan bila format pelaporan berubah.

Berapa biaya bulanan realistis untuk arsitektur ini?

Untuk volume di bawah 500 jamaah per tahun, tier gratis Supabase dan Vercel umumnya masih mencukupi. Biaya yang muncul biasanya dari WhatsApp Cloud API dan domain. Perkiraan wajar berada di kisaran ratusan ribu hingga satu setengah juta rupiah per bulan, tergantung volume pesan.

Bagaimana jika tim kami tidak punya developer?

Mulai dari yang paling kecil: formulir dengan validasi ketat dan database yang punya constraint. Banyak biro memulai dengan tools no-code sebelum meningkat ke sistem kustom. Yang penting adalah disiplin struktur data sejak awal, karena migrasi data berantakan jauh lebih mahal daripada membangun sistem baru.

Apakah aman menyimpan data paspor di cloud?

Aman selama enkripsi, kontrol akses, dan kebijakan retensi diterapkan dengan benar. Penyedia cloud besar umumnya memiliki standar keamanan yang lebih tinggi daripada laptop kantor. Risiko terbesar biasanya bukan pada infrastrukturnya, melainkan pada tautan dokumen yang dibagikan sembarangan.

Berapa lama sampai sistem ini terasa manfaatnya?

Efisiensi input biasanya terasa dalam satu siklus keberangkatan. Manfaat yang lebih besar — berkurangnya sengketa data dan visa tertahan — baru terlihat setelah dua hingga tiga musim, ketika basis data jamaah lama sudah bersih.


Mengubah Kepercayaan Jamaah Menjadi Sistem yang Bisa Diandalkan

Mengakhiri pembahasan ini, ada satu hal yang perlu ditegaskan: membangun sistem pendaftaran jamaah umroh digital bukan proyek teknologi, melainkan proyek kepercayaan. Jamaah menyerahkan tabungan bertahun-tahun dan dokumen paling personal mereka kepada sebuah biro travel. Sistem yang rapi adalah cara paling konkret untuk menghormati kepercayaan itu.

Prinsip ini beresonansi dengan apa yang lama dipegang oleh Martin Fowler:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

Fowler adalah seorang software engineer dan penulis asal Inggris yang dikenal luas atas karyanya di bidang refactoring, arsitektur perangkat lunak, dan pola desain enterprise. Kutipannya relevan di sini karena sistem untuk PPIU skala UKM tidak akan dirawat oleh tim engineering besar — ia akan dipegang oleh admin yang belajar sambil jalan, atau developer freelance berikutnya. Kode dan skema data yang mudah dipahami manusia adalah satu-satunya jaminan sistem itu masih hidup tiga tahun lagi.

Pendekatan yang dibahas di artikel ini disusun dari observasi terhadap operasional biro perjalanan umroh yang berjalan nyata, termasuk praktik pengelolaan jamaah di Habibina Tour & Travel, sebuah PPIU berizin resmi di Karawang, Jawa Barat. Konteks lapangan seperti itu penting, karena arsitektur terbaik di atas kertas sering gagal bertemu kenyataan meja admin.

Mulai dari yang kecil. Perbaiki skema data lebih dulu.

Sisanya akan menyusul dengan sendirinya.


Punya pengalaman membangun sistem operasional untuk bisnis jasa lokal di Indonesia? Ceritakan tantangan terbesarnya di kolom komentar — terutama soal migrasi data lama.

Top comments (0)