vandy

Blog

  • Manajemen Asrama Pesantren: Kamar, Piket, dan Data Santri

    Manajemen Asrama Pesantren: Kamar, Piket, dan Data Santri

    Manajemen asrama pesantren yang rapi sebenarnya bisa diukur dengan tiga pertanyaan sederhana. Pertama, santri X tidur di kamar mana dan siapa musyrifnya. Kedua, siapa yang piket apa hari ini. Ketiga, bagaimana kondisi tiap kamar, mulai dari kapasitas, jumlah penghuni, sampai inventaris di dalamnya. Kalau tiga pertanyaan itu bisa dijawab kapan saja tanpa membuka lima buku berbeda, pengelolaan asrama sudah sehat, apa pun alatnya.

    Pengelolaan asrama adalah salah satu modul dalam aplikasi pesantren. Data kamar biasanya terhubung dengan absensi santri dan perizinan keluar-masuk, jadi ketiganya lebih ringan kalau dikelola di satu tempat.

    Masalahnya, di banyak pondok tiga pertanyaan itu hanya bisa dijawab oleh satu dua orang. Biasanya ustadz bagian keasramaan yang hafal semuanya di luar kepala. Selama beliau ada di tempat, semua aman. Begitu beliau pulang kampung atau pindah tugas, jawabannya ikut pergi. Artikel ini membahas cara menata tiga hal itu: penempatan kamar, jadwal piket, dan data keseharian santri di asrama. Mulai dari yang bisa dirapikan tanpa aplikasi apa pun.

    Masalah klasik asrama yang dikelola papan tulis dan buku

    Papan tulis di kantor keasramaan dan beberapa buku tulis adalah alat kerja paling umum di bagian asrama. Tidak ada yang salah dengan itu. Tapi ada pola masalah yang hampir selalu muncul ketika jumlah santri terus bertambah.

    • Penempatan kamar tiap tahun ajaran jadi proyek besar. Berhari-hari rapat, kertas penuh coretan, nama santri dipindah-pindah sampai malam. Hasil akhirnya sering hanya tersimpan di satu lembar yang ditempel di dinding.
    • Kamar kelebihan penghuni baru ketahuan saat ada masalah. Misalnya saat ada santri sakit dan kamarnya ternyata diisi 14 orang padahal kapasitasnya 10.
    • Piket tidak jalan karena jadwalnya hilang. Kertas jadwal lepas dari papan, atau versi terbaru hanya ada di catatan pribadi salah satu pengurus.
    • Mencari data satu santri harus membuka beberapa buku. Data kamar di buku keasramaan, catatan pembinaan di buku musyrif, riwayat sakit di buku lain lagi.
    • Rotasi kamar tidak terdokumentasi. Santri yang dipindah karena masalah dengan teman sekamar tercatat di ingatan, bukan di berkas. Tahun depan, pengurus baru bisa saja menempatkan mereka sekamar lagi.

    Semua masalah di atas punya akar yang sama. Datanya ada, tapi terpencar dan menempel pada orang, bukan pada sistem yang bisa diwariskan.

    Penempatan kamar yang sistematis

    Penempatan kamar bukan sekadar membagi nama ke ruangan. Ada beberapa hal yang perlu tercatat dan dipikirkan sejak awal.

    Mulai dari kapasitas, bukan dari daftar nama

    Langkah pertama yang sering dilewati: mendata dulu semua kamar beserta kapasitas wajarnya. Berapa ranjang, berapa lemari, berapa penghuni maksimal yang masih sehat untuk kamar itu. Tanpa angka ini, kelebihan penghuni tidak akan pernah terlihat di atas kertas. Baru setelah itu daftar santri dibagi ke dalam kamar yang tersedia.

    Tentukan kebijakan pencampuran secara sadar

    Tiap pondok punya kebijakan berbeda. Ada yang mencampur angkatan supaya senior membimbing junior. Ada yang memisahkan per angkatan supaya pembinaan lebih fokus. Ada yang sengaja mencampur daerah asal supaya santri tidak berkelompok dengan teman sekampungnya, ada juga yang justru mengelompokkan. Tidak ada yang paling benar. Yang penting kebijakannya diputuskan secara sadar, ditulis, dan dipakai konsisten saat penempatan. Ditambah satu hal lagi: riwayat. Santri yang pernah bermasalah serius dengan santri lain sebaiknya tidak ditempatkan sekamar, dan itu hanya mungkin kalau riwayatnya tercatat.

    Musyrif per kamar dan rasio yang sehat

    Setiap kamar atau kelompok kamar butuh satu penanggung jawab yang jelas, biasanya musyrif atau pembina. Rasio yang terlalu berat, misalnya satu musyrif memegang 60 santri lintas gedung, membuat pembinaan hanya jalan di permukaan. Banyak pondok memakai kisaran satu musyrif untuk 20 sampai 30 santri, lalu menyesuaikan dengan usia santri dan ketersediaan SDM. Yang penting daftar ini tertulis dan mudah dicek, sehingga pertanyaan siapa musyrifnya si Fulan tidak perlu menunggu satu orang tertentu datang.

    Jadwal piket yang benar-benar jalan

    Hampir semua asrama punya jadwal piket. Yang jarang dimiliki adalah jadwal piket yang masih jalan di bulan ketiga. Ada tiga hal yang membedakan keduanya.

    Pertama, rotasi yang otomatis dan adil. Kalau rotasi disusun manual tiap pekan, cepat atau lambat penyusunnya lelah dan jadwal berhenti diperbarui. Pola rotasi sebaiknya ditetapkan sekali di awal, misalnya per kamar bergilir mingguan untuk area umum, lalu tinggal dijalankan. Sistem digital bisa memutar rotasi ini sendiri, tapi pola yang jelas di kertas pun sudah jauh lebih baik daripada menyusun ulang tiap pekan.

    Kedua, penukaran piket yang tercatat. Santri saling bertukar jadwal itu wajar. Yang jadi masalah adalah ketika penukaran hanya lewat lisan. Saat area kotor dan ditanya siapa piketnya, semua saling tunjuk. Aturannya sederhana: boleh bertukar, asal lapor dan dicatat. Dengan begitu tanggung jawab tetap bisa dilacak.

    Ketiga, kaitkan piket dengan pembinaan, bukan hanya hukuman. Catatan piket yang rapi memperlihatkan pola. Santri yang tiga kali berturut-turut absen piket mungkin bukan malas, bisa jadi sedang ada masalah. Musyrif yang memegang catatan ini bisa mengajak bicara lebih awal, sebelum masalahnya membesar. Di titik ini piket berhenti jadi urusan sapu dan pel, dan mulai jadi alat membaca kondisi santri.

    Data keseharian santri di asrama

    Di luar kamar dan piket, ada tiga jenis catatan harian yang menentukan kualitas pengelolaan asrama.

    Catatan pembinaan

    Setiap interaksi pembinaan yang penting layak dicatat singkat. Kapan, santri siapa, masalahnya apa, tindak lanjutnya apa. Catatan ini yang membuat pembinaan berkesinambungan ketika musyrif berganti. Tanpa itu, setiap pergantian pengurus berarti mengulang dari nol.

    Kesehatan ringan

    Santri demam atau sakit perut hampir tiap hari ada di asrama besar. Dua pertanyaan yang harus selalu bisa dijawab: siapa saja yang sedang sakit hari ini, dan apakah orang tuanya sudah diberi kabar. Kalau kabar ke orang tua masih bergantung pada sempatnya pengurus mengetik pesan satu per satu, cepat atau lambat ada yang terlewat, dan yang terlewat itu biasanya jadi keluhan paling keras. Beberapa pondok menyelesaikan ini lewat portal yang bisa dibuka wali dari rumah. Cara kerjanya pernah kami bahas lengkap di artikel tentang portal wali santri.

    Inventaris kamar

    Kasur, lemari, kipas angin, dan ranjang adalah aset yang nilainya besar kalau dijumlahkan satu pondok. Catat per kamar: apa saja isinya, kondisinya, dan kerusakan yang dilaporkan. Manfaatnya dua arah. Pengadaan barang jadi berbasis data, dan santri lebih menjaga barang karena tahu kondisi kamar dicatat dan diserahterimakan tiap pergantian penghuni.

    Kenapa data asrama sebaiknya satu sistem dengan data induk santri

    Semua catatan di atas bisa saja disimpan di buku terpisah per bagian. Tapi ada alasan kuat untuk menyatukannya dengan data induk santri, satu santri satu profil.

    • Tidak ada pengulangan data. Nama, kelas, asal, dan wali santri cukup dicatat sekali. Bagian asrama tinggal menambahkan kamar, musyrif, dan catatan hariannya.
    • Pindah kamar tinggal update satu kolom, bukan mencoret di tiga buku. Riwayat perpindahannya pun otomatis tersimpan.
    • Laporan cepat saat dibutuhkan pimpinan. Ketika mudir bertanya berapa kamar yang kelebihan penghuni atau santri mana yang paling sering sakit bulan ini, jawabannya hitungan menit, bukan proyek rekap semalaman.

    Kami melihat pola ini langsung saat membangun sistem untuk Pondok Pesantren Al-Muttaqin. Pondok ini mengelola ratusan santri, dan sebelumnya operasional hariannya bergantung pada catatan manual serta koordinasi lewat pesan singkat. Setiap kali butuh laporan, pengurus harus mengumpulkan data dari berbagai sumber. Sistem yang kami bangun menyatukan itu dalam satu platform: dasbor utama menampilkan jumlah santri aktif dan status santri yang sedang dirawat di klinik poskestren secara real-time, sementara akses tiap pengurus diatur sesuai tanggung jawabnya. Modul lain seperti setoran hafalan dan kantin cashless menempel di data santri yang sama, jadi satu santri benar-benar punya satu profil. Prinsip yang sama persis berlaku untuk data asrama. Detail proyeknya bisa dibaca di studi kasus SIM Pesantren Al-Muttaqin.

    Kapan papan tulis dan buku masih cukup

    Jujur saja, tidak semua pondok butuh sistem digital untuk asramanya hari ini. Kalau asrama masih satu gedung dengan puluhan santri, satu musyrif yang menetap, dan papan tulis yang rajin diperbarui, sistem manual itu masih sangat layak. Memaksakan aplikasi di kondisi ini hanya menambah pekerjaan.

    Tanda bahwa sudah waktunya naik kelas biasanya terasa sendiri. Gedung mulai lebih dari satu, santri ratusan, pergantian pengurus mulai sering, dan pertanyaan sederhana seperti si Fulan kamarnya di mana mulai butuh waktu untuk dijawab. Di titik itu, sistem yang menyatukan data asrama dengan data induk santri akan terasa manfaatnya sejak bulan pertama.

    Kalau pondok Anda sedang di titik itu dan ingin berdiskusi mulai dari mana, tim kami di Arrazy biasa memulai dari mendengar dulu alur kerja keasramaan yang sudah jalan, baru merancang sistem yang mengikutinya. Bukan sebaliknya.

    Pertanyaan yang sering diajukan

    Apakah penempatan kamar harus diulang total setiap tahun ajaran?

    Tidak harus. Kalau data kamar, kapasitas, dan riwayat penghuni tercatat rapi, penempatan tahun berikutnya sifatnya menggeser sebagian, bukan menyusun ulang dari nol. Santri yang naik jenjang dipindah sesuai kebijakan, sisanya tetap. Yang membuat penempatan jadi proyek besar tiap tahun biasanya bukan jumlah santrinya, tapi hilangnya data tahun sebelumnya.

    Berapa rasio musyrif terhadap santri yang ideal?

    Tidak ada angka baku yang berlaku untuk semua pondok. Kisaran yang banyak dipakai adalah satu musyrif untuk 20 sampai 30 santri, lebih kecil untuk santri usia SMP ke bawah. Lebih penting dari angkanya: setiap santri harus jelas siapa musyrifnya, dan setiap musyrif tahu persis siapa saja santri binaannya.

    Apakah data asrama perlu aplikasi terpisah dari sistem pesantren?

    Sebaiknya justru tidak terpisah. Data asrama paling berguna ketika menempel pada data induk santri yang sama dengan modul lain. Aplikasi terpisah hanya memindahkan masalah buku yang terpencar ke layar yang terpencar.

  • Contoh Surat Penawaran Harga (Quotation) yang Bikin Klien Yakin

    Contoh Surat Penawaran Harga (Quotation) yang Bikin Klien Yakin

    Surat penawaran harga yang bikin klien yakin sebenarnya hanya perlu menjawab tiga hal, tanpa klien harus bertanya lagi. Apa persisnya yang mereka dapat, alias scope yang jelas. Berapa biayanya dan bagaimana cara bayarnya. Lalu kenapa harus dari kamu, dibuktikan lewat portofolio atau pengalaman singkat. Ditambah satu hal yang paling sering dilupakan: masa berlaku penawaran. Kalau empat poin ini lengkap, klien bisa langsung mengambil keputusan tanpa bolak-balik tanya. Penawaran yang memaksa klien bertanya dulu biasanya berakhir didiamkan.

    Satu hal dulu biar tidak tertukar. Quotation atau surat penawaran harga dikirim sebelum deal, isinya tawaran yang masih bisa dinegosiasi. Sedangkan invoice dikirim setelah deal, isinya tagihan atas pekerjaan yang sudah disepakati atau selesai. Kalau kesepakatan sudah terjadi dan kamu butuh menagih, yang kamu perlukan bukan artikel ini, tapi contoh invoice usaha jasa. Artikel ini fokus ke tahap sebelumnya: bagaimana membuat penawaran yang membuat klien mau bilang ya.

    Anatomi surat penawaran harga yang lengkap

    Tidak ada format baku yang diwajibkan aturan mana pun. Tapi dari pengalaman kami mengirim penawaran proyek software ke berbagai perusahaan, bagian-bagian ini yang membuat penawaran terasa profesional dan mudah disetujui. Urutannya juga bukan kebetulan. Dokumen mengalir dari siapa kamu, apa yang klien butuhkan, apa yang kamu tawarkan, sampai apa yang harus klien lakukan berikutnya.

    • Kop atau identitas usaha. Nama usaha, alamat, kontak, dan logo kalau ada. Klien perlu tahu sedang berurusan dengan siapa. Ini juga jadi dasar kalau nanti dibutuhkan untuk dokumen resmi.
    • Nomor dan tanggal. Contohnya QUO/2026/07/012. Nomor memudahkan kedua pihak merujuk dokumen yang sama saat diskusi. Tanggal jadi patokan masa berlaku harga.
    • Ditujukan ke siapa. Tulis nama orangnya, bukan cuma nama PT. “Kepada Ibu Ratna, Manajer HRD PT Maju Sentosa” terasa personal. “Kepada PT Maju Sentosa” terasa seperti penawaran massal yang dikirim ke banyak perusahaan sekaligus.
    • Ringkasan kebutuhan klien versi kamu. Dua sampai tiga kalimat yang merangkum apa yang klien butuhkan berdasarkan obrolan sebelumnya. Bagian ini pembeda besar. Klien langsung merasa didengar, dan kalau ada salah paham soal kebutuhan, ketahuan di sini, bukan di tengah pengerjaan.
    • Rincian scope per item dengan harga. Pecah pekerjaan jadi item yang bisa dipahami, masing-masing dengan harganya. Kalau modelnya paket, jelaskan isi tiap paket. Rincian membuat harga terasa masuk akal karena klien melihat apa saja yang dibayar.
    • Yang tidak termasuk. Bagian ini menyelamatkanmu dari scope creep. Tulis dengan sopan, misalnya “Penawaran ini belum termasuk biaya cetak dan pengiriman ke luar kota. Kalau dibutuhkan, bisa kami hitungkan terpisah.” Nadanya membantu, bukan membatasi.
    • Termin pembayaran. Misalnya DP 50 persen saat konfirmasi, pelunasan saat serah terima. Klien tahu kapan harus siapkan dana, kamu tahu kapan uang masuk.
    • Estimasi waktu pengerjaan. Hitung dari pembayaran DP, bukan dari tanggal penawaran. “14 hari kerja sejak DP diterima” jauh lebih aman daripada “selesai akhir bulan”.
    • Masa berlaku harga. Misalnya 14 hari sejak tanggal penawaran. Harga bahan dan ongkos berubah. Tanpa masa berlaku, kamu bisa dihubungi enam bulan kemudian dan diminta harga lama. Masa berlaku juga memberi alasan halus untuk follow-up.
    • Portofolio atau bukti singkat. Satu dua kalimat plus tautan. Tidak perlu daftar panjang. Cukup bukti bahwa kamu pernah mengerjakan hal serupa.
    • Langkah selanjutnya yang jelas. Tutup dengan instruksi konkret. “Balas email ini atau hubungi 0812-xxxx untuk konfirmasi” lebih efektif daripada “demikian penawaran kami, atas perhatiannya kami ucapkan terima kasih” yang menggantung tanpa arah.

    Contoh surat penawaran harga utuh

    Berikut contoh untuk kasus jasa pembuatan seragam kantor. Strukturnya bisa ditiru usaha apa pun, tinggal ganti isi itemnya.

    Contoh format lengkap

    • CV Kirana Konveksi
      Jl. Ahmad Yani No. 45, Purwokerto
      0812-3456-7890 | halo@kiranakonveksi.id
    • Surat Penawaran Harga
      Nomor: QUO/2026/07/012
      Tanggal: 26 Juli 2026
    • Kepada: Ibu Ratna Dewi, Manajer HRD PT Maju Sentosa
    • Ringkasan kebutuhan: Berdasarkan diskusi kita tanggal 22 Juli, PT Maju Sentosa membutuhkan 50 pcs seragam kantor lengan panjang dengan bordir logo di dada kiri, target selesai sebelum acara ulang tahun perusahaan pertengahan September.
    • Rincian penawaran:
      1. Kemeja seragam bahan katun drill Nagata, lengan panjang, 50 pcs x Rp135.000 = Rp6.750.000
      2. Bordir logo perusahaan di dada kiri, 50 pcs x Rp15.000 = Rp750.000
      3. Sampel jadi 1 pcs untuk approval sebelum produksi massal = Rp200.000
      Total: Rp7.700.000
    • Belum termasuk: ongkos kirim ke luar Purwokerto dan penambahan ukuran jumbo di atas XXL (selisih Rp10.000 per pcs). Kalau dibutuhkan, kami hitungkan terpisah.
    • Termin pembayaran: DP 50 persen saat konfirmasi, pelunasan saat barang siap kirim.
    • Estimasi pengerjaan: 20 hari kerja sejak DP dan approval sampel.
    • Masa berlaku: harga berlaku 14 hari sejak tanggal surat ini.
    • Portofolio: kami rutin mengerjakan seragam untuk instansi di Banyumas, di antaranya 120 pcs untuk BPR setempat bulan Mei lalu. Foto hasil bisa dilihat di kiranakonveksi.id/galeri.
    • Langkah selanjutnya: balas email ini atau hubungi 0812-3456-7890 untuk konfirmasi. Setelah DP masuk, sampel kami kerjakan dalam 3 hari kerja.

    Perhatikan polanya. Setiap angka ada penjelasannya. Setiap tahap ada patokannya. Klien yang membaca ini tidak perlu bertanya apa pun untuk mengambil keputusan.

    Kalimat pengantar saat mengirim penawaran

    Jangan kirim file kosong tanpa konteks. Klien sibuk. Kalau harus membuka PDF dulu untuk tahu isinya, sebagian tidak akan membukanya sama sekali. Tulis pengantar singkat yang menyebut poin utama, jadi isi penawaran sudah tersampaikan bahkan sebelum file dibuka.

    Contoh untuk email:

    • “Ibu Ratna, terlampir penawaran seragam kantor 50 pcs sesuai diskusi kita kemarin. Totalnya Rp7.700.000 sudah termasuk bordir logo dan sampel approval, estimasi selesai 20 hari kerja. Detail lengkap ada di lampiran. Kalau ada yang mau disesuaikan, kabari saya ya Bu.”

    Contoh untuk WhatsApp:

    • “Pak Dimas, penawaran website company profile yang kemarin sudah saya kirim ke email ya. Ringkasnya: Rp12 juta, termasuk desain custom dan 5 halaman, selesai 30 hari kerja. Harga berlaku sampai 9 Agustus. Kalau mau bahas dulu sebelum putuskan, saya bisa telepon besok pagi.”

    Dua contoh itu punya pola sama. Sebut angka utama, sebut waktu, buka pintu diskusi. Klien merasa dipermudah, bukan disuruh membaca sendiri.

    Follow-up kalau penawaran belum dibalas

    Penawaran yang didiamkan itu normal. Kebanyakan bukan karena klien menolak, tapi karena tenggelam di antara urusan lain. Bisa juga sedang menunggu persetujuan atasan, atau sedang membandingkan dengan vendor lain. Aturan praktisnya: follow-up pertama di hari ketiga, follow-up kedua di hari ketujuh. Terlalu cepat terkesan mendesak, terlalu lama membuat penawaranmu keburu dilupakan.

    Contoh H+3, nadanya bantu bukan nagih:

    • “Ibu Ratna, mau memastikan penawaran seragam yang saya kirim Senin sudah diterima ya Bu. Kalau ada bagian yang perlu dijelaskan atau disesuaikan, saya siap bantu.”

    Contoh H+7, pakai masa berlaku sebagai pengingat wajar:

    • “Ibu Ratna, sekadar mengingatkan harga di penawaran kami berlaku sampai 9 Agustus ya Bu. Kalau butuh waktu lebih, tidak apa-apa, kabari saja supaya bisa saya perpanjang atau sesuaikan.”

    Setelah dua kali follow-up masih sunyi, beri jeda lebih panjang atau tutup dengan sopan. Cara lengkap menangani calon klien yang tanya harga lalu menghilang sudah kami bahas di artikel follow-up pelanggan.

    Kesalahan yang bikin penawaran didiamkan

    Empat kesalahan ini paling sering kami temui, dan semuanya mudah dihindari.

    • Harga gelondongan tanpa rincian. “Total Rp15 juta” tanpa pecahan item memicu tawar buta. Klien tidak tahu apa yang bisa dikurangi, jadi mereka menawar totalnya. Kalau ada rincian, negosiasi jadi soal menyesuaikan scope, bukan memotong harga.
    • Scope ambigu. “Desain sampai jadi” itu jadi menurut siapa. Klien bisa minta revisi kesepuluh dan merasa masih dalam kesepakatan. Tulis batasnya: berapa konsep, berapa kali revisi, apa definisi selesai.
    • Tidak ada masa berlaku. Tanpa tanggal kedaluwarsa, penawaranmu hidup selamanya. Ada yang dihubungi enam bulan kemudian dan diminta mengerjakan dengan harga lama, padahal ongkos sudah naik. Posisimu lemah karena dokumenmu sendiri tidak menyebut batas waktu.
    • File berat atau format aneh. Penawaran dalam file desain 25 MB atau format yang butuh aplikasi khusus hampir pasti tidak dibuka. PDF rapi di bawah 1 MB adalah standar yang aman di mana pun.

    Mulai dari template, rapikan seiring jalan

    Kamu tidak perlu langsung sempurna. Ambil struktur di atas, buat satu template, lalu perbaiki setiap kali ada klien yang bertanya sesuatu yang seharusnya sudah terjawab di dokumen. Pertanyaan klien adalah daftar revisi terbaik untuk template penawaranmu.

    Satu catatan untuk yang volumenya sudah besar. Kalau tiap bulan kamu mengirim belasan penawaran dan mulai kehilangan jejak mana yang sudah dibalas, mana yang harus di-follow-up, dan mana yang kedaluwarsa, itu tanda proses manualnya sudah mentok. Sistem aplikasi yang menggenerate quotation otomatis dan melacak statusnya bisa memangkas pekerjaan admin itu, jadi waktumu habis untuk menutup deal, bukan menyusun dokumen.

  • Aplikasi Kasir Restoran: Meja, Pesanan ke Dapur, dan Split Bill

    Aplikasi Kasir Restoran: Meja, Pesanan ke Dapur, dan Split Bill

    Aplikasi kasir restoran itu beda dengan kasir toko biasa. Tugasnya membereskan tiga alur sekaligus: kondisi meja, pesanan yang jalan ke dapur, dan pembayaran yang sering dipecah per orang. Kasir toko cukup scan barang lalu terima uang. Restoran tidak sesederhana itu. Satu meja bisa pesan tiga kali, minta catatan khusus, lalu bayarnya patungan berlima.

    Artikel ini untuk Anda yang punya resto, kafe, atau warung makan yang ordernya masih dicatat di kertas lalu diteriakkan ke dapur. Kita bahas fitur yang benar-benar dipakai setiap hari, kapan warung kecil sebenarnya belum butuh aplikasi seperti ini, dan kapan lebih masuk akal bikin sistem sendiri.

    Manajemen meja: tahu kondisi resto tanpa keliling

    Di jam ramai, pertanyaan paling sering muncul sebenarnya sederhana. Meja mana yang kosong. Meja mana yang sudah pesan tapi makanannya belum keluar. Meja mana yang dari tadi minta bill. Kalau jawabannya harus dicari dengan keliling ruangan, ada yang bisa diperbaiki.

    Aplikasi kasir restoran yang baik menampilkan denah meja sesuai layout resto Anda. Setiap meja punya status yang kelihatan sekilas:

    • Kosong, siap diisi tamu baru
    • Terisi, tamu sudah duduk tapi belum pesan
    • Sudah pesan, order sedang diproses dapur
    • Minta bill, tinggal proses pembayaran

    Waiter jadi tahu meja mana yang belum dilayani tanpa harus ditegur tamu dulu. Kasir tahu tagihan mana yang harus disiapkan. Untuk rombongan, fitur gabung meja juga penting. Dua meja disatukan, pesanannya masuk ke satu tagihan, tidak perlu dicatat terpisah lalu dijumlah manual di akhir.

    Pesanan langsung sampai ke dapur, bukan lewat teriakan

    Ini pembeda paling besar dari kasir toko. Di restoran, mencatat pesanan baru setengah pekerjaan. Setengahnya lagi adalah memastikan pesanan itu sampai ke dapur dengan benar dan dimasak sesuai urutan.

    Alur manualnya biasanya begini. Waiter catat di kertas, teriak ke dapur atau antar notanya, lalu koki masak berdasarkan ingatan dan tumpukan nota. Di jam sepi cara ini masih jalan. Di jam ramai mulai muncul masalah klasik: salah dengar, nota selip di antara nota lain, dan urutan masak yang kacau sehingga tamu yang datang duluan malah dapat makanan belakangan.

    Dengan aplikasi kasir, order yang diketik waiter atau kasir langsung tercetak di printer dapur, atau tampil di layar dapur. Koki melihat antrian pesanan berurutan, lengkap dengan nomor meja dan jam masuk order. Tidak ada lagi perdebatan soal siapa pesan duluan, karena semuanya tercatat.

    Pesanan per meja yang terus berjalan

    Tamu restoran jarang pesan sekali lalu selesai. Di tengah makan, mereka tambah minuman atau pesan menu lagi. Sistem yang benar memperlakukan satu meja sebagai satu tagihan berjalan. Order tambahan masuk ke tagihan yang sama, dapur menerima order baru itu sebagai antrian baru, dan di akhir semua terjumlah rapi dalam satu bill.

    Catatan khusus juga wajib ada. Tanpa cabe, saus dipisah, es sedikit, tidak pakai bawang. Permintaan seperti ini paling sering hilang kalau hanya disampaikan lisan. Kalau catatannya menempel di order yang tampil di dapur, koki tinggal baca.

    Tandai menu habis sebelum dijanjikan ke tamu

    Situasi yang bikin tamu kesal: sudah pesan, ditunggu lama, lalu waiter datang bilang menunya habis. Aplikasi kasir yang baik punya penanda sold out. Begitu bahan habis, dapur atau kasir menandai menu itu, dan menu langsung tidak bisa dipesan dari perangkat mana pun. Waiter tidak akan menjanjikan sesuatu yang tidak bisa dimasak.

    Kalau resto Anda sudah rapi di alur dasar ini, langkah lanjutannya adalah QR menu di meja. Tamu scan kode, lihat menu, dan pesan sendiri dari ponselnya tanpa menunggu waiter datang. Cara kerja QR untuk kebutuhan bisnis seperti ini pernah kami bahas di artikel cara membuat QR code untuk bisnis.

    Split bill, pajak resto, dan hitungan yang rawan salah

    Rombongan enam orang selesai makan, lalu bilang mau bayar sendiri-sendiri. Kalau kasir harus memilah nota tulisan tangan sambil menghitung ulang di kalkulator, antrian di belakang ikut menunggu. Split bill adalah salah satu fitur yang paling sering diminta pelanggan resto, dan paling menyiksa kalau dikerjakan manual.

    Di aplikasi kasir restoran, kasir tinggal memilih item mana milik siapa, lalu sistem memecah tagihan per orang. Bisa juga dibagi rata. Kebalikannya pun didukung: beberapa tagihan digabung jadi satu ketika ada yang mau mentraktir satu rombongan.

    Hitungan lain yang rawan salah adalah pajak dan biaya layanan. Pajak restoran atau PB1 umumnya 10 persen, dan sebagian resto menambahkan service charge. Kalau ada diskon, urutannya harus benar: diskon dulu, baru pajak dihitung dari nilai setelah diskon. Salah urutan sedikit saja, angka di struk jadi tidak konsisten. Sistem menghitung semua ini otomatis, dan struknya merinci jelas sehingga tamu tidak curiga ada biaya siluman.

    Laporan yang memberi tahu pemilik apa yang sebenarnya terjadi

    Bagi pemilik, nilai terbesar aplikasi kasir justru muncul setelah tutup toko. Beberapa laporan yang layak dicek rutin:

    • Menu terlaris dan margin per menu. Menu yang paling sering dipesan belum tentu paling menguntungkan. Data ini jadi dasar keputusan menu mana dipertahankan, mana dinaikkan harganya, mana dihapus.
    • Jam ramai. Kalau data menunjukkan resto padat jam 12 sampai 2 siang dan jam 7 sampai 9 malam, jadwal shift dan belanja bahan bisa disesuaikan, bukan dikira-kira.
    • Penjualan per waiter. Kelihatan siapa yang paling banyak melayani order, berguna untuk evaluasi dan insentif.
    • Void dan pembatalan. Ini yang paling sering dilewatkan. Transaksi dibatalkan setelah tamu bayar tunai adalah celah kecurangan klasik di bisnis makanan. Kalau setiap void tercatat siapa pelakunya dan jam berapa, celah itu tertutup rapat.

    Semua laporan ini bisa dilihat dari mana saja. Pemilik tidak harus duduk di kasir tiap malam untuk tahu omzet hari itu.

    Kapan belum butuh, dan pilih aplikasi jadi atau custom

    Jujur saja, tidak semua usaha makan butuh sistem seperti ini sekarang. Kalau warung Anda punya lima meja, menu belasan, dan Anda sendiri yang jaga kasir sekaligus hafal semua pesanan, buku catatan masih cukup. Aplikasi kasir di kondisi ini hanya menambah pekerjaan input tanpa mengurangi masalah, karena memang belum ada masalah alur yang serius.

    Tanda-tanda sudah waktunya pindah ke sistem biasanya jelas. Pesanan mulai sering salah antar. Nota hilang atau tertukar saat ramai. Antrian bayar mengular karena kasir menghitung manual. Anda tidak tahu pasti menu mana yang untung. Atau Anda mulai curiga ada selisih uang yang tidak bisa dijelaskan. Satu saja dari daftar ini terjadi berulang, biaya aplikasi kasir hampir pasti lebih murah daripada biaya kekacauannya.

    Soal pilihannya, ada dua jalur. Aplikasi kasir jadi dengan model langganan bulanan cocok untuk mulai cepat. Fiturnya standar dan sudah teruji, meski Anda harus menyesuaikan alur resto dengan cara kerja aplikasinya, bukan sebaliknya. Jalur kedua adalah sistem custom. Ini masuk akal kalau alur resto Anda punya keunikan yang tidak diakomodasi aplikasi jadi, punya beberapa cabang yang perlu laporan terpusat, atau ingin sistem yang jadi milik sendiri tanpa biaya langganan selamanya. Gambaran cara kami membangun sistem seperti ini bisa dilihat di halaman pengembangan sistem aplikasi.

    Pertanyaan yang sering muncul

    Apakah aplikasi kasir restoran harus selalu terhubung internet?

    Tidak selalu. Banyak aplikasi kasir punya mode offline, jadi transaksi tetap jalan saat internet putus dan data tersinkron begitu koneksi kembali. Yang penting dicek: apakah printer dapur dan perangkat kasir masih saling terhubung lewat jaringan lokal saat offline. Kalau semua fitur mati begitu wifi mati, itu tanda arsitekturnya kurang cocok untuk resto.

    Perangkat apa saja yang dibutuhkan untuk mulai?

    Minimal satu tablet atau komputer untuk kasir, satu printer struk, dan satu printer dapur atau layar dapur. Waiter bisa memakai ponsel Android biasa untuk input order dari meja. Tidak wajib beli perangkat mahal di awal. Mulai dari kebutuhan inti dulu, tambah perangkat saat alurnya sudah terbukti jalan.

    Fitur mana yang paling penting kalau anggarannya terbatas?

    Prioritaskan alur order ke dapur dan pencatatan per meja. Dua hal itu yang paling banyak menghapus kesalahan harian. Split bill dan laporan menyusul di urutan berikutnya. QR menu untuk pesan mandiri bisa jadi tahap paling akhir, setelah tim Anda terbiasa dengan sistem dasarnya.

    Kalau order di resto Anda masih mengandalkan teriakan dan tumpukan nota, mulailah dari memetakan tiga alur tadi: meja, dapur, pembayaran. Dari situ akan kelihatan apakah aplikasi kasir jadi sudah cukup, atau alur resto Anda butuh sistem yang dirancang khusus. Kalau mau mendiskusikan alur resto Anda dulu sebelum memutuskan, tim kami bisa diajak ngobrol lewat halaman kontak. Ceritakan saja kondisi sekarang, nanti kita lihat bersama solusi yang paling masuk akal.

  • RAB vs Realisasi: Cara Kontraktor Mengendalikan Biaya Proyek

    RAB vs Realisasi: Cara Kontraktor Mengendalikan Biaya Proyek

    Biaya proyek konstruksi terkendali kalau tiga kebiasaan ini jalan bersamaan. Pertama, RAB dipecah per item pekerjaan, bukan satu angka gelondongan. Kedua, setiap pengeluaran dicatat hari itu juga ke item RAB yang sesuai. Ketiga, selisih antara rencana dan realisasi dicek setiap minggu, bukan pas proyek selesai. Kalau salah satu dari tiga ini tidak jalan, biaya proyek pada dasarnya berjalan tanpa kendali.

    Banyak kontraktor kecil dan pemborong baru sadar ada masalah justru saat proyek sudah beres. Termin sudah cair semua, tagihan toko sudah dibayar, upah tukang sudah lunas. Tapi sisa uang di rekening jauh dari hitungan awal, dan tidak ada yang bisa menjelaskan angkanya lari ke mana. Artikel ini membahas cara mengendalikan biaya proyek dengan disiplin membandingkan RAB vs realisasi, pakai contoh angka dari satu proyek renovasi sederhana supaya gampang diikuti.

    Ke Mana Perginya Untung Proyek

    Untung proyek jarang hilang dalam satu kejadian besar. Biasanya menguap sedikit demi sedikit lewat empat lubang yang sama di hampir semua proyek.

    • Bon material tercecer. Beli semen pagi, bonnya masuk kantong celana, sorenya hilang. Satu bon Rp 300 ribu terlihat kecil. Tapi kalau kejadian dua kali seminggu selama tiga bulan, itu sudah Rp 7 jutaan yang tidak pernah masuk hitungan.
    • Kasbon tukang tidak tercatat. Tukang pinjam Rp 200 ribu hari Rabu, dijanjikan potong gajian Sabtu. Sabtu datang, yang ingat cuma tukangnya. Kasbon yang lupa dipotong itu biaya upah tambahan yang tidak pernah direncanakan.
    • Pekerjaan tambah dikerjakan tanpa hitung ulang. Owner minta geser posisi pintu, tambah satu titik listrik, ganti model kanopi. Karena merasa tidak enak, semua dikerjakan dulu tanpa bicara harga. Materialnya keluar dari kantong kontraktor, dan di akhir proyek sulit menagihnya.
    • Harga material naik di tengah jalan. RAB disusun pakai harga besi bulan Januari, proyek jalan sampai April. Kalau kenaikan harga tidak pernah dibandingkan dengan asumsi RAB, selisihnya diam diam menggerogoti margin.

    Keempat lubang ini punya satu kesamaan. Semuanya baru ketahuan kalau ada pembanding. Dan pembanding itu namanya RAB yang disusun dengan benar.

    Menyusun RAB yang Bisa Dikontrol

    RAB satu baris berbunyi “Renovasi rumah: Rp 150 juta” tidak bisa dikontrol. Kalau di tengah proyek uang sudah keluar Rp 100 juta, tidak ada cara untuk tahu itu wajar atau sudah kebablasan. RAB yang bisa dikontrol dipecah per item pekerjaan.

    Ambil contoh proyek renovasi rumah dengan nilai kontrak Rp 150 juta. Pecahannya kira kira seperti ini.

    • Bongkaran dan persiapan: Rp 5 juta
    • Pondasi dan struktur: Rp 30 juta
    • Dinding dan plesteran: Rp 25 juta
    • Atap: Rp 20 juta
    • Lantai dan keramik: Rp 18 juta
    • Kusen, pintu, jendela: Rp 12 juta
    • Finishing dan pengecatan: Rp 15 juta
    • Biaya tak langsung: Rp 7,5 juta
    • Cadangan tak terduga: Rp 7,5 juta

    Total anggaran biaya Rp 140 juta, sehingga target untung Rp 10 juta dari kontrak Rp 150 juta. Angka target ini penting. Tanpa target yang jelas, kontraktor tidak akan pernah tahu apakah proyek untung sesuai rencana atau cuma untung seadanya.

    Pisahkan material dan upah di setiap item

    Setiap item dipecah lagi jadi dua: material dan upah. Item dinding dan plesteran Rp 25 juta misalnya, dipecah jadi material Rp 16 juta dan upah Rp 9 juta. Gunanya, saat ada selisih, langsung ketahuan sumbernya. Selisih di material berarti soal harga atau pemakaian bahan. Selisih di upah berarti soal jumlah hari kerja atau produktivitas tukang.

    Jangan lupa dua pos yang paling sering hilang

    Biaya tak langsung sering tidak masuk RAB karena dianggap kecil. Padahal transport material, sewa alat, konsumsi rapat dengan owner, sampai retribusi lingkungan bisa makan 4 sampai 6 persen nilai proyek. Di contoh tadi, Rp 7,5 juta sudah disiapkan untuk pos ini.

    Pos kedua adalah cadangan tak terduga. Sisihkan 5 sampai 10 persen dari anggaran biaya. Cadangan ini bukan untuk menutup salah hitung, tapi untuk hal yang memang tidak bisa diprediksi, seperti hujan berkepanjangan atau kondisi struktur lama yang ternyata lebih parah dari perkiraan. Kalau tidak terpakai, cadangan ini jadi tambahan untung. Kalau tidak disiapkan sama sekali, setiap kejutan langsung memotong margin.

    Disiplin Pencatatan Harian

    RAB serapi apa pun tidak ada gunanya kalau realisasinya tidak dicatat. Aturannya sederhana. Setiap pengeluaran dicatat hari itu juga, dan dicatat ke item RAB yang sesuai.

    Tentukan dulu siapa yang pegang catatan. Di proyek kecil biasanya mandor atau kontraktornya sendiri. Kalau sudah ada admin, serahkan ke admin dengan aturan jelas: mandor wajib setor bon dan laporan setiap sore. Yang penting satu orang yang bertanggung jawab, bukan semua orang mencatat semaunya di tempat masing masing.

    Tiga kebiasaan kecil yang menyelamatkan banyak uang:

    • Bon difoto hari itu juga. Kertas bon boleh hilang, fotonya tidak. Beli semen Rp 1,2 juta, foto bonnya sebelum keluar dari toko, catat ke item dinding dan plesteran.
    • Kasbon langsung masuk catatan. Tukang kasbon Rp 200 ribu, detik itu juga dicatat ke item upah pekerjaan yang sedang dia kerjakan. Saat gajian tinggal lihat catatan, tidak ada yang lupa dipotong.
    • Tidak ada istilah “nanti dirapikan”. Catatan yang ditunda sampai akhir minggu hampir pasti bolong. Ingatan manusia untuk urusan uang receh itu pendek sekali.

    Kuncinya bukan alatnya. Buku tulis bisa, spreadsheet bisa. Kuncinya konsistensi harian dan setiap angka menempel ke item RAB-nya.

    Review Mingguan, Bukan Review Akhir Proyek

    Ini kebiasaan yang paling membedakan proyek untung dan proyek buntung. Setiap akhir minggu, duduk 30 menit, bandingkan realisasi dengan RAB per item.

    Kembali ke contoh renovasi tadi. Masuk minggu kedua, item dinding dan plesteran sudah menyerap Rp 12 juta dari anggaran Rp 25 juta, alias 48 persen. Padahal progres fisik dindingnya baru sekitar 35 persen. Ada selisih sekitar Rp 3 juta yang jalan lebih cepat dari pekerjaannya. Karena ketahuan di minggu kedua, masih ada waktu untuk cari sebabnya. Ternyata harga bata naik dan pemakaian semen lebih boros dari asumsi.

    Dari temuan seperti itu, ada beberapa keputusan yang bisa diambil selagi proyek masih panjang:

    • Ganti spesifikasi material yang setara tapi lebih masuk anggaran, tentu dengan sepengetahuan owner
    • Nego ulang harga ke toko material, atau pindah ke supplier lain untuk kebutuhan sisa proyek
    • Perketat pemakaian bahan di lapangan dan atur ulang komposisi tukang dan kenek supaya upah harian lebih efisien
    • Kalau selisihnya memang di luar kendali, pakai sebagian cadangan tak terduga secara sadar, bukan diam diam

    Bandingkan dengan kontraktor yang baru menghitung di akhir proyek. Selisih Rp 3 juta di item dinding baru ketahuan setelah semua selesai, digabung selisih di atap dan finishing yang juga tidak pernah dicek. Tidak ada satu pun keputusan yang bisa diambil lagi. Item yang mulai jebol harusnya ketahuan sejak minggu kedua, bukan bulan kedua.

    Pekerjaan Tambah Kurang: Penyelamat Margin Nomor Satu

    Kalau cuma boleh pilih satu aturan dari seluruh artikel ini, pilih yang ini. Setiap pekerjaan tambah harus dihitung, ditulis, dan disetujui owner sebelum dikerjakan, lengkap dengan harganya.

    Di lapangan, permintaan tambahan hampir selalu datang. Di contoh renovasi tadi, masuk minggu keempat owner minta tambah kanopi carport yang tidak ada di kontrak. Kontraktor yang disiplin akan berhenti sebentar, hitung material dan upahnya, misalnya ketemu Rp 8 juta, lalu sodorkan catatan tambah kurang untuk ditandatangani. Baru setelah itu kanopi dikerjakan, dan RAB ditambah satu item baru senilai Rp 8 juta.

    Kontraktor yang tidak enakan akan langsung mengerjakan. Di akhir proyek, tagihan Rp 8 juta itu jadi bahan debat. Owner merasa itu bagian dari harga borongan, kontraktor merasa itu tambahan. Yang sering terjadi, tagihannya dibayar sebagian atau tidak dibayar sama sekali. Dari target untung Rp 10 juta, hilang Rp 8 juta gara gara satu kanopi. Itulah kenapa aturan tertulis sebelum dikerjakan disebut penyelamat margin nomor satu.

    Berlaku juga sebaliknya untuk pekerjaan kurang. Kalau owner membatalkan satu pekerjaan, catat pengurangannya secara tertulis juga, supaya nilai kontrak akhir sama sama jelas.

    Membaca Kesehatan Proyek dari Angka

    Ada satu cara cepat menilai proyek sehat atau tidak: bandingkan persentase realisasi biaya dengan persentase progres fisik.

    Contohnya begini. Di minggu keenam, progres fisik renovasi sekitar 60 persen. Cek total realisasi biaya. Kalau yang terpakai Rp 82 juta dari anggaran Rp 140 juta, itu sekitar 58 persen. Biaya jalan seiring pekerjaan, proyek sehat. Kalau yang terpakai Rp 105 juta alias 75 persen padahal fisik baru 60 persen, ada masalah serius. Sisa anggaran 25 persen harus menyelesaikan 40 persen pekerjaan, dan itu hampir pasti tidak cukup.

    Aturan praktisnya: realisasi biaya boleh sedikit di bawah atau setara progres fisik. Begitu realisasi konsisten lebih tinggi dari progres fisik dua minggu berturut turut, berhenti dan cari sumbernya di level item. Angka gabungan hanya memberi tahu ada masalah. RAB per item yang memberi tahu masalahnya di mana.

    Kalau Proyeknya Sudah Lebih dari Satu

    Semua praktik di atas bisa dijalankan dengan buku tulis atau spreadsheet, dan untuk satu proyek itu cukup. Masalah mulai muncul saat proyek jalan dua atau tiga sekaligus. Bon proyek A tercampur dengan proyek B, kasbon tukang yang pindah pindah lokasi jadi kabur, dan review mingguan yang harusnya 30 menit berubah jadi kerja semalaman merapikan catatan. Di titik itu banyak kontraktor menyerah, dan kebocoran lama kambuh lagi.

    Kalau sudah sampai fase itu, wajar mulai melirik alat bantu. Kami pernah membahas lebih dalam soal ini di artikel aplikasi manajemen proyek konstruksi untuk anggaran dan progres, termasuk kapan spreadsheet masih cukup dan kapan tidak. Arrazy sendiri terbiasa mengerjakan kebutuhan digital untuk bisnis konstruksi, salah satunya website Mandor Bangun, company profile kontraktor dengan galeri proyek yang dibangun untuk memenangkan kepercayaan calon klien.

    Yang terpenting, mulai dulu dari disiplinnya. RAB dipecah per item, catat pengeluaran hari itu juga, review selisih tiap minggu, dan jangan pernah mengerjakan pekerjaan tambah tanpa persetujuan tertulis. Empat kebiasaan itu gratis, dan dampaknya ke margin jauh lebih besar daripada alat secanggih apa pun. Kalau suatu saat butuh sistem pencatatan yang dirancang khusus untuk alur kerja proyek Anda, tim kami terbuka untuk diskusi lewat halaman kontak Arrazy.

  • Membaca Google Analytics: 5 Angka Penting untuk Pemilik Bisnis

    Membaca Google Analytics: 5 Angka Penting untuk Pemilik Bisnis

    Website sudah jadi, developer bilang Google Analytics sudah dipasang, lalu dashboard itu tidak pernah dibuka lagi. Kalau itu terjadi pada Anda, tenang saja. Anda tidak sendirian, dan Anda memang tidak perlu paham semua menu di dalamnya. Google Analytics versi sekarang (GA4) memang terasa rumit untuk orang yang bukan praktisi digital marketing. Menunya banyak, istilahnya asing, dan sebagian besar laporannya tidak Anda butuhkan.

    Kabar baiknya, sebagai pemilik bisnis Anda cukup melihat lima angka saja, sebulan sekali. Lima angka itu: berapa orang yang berkunjung, dari mana mereka datang, halaman apa yang paling banyak dilihat, berapa yang melakukan aksi penting seperti klik tombol WhatsApp atau mengisi form, dan apakah mereka membuka website lewat HP atau laptop. Lima angka ini sudah cukup untuk mengambil keputusan bisnis yang nyata. Sisanya boleh Anda abaikan.

    Satu hal dulu sebelum masuk ke angkanya, supaya tidak tertukar. Google Analytics berbeda dengan Google Search Console. Analytics menceritakan apa yang terjadi di dalam website Anda: siapa yang datang, apa yang mereka lihat, apa yang mereka lakukan. Search Console menceritakan bagaimana orang menemukan website Anda di hasil pencarian Google: kata kunci apa yang mereka ketik, di posisi berapa website Anda muncul. Kalau masalah Anda justru website tidak muncul di Google sama sekali, itu urusan Search Console dan sudah kami bahas terpisah di artikel website sudah jadi tapi belum muncul di Google. Artikel yang sedang Anda baca fokus ke Analytics.

    1. Berapa Orang yang Berkunjung (Users)

    Ini angka paling dasar. Di GA4, angka ini muncul di laporan ringkasan paling depan, biasanya dengan label Users atau Pengguna. Satu user berarti satu orang, walaupun dia membuka website beberapa kali dalam sebulan.

    Cara membacanya sederhana. Lihat angka bulan ini, bandingkan dengan bulan lalu. Naik, turun, atau datar. Itu saja dulu.

    Keputusan bisnis yang bisa diambil dari angka ini:

    • Kalau angkanya nol atau nyaris nol selama berbulan-bulan, website Anda praktis tidak dikunjungi siapa pun. Percuma memikirkan desain atau konten sebelum masalah ini dibereskan.
    • Kalau angkanya naik setelah Anda rajin posting di media sosial atau pasang iklan, berarti aktivitas itu ada hasilnya dan layak diteruskan.
    • Kalau angkanya turun terus tiga bulan berturut-turut, ada sesuatu yang perlu dicek, entah dari sisi konten, teknis, atau promosi.

    Jangan terpaku pada besar kecilnya angka. Website bisnis lokal dengan 300 pengunjung sebulan bisa jauh lebih menguntungkan daripada blog dengan 30 ribu pengunjung yang tidak pernah menghasilkan satu transaksi pun.

    2. Dari Mana Mereka Datang (Kanal Trafik)

    Angka kedua ada di laporan Acquisition, atau Akuisisi kalau bahasa dashboard Anda Indonesia. Laporan ini membagi pengunjung berdasarkan asalnya: dari pencarian Google (organic search), dari media sosial, dari iklan berbayar, datang langsung dengan mengetik alamat website (direct), atau dari link di website lain (referral).

    Ini laporan yang paling sering membuka mata pemilik bisnis. Contoh nyata: 80 persen trafik Anda ternyata dari Instagram, sementara dari pencarian Google nyaris nol. Artinya bisnis Anda bergantung penuh pada media sosial, dan orang yang mencari produk sejenis di Google tidak pernah menemukan Anda. Kalau akun Instagram Anda kena masalah, trafik langsung mati. Kondisi seperti ini biasanya jadi alasan mulai serius menggarap trafik pencarian, entah dikerjakan sendiri atau lewat jasa SEO yang paham konteks bisnis Anda.

    Sebaliknya juga bisa terjadi. Trafik pencarian bagus tapi media sosial tidak menyumbang apa-apa, padahal Anda membayar admin untuk posting tiap hari. Angka di laporan ini membantu Anda menaruh budget promosi di tempat yang benar, bukan di tempat yang terasa paling sibuk.

    3. Halaman Apa yang Paling Banyak Dilihat

    Angka ketiga ada di laporan Engagement, bagian Pages and screens (Halaman dan layar). Laporan ini mengurutkan halaman dari yang paling banyak dibuka sampai yang paling sepi.

    Yang menarik dari laporan ini bukan sekadar peringkatnya, tapi cerita di baliknya:

    • Halaman harga paling banyak dilihat berarti pengunjung Anda serius, mereka sudah menimbang untuk membeli. Pastikan halaman itu jelas dan gampang ditindaklanjuti.
    • Satu artikel blog lama ternyata menyumbang separuh trafik. Berarti topik itu dicari orang. Perbarui artikelnya, tambahkan arahan ke halaman layanan Anda.
    • Halaman layanan andalan justru sepi. Bisa jadi tidak ada jalan menuju ke sana, tidak muncul di menu, tidak pernah di-link dari halaman lain.

    Kombinasikan dengan angka keempat di bawah, dan laporan ini jadi makin tajam. Halaman harga ramai dilihat tapi tidak ada satu pun yang klik tombol WhatsApp, berarti ada yang salah di halaman itu. Mungkin harganya membingungkan, mungkin tombolnya tersembunyi, mungkin tidak ada ajakan yang jelas. Yang pasti, masalahnya di halaman itu, bukan di jumlah pengunjung.

    4. Berapa yang Melakukan Aksi Penting (Konversi)

    Ini angka paling penting dari kelimanya, dan justru paling sering tidak ada. Di GA4 istilahnya key event, dulu disebut conversion. Maksudnya sederhana: berapa pengunjung yang melakukan aksi yang berarti untuk bisnis Anda. Untuk kebanyakan bisnis di Indonesia, aksi itu biasanya klik tombol WhatsApp atau mengirim form kontak.

    Kenapa penting sekali? Karena tanpa angka ini, Analytics cuma daftar jumlah pengunjung. Anda tahu 1.000 orang datang bulan ini, tapi tidak tahu apakah dari 1.000 itu ada yang benar-benar menghubungi Anda. Semua keputusan jadi tebakan. Dengan angka konversi, ceritanya berubah. Seribu pengunjung dengan 30 klik WhatsApp berarti kira-kira 3 dari 100 pengunjung tertarik menghubungi. Bulan depan Anda tinggal pantau: pengunjungnya yang perlu ditambah, atau rasio konversinya yang perlu diperbaiki.

    Masalahnya, pelacakan klik tombol WhatsApp dan form tidak otomatis ada. Harus dipasang. Kalau Anda tidak yakin website Anda sudah punya, tanyakan ke developer Anda dan minta dipasangkan. Satu hal yang perlu Anda tahu: ini setup standar yang biasa dikerjakan developer web, bukan proyek besar yang butuh biaya aneh-aneh.

    5. Dibuka Lewat HP atau Laptop

    Angka terakhir ada di laporan Tech atau User attributes, bagian perangkat (device). Laporan ini membagi pengunjung berdasarkan alat yang mereka pakai: mobile, desktop, atau tablet.

    Untuk kebanyakan bisnis di Indonesia, hasilnya hampir selalu sama: 70 sampai 90 persen pengunjung datang lewat HP. Konsekuensinya jelas. Website Anda harus nyaman dibuka di layar kecil. Tombol WhatsApp harus gampang dijangkau jempol. Tabel harga tidak boleh terpotong. Form tidak boleh menyiksa untuk diisi di HP.

    Keputusan praktisnya begini. Buka website Anda sendiri lewat HP, telusuri dari beranda sampai halaman kontak, dan rasakan sendiri. Kalau Anda saja malas menyelesaikannya, pengunjung Anda apalagi. Dan setiap kali developer menunjukkan tampilan baru lewat laptop, minta juga lihat versi HP-nya, karena di situlah mayoritas calon pelanggan Anda berada.

    Cara Membaca Pola Bulanan yang Sehat

    Lima angka tadi baru berguna kalau dibaca sebagai tren, bukan angka mati. Prinsipnya satu: bandingkan dengan bulan lalu, jangan terpaku pada angka absolut. Trafik 500 pengunjung itu bagus atau jelek? Tidak ada jawabannya. Tapi 500 pengunjung bulan ini dibanding 350 bulan lalu, itu cerita yang jelas.

    Prinsip kedua: trafik kecil dengan konversi bagus lebih sehat daripada trafik besar yang kosong. Website dengan 200 pengunjung dan 20 chat WhatsApp masuk sedang bekerja dengan baik. Website dengan 10 ribu pengunjung tanpa satu pun kontak masuk sedang punya masalah serius, berapa pun besar trafiknya.

    Ada beberapa jebakan yang sering menjerat pemilik bisnis saat membaca laporan bulanan:

    • Bangga dengan pageview tanpa tahu angka konversi. Pageview tinggi enak dilihat, tapi tidak membayar tagihan.
    • Panik saat trafik turun, padahal polanya musiman. Trafik bulan Ramadan, musim liburan, atau akhir tahun memang berbeda dari bulan biasa. Bandingkan juga dengan bulan yang sama tahun lalu kalau datanya sudah ada.
    • Lupa memfilter kunjungan sendiri. Kalau Anda dan tim membuka website berkali-kali tiap hari, angkanya ikut tercatat dan bisa menipu. Minta developer memasang filter internal traffic, ini juga pekerjaan kecil.

    Rutinitas 15 Menit Sebulan Sekali

    Supaya kebiasaan ini benar-benar jalan, buat sederhana saja. Pilih satu tanggal tetap tiap bulan, misalnya tanggal 1 atau tanggal 5. Buka Google Analytics, atur rentang tanggal ke bulan kemarin, lalu catat lima angka tadi di catatan HP atau spreadsheet sederhana: jumlah users, kanal terbesar, halaman terpopuler, jumlah konversi, dan persentase pengunjung mobile.

    Lima belas menit selesai. Dalam tiga sampai empat bulan, catatan sederhana itu akan menunjukkan pola yang tidak pernah Anda sadari sebelumnya. Dan saat Anda berdiskusi dengan developer atau tim marketing, Anda datang membawa data, bukan perasaan.

    Pertanyaan yang Sering Muncul

    Google Analytics itu gratis atau berbayar?

    Gratis. GA4 bisa dipakai tanpa biaya untuk kebutuhan bisnis kecil sampai menengah, dan untuk lima angka di artikel ini versi gratis sudah lebih dari cukup. Ada versi berbayar bernama Analytics 360, tapi itu untuk perusahaan berskala sangat besar.

    Apakah saya bisa melihat identitas orang yang berkunjung?

    Tidak. Google Analytics menampilkan data agregat, artinya angka gabungan seperti jumlah pengunjung, kota asal, dan jenis perangkat. Anda tidak bisa melihat nama, nomor HP, atau identitas pribadi pengunjung. Kalau ingin tahu siapa calon pelanggan Anda, cara yang benar adalah membuat mereka menghubungi lewat tombol WhatsApp atau form, dan itulah kenapa pelacakan konversi tadi penting.

    Apakah harus dicek setiap hari?

    Tidak perlu. Untuk pemilik bisnis, sebulan sekali sudah pas. Mengecek tiap hari justru membuat Anda bereaksi berlebihan pada naik turun harian yang wajar. Pengecualiannya hanya saat Anda sedang menjalankan iklan berbayar, saat itu wajar memantau lebih sering.

    Sampai sini, Anda sudah punya bekal yang cukup. Tidak perlu kursus, tidak perlu paham semua menu. Lima angka, sebulan sekali, dan keputusan bisnis Anda soal website tidak lagi berdasarkan tebakan.

    Satu catatan penutup. Semua ini mengandaikan website Anda memang sudah dipasangi Analytics dan pelacakan tombol WhatsApp dengan benar. Kalau Anda berencana membuat website baru atau membenahi yang lama, jadikan itu syarat sejak awal. Di Arrazy, pemasangan Google Analytics dan pelacakan klik WhatsApp termasuk hal yang wajar Anda minta dalam jasa pembuatan website, bukan tambahan mewah. Website tanpa alat ukur itu seperti toko tanpa catatan penjualan, ramai atau sepi hanya bisa ditebak dari perasaan.

  • Contoh Broadcast WhatsApp yang Tidak Bikin Pelanggan Kabur

    Contoh Broadcast WhatsApp yang Tidak Bikin Pelanggan Kabur

    Broadcast WhatsApp yang tidak bikin pelanggan kabur itu sebenarnya cuma butuh tiga syarat. Pertama, kirim ke orang yang memang pernah berinteraksi dengan bisnismu. Pernah beli, pernah tanya harga, pernah chat. Bukan nomor hasil beli daftar dari orang lain. Kedua, isi pesannya harus ada manfaat untuk penerima. Bukan sekadar promo, promo, dan promo lagi. Ketiga, frekuensinya jarang tapi berbobot. Satu sampai dua kali sebulan jauh lebih aman daripada muncul di notifikasi orang tiap hari.

    Kedengarannya sederhana. Tapi kebanyakan bisnis melanggar minimal satu dari tiga syarat itu. Hasilnya broadcast dibaca lalu didiamkan, atau lebih parah, langsung di-block. Di artikel ini kita bahas aturan teknisnya dulu, lalu anatomi pesan yang enak dibaca, enam contoh siap edit untuk situasi berbeda, sampai cara mengukur hasilnya.

    Aturan main broadcast WhatsApp yang jarang dijelaskan

    Sebelum bicara isi pesan, ada tiga fakta teknis yang sering bikin orang salah paham.

    Pertama, fitur broadcast list di WhatsApp biasa hanya sampai ke orang yang menyimpan nomormu di kontak mereka. Ini yang banyak pemilik usaha tidak tahu. Kamu kirim ke 200 nomor, yang benar-benar menerima mungkin cuma 50. Sisanya tidak menerima apa-apa, tanpa notifikasi gagal. Jadi kalau broadcast terasa sepi, cek dulu: apakah pelangganmu memang menyimpan nomormu? Cara paling natural membuat mereka menyimpan nomor adalah memberi alasan sejak transaksi pertama. Misalnya, “simpan nomor ini ya Kak, biar info garansi dan resi masuk ke chat”.

    Kedua, spam massal ke nomor asing berisiko kena banned. WhatsApp membaca sinyal seperti banyak penerima yang menandai pesanmu sebagai spam atau mem-block nomormu dalam waktu berdekatan. Kalau sinyal itu menumpuk, nomor bisnismu bisa dibekukan. Nomor yang sudah dipakai bertahun-tahun untuk jualan, hilang aksesnya dalam semalam. Ini alasan paling kuat kenapa kirim ke nomor beli-belian itu bukan strategi, tapi bunuh diri pelan-pelan.

    Ketiga, broadcast list dan grup itu dua hal berbeda. Broadcast list terkirim sebagai chat pribadi, penerima tidak tahu siapa saja yang menerima pesan yang sama. Grup sebaliknya, semua orang melihat semua orang, dan balasan satu orang mengganggu semua anggota. Jangan pakai grup untuk promo. Orang dimasukkan grup jualan tanpa izin itu salah satu alasan block paling cepat di WhatsApp.

    Anatomi broadcast yang enak dibaca

    Pesan broadcast yang direspons baik biasanya punya pola yang sama. Bukan soal bakat menulis, lebih ke disiplin struktur.

    • Sapaan yang tidak lebay. Cukup “Halo Kak” atau sebut nama kalau daftarmu kecil. Tidak perlu “HALO SAHABAT SETIA TOKO KAMI YANG LUAR BIASA”.
    • Inti pesan di dua baris pertama. Orang memutuskan lanjut baca atau tidak dari preview notifikasi. Jangan buang dua baris pertama untuk basa-basi.
    • Satu pesan satu tujuan. Mau info produk baru, ya itu saja. Jangan sekalian titip promo lain, info libur, dan minta review dalam satu pesan.
    • Cara merespons yang jelas. Sebutkan persis apa yang harus dilakukan penerima. Balas “MAU”, klik link, atau datang ke toko. Satu instruksi, bukan tiga.
    • Opsi berhenti di penutup. Kalimat seperti “balas STOP kalau tidak mau info seperti ini lagi” terlihat berisiko, padahal justru bikin dipercaya. Orang yang tahu dia bisa berhenti kapan saja cenderung tidak buru-buru mem-block. Dan yang balas STOP itu bukan kerugian, mereka memang bukan calon pembeli.

    Enam contoh broadcast siap edit

    Semua contoh di bawah bisa langsung disalin lalu disesuaikan dengan nama bisnis dan produkmu. Perhatikan polanya: pendek, jelas manfaatnya, ada satu ajakan.

    1. Info produk baru untuk pelanggan lama

    “Halo Kak, ini Dita dari Kopi Selasar. Kami baru rilis varian susu oat, cocok buat yang kemarin nanya opsi non-dairy. Sampai Minggu ini masih harga perkenalan 25 ribu dari normalnya 32 ribu. Kalau mau coba, balas MAU ya, nanti saya siapkan. Balas STOP kalau tidak ingin dapat info seperti ini lagi.”

    2. Promo terbatas dengan alasan yang jelas

    “Kak, kami mau kosongkan rak untuk stok kemasan baru yang datang minggu depan. Jadi semua tumbler model lama diskon 30 persen sampai Jumat, selama stok ada. Bukan diskon pancingan, setelah Jumat harga balik normal karena barangnya memang habis. Lihat sisa stok di sini: [link katalog]. Balas STOP kalau tidak mau info promo lagi.”

    Alasan di balik promo itu penting. Diskon tanpa alasan bikin orang curiga harga normalmu memang digelembungkan. Diskon karena cuci gudang, ganti kemasan, atau ulang tahun toko terasa masuk akal dan lebih dipercaya.

    3. Restock barang yang sering ditanyakan

    “Kak, gamis seri Hana warna mocca yang kemarin banyak ditanyakan sudah restock. Kali ini masuk 15 pcs untuk semua ukuran. Batch sebelumnya habis dalam dua hari, jadi kalau mau ambil, balas ukurannya ya, saya keep maksimal sampai besok sore.”

    4. Ucapan hari raya yang tidak sekadar template

    “Selamat Idulfitri, Kak. Mohon maaf lahir dan batin dari saya dan tim Toko Berkah. Terima kasih sudah jadi bagian dari perjalanan kami setahun ini. Kami libur sampai tanggal 5 dan buka lagi tanggal 6. Pesanan yang masuk selama libur tetap kami catat dan diproses paling awal begitu buka.”

    Perhatikan sentuhan bisnisnya halus: info libur dan kepastian pesanan diproses. Bukan “MUMPUNG LEBARAN, DISKON 50%!!” yang justru merusak momen.

    5. Info operasional: libur atau pindah lokasi

    “Halo Kak, info penting dari Bengkel Duta. Mulai 1 Agustus kami pindah ke Jl. Ahmad Yani No. 12, sekitar 500 meter dari lokasi lama, tepat sebelah minimarket. Nomor WhatsApp tetap yang ini. Simpan dulu ya biar tidak nyasar pas servis berikutnya. Titik lokasi barunya: [link maps].”

    Broadcast jenis ini hampir tidak pernah bikin orang kesal, karena isinya murni informasi yang mereka butuhkan. Sesekali selingi broadcast promo dengan pesan seperti ini supaya nomormu tidak diasosiasikan dengan jualan terus.

    6. Menghidupkan pelanggan yang lama tidak order

    “Halo Kak, sudah sekitar tiga bulan sejak order terakhir, semoga sehat selalu ya. Sebagai pelanggan lama, ada voucher 20 ribu khusus yang bisa dipakai sampai akhir bulan, tanpa minimal belanja. Tinggal tunjukkan chat ini atau balas PAKAI kalau order online. Kalau sudah tidak butuh info dari kami, balas STOP saja, tidak apa-apa.”

    Contoh ini untuk dikirim massal ke segmen pelanggan pasif. Kalau yang mau kamu kejar itu satu orang tertentu yang pernah tanya harga lalu menghilang, pendekatannya beda dan lebih personal. Cara lengkapnya ada di artikel follow-up pelanggan yang tanya harga lalu hilang.

    Soal waktu kirim, jangan asal pencet

    Isi pesan bagus bisa gagal cuma karena dikirim jam yang salah. Beberapa patokan sederhana.

    • Kirim di jam orang santai memegang HP: sekitar jam 10 sampai 11 pagi, atau jam 4 sampai 8 malam. Hindari subuh, tengah malam, dan jam sibuk berangkat kerja. Notifikasi promo jam 2 pagi itu jalan pintas menuju block.
    • Untuk promo dengan harga lumayan, hindari tanggal tua. Kirim penawaran 500 ribu di tanggal 25 hasilnya beda jauh dengan tanggal 1 sampai 5 saat gajian baru masuk.
    • Hindari juga hari orang sedang sibuk dengan urusan lain, misalnya hari pertama masuk sekolah atau H-1 hari raya, kecuali pesanmu memang relevan dengan momen itu.

    Segmentasi sederhana tanpa tools

    Kesalahan umum: satu pesan yang sama dikirim ke semua nomor. Padahal kebutuhan reseller beda dengan pembeli eceran, dan pelanggan aktif beda dengan yang sudah lama menghilang. Tidak perlu aplikasi mahal untuk memisahkan mereka. Di WhatsApp Business ada fitur label, atau paling sederhana buat beberapa broadcast list terpisah.

    Minimal pisahkan dua hal ini:

    • Aktif vs pasif. Pelanggan aktif cukup diberi info produk baru dan restock. Pelanggan pasif butuh pancingan lebih, misalnya voucher seperti contoh nomor 6. Jangan kirim voucher comeback ke pelanggan yang baru order kemarin, mereka bisa merasa rugi.
    • Reseller vs eceran. Reseller peduli harga grosir, stok, dan margin. Pembeli eceran peduli harga satuan dan promo. Info harga grosir yang bocor ke pembeli eceran malah bikin masalah.

    Isi pesan untuk tiap segmen harus beda. Dua atau tiga versi pesan memang lebih repot lima menit, tapi hasilnya jauh berbeda.

    Ukur hasilnya, lalu tahu kapan harus naik kelas

    Tidak perlu dashboard rumit. Setelah tiap broadcast, catat tiga angka di buku atau spreadsheet: berapa yang membalas, berapa yang jadi order, dan berapa yang minta stop. Tiga angka ini sudah cukup jadi kompas.

    Cara bacanya sederhana. Banyak yang balas tapi sedikit yang order, berarti penawaranmu kurang menarik atau harganya belum pas. Sepi total, kemungkinan daftar penerimamu bermasalah, entah nomornya tidak menyimpan kontakmu atau segmennya salah sasaran. Yang minta stop banyak, itu alarm paling jelas: frekuensimu terlalu sering atau isinya terlalu jualan. Turunkan frekuensi dulu sebelum memperbaiki yang lain.

    Kalau daftar pelangganmu sudah ribuan nomor dan kamu butuh kirim pesan dengan nama penerima yang otomatis berbeda-beda, balasan “MAU” yang langsung tercatat, plus jalur resmi yang tidak berisiko banned, broadcast manual sudah tidak memadai. Di titik itu solusinya WhatsApp Business API resmi yang digabung chatbot, supaya blast besar tetap terasa personal dan balasan masuk terlayani otomatis. Kami bahas dan kerjakan ini di layanan WhatsApp chatbot AI.

    Pada akhirnya broadcast itu cuma perpanjangan dari cara kamu memperlakukan pelanggan. Kirim ke orang yang tepat, beri sesuatu yang berguna, dan jangan terlalu sering muncul. Mulai dari satu broadcast bulan ini, pakai salah satu contoh di atas, catat hasilnya. Dari situ kamu akan tahu sendiri pola mana yang paling cocok untuk pelangganmu.

  • Aplikasi Manajemen Kos dan Kontrakan: Tagihan, Kamar, Komplain

    Aplikasi Manajemen Kos dan Kontrakan: Tagihan, Kamar, Komplain

    Aplikasi manajemen kos dan kontrakan pada dasarnya menyelesaikan tiga hal. Pertama, tagihan sewa bulanan digenerate otomatis setiap jatuh tempo, lalu penghuni diingatkan lewat WhatsApp tanpa Anda perlu mengetik satu per satu. Kedua, status setiap kamar terlihat jelas: terisi, kosong, atau sudah dipesan. Ketiga, komplain penghuni masuk lewat satu jalur yang tercatat, bukan lewat telepon tengah malam yang besoknya terlupa.

    Tiga hal itu kelihatan sederhana. Tapi kalau Anda pegang 15 kamar kos atau tiga rumah kontrakan sekaligus, tiga hal itu yang paling sering bikin kepala panas. Artikel ini membahas apa saja yang sebaiknya ada di aplikasi pengelolaan kos, kapan sistem seperti ini mulai masuk akal secara hitungan, dan pilihan antara aplikasi jadi atau bikin sendiri.

    Nagih Satu per Satu Itu Melelahkan, dan Bocornya Pelan-pelan

    Pemilik kos jarang mengeluh soal bangunannya. Yang bikin capek justru rutinitas awal bulan. Kirim pesan ke belasan penghuni, tunggu balasan, cek mutasi rekening, cocokkan transfer yang tidak pakai berita acara, lalu catat di buku. Ada penghuni yang langsung bayar. Ada yang dibaca saja. Ada yang bilang besok, dan besoknya lupa lagi. Menagih orang yang tiap hari papasan di depan kamar itu tidak enak, jadi banyak pemilik memilih diam.

    Diam itu ada harganya. Beberapa pola yang sering terjadi:

    • Penghuni telat bayar dua sampai tiga bulan, dan baru ketahuan waktu iseng cek catatan. Tunggakan sudah jutaan.
    • Catatan pembayaran ada di buku tulis atau chat WhatsApp yang tercecer. Waktu penghuni bilang sudah bayar, tidak ada bukti pembanding yang rapi.
    • Komplain masuk lewat telepon malam hari saat Anda sedang di luar. Paginya lupa. Penghuni merasa tidak diurus.
    • Kamar kosong sebulan tidak segera dipasarkan karena Anda sendiri tidak sadar kamar itu sudah kosong sejak penghuni lama pindah.

    Satu kamar kosong sebulan di kos dengan sewa Rp1,5 juta artinya Rp1,5 juta hilang begitu saja. Satu penghuni nunggak tiga bulan tanpa ketahuan, hilang lagi. Bocornya kecil-kecil, tapi kalau dijumlah setahun angkanya sering lebih besar dari biaya bikin sistemnya.

    Tagihan Berulang, Reminder WhatsApp, dan Pencatatan Pembayaran

    Inti dari aplikasi manajemen kos ada di siklus tagihannya. Sewa kos itu tagihan berulang: nominal sama, jatuh tempo sama, penerima sama. Pola seperti ini justru paling gampang diotomatisasi.

    Alurnya kira-kira begini. Setiap tanggal yang ditentukan, sistem membuat tagihan untuk semua penghuni aktif. Beberapa hari sebelum jatuh tempo, penghuni menerima pesan WhatsApp berisi nominal, tanggal jatuh tempo, dan cara bayar. Kalau lewat jatuh tempo belum lunas, reminder kedua terkirim otomatis. Anda tidak lagi jadi orang yang menagih. Sistem yang menagih, dan hubungan Anda dengan penghuni tetap enak.

    Untuk pembayarannya sendiri ada dua level:

    • Transfer manual yang dicatat. Penghuni transfer seperti biasa, Anda atau penjaga kos menandai lunas di aplikasi sambil melampirkan bukti. Ini saja sudah jauh lebih rapi daripada buku.
    • Virtual account atau payment gateway. Setiap penghuni dapat nomor VA sendiri. Begitu dia bayar, status tagihan langsung berubah lunas tanpa ada yang perlu cek mutasi. Cara kerja mekanisme ini kami bahas lebih detail di artikel tentang apa itu payment gateway dan cara kerjanya.

    Satu hal lagi yang sering diremehkan: denda keterlambatan. Banyak pemilik kos tidak enak menerapkan denda karena aturannya tidak pernah jelas dari awal. Di sistem, aturannya ditulis sekali, misalnya denda Rp10 ribu per hari setelah lewat tiga hari dari jatuh tempo. Sistem yang menghitung dan mencantumkannya di tagihan. Penghuni tahu aturan mainnya sejak awal, jadi tidak ada drama waktu denda muncul.

    Data Penghuni, Masa Kontrak, dan Status Kamar

    Bagian kedua yang dirapikan sistem adalah data. Untuk setiap penghuni, minimal yang tersimpan: identitas dan foto KTP, kontak yang bisa dihubungi, tanggal masuk, jatuh tempo sewa, nominal deposit, dan isi kesepakatan awal. Kalau suatu saat ada sengketa soal deposit atau kerusakan kamar, Anda punya pegangan, bukan mengandalkan ingatan.

    Untuk kontrakan tahunan, sistem mengingatkan Anda beberapa bulan sebelum kontrak habis. Jadi ada waktu untuk menanyakan perpanjangan, menyesuaikan harga, atau mulai mencari penyewa baru sebelum rumah benar-benar kosong.

    Lalu status kamar. Dasbor yang baik menunjukkan dalam sekali lihat: kamar mana terisi, mana kosong, mana sudah dipesan tapi belum masuk. Kelihatannya sepele, tapi efeknya ke okupansi nyata. Begitu penghuni mengajukan keluar, kamar langsung berstatus akan kosong. Anda bisa langsung memasarkannya, apalagi kalau foto kamar dan deskripsi sudah tersimpan di sistem dan tinggal disebar ke listing atau grup pencari kos. Kamar yang biasanya nganggur sebulan bisa terisi lagi dalam hitungan hari, dan selisihnya itu uang sewa utuh.

    Komplain dan Perbaikan yang Ada Statusnya

    AC bocor, air mati, lampu koridor putus, WiFi lemot. Komplain seperti ini pasti ada di semua kos. Masalahnya bukan komplainnya, tapi cara masuknya: lewat telepon, lewat chat pribadi, lewat titip pesan ke penjaga. Setengahnya hilang di jalan.

    Di sistem, komplain masuk lewat satu jalur, misalnya form sederhana yang linknya dibagikan ke penghuni. Setiap komplain tercatat dengan tanggal, kamar, dan fotonya. Statusnya jelas: diterima, sedang dikerjakan, selesai. Penghuni bisa melihat progresnya, dan Anda bisa melihat komplain mana yang sudah menggantung terlalu lama.

    Ini bukan soal kelihatan profesional saja. AC bocor yang tiga hari tidak jelas nasibnya itu salah satu alasan klasik penghuni pindah. Padahal biaya mencari penghuni baru, plus kamar kosong selama masa transisi, hampir selalu lebih mahal daripada memperbaiki AC tepat waktu. Sistem komplain yang rapi pada akhirnya adalah alat menjaga penghuni bertahan lama.

    Laporan untuk Pemilik: Okupansi, Pendapatan, Tunggakan

    Kalau tagihan, pembayaran, dan status kamar sudah tercatat di satu tempat, laporan tinggal konsekuensinya. Tiga angka yang paling berguna untuk pemilik:

    • Okupansi. Dari total kamar, berapa persen yang terisi bulan ini, dan trennya naik atau turun.
    • Pendapatan per properti. Kalau Anda punya kos di dua lokasi plus beberapa kontrakan, kelihatan mana yang paling sehat dan mana yang perlu perhatian.
    • Tunggakan. Siapa saja yang belum bayar, sudah berapa lama, dan totalnya berapa. Angka ini yang paling sering mengejutkan pemilik waktu pertama kali datanya dirapikan.

    Laporan seperti ini juga berguna waktu Anda mau mengambil keputusan besar: naikkan harga sewa, renovasi, atau tambah properti baru. Keputusannya jadi berbasis angka, bukan perasaan.

    Mulai Berapa Kamar Sistem Ini Masuk Akal

    Jujur saja, tidak semua pemilik kos butuh aplikasi. Kalau kamarnya di bawah 10 dan Anda tinggal satu atap dengan penghuni, buku catatan plus grup WhatsApp biasanya masih terkendali. Anda hafal semua penghuni, tunggakan cepat ketahuan, dan komplain langsung sampai ke telinga.

    Yang berubah adalah ketika jumlah kamar lewat dari yang bisa Anda hafal. Di atas 10 sampai 15 kamar, apalagi kalau tersebar di beberapa lokasi atau dikelola penjaga, celah mulai terbuka. Tunggakan lolos, kamar kosong telat ketahuan, komplain hilang. Di titik ini biaya sistem biasanya lebih kecil daripada bocornya.

    Soal pilihan sistemnya, ada dua jalur. Aplikasi kos siap pakai yang berlangganan bulanan cocok kalau kebutuhan Anda standar dan Anda tidak keberatan menyesuaikan cara kerja dengan aplikasinya. Sistem custom masuk akal kalau pola bisnis Anda punya kekhususan, misalnya gabungan kos harian dan bulanan, aturan denda dan deposit sendiri, perhitungan komisi penjaga, atau ingin tagihan kos digabung dengan usaha lain yang Anda jalankan. Bedanya sederhana: aplikasi jadi Anda yang menyesuaikan diri, sistem custom yang menyesuaikan Anda. Gambaran umum cara kami membangun sistem seperti ini bisa dilihat di halaman jasa pembuatan sistem dan aplikasi.

    Pertanyaan yang Sering Muncul

    Apakah penghuni harus install aplikasi?

    Tidak wajib, dan sebaiknya memang tidak. Meminta penghuni install aplikasi hanya untuk bayar kos itu hambatan yang tidak perlu. Cukup pesan WhatsApp berisi tagihan dan link pembayaran atau link form komplain yang dibuka lewat browser. Aplikasinya cukup dipegang Anda dan penjaga kos.

    Bagaimana dengan listrik token atau tagihan tambahan lain?

    Kalau listrik pakai token, penghuni beli sendiri dan urusan selesai, tidak perlu masuk sistem. Kalau listrik pascabayar per kamar atau ada biaya tambahan seperti laundry dan parkir, sistem bisa menambahkannya sebagai item di tagihan bulanan. Angka meteran dicatat, selisihnya dihitung, dan totalnya muncul di satu tagihan yang sama supaya penghuni tidak menerima banyak tagihan terpisah.

    Bisa untuk beberapa properti sekaligus?

    Bisa, dan justru di situ nilainya paling terasa. Satu akun memegang beberapa kos dan kontrakan sekaligus, dengan laporan yang bisa dilihat per properti maupun digabung. Pemilik yang propertinya tersebar di beberapa kota biasanya paling terbantu, karena tidak mungkin lagi mengandalkan pantauan langsung tiap hari.

    Langkah Berikutnya

    Kalau bulan depan Anda masih berencana menagih belasan penghuni satu per satu sambil mencocokkan mutasi rekening, mungkin ini waktunya menghitung ulang. Coba jumlahkan tunggakan yang pernah lolos dan kamar kosong yang telat terisi setahun terakhir. Angka itu biasanya cukup untuk mengambil keputusan.

    Kalau mau mendiskusikan seperti apa sistem yang pas untuk kos atau kontrakan Anda, termasuk perkiraan biayanya, silakan hubungi tim Arrazy Inovasi. Ceritakan saja jumlah kamar dan cara Anda mengelolanya sekarang, nanti kita lihat bersama apakah sistem memang sudah waktunya, atau buku catatan Anda sebenarnya masih cukup.

  • Checklist Panitia Event Lari: H-60 sampai Hari H Tanpa Kelabakan

    Checklist Panitia Event Lari: H-60 sampai Hari H Tanpa Kelabakan

    Kerja panitia event lari terbagi jadi lima fase besar. H-60 untuk perizinan dan rute. H-45 untuk buka pendaftaran dan cari sponsor. H-30 untuk produksi jersey, medali, dan BIB. H-7 untuk technical meeting dan pembagian race pack. Lalu hari H untuk eksekusi. Setiap fase punya penentu gagalnya sendiri. Izin yang telat membuat semua jadwal mundur. Pendaftaran yang berantakan membuat kuota jebol. Produksi yang pakai tebakan ukuran membuat peserta protes di lokasi. Race pack yang dibagikan pagi hari race membuat garis start kacau sebelum lomba dimulai.

    Artikel ini adalah checklist lengkap untuk panitia fun run, night run, atau race lokal skala ratusan sampai ribuan peserta. Cocok untuk komunitas lari yang baru pertama bikin event sendiri, atau EO yang baru pertama pegang event lari. Urutannya sengaja dibuat mundur dari H-60, karena kesalahan paling mahal justru terjadi di fase paling awal, saat semuanya masih terasa santai.

    H-60: Izin, Rute, dan Target Peserta

    Dua bulan sebelum hari H, fokusnya cuma tiga hal: izin, rute, dan angka target. Belum perlu mikir desain jersey. Belum perlu mikir MC. Kalau tiga hal ini beres, sisanya tinggal eksekusi.

    • Urus izin keramaian ke kepolisian. Prosesnya butuh surat dari penyelenggara, rundown acara, estimasi jumlah peserta, dan peta rute. Mulai dari Polsek atau Polres sesuai skala event.
    • Koordinasi dengan pemda atau dinas terkait, terutama kalau rute lewat jalan protokol atau area publik seperti alun-alun dan stadion.
    • Survei rute langsung di lapangan, jangan cuma dari peta digital. Jalan berlubang, penerangan mati, atau proyek galian baru ketahuan kalau disusuri sendiri. Untuk night run, survei wajib dilakukan malam hari.
    • Ukur jarak rute dengan alat yang bisa dipertanggungjawabkan, minimal roda ukur atau GPS yang dikalibrasi. Pelari serius akan protes kalau kategori 10K ternyata cuma 9,2 km. Rute yang jaraknya tervalidasi juga jadi nilai jual saat promosi.
    • Susun rencana penutupan jalan bersama kepolisian: ruas mana yang ditutup penuh, mana yang buka tutup, dan jam berapa dibuka kembali. Siapkan juga jalur alternatif untuk warga.
    • Tetapkan target jumlah peserta yang realistis. Event pertama di kota kecil biasanya di angka 300 sampai 800 peserta. Angka ini jadi dasar semua keputusan berikutnya: kuota, anggaran, jumlah volunteer, sampai stok air minum.

    Penentu gagal di fase ini adalah izin. Tanpa izin, tanggal event tidak bisa dikunci. Tanpa tanggal pasti, pendaftaran tidak bisa dibuka dan sponsor tidak akan percaya.

    H-45: Pendaftaran, Sponsor, dan Medis

    Begitu tanggal dan rute terkunci, buka pendaftaran secepatnya. Jarak 45 hari memberi waktu cukup untuk promosi sekaligus mengumpulkan data yang dibutuhkan fase produksi.

    • Buka pendaftaran online dengan sistem yang jelas: kuota per kategori, pembayaran otomatis, dan konfirmasi langsung ke peserta. Cara memilih dan menyiapkan sistemnya sudah kami bahas lengkap di artikel sistem pendaftaran event lari online, jadi di sini cukup satu prinsip: jangan pakai pendaftaran manual lewat chat kalau target peserta di atas seratus orang.
    • Tentukan kuota per kategori sejak awal dan pastikan sistem menutup pendaftaran otomatis saat kuota penuh. Kuota jebol hampir selalu berawal dari pencatatan manual.
    • Pasang harga early bird dengan batas waktu atau batas slot yang tegas. Early bird bukan sekadar diskon. Dia alat untuk memancing pendaftar awal, dan angka pendaftar awal itulah yang dipakai meyakinkan sponsor.
    • Susun proposal sponsor yang benefit-nya konkret: logo di jersey dan BIB, booth di venue, sebutan MC, konten media sosial, dan estimasi jumlah audiens. Sponsor lokal lebih tertarik pada angka peserta dan jangkauan daripada kata-kata indah.
    • Kunci tim medis dan ambulans dari sekarang. Hubungi PMI, puskesmas, atau rumah sakit terdekat. Untuk event ribuan peserta, siapkan minimal satu ambulans standby plus pos medis di rute. Jangan tunggu H-7, karena jadwal ambulans sering bentrok dengan acara lain.

    Penentu gagal di fase ini adalah sistem pendaftaran. Kalau alurnya ribet atau pembayarannya harus dicek satu per satu, calon peserta batal daftar dan panitia kehabisan tenaga sebelum event dimulai.

    H-30: Produksi dan Volunteer

    Sebulan sebelum hari H, data pendaftaran mulai gemuk. Inilah saatnya produksi. Kata kuncinya satu: produksi harus berangkat dari data, bukan tebakan.

    Jersey, medali, dan BIB

    • Ambil rekap ukuran jersey langsung dari data pendaftaran. Jebakan paling umum adalah memesan ukuran pakai perkiraan rata-rata. Hasilnya selalu sama: ukuran M dan L habis duluan, peserta badan besar dapat jersey sempit, dan meja komplain penuh di hari race.
    • Pesan jersey dengan buffer 5 sampai 10 persen untuk kategori on the spot dan salah kirim ukuran.
    • Pesan medali finisher sesuai kuota per kategori, bukan total pendaftar saja. Kategori 10K dan 5K biasanya beda desain atau beda pita.
    • Cetak nomor BIB dengan data peserta yang sudah final. Kalau sistem pendaftaran rapi, nomor BIB bisa digenerate otomatis dan tinggal kirim ke percetakan.

    Volunteer dan water station

    • Rekrut volunteer dengan rasio kasar satu volunteer per 20 sampai 30 peserta, ditambah tim khusus di titik rawan: start, finish, persimpangan, dan pos medis.
    • Briefing volunteer minimal sekali sebelum gladi. Setiap orang harus tahu tiga hal: posisinya di mana, tugasnya apa, dan lapor ke siapa kalau ada masalah.
    • Petakan water station di rute. Standar umum: satu station tiap 2 sampai 2,5 km untuk lomba jarak 10K, lebih rapat kalau cuaca panas. Untuk fun run 5K, dua station biasanya cukup.
    • Hitung stok air dari jumlah peserta dikali dua gelas per station. Kekurangan air di kilometer akhir adalah komplain yang paling cepat menyebar di media sosial.

    Penentu gagal di fase ini adalah data. Produksi yang salah tidak bisa diperbaiki di hari H. Jersey tidak bisa dijahit ulang semalam.

    H-7: Technical Meeting, Race Pack, dan Rencana Hujan

    Seminggu terakhir bukan waktunya menambah hal baru. Ini waktunya memastikan semua yang sudah disiapkan benar-benar jalan.

    • Adakan technical meeting atau minimal publikasi rute final ke semua peserta: peta rute, lokasi water station, cut off time, aturan lomba, dan titik kumpul. Kirim lewat email dan media sosial resmi event.
    • Jadwalkan pengambilan race pack satu sampai dua hari sebelum race, bukan pagi hari H. Alasannya sederhana. Membagikan ratusan race pack butuh verifikasi satu per satu. Kalau dilakukan jam 4 pagi sebelum start jam 6, antrian pasti mengular dan start molor. Peserta luar kota bisa diberi opsi pengambilan diwakilkan dengan surat kuasa.
    • Cek prakiraan cuaca dan susun rencana hujan. Tentukan sejak sekarang: hujan seperti apa yang membuat start ditunda, siapa yang berhak memutuskan, dan bagaimana pengumumannya ke peserta. Siapkan juga tenda tambahan untuk race pack, sound system, dan area medis.
    • Gladi tim inti di venue. Simulasikan alur start, posisi volunteer, jalur ambulans, dan skenario peserta cedera di tengah rute.
    • Finalkan rundown hari H sampai level menit, lalu bagikan ke semua koordinator. Satu dokumen yang sama untuk semua orang.

    Penentu gagal di fase ini adalah komunikasi. Rencana yang bagus tapi cuma ada di kepala ketua panitia sama saja dengan tidak ada rencana.

    Hari H: Timeline Subuh Sampai Bubar

    Kalau empat fase sebelumnya beres, hari H seharusnya terasa seperti menjalankan naskah. Ini kerangka timeline yang umum dipakai event lari pagi dengan start jam 6.

    • 03.00 tim inti dan vendor tiba, cek sound system, gate start, dan listrik.
    • 04.00 volunteer tiba, langsung ke posisi masing-masing sesuai pembagian zona.
    • 04.30 pos medis, ambulans, dan water station siap. Jalan mulai ditutup sesuai kesepakatan dengan kepolisian.
    • 05.00 area start dibuka, peserta masuk, pemanasan bersama.
    • 06.00 start. Kalau ada beberapa kategori, beri jeda antar gelombang supaya rute tidak menumpuk.
    • Selama lomba, sweeper bergerak di belakang pelari paling akhir. Tugasnya memastikan tidak ada peserta tertinggal di rute, memberi tanda ke water station bahwa pelari terakhir sudah lewat, dan menjadi penanda kapan jalan boleh dibuka kembali.
    • Setelah finisher terakhir masuk, baru mulai pembagian doorprize dan acara hiburan. Jangan bagikan doorprize saat masih ada pelari di rute, karena volunteer akan tergoda meninggalkan pos.
    • Selesai acara, tim kebersihan menyisir rute dan venue. Sampah gelas air di rute adalah wajah panitia di mata warga sekitar.

    Bagi tanggung jawab per zona, bukan per tugas. Satu koordinator pegang area start dan finish, satu pegang rute dan water station, satu pegang medis, satu pegang panggung dan acara. Setiap koordinator punya kanal komunikasi langsung ke ketua, idealnya lewat HT atau grup khusus koordinator. Pastikan juga jalur darurat medis sudah disepakati: ambulans lewat mana, rumah sakit rujukan yang mana, dan siapa yang mendampingi peserta.

    Satu hal lagi yang sering dilupakan karena semua orang sibuk: dokumentasi. Tunjuk tim khusus foto dan video sejak awal. Materi dokumentasi ini adalah modal utama laporan sponsor dan promosi event tahun depan.

    Kesalahan yang Paling Sering Terjadi

    Dari berbagai event lari lokal, pola kegagalannya berulang. Empat ini yang paling sering muncul.

    • Race pack dibagikan pagi hari race. Antrian mengular, start molor, peserta kesal sebelum lari dimulai. Selalu jadwalkan pengambilan minimal sehari sebelumnya.
    • Kuota jebol karena pendaftaran manual. Pendaftar dicatat di spreadsheet, pembayaran dicek satu per satu, lalu jumlah peserta ternyata melebihi stok jersey dan medali. Sistem online dengan kuota otomatis menutup celah ini.
    • Volunteer tidak tahu tugasnya. Direkrut H-3, tidak pernah briefing, ditaruh di persimpangan tanpa tahu arah rute. Hasilnya pelari nyasar. Briefing dan gladi bukan formalitas.
    • Tidak ada rencana hujan. Panitia baru rapat dadakan saat gerimis turun jam 5 pagi. Keputusan jadi lambat, pengumuman simpang siur. Rencana hujan harus sudah tertulis sejak H-7.

    Sistem yang Rapi Memangkas Separuh Kerja Panitia

    Kalau diperhatikan, hampir semua checklist di atas bergantung pada satu hal: data pendaftaran yang rapi. Ukuran jersey diambil dari sana. Nomor BIB digenerate dari sana. Kuota dijaga dari sana. Verifikasi race pack juga dari sana. Panitia yang pendaftarannya masih manual pada dasarnya mengerjakan dua event sekaligus: event larinya sendiri dan event administrasi di belakangnya.

    Kami pernah membangun sistem seperti ini untuk B.Night Run Party, event marathon di Berau, Kalimantan Timur. Sistemnya mencakup alur pendaftaran singkat, payment gateway supaya panitia tidak perlu cek transfer manual, mekanisme antrian untuk momen rebutan kuota saat pendaftaran dibuka serentak, dashboard manajemen peserta, sampai sertifikat online otomatis setelah event. Dengan sistem semacam itu, energi panitia bisa dialihkan ke hal yang memang butuh manusia: rute, volunteer, dan pengalaman peserta di hari H.

    Kalau event lari Anda masih di tahap perencanaan dan ingin urusan pendaftaran, kuota, dan e-ticket beres dari awal, silakan ngobrol dengan tim Arrazy. Ceritakan skala event dan target pesertanya, nanti kita cari bentuk sistem yang paling masuk akal untuk anggaran panitia lokal.

  • Web App vs Aplikasi Mobile: Bisnismu Sebenarnya Butuh yang Mana

    Web App vs Aplikasi Mobile: Bisnismu Sebenarnya Butuh yang Mana

    Langsung ke jawabannya dulu. Kalau sistem yang mau kamu bikin dipakai tim internal, seperti admin, kasir, staf gudang, atau guru, hampir selalu cukup web app. Aplikasi yang dibuka lewat browser, tanpa install apa pun. Sama juga kalau penggunanya cuma buka sesekali, misalnya cek laporan seminggu sekali atau daftar sekali setahun. Bikin aplikasi Android atau iOS untuk kebutuhan seperti ini biasanya buang uang.

    Aplikasi mobile baru masuk akal kalau penggunanya adalah pelanggan umum yang membuka aplikasi hampir setiap hari, dan kamu butuh fitur yang memang kuatnya di HP. Notifikasi yang andal, akses GPS terus menerus, kamera yang dipakai intensif, atau bisa jalan tanpa internet. Di luar itu, web app dulu. Artikel ini menjelaskan alasannya, plus contoh keputusan nyata biar kamu bisa mengukur sendiri posisimu.

    Apa itu web app, dan kenapa sering kali sudah cukup

    Web app itu aplikasi yang jalan di browser. Kamu buka alamatnya di Chrome atau Safari, login, lalu langsung pakai. Bisa dari HP, laptop, atau komputer kasir. Tidak perlu download dari Play Store atau App Store. Contoh yang mungkin sudah kamu pakai tiap hari: Google Docs, internet banking versi web, atau dashboard iklan Facebook.

    Untuk kebutuhan bisnis, kelebihannya lumayan banyak:

    • Biaya lebih hemat. Satu kode jalan di semua perangkat. Tidak perlu bikin versi Android dan iOS terpisah, yang artinya tidak bayar dua kali untuk fitur yang sama.
    • Rilis cepat. Tidak ada antrean review dari Google atau Apple. Selesai dibangun, langsung bisa dipakai.
    • Update sekali, semua kebagian. Perbaikan atau fitur baru langsung aktif untuk semua pengguna begitu di-deploy. Tidak ada cerita “pelanggan masih pakai versi lama”.
    • Tanpa install. Karyawan baru tinggal dikasih link dan akun. Selesai.

    Tapi biar adil, kekurangannya juga perlu kamu tahu. Web app butuh koneksi internet, kemampuan offline-nya terbatas. Notifikasi push di web lebih terbatas dibanding aplikasi native, apalagi di iPhone yang dukungannya masih setengah hati. Akses ke hardware HP seperti sensor atau Bluetooth tidak sedalam aplikasi native. Dan yang terakhir soal gengsi: web app tidak punya ikon di Play Store. Untuk sistem internal ini tidak penting, tapi untuk produk yang dijual ke konsumen umum, keberadaan di store itu sinyal kepercayaan tersendiri.

    Kapan aplikasi mobile memang layak dibayar mahal

    Aplikasi mobile alias aplikasi native adalah yang di-download dari Play Store atau App Store. Gojek, Shopee, mobile banking. Kelebihannya nyata:

    • Notifikasi andal. Push notification sampai ke pengguna hampir pasti, di Android maupun iPhone. Untuk bisnis yang perlu mengabari pelanggan soal status pesanan, ini penting.
    • Akses hardware penuh. GPS yang jalan di background, kamera dengan kontrol penuh, sensor, Bluetooth, NFC. Kalau fiturmu bergantung pada hal seperti ini, native menang jauh.
    • Performa lebih halus. Animasi dan interaksi terasa lebih responsif, terutama untuk aplikasi yang dipakai lama dan sering.
    • Bisa offline. Data bisa disimpan di HP dan disinkronkan saat online lagi. Berguna untuk pekerja lapangan di area sinyal jelek.
    • Ada di store. Untuk produk konsumer, aplikasi yang bisa dicari di Play Store terasa lebih kredibel di mata pelanggan.

    Harganya juga nyata. Biaya development lebih tinggi, apalagi kalau harus meng-cover Android dan iOS sekaligus. Maintenance jangka panjang juga lebih berat, karena tiap update sistem operasi bisa menuntut penyesuaian. Setiap rilis harus lewat review store, yang bisa memakan waktu berhari-hari. Untuk akun developer baru, masih ada syarat uji tertutup sebelum aplikasi boleh tayang. Rinciannya kami tulis di biaya dan syarat upload aplikasi ke Play Store. Dan pengguna harus mau install dulu, lalu mau update. Faktanya banyak orang malas install aplikasi baru kalau manfaatnya belum jelas. Jadi aplikasi mobile itu investasi yang layak, tapi hanya kalau perilakunya cocok: dipakai sering, oleh orang banyak, dengan fitur yang memang butuh HP.

    PWA, jalan tengah yang sering dilupakan

    Ada satu opsi di tengah yang jarang dibahas: PWA atau Progressive Web App. Sederhananya, ini web app yang bisa “di-install” ke layar utama HP, punya ikon sendiri, dan bisa jalan sebagian saat offline. Pengguna merasa pakai aplikasi, padahal di baliknya tetap web. Biayanya jauh lebih dekat ke web app daripada ke aplikasi native.

    PWA cocok kalau kamu ingin pengalaman yang terasa seperti aplikasi tanpa bayar biaya native. Batasnya tetap ada, terutama notifikasi di iPhone dan akses hardware yang dalam. Tapi untuk banyak kasus, misalnya portal pelanggan atau sistem absensi sederhana, PWA sudah lebih dari cukup.

    Studi kasus: keputusan nyata per skenario

    Teori di atas lebih gampang dicerna lewat contoh. Ini beberapa skenario yang sering kami temui saat ngobrol dengan calon klien, plus keputusan yang menurut kami paling masuk akal.

    Sistem kasir dan stok toko

    Web app. Pemakainya kasir dan admin, alias tim internal. Dipakai di komputer kasir atau tablet yang selalu terhubung WiFi toko. Tidak butuh GPS, tidak butuh push notification ke pelanggan. Bikin versi Android untuk kasus ini cuma menambah biaya tanpa menambah manfaat.

    Aplikasi absensi karyawan lapangan dengan GPS

    Ini wilayah aplikasi mobile atau hybrid. Absensi lapangan butuh lokasi yang akurat, kadang foto selfie sebagai bukti, dan harus tetap jalan saat sinyal jelek. Kebutuhan hardware-nya nyata. Kalau budget terbatas, PWA dengan akses lokasi bisa jadi langkah awal, tapi untuk keandalan penuh, aplikasi mobile lebih aman.

    Portal wali santri atau wali murid

    Web dulu cukup. Orang tua buka portal untuk cek tagihan, nilai, atau pengumuman. Frekuensinya sesekali, bukan tiap hari. Kabari lewat WhatsApp, arahkan ke link portal. Kalau nanti pesantren atau sekolahnya tumbuh dan wali benar-benar minta notifikasi langsung di HP, baru pikirkan aplikasi.

    Aplikasi pelanggan laundry antar jemput

    Ini menarik karena jawabannya berubah seiring skala. Saat pelangganmu masih puluhan, web app plus notifikasi WhatsApp sudah cukup untuk kabar status cucian. Saat volumenya besar dan pelanggan order berulang tiap minggu, aplikasi mobile mulai masuk akal. Notifikasi status yang andal dan ikon di HP pelanggan membuat mereka lebih gampang order lagi.

    Dashboard laporan untuk owner

    Web app, hampir tanpa pengecualian. Kamu buka dari laptop di kantor atau HP saat di jalan, lihat omzet dan stok, tutup lagi. Browser sudah lebih dari cukup.

    Polanya kelihatan kan. Yang menentukan bukan gengsi atau tren, tapi siapa pemakainya dan apa yang mereka lakukan di dalamnya.

    Jalur yang paling sering masuk akal: web dulu, mobile menyusul

    Kalau setelah baca sampai sini kamu masih ragu, ada satu jalur yang jarang salah: mulai dari web app, lalu bikin aplikasi mobile saat kebutuhan nyatanya muncul. Bukan saat “kayaknya keren kalau ada aplikasinya”, tapi saat data menunjukkan pengguna aktif tiap hari dan mulai minta notifikasi atau fitur HP lainnya.

    Jalur ini hemat karena satu alasan teknis yang penting: backend-nya bisa dipakai ulang. Backend itu bagian sistem yang menyimpan data dan mengatur logika bisnis, semacam dapurnya aplikasi. Saat kamu bikin web app, dapur ini sudah berdiri. Kalau nanti butuh aplikasi mobile, tim developer tinggal membangun tampilannya saja, lalu menyambungkannya ke dapur yang sama. Kamu tidak bayar dua kali untuk fondasi yang sama, dan data web serta aplikasi otomatis sinkron.

    Prinsip ini sejalan dengan pendekatan mulai dari versi kecil yang pernah kami bahas di artikel soal MVP, mulai dari versi kecil biar tidak boncos. Validasi dulu dengan biaya minimum, baru investasi lebih besar saat terbukti dipakai.

    Empat pertanyaan sebelum kamu memutuskan

    Sebelum ngobrol dengan vendor mana pun, jawab dulu empat pertanyaan ini. Jawabannya biasanya sudah cukup untuk menentukan arah.

    • Siapa pemakainya? Tim internal condong ke web app. Pelanggan umum bisa ke arah mobile, tergantung jawaban berikutnya.
    • Seberapa sering mereka buka? Tiap hari condong ke mobile. Seminggu sekali atau lebih jarang, web app saja.
    • Butuh notifikasi, kamera, atau GPS yang intensif? Kalau ya, mobile atau minimal PWA. Kalau tidak, tidak ada alasan teknis untuk native.
    • Berapa budget-mu? Kalau budget terbatas, web app memberi fitur inti yang sama dengan biaya jauh lebih kecil. Sisanya bisa dialokasikan saat kebutuhan mobile benar-benar terbukti.

    Kalau mayoritas jawabanmu mengarah ke web, mulailah dari sistem aplikasi berbasis web yang dirancang sesuai alur bisnismu. Kalau jawabannya jelas mengarah ke HP, misalnya karena pengguna harian dan kebutuhan GPS atau notifikasi, lihat layanan pembuatan aplikasi mobile kami. Dan kalau masih abu-abu, ceritakan saja kasusmu. Kami biasa membantu memetakan kebutuhan dulu sebelum bicara harga, termasuk bilang terus terang kalau menurut kami kamu belum perlu aplikasi mobile.

    Pertanyaan yang sering muncul

    Apakah web app bisa dibuka di HP?

    Bisa. Web app modern dirancang responsif, jadi tampilannya menyesuaikan layar HP, tablet, maupun laptop. Bedanya dengan aplikasi mobile hanya di cara aksesnya: lewat browser, bukan lewat install dari store.

    Kalau mulai dari web app, apakah nanti harus bikin ulang dari nol saat butuh aplikasi mobile?

    Tidak, asalkan sistemnya dibangun dengan benar. Backend dan database yang sudah jalan bisa dipakai ulang sepenuhnya. Yang dibangun baru hanya aplikasi mobilenya, jadi biayanya jauh lebih kecil dibanding mulai dari nol.

    Berapa perbandingan biaya web app dan aplikasi mobile?

    Tergantung kompleksitas fiturnya, jadi tidak ada angka pasti. Yang jelas, aplikasi mobile untuk dua platform hampir selalu lebih mahal dari web app dengan fitur setara, karena ada pekerjaan tambahan per platform, proses publikasi store, dan maintenance yang lebih berat tiap ada update Android atau iOS.

  • Cara Menentukan Target Penjualan Bulanan yang Masuk Akal

    Cara Menentukan Target Penjualan Bulanan yang Masuk Akal

    Target penjualan yang masuk akal tidak lahir dari feeling atau dari angka bulat yang enak diucapkan waktu rapat. Dia dihitung dari dua arah, lalu dipertemukan. Dari bawah, lihat kapasitas nyata usahamu: rata-rata penjualan tiga bulan terakhir, ditambah pertumbuhan wajar 10 sampai 20 persen. Dari atas, lihat kebutuhanmu: total biaya bulanan, ditambah gaji untuk diri sendiri, ditambah tabungan usaha. Kalau dua angka itu ketemu di kisaran yang sama, itulah target kamu.

    Kalau angka kebutuhan ternyata jauh di atas kapasitas, yang harus diubah adalah strateginya, bukan sekadar angkanya. Menaikkan target di atas kertas tidak pernah menaikkan penjualan. Supaya gampang diikuti, sepanjang artikel ini kita pakai satu contoh yang sama: kedai minuman yang jual es kopi susu dan teh, harga rata-rata Rp 15.000 per cup.

    Kenapa target asal sebut itu berbahaya

    Banyak pemilik usaha menentukan target dengan dua cara: nebak, atau tidak menentukan sama sekali. Dua-duanya sama mahalnya.

    Target yang terlalu tinggi kelihatannya memotivasi, padahal efeknya kebalikan. Misalnya kedai minuman tadi biasa jual Rp 30 juta sebulan, lalu kamu tiba-tiba pasang target Rp 60 juta biar semangat. Minggu pertama baru tercapai Rp 7 juta, semua orang sudah tahu angka itu mustahil. Ada dua reaksi yang biasanya muncul. Tim menyerah diam-diam dan berhenti berusaha, atau sebaliknya, kamu panik lalu tebar diskon besar-besaran demi mengejar angka. Omzet mungkin naik, tapi untungnya menguap.

    Target yang terlalu rendah bahayanya lebih halus. Angka tercapai di tanggal 20, semua merasa aman, ritme kerja melambat. Padahal sewa, gaji, dan listrik jalan terus dengan atau tanpa penjualan. Merasa aman padahal sebenarnya pas-pasan itu jebakan yang baru terasa beberapa bulan kemudian.

    Hitung dari bawah: kapasitas nyata usahamu

    Mulai dari data, bukan harapan. Buka catatan penjualan tiga bulan terakhir. Katakanlah kedai minuman kita angkanya begini:

    • April: Rp 27 juta
    • Mei: Rp 30 juta
    • Juni: Rp 33 juta

    Rata-ratanya Rp 30 juta per bulan. Dengan harga Rp 15.000 per cup, itu sekitar 2.000 cup sebulan, atau kurang lebih 67 cup per hari. Ini kapasitas nyata kamu hari ini, bukan angka impian.

    Koreksi dulu dengan faktor musiman

    Sebelum menambah pertumbuhan, cek dulu bulan yang mau kamu targetkan itu bulan seperti apa. Bulan puasa, kedai minuman biasanya sepi di siang hari tapi ramai menjelang buka. Awal bulan orang belanja lebih longgar, tanggal tua semua orang mengerem jajan. Musim hujan, minuman dingin bisa turun. Kalau bulan depan ada faktor seperti ini, sesuaikan angka dasarnya dulu. Jangan bandingkan bulan puasa dengan bulan biasa lalu menyimpulkan penjualan anjlok.

    Tambahkan pertumbuhan yang wajar

    Untuk bulan normal, tambahkan pertumbuhan 10 sampai 20 persen dari rata-rata. Ambil tengahnya, 15 persen. Dari Rp 30 juta, target versi kapasitas jadi Rp 34,5 juta, atau sekitar 77 cup per hari. Dari 67 cup ke 77 cup itu terasa bisa dikejar: kira-kira 10 cup ekstra per hari. Bandingkan dengan target dua kali lipat tadi yang menuntut 133 cup per hari tanpa rencana apa pun.

    Hitung dari atas: angka yang kamu butuhkan

    Sekarang arah sebaliknya. Berapa penjualan minimal supaya usaha ini layak dijalankan, bukan sekadar jalan. Jumlahkan tiga hal: biaya bulanan, gaji untuk dirimu sendiri, dan tabungan usaha. Untuk kedai minuman kita:

    • Sewa tempat: Rp 2,5 juta
    • Gaji dua karyawan: Rp 4 juta
    • Listrik, air, internet: Rp 700 ribu
    • Cicilan alat: Rp 1,3 juta
    • Gaji untuk diri sendiri: Rp 4 juta
    • Tabungan usaha: Rp 2 juta

    Totalnya Rp 14,5 juta per bulan yang harus tertutup dari sisa penjualan setelah bahan baku. Gaji sendiri dan tabungan usaha sengaja dimasukkan sejak awal. Kalau dua pos itu dianggap bonus, kamu sedang membangun usaha yang hanya sehat kalau pemiliknya tidak digaji.

    Terjemahkan ke omzet, lalu ke cup

    Dari harga jual Rp 15.000, anggap biaya bahan, cup, dan kemasan Rp 9.000. Sisa Rp 6.000 per cup, alias margin kotor 40 persen. Supaya sisa penjualan bisa menutup Rp 14,5 juta, omzetnya harus Rp 14,5 juta dibagi 40 persen, sekitar Rp 36 juta. Itu 2.400 cup sebulan, atau 80 cup per hari.

    Menerjemahkan omzet ke unit seperti ini penting, karena di situlah kelihatan targetmu realistis atau tidak. Angka Rp 36 juta terdengar abstrak. Angka 80 cup per hari bisa kamu bayangkan: antriannya, stok gelasnya, tenaga karyawannya.

    Pertemukan dua angka itu

    Versi kapasitas bilang Rp 34,5 juta. Versi kebutuhan bilang Rp 36 juta. Selisihnya tipis, jadi Rp 36 juta layak dipasang sebagai target, dengan catatan ada usaha ekstra yang jelas untuk menutup 3 cup per hari selisihnya.

    Yang gawat itu kalau jomplang. Misalnya kebutuhanmu ternyata Rp 50 juta sementara kapasitas mentok di Rp 34 juta. Memaksakan angka Rp 50 juta ke tim yang sama, produk yang sama, dan cara jualan yang sama itu bukan target, itu doa. Yang perlu diubah strateginya: naikkan harga, tambah kanal jualan, buka jam operasional baru, atau pangkas biaya yang tidak perlu. Kalau semua opsi sudah dicoba dan angkanya tetap tidak ketemu, itu sinyal serius soal model usahamu, dan lebih baik ketahuan sekarang lewat hitungan daripada setahun lagi lewat kebangkrutan.

    Pecah target supaya bisa dieksekusi

    Target bulanan yang dibiarkan utuh hampir pasti berakhir dengan panik di tanggal 25. Pecah jadi tiga lapis.

    Per minggu. Rp 36 juta sebulan artinya sekitar Rp 9 juta per minggu. Angka mingguan ini yang kamu pelototi, bukan angka bulanan. Meleset satu minggu masih bisa dikejar tiga minggu. Meleset ketahuan di akhir bulan sudah tidak bisa diapa-apakan.

    Per kanal. Jangan gantungkan semua di satu pintu. Misalnya: penjualan langsung di kedai 60 persen atau sekitar Rp 21,5 juta, aplikasi ojek online 25 persen sekitar Rp 9 juta, dan pesanan lewat WA untuk acara atau kantor 15 persen sekitar Rp 5,5 juta. Dengan pecahan ini, saat penjualan turun kamu langsung tahu kanal mana yang bermasalah.

    Per aktivitas. Ini yang paling sering dilewatkan. Omzet itu target hasil, dan hasil tidak bisa kamu kontrol langsung. Yang bisa kamu kontrol adalah aktivitas: berapa posting konten per hari, berapa follow-up WA ke pelanggan lama per minggu, berapa penawaran kerja sama ke kantor atau acara yang keluar. Contohnya: satu posting per hari, 20 follow-up per minggu, 2 penawaran kerja sama per minggu. Kalau aktivitas jalan penuh tapi hasil tetap meleset, berarti masalahnya di tempat lain, misalnya harga atau produk. Kalau aktivitasnya saja tidak jalan, ya jelas dari mana hasilnya.

    Review mingguan 15 menit, jangan tunggu akhir bulan

    Setiap awal minggu, sisihkan 15 menit. Cukup jawab tiga pertanyaan: berapa realisasi minggu kemarin dibanding target Rp 9 juta, kanal mana yang meleset, dan aktivitas mana yang tidak jalan.

    Satu minggu meleset itu normal. Dua minggu berturut-turut meleset, berhenti dan cari penyebabnya. Biasanya jatuh ke salah satu dari tiga hal: trafik turun (orang yang datang atau menghubungi berkurang), closing rate turun (orang datang tapi tidak jadi beli), atau ada masalah harga dibanding pesaing sekitar. Tiga penyebab ini butuh obat yang beda-beda, jadi jangan asal jawab dengan diskon.

    Ritme mingguan ini juga yang membedakan target hidup dan target pajangan. Target yang hanya dilihat tanggal 1 dan tanggal 30 tidak pernah mengubah perilaku siapa pun.

    Kesalahan umum saat menentukan target

    Target omzet, lupa margin. Ini yang paling sering. Demi mengejar Rp 36 juta, kamu diskon 30 persen di minggu terakhir. Omzet tercapai, tapi sisa per cup yang tadinya Rp 6.000 tinggal Rp 1.500. Omzet naik, untung justru turun. Kalau memang mau pakai promo untuk mengejar target, hitung dulu batas amannya, seperti yang dibahas di cara bikin promo yang tidak bikin rugi. Pasang target laba minimal berdampingan dengan target omzet supaya dua-duanya kejaga.

    Target tidak pernah dievaluasi. Angka dipasang bulan Januari, ditempel di dinding, lalu tidak pernah disentuh lagi. Padahal kondisi berubah: ada pesaing baru, harga bahan naik, kanal baru mulai jalan. Target itu alat kerja, bukan pajangan. Setiap akhir bulan, angka bulan berikutnya dihitung ulang dari data terbaru.

    Target sama rata sepanjang tahun. Kedai minuman di bulan puasa, musim hujan, dan musim liburan itu tiga usaha yang berbeda perilaku pembelinya. Memasang Rp 36 juta flat dari Januari sampai Desember artinya kamu akan merasa gagal di bulan yang memang sepi dan merasa jago di bulan yang memang ramai, padahal dua-duanya cuma musim.

    Semua hitungan di artikel ini punya satu syarat: catatan penjualanmu harus ada dan bisa dipercaya. Rata-rata tiga bulan, margin per cup, porsi tiap kanal, semuanya diambil dari catatan. Kalau selama ini penjualan hanya diingat-ingat, mulai dari sana dulu. Panduan laporan keuangan sederhana untuk usaha kecil bisa jadi titik awal yang ringan, tanpa perlu akuntan.

    Begitu pencatatan rapi jalan dua tiga bulan, menentukan target berikutnya bukan lagi acara tebak-tebakan. Tinggal baca data, tambahkan pertumbuhan yang wajar, cek kebutuhan, selesai. Dan kalau suatu saat catatan manual mulai kewalahan mengikuti transaksi harianmu, sistem pencatatan yang dibuat sesuai alur usahamu bisa sangat membantu. Itu salah satu hal yang biasa kami kerjakan di Arrazy, kapan pun kamu merasa butuh.