Website Sudah Live, Lead Tidak Masuk: Cek Form, Mobile, dan Tracking Setelah Publish

Website yang sudah live sering dianggap selesai.

Halaman sudah bisa dibuka. Desain tampil rapi. Tombol WhatsApp terlihat jelas. Form kontak ada di bagian bawah. Meta title dan gambar social preview sudah muncul. Tim merasa pekerjaan utama sudah lewat.

Tetapi beberapa hari kemudian, lead tidak masuk.

Owner mulai bertanya: apakah memang belum ada yang tertarik, atau ada calon pelanggan yang mencoba menghubungi tetapi jalurnya putus?

Untuk website bisnis, pertanyaan itu penting. Website tidak hanya harus tampil. Website harus bisa membawa niat calon pelanggan sampai ke tim yang akan menindaklanjuti.

Di sinilah pekerjaan post-launch developer menjadi krusial. Bukan untuk menambah fitur besar, tetapi untuk mengecek jalur kecil yang sering menentukan apakah lead benar-benar sampai.

Live bukan berarti jalur contact sudah aman

Saat website dipublish, banyak checklist berhenti di hal-hal yang terlihat dari luar:

• halaman bisa diakses,
• layout tidak berantakan,
• gambar muncul,
• copy sudah benar,
• dan link utama tidak 404.

Itu perlu, tetapi belum cukup untuk halaman yang tugasnya menerima lead.

Calon pelanggan tidak hanya melihat halaman. Mereka klik tombol, mengisi form, memilih layanan, menulis pesan, mengirim data, menunggu feedback, lalu berharap ada tanda bahwa permintaan mereka diterima.

Jika salah satu langkah itu gagal, website tetap terlihat live, tetapi jalur bisnisnya putus.

Masalahnya, bug contact flow sering tidak dramatis. Tidak selalu ada layar error besar. Kadang tombol tetap bisa diklik, tetapi nomor WhatsApp salah. Form bisa dikirim, tetapi email internal tidak terkirim. Halaman bisa memberi pesan sukses, tetapi backend menolak data. Event analytics tercatat, tetapi bukan event yang bisa dibaca sebagai lead. Di mobile, field terlihat rapi, tetapi keyboard menutup tombol submit.

Dari sisi calon pelanggan, hasilnya sama: mereka batal menghubungi atau merasa pesannya tidak jelas masuk ke mana.

Form harus diuji seperti percakapan bisnis

Form kontak bukan komponen dekoratif.

Form adalah percakapan pertama antara calon pelanggan dan bisnis. Karena itu, pengujiannya tidak cukup dengan melihat apakah field muncul di layar.

Minimal, tim perlu mencoba beberapa skenario nyata:

• calon pelanggan mengisi semua field dengan benar,
• calon pelanggan lupa mengisi field wajib,
• email atau nomor telepon salah format,
• pesan terlalu pendek atau terlalu panjang,
• pilihan layanan tidak dipilih,
• koneksi lambat saat submit,
• dan submit dilakukan dari mobile.

MDN Web Docs menjelaskan client-side form validation sebagai pemeriksaan awal agar pengguna bisa memperbaiki input yang tidak valid sebelum data dikirim ke server. Ini berguna untuk pengalaman pengguna, tetapi bukan pengganti pengecekan server.

Untuk owner, pelajarannya sederhana: jangan hanya tanya apakah form ada. Tanya apakah form membantu calon pelanggan mengirim data yang benar, memberi pesan error yang jelas, dan tetap diterima dengan aman oleh sistem di belakangnya.

Jika form hanya terlihat benar tetapi tidak diuji sebagai percakapan nyata, risiko lead putus masih besar.

Tombol contact perlu dites dari halaman asal

Banyak website punya lebih dari satu tombol contact.

Ada tombol di hero, navbar, halaman layanan, artikel, footer, pricing section, dan floating WhatsApp. Semuanya tampak menuju tempat yang sama, tetapi secara teknis bisa berbeda.

