Mulai dari Prinsip Produk: “Tidak Diterima” Itu Bukan Satu Masalah

Dari sudut pandang pengguna, semuanya sama: mereka tidak melihat email di inbox. Namun di bawahnya, ada beberapa kategori yang berbeda: email gagal dikirim, email dikirim tapi ditolak, email diterima tapi masuk spam, email tertahan delay, email masuk tapi tidak terlihat (filter, tab, thread), atau email terkirim ke alamat yang salah.

Langkah pertama tim produk adalah mendefinisikan dengan presisi apa yang dimaksud “sent” dan “received” di sistem Anda. Jika “sent” hanya berarti “request enqueue sukses”, Anda sedang memantau metrik yang salah.

Cerita Singkat: Satu Tiket yang Mengubah Cara Tim Melihat Masalah

Bayangkan seorang pengguna baru mendaftar. Mereka menekan tombol “Kirim kode verifikasi”. UI menampilkan toast: “Email terkirim”. Lima menit kemudian, mereka menekan lagi. Dan lagi. Di sisi pengguna: tidak ada email. Di sisi sistem: ada tiga event “sent”.

Awalnya tim mengira provider email sedang lambat. Tapi setelah dicek, ternyata alamat email pengguna mengandung typo kecil (misalnya gmial.com). Sistem Anda menganggap “sent” karena request ke provider sukses, tapi email masuk ke domain yang salah. Hasilnya: tim belajar satu hal penting — debugging harus dimulai dari kebenaran input dan definisi event, bukan asumsi teknis.

Peta Rantai Pengiriman (End-to-End): Tempel di Dinding Tim

Untuk debug yang cepat, tim produk butuh peta sederhana end-to-end. Contoh umum: UI/Client → API → Queue/Job → Email Service/Provider → DNS/Domain Auth → Inbox Provider (Gmail/Outlook/Yahoo) → Perangkat pengguna.

Di tiap titik, tanyakan: apa bukti yang bisa kita lihat? event log? status code? message id? response dari provider? Kalau Anda tidak punya “jejak” di salah satu titik, itulah kandidat akar masalah pertama: observability yang bolong.

Checklist Pertanyaan yang Harus Dijawab Sebelum Menyimpulkan Apa Pun

• Jenis email apa? OTP, reset password, magic link, invoice, newsletter, notifikasi.
• Provider penerima apa? Gmail, Outlook, Yahoo, domain kantor, iCloud.
• Apakah user salah input email? typo, spasi, karakter aneh, unicode.
• Apakah user melihat folder spam/promotions? atau tab lain di aplikasi email.
• Apakah terjadi di wilayah tertentu? negara, ISP, jam sibuk.
• Apakah ini intermittent? hanya sebagian user, atau semua.
• Apakah ini baru terjadi? setelah deploy, ganti domain, ganti provider, ubah template.

Pertanyaan-pertanyaan ini terlihat “support banget”, tapi ini bahan bakar utama untuk membangun hipotesis yang bisa diuji. Tim produk yang baik tidak langsung melompat ke “deliverability jelek” sebelum membuktikan dasar-dasarnya.

Klasifikasi Gejala (Agar Tiket Tidak Campur Aduk)

Buat klasifikasi sederhana untuk mengelompokkan laporan. Ini membantu melihat pola dan memprioritaskan:

• A. Tidak ada event send attempt (user klik, tapi sistem tidak memproses).
• B. Ada attempt, tapi gagal sebelum provider (error internal, queue penuh, job retry macet).
• C. Provider menerima, tapi reject/bounce (alamat tidak valid, domain menolak, policy).
• D. Provider menerima, tapi inbox tidak menampilkan (spam, filtering, tab).
• E. Provider menerima, tapi delay ekstrem (throttling, rate limit, backlog).

Dengan klasifikasi ini, tim produk bisa mengubah kalimat “email tidak masuk” menjadi “kategori D dominan pada Gmail untuk template OTP sejak rilis X”. Itu jauh lebih bisa ditindaklanjuti.

