Bro Servis adalah bengkel servis elektronik rumahan (AC, TV, kulkas, sampai perangkat kecil seperti blender, charger, dan radio) di Merauke, Papua Selatan. Sebelum sistem ini dibangun, prosesnya masih serba manual — pelanggan lapor lewat WhatsApp, admin mencatat manual, dan status pengerjaan cuma diketahui kalau pelanggan bertanya langsung.
Sistem web ini mendigitalkan seluruh alur berbasis role (admin, teknisi, pelanggan): dari pengajuan servis, estimasi biaya, pengerjaan, sampai pembayaran dan pengambilan barang — semuanya tercatat dan bisa dipantau semua pihak.
Latar Belakang Masalah
Pola kerja manual sebelumnya memunculkan beberapa masalah yang berulang:
- Pelanggan tidak tahu progres servisnya ada di tahap mana kecuali bertanya manual lewat chat.
- Tidak ada estimasi biaya/waktu di awal, jadi pelanggan kadang kaget saat total biaya keluar — terutama kalau biaya perbaikan sudah mendekati harga barang baru.
- Antrean dan histori servis rawan hilang atau tercecer karena dicatat manual.
- Tidak ada jejak digital untuk pembayaran, rawan selisih paham soal siapa sudah bayar dan berapa.
Solusi yang Dibangun
Bro Servis versi web mendigitalkan alur servis dari ujung ke ujung berbasis tiga role:
- Pelanggan mengajukan servis, memantau status lewat dashboard, menyetujui estimasi, dan memberi ulasan setelah barang diambil.
- Admin mengonfirmasi servis masuk, mengirim estimasi biaya, menugaskan teknisi, mengonfirmasi pembayaran, dan mengelola konten publik.
- Teknisi menerima tugas, memeriksa perangkat, dan mengisi hasil perbaikan.
Di luar alur inti, ada juga sistem pakar diagnosa mandiri yang bisa diakses publik tanpa login untuk membantu calon pelanggan memperkirakan kerusakan sebelum memutuskan servis, artikel edukasi per jenis perangkat, chat internal per nomor servis, serta ulasan pelanggan yang dimoderasi admin sebelum tayang di halaman publik.
Keputusan Desain & Teknis Penting
Polling ringan, bukan WebSocket. Update status servis dideteksi lewat polling berbasis updated_at, bukan push notification. Pilihan ini pragmatis karena aplikasi di-deploy ke shared hosting cPanel yang tidak selalu punya akses penuh untuk infrastruktur realtime seperti WebSocket atau Pusher.
Estimasi dua tahap — direvisi di tengah jalan. Awalnya hanya ada satu estimasi (setelah teknisi bongkar barang). Berdasarkan masukan dosen penguji dan klien, ditambahkan Estimasi 1 (perkiraan awal sebelum bongkar) supaya pelanggan bisa memutuskan lanjut atau tidak lebih dini. Teknisi sengaja dikunci tidak bisa mulai kerja sebelum admin mengirim Estimasi 1, sementara alur Estimasi 2 (final, pasca-bongkar) tidak diubah karena sudah berjalan baik — keduanya dipisah sebagai dua endpoint independen di controller.
Notifikasi WhatsApp manual, bukan WA Business API. Sistem menyiapkan template pesan siap-kirim per tahap status, lalu admin klik dan pesannya terkirim lewat WhatsApp miliknya sendiri — cocok untuk skala bengkel kecil tanpa biaya API resmi, tapi format pesannya tetap konsisten.
Pembayaran manual, bukan payment gateway. Pelanggan memilih tunai atau transfer manual dengan upload bukti foto, dikonfirmasi admin. Kolom untuk integrasi Midtrans sudah disiapkan di database untuk kebutuhan masa depan, tapi belum diimplementasikan — sesuai kebutuhan usaha skala lokal saat ini.
Auto-cancel via scheduled command. Servis otomatis dibatalkan kalau pelanggan tidak merespons estimasi dalam 1×24 jam, atau barang tidak dibawa ke bengkel dalam 3 hari setelah dikonfirmasi — menjaga antrean tetap bersih tanpa admin harus mengecek manual satu per satu.
Fitur Utama
| Fitur | Deskripsi |
|---|---|
| Order & tracking servis | Alur pengajuan dari pelanggan sampai status akhir (11 status berbeda), dengan nomor antrean & nomor servis otomatis |
| Sistem pakar diagnosa | Forward chaining gejala–kerusakan untuk estimasi kemungkinan kerusakan, bisa diakses tanpa login |
| Estimasi dua tahap | Estimasi kasar sebelum bongkar (mengunci mulai kerja teknisi) dan estimasi final setelah pemeriksaan |
| Manajemen penugasan teknisi | Admin menugaskan servis ke teknisi tertentu beserta instruksi kerja |
| Pembayaran manual | Tunai atau transfer dengan upload bukti foto, dikonfirmasi manual oleh admin |
| Chat per servis | Percakapan terpisah per nomor servis antara pelanggan, admin, dan teknisi |
| Notifikasi WhatsApp semi-otomatis | Template pesan status siap-kirim per tahap, dikirim manual lewat wa.me |
| Auto-cancel servis kadaluarsa | Scheduled command yang membatalkan otomatis servis tanpa respons dalam jangka waktu tertentu |
| Ulasan & rating termoderasi | Pelanggan memberi rating & komentar setelah barang diambil, tayang setelah disetujui admin |
| Laporan & ekspor | Rekap data servis dalam format Excel dan PDF |
Tech Stack
| Layer | Teknologi | Catatan |
|---|---|---|
| Backend | Laravel 13 (PHP 8.3) | |
| Frontend | Blade + Tailwind CSS 4 | Dibundling lewat Vite |
| Database | MySQL (InnoDB, utf8mb4) | |
| Export/Report | Dompdf, PhpSpreadsheet | Ekspor PDF & Excel |
| SMTP via Brevo | Verifikasi akun & reset password | |
| Notifikasi eksternal | WhatsApp via deep link wa.me | Bukan API resmi |
| Deployment | Shared hosting cPanel | Scheduler lewat cron php artisan schedule:run |
Tantangan Teknis
- Merancang mesin status yang kompleks. 11 status servis yang saling terkait dengan data penugasan teknisi dan pembayaran, tapi harus tetap konsisten dilihat dari tiga sudut pandang role berbeda tanpa duplikasi logika.
- Revisi alur di tengah development. Perubahan dari estimasi satu tahap ke dua tahap — plus syarat "kunci tombol mulai teknisi" — harus diimplementasikan tanpa mengganggu alur estimasi final yang sudah berjalan dan tervalidasi.
- Update real-time tanpa infrastruktur realtime. Karena keterbatasan hosting, "live update" disimulasikan lewat polling ringan, bukan push notification/WebSocket.
- Basis pengetahuan sistem pakar untuk banyak jenis perangkat. Puluhan jenis perangkat kecil dengan gejala dan kerusakan masing-masing perlu dipetakan secara manual.
- Penjadwalan otomatis di lingkungan hosting terbatas. Fitur auto-cancel butuh cron job presisi tiap menit, sementara sebagian proses hosting harus dilakukan manual tanpa akses SSH.
- Moderasi konten user-generated. Ulasan pelanggan perlu alur approval supaya tidak disalahgunakan, tanpa membuat proses submit ulasan jadi ribet buat pelanggan biasa.