Satu tombol bisa mengarah ke /contact/. Tombol lain membuka WhatsApp. Tombol lain membawa teks otomatis. Tombol dari campaign mungkin membawa parameter sumber. Tombol dari mobile mungkin memakai event berbeda dari desktop.

Karena itu, checklist post-launch harus mengetes tombol dari halaman asal, bukan hanya mengetes satu route contact.

Pertanyaan praktisnya:

• apakah semua tombol menuju destination yang benar,
• apakah teks WhatsApp sesuai konteks halaman,
• apakah nomor telepon benar,
• apakah link email memakai format yang bisa dibuka,
• apakah tombol tetap mudah diklik di mobile,
• apakah tombol tidak tertutup sticky bar,
• dan apakah klik contact tercatat sebagai sinyal yang bisa dibaca tim.

Untuk bisnis, perbedaan kecil ini penting. Calon pelanggan dari halaman layanan desain web mungkin butuh konteks berbeda dari calon pelanggan yang membaca artikel teknis. Jika semua tombol mengirim pesan kosong, tim kehilangan konteks awal yang bisa mempercepat follow-up.

Backend response jangan diasumsikan dari tampilan sukses

Salah satu risiko klasik di website modern adalah frontend terlihat sukses, tetapi backend tidak benar-benar menerima data.

Misalnya, tombol berubah menjadi “terkirim” setelah pengguna klik. Tetapi request ke server sebenarnya gagal. Atau response server mengirim status error, tetapi kode frontend tidak membedakannya. Atau data masuk ke endpoint lama, bukan workflow baru yang dipakai tim sekarang.

MDN Web Docs menjelaskan bahwa penggunaan Fetch API perlu memperhatikan response status; sebuah request bisa mendapat respons HTTP tertentu yang harus ditangani oleh aplikasi. Untuk artikel ini, poinnya bukan mengajarkan kode. Poinnya: jalur submit perlu dicek end-to-end.

Tes yang berguna bukan hanya “klik submit lalu lihat halaman”.

Tes yang lebih sehat adalah:

• submit form dari browser,
• cek response backend,
• cek data benar-benar tersimpan atau terkirim,
• cek notifikasi internal masuk,
• cek pesan sukses hanya muncul jika proses berhasil,
• dan cek apa yang terjadi saat proses gagal.

Jika tim tidak mengecek sampai titik internal, calon pelanggan bisa merasa sudah mengirim pesan, sementara bisnis tidak pernah menerimanya.

Mobile browser sering membuka bug yang tidak terlihat di desktop

Banyak owner dan tim internal mengecek website dari laptop.

Padahal calon pelanggan sering membuka halaman dari ponsel. Mereka datang dari chat, Google, iklan, social media, atau referral link. Jalur mereka pendek: lihat halaman, scroll cepat, klik contact, kirim pesan.

Di mobile, masalah kecil bisa terasa besar.

Field terlalu sempit. Keyboard menutup tombol. Dropdown susah dipilih. Sticky header menutup anchor form. Tombol WhatsApp terlalu dekat dengan elemen lain. Validasi error muncul di luar viewport. Loading setelah submit tidak memberi feedback. Form terlihat pendek, tetapi membutuhkan scroll panjang setelah keyboard terbuka.

web.dev menjelaskan Core Web Vitals sebagai metrik yang mewakili loading, interactivity, dan visual stability. web.dev juga membahas Interaction to Next Paint sebagai cara memahami respons setelah interaksi pengguna. Artikel ini tidak mengklaim semua website harus mengejar angka tertentu sebelum menerima lead. Namun untuk jalur contact, respons interaksi tetap penting karena pengguna perlu tahu bahwa klik atau submit mereka sedang diproses.

Checklist Dev yang buyer-facing harus mencakup mobile, bukan sebagai formalitas, tetapi karena mobile sering menjadi jalur pertama calon pelanggan.