Data yang Harus Ada (Kalau Tidak Ada, Jadikan PR Produk)

Masalah “sent but not received” biasanya sulit karena data tersebar. Tim produk perlu memastikan minimal ada:

• Correlation ID per aksi user (klik “send code”) yang mengalir sampai provider.
• Timestamp di setiap tahap (request diterima, enqueue, dequeue, provider accepted, delivered/bounced).
• Recipient hash (bukan email plain) untuk privasi tapi tetap bisa analisis.
• Provider message id dari respons provider email.
• Status detail (accepted, deferred, bounced, complaint, suppressed).
• Template/version dari email yang dipakai (OTP v3, reset v2, dsb.).
• Domain/sender yang digunakan (subdomain per use-case).

Kalau saat ini Anda hanya punya log “sent=true”, maka pekerjaan pertama bukan “debug”, tapi membangun telemetry yang benar agar debug mungkin dilakukan.

Hipotesis Cepat dan Cara Mengujinya (Tanpa Menunggu 2 Minggu)

Hipotesis 1: Input email salah atau tidak valid

Uji dengan melihat pola domain typo, bounce rate karena invalid mailbox, atau format yang tidak normal. Di produk, tambahkan validasi yang lebih tegas: trim spasi, normalisasi, dan konfirmasi ulang alamat untuk flow penting.

Hipotesis 2: Rate limit dan throttling di provider

Gejalanya: email akhirnya masuk, tapi terlambat. Lihat antrian job, waktu tunggu, dan status “deferred”. Solusi produk bisa berupa: batasi resend, tampilkan countdown, dan jangan menipu user dengan “terkirim” jika baru enqueue.

Hipotesis 3: Masuk spam/promotions

Gejalanya: provider accepted, tapi user tidak lihat di inbox utama. Minta beberapa user cek spam/promotions. Dari sisi produk, perbaiki copy dan edukasi: “Jika tidak terlihat, cek Spam/Promotions”. Dari sisi engineering, audit autentikasi domain (SPF/DKIM/DMARC), konsistensi From, dan kualitas konten template.

Hipotesis 4: Suppression list atau blokir karena complaint

Banyak provider email service menyimpan daftar alamat yang pernah bounce/complain. Akibatnya, sistem Anda merasa “send job sukses” tapi provider menahan atau tidak mengirim. Uji dengan melihat status suppressed dan sebabnya. Solusi: transparansi di tooling, dan mekanisme “unsuppress” yang aman setelah verifikasi.

Hipotesis 5: Perubahan template memicu filter

Terkadang perubahan kecil seperti menambah link tracking, mengganti subject yang terlalu agresif, atau memasukkan kata-kata tertentu membuat deliverability turun. Uji dengan A/B template version, kirim ke seed mailbox, dan pantau per provider.

Perbaikan Bahasa Produk: Jangan Bilang “Terkirim” Kalau Baru “Diproses”

Banyak tim produk tanpa sadar menciptakan ekspektasi palsu. Di UI, label seperti “Email terkirim” sering muncul saat server baru menerima request, bukan saat provider menerima email. Akibatnya, ketika email delay, user merasa dibohongi.

Pertimbangkan status yang lebih jujur, misalnya: “Kami sedang mengirim email…” lalu konfirmasi “Email sudah dikirim. Silakan cek inbox/spam.” setelah Anda benar-benar punya sinyal “accepted” dari provider, atau setidaknya setelah job keluar dari queue.

Ini bukan sekadar copywriting; ini strategi untuk mengurangi tiket support dan mengarahkan user melakukan langkah yang tepat.

Eksperimen Produk yang Efektif untuk Mengurangi Friksi

1) Tombol resend dengan cooldown yang jelas

Daripada user menekan berkali-kali (dan membanjiri antrian), tampilkan countdown 30–60 detik. Jelaskan: “Terlalu sering meminta kode bisa membuat pengiriman tertunda.”

2) Alternatif channel (opsional)

Jika use-case memungkinkan, sediakan fallback seperti OTP via SMS atau login link di kanal lain. Bahkan jika tidak selalu diaktifkan, opsi ini bisa menyelamatkan funnel saat email bermasalah.