Tracking lead signal harus dibedakan dari sekadar pageview

Jika lead tidak masuk, analytics bisa membantu menjawab apakah tidak ada yang mencoba kontak atau jalur kontaknya bermasalah.

Tetapi analytics yang hanya berisi pageview tidak cukup.

Bisnis perlu membedakan beberapa sinyal:

• orang melihat halaman layanan,
• orang klik tombol contact,
• orang mulai mengisi form,
• orang berhasil submit form,
• orang klik WhatsApp,
• dan orang sampai ke halaman terima kasih jika ada.

Google Analytics Help mencantumkan generate_lead sebagai recommended event untuk submission form atau request for information. Ini bukan janji bahwa analytics selalu sempurna atau semua lead otomatis terukur. Tetapi event lead yang rapi membantu tim membedakan traffic biasa dari niat kontak.

Tanpa itu, tim mudah salah membaca situasi.

Website bisa terlihat sepi padahal tombol contact rusak. Atau traffic terlihat ramai, tetapi tidak ada sinyal bahwa pengunjung mencoba menghubungi. Atau event tercatat terlalu umum sehingga owner tidak tahu halaman mana yang menghasilkan intent.

Tracking yang berguna tidak harus rumit. Mulai dari mencatat tombol contact penting, submit form berhasil, source halaman, dan channel follow-up.

Handoff frontend ke backend perlu punya bukti kecil

Di banyak project, frontend dan backend dianggap selesai secara terpisah.

Frontend selesai saat form dan tombol tampil. Backend selesai saat endpoint tersedia. Marketing selesai saat copy dan CTA disetujui. Operations selesai saat ada email atau admin yang menerima pesan.

Tetapi lead tidak peduli batas tim.

Lead hanya peduli apakah pesan mereka sampai.

Karena itu, handoff perlu punya bukti kecil yang bisa dicek bersama:

• input yang dikirim dari form,
• response yang diterima browser,
• data yang diterima backend,
• notifikasi yang diterima tim,
• event tracking yang tercatat,
• dan instruksi follow-up setelah lead masuk.

Bukti ini tidak perlu menjadi dokumen panjang. Bahkan screenshot, log singkat, atau checklist post-launch bisa cukup untuk memastikan jalur bisnis tidak putus di antara tim.

Yang berbahaya adalah asumsi: frontend mengira backend sudah menangani, backend mengira frontend sudah validasi, marketing mengira semua tombol menuju channel yang benar, dan owner mengira lead memang belum ada.

Checklist audit setelah publish

Sebelum menganggap website siap menerima lead, audit satu jalur contact dari awal sampai akhir.

Mulai dari halaman yang paling mungkin dikunjungi calon pelanggan:

• buka dari desktop dan mobile,
• klik CTA utama,
• isi form dengan data valid,
• coba input yang salah,
• submit dari koneksi normal,
• cek pesan sukses dan pesan error,
• cek response backend,
• cek notifikasi internal,
• cek event contact atau generate_lead,
• cek nomor WhatsApp dan teks awal,
• cek halaman asal atau campaign context,
• dan cek siapa yang menerima lead setelah masuk.

Kalau satu langkah gagal, jangan langsung menyalahkan traffic atau market. Bisa jadi masalahnya lebih dekat: jalur contact belum diuji sebagai sistem utuh.

Website yang baik bukan hanya halaman yang bisa dilihat. Untuk bisnis, website harus menjadi jalur yang bisa dipercaya calon pelanggan untuk menghubungi, dan bisa dipercaya tim internal untuk menindaklanjuti.

Jika website Anda sudah live tetapi jalur lead belum pernah diaudit end-to-end, Havedev bisa membantu mengecek form, tombol contact, mobile behavior, backend handoff, dan tracking signal sebelum friksi kecil berubah menjadi lead yang hilang.

Audit jalur contact website