3) “Cek folder spam/promotions” sebagai langkah terstruktur

Jangan hanya menulis catatan kecil. Buat micro-guide di layar: “Cari subject X”, “Cek Promotions”, “Cek Spam”, “Cari nama pengirim”. Ini mengurangi churn tanpa perlu user membuka tiket.

4) Deteksi domain yang sering bermasalah

Jika data menunjukkan domain tertentu sering delay atau reject, produk bisa menampilkan rekomendasi: “Jika Anda memakai email kantor, pertimbangkan email personal untuk verifikasi.” Pastikan penyampaian tetap netral dan tidak menyalahkan user.

Metrik yang Perlu Dipantau Tim Produk (Bukan Cuma “Send Count”)

• Request-to-Accepted Rate: persentase klik user yang benar-benar accepted oleh provider.
• Accepted-to-Delivered/Inbox Proxy: jika ada sinyal delivered atau open, gunakan sebagai proksi.
• Median & P95 Delivery Time: waktu dari klik user sampai email diterima (atau setidaknya accepted).
• Resend Rate: seberapa sering user menekan resend, dan dampaknya ke conversion.
• Drop-off Verification Funnel: titik churn terbesar (setelah klik, setelah input OTP, dsb.).
• Bounce/Reject Rate per Provider: Gmail vs Outlook vs domain korporat.
• Spam Complaint Rate: sinyal kuat deliverability bermasalah.

Metrik ini membantu tim produk berbicara dalam bahasa yang sama dengan engineering dan deliverability, sekaligus menjaga fokus pada dampak bisnis: conversion, activation, dan biaya support.

Alur Debug Praktis (Mode War Room 60 Menit)

1. Kumpulkan 3–5 contoh kasus lengkap dengan waktu, email penerima, jenis email, dan provider penerima.
2. Telusuri correlation ID dari UI event sampai job queue dan respons provider.
3. Pastikan definisi “sent”: apakah berarti enqueue, processed, atau accepted?
4. Cek status provider: accepted, deferred, bounced, suppressed.
5. Segmentasi berdasarkan provider penerima dan template version.
6. Uji seed inbox untuk Gmail/Outlook/Yahoo guna melihat apakah masuk inbox atau spam.
7. Putuskan tindakan cepat: rollback template, kurangi resend, perbaiki copy UI, atau eskalasi ke provider.
8. Dokumentasikan temuan dan buat action items: telemetry, guardrail, dan perubahan produk.

Dengan alur ini, Anda mengubah “masalah misterius” menjadi rangkaian langkah yang bisa dieksekusi lintas tim.

Hal yang Sering Terlewat (Tapi Sering Jadi Biang Kerok)

• Perbedaan lingkungan: staging sukses, production gagal karena domain, konfigurasi DNS, atau rate limit berbeda.
• Link tracking dan redirect: beberapa filter spam sensitif terhadap pola URL tertentu.
• From name berubah-ubah: inkonsistensi pengirim menurunkan trust.
• Template OTP terlalu “marketing”: terlalu banyak elemen visual, terlalu banyak link, atau kata-kata promosi.
• Resend tanpa batas: memperparah throttling dan membuat deliverability tambah buruk.
• System clock dan timestamp: jika jam server salah, analisis delay jadi menyesatkan.

Kesimpulan: Produk yang Baik Membuat Debug Menjadi Mudah

“Sent but not received” bukan cuma urusan deliverability; ini masalah end-to-end yang menyentuh definisi event, telemetry, UX, dan kebiasaan pengguna. Tim produk punya peran penting: menyatukan data, mengarahkan investigasi, dan mengubah temuan teknis menjadi perbaikan pengalaman.

Jika Anda harus mengingat satu hal: jangan puas dengan “sent=true”. Bangun jejak yang jelas sampai provider, segmentasikan kasus, dan jadikan UI Anda jujur serta membantu. Hasilnya bukan hanya email yang lebih sering sampai, tapi funnel yang lebih stabil dan support yang lebih tenang.