Pola yang Saya Lihat Sebelum Perusahaan Akhirnya Ganti Infrastruktur Email

Sebagai Product Marketing Manager di Mailtarget, saya cukup sering mendengar keluhan dari calon customer. Sebagian besar cerita yang saya dengar tidak dimulai dari technical decision. Mereka dimulai dari momen yang tidak nyaman: seseorang di tim mereka, biasanya dari support atau product, tiba-tiba menyadari ada pola di komplain user yang tidak bisa dijelaskan dari sisi sistem.

OTP tidak sampai. Notifikasi transaksi terlambat. User tidak bisa login. Dan ketika tim mulai investigasi, semua dashboard masih hijau.

Artikel ini tentang pola itu. Kenapa terjadi, kenapa susah dideteksi lebih awal, dan apa yang biasanya berubah ketika tim akhirnya memutuskan untuk evaluasi ulang infrastruktur email mereka.

Ini cerita yang saya dengar berulang

Saya cukup sering duduk di percakapan awal dengan calon customer sebelum mereka akhirnya pindah ke Mailtarget. Dan ada satu pola yang muncul konsisten.

Mereka tidak datang karena sistem mereka jelas-jelas bermasalah. Mereka datang karena ada sesuatu yang tidak bisa mereka jelaskan. Delivery terasa tidak konsisten. Ada periode di mana semuanya berjalan normal, lalu tiba-tiba ada keluhan dari user, lalu normal lagi. Tim engineering sudah cek berkali-kali, tidak ada yang berubah di sisi mereka.

Dan satu kalimat yang hampir selalu muncul di percakapan itu: "Kemarin masih jalan."

Kalimat itu terdengar seperti pembelaan. Tapi sebenarnya itu adalah diagnosis yang paling jujur tentang kondisi mereka: sistem berjalan bukan karena mereka punya kontrol penuh atas variabelnya, tapi karena kondisi eksternal kebetulan mendukung.

Salah satu percakapan yang cukup saya ingat

Beberapa waktu lalu saya berbicara dengan tim product dari sebuah perusahaan fintech. Mereka menghubungi Mailtarget bukan karena ada insiden besar, tapi karena ada sesuatu yang mengganggu mereka selama beberapa bulan.

Mereka mulai notice ada pola aneh di support ticket. Beberapa user melaporkan tidak menerima OTP, tapi tidak semua. Tidak ada keluhan massal, tidak ada waktu yang konsisten, tidak ada pola yang jelas dari sisi user. Tim engineering sudah investigasi beberapa kali dan tidak menemukan apa-apa yang salah di sistem mereka.

Percakapan itu dimulai dengan pertanyaan yang cukup sederhana dari saya:
"Kalau ada masalah delivery hari ini, dari mana kamu akan tahu pertama kali?"

Mereka diam sebentar. Lalu salah satu dari mereka menjawab: "Dari support ticket, kayaknya."

Itu bukan jawaban yang salah. Tapi itu adalah jawaban yang menggambarkan sebuah sistem di mana user menjadi alert system. Dan untuk produk fintech yang flow autentikasinya bergantung pada OTP, itu adalah risiko yang terlalu mahal untuk dibiarkan jalan terus.

Setelah kami breakdown lebih dalam, ternyata mereka menggunakan shared sending infrastructure yang tidak memberikan visibility ke delivery layer sama sekali. Tidak ada cara untuk tahu apakah masalahnya ada di sisi mereka atau di sisi infrastruktur yang mereka tumpangi. Dan memang itulah yang terjadi: reputasi shared IP pool mereka sedang dalam kondisi tidak stabil karena perilaku sender lain di pool yang sama.

Mereka tidak melakukan kesalahan apapun. Tapi user mereka yang merasakannya.

Mengapa sinyal masalah sering muncul dari user, bukan dari sistem

Monitoring sistem dirancang untuk menangkap sinyal dari sisi infrastruktur. API response, error rate, queue status. Tapi ada kategori masalah yang tidak tertangkap di sana karena origin-nya bukan di sistem si pengirim.

Ketika sebuah tim menggunakan shared sending infrastructure, reputasi IP yang menentukan apakah email mereka sampai atau tidak bukan sepenuhnya hasil dari apa yang mereka lakukan. IP yang sama digunakan oleh banyak sender lain. Kalau salah satu sender di pool itu berperilaku buruk, reputasi seluruh pool ikut terdampak. Delivery semua orang di dalamnya, termasuk tim yang tidak melakukan kesalahan apapun, bisa ikut memburuk.

Tidak ada error. Tidak ada alert. Yang ada hanya user yang tiba-tiba tidak menerima OTP, atau notifikasi transaksi yang masuk terlambat, atau email password reset yang tidak pernah sampai.

Karena gejalanya subtil dan tidak konsisten, sinyal ini sering pertama kali tertangkap bukan oleh sistem monitoring, tapi oleh orang yang paling dekat dengan user. Support team yang menerima ticket. Product manager yang melihat pola di feedback. Atau sales yang mendengar dari prospect bahwa mereka tidak menerima email onboarding.

User menjadi alert system. Dan itu adalah posisi yang tidak seharusnya ada di produk yang user-nya bergantung pada email untuk autentikasi, transaksi, atau notifikasi kritis.

"Kemarin masih jalan" adalah indikator ketergantungan, bukan bukti stabilitas

Kalau sistem berjalan baik bukan karena ada kontrol yang dipegang, tapi karena kondisi eksternal kebetulan mendukung, itu bukan stabilitas. Reliability yang sesungguhnya bukan tentang seberapa jarang sistem rusak. Tapi tentang seberapa banyak kontrol dan visibility yang dimiliki ketika sesuatu mulai tidak berjalan sesuai harapan.

Sebagian besar kegagalan yang saya lihat bukan karena keputusan yang jelas-jelas buruk. Tapi karena asumsi yang tidak pernah diuji sampai terlambat. "Pakai shared infrastructure karena murah dan mudah setup" adalah keputusan yang valid, kalau dibuat dengan sadar dan dengan pemahaman penuh tentang trade-off-nya.

Tapi kalau keputusan itu tidak pernah benar-benar dibuat, kalau shared IP hanya jadi default karena tidak ada yang pernah mempertanyakannya, maka "kemarin masih jalan" bukan bukti bahwa pilihannya tepat. Itu bukti bahwa evaluasinya belum pernah terjadi.

Apa yang biasanya berubah setelah tim memutuskan untuk evaluasi ulang

Dari banyak percakapan yang saya ikuti, ada tiga hal yang hampir selalu menjadi turning point.

Pertama adalah ketika impact-nya sudah terukur secara bisnis. Bukan hanya "ada user yang komplain", tapi "conversion di flow autentikasi turun" atau "ada churn yang bisa ditrace ke masalah notifikasi". Di titik itu, percakapan tentang infrastruktur berhenti jadi urusan teknis dan mulai jadi urusan product dan bisnis.

Kedua adalah ketika tim menyadari mereka tidak bisa menjawab pertanyaan sederhana ini: kalau ada masalah delivery hari ini, dari mana kita akan tahu, dan seberapa cepat? Kalau jawabannya adalah "dari user yang komplain", itu sendiri sudah cukup untuk memulai evaluasi.

Ketiga adalah ketika ada requirement baru yang tidak bisa dipenuhi oleh setup yang sekarang. SLA yang lebih ketat, compliance requirement, atau skalabilitas yang mulai jadi constraint. Di sini biasanya percakapan tentang dedicated infrastructure mulai serius dipertimbangkan.

Apa yang sebenarnya berubah dengan dedicated infrastructure

Satu hal yang sering saya luruskan di percakapan evaluasi: dedicated IP bukan solusi instan. IP baru tetap butuh proses warm-up yang benar. Reputasi tetap harus dibangun dari nol.

Tapi yang berubah fundamental adalah kontrol dan visibility. Reputasi IP itu sepenuhnya hasil dari perilaku tim sendiri. Naik turunnya bisa di-trace. Kalau ada penurunan delivery, ada tempat yang jelas untuk mulai investigasi, bukan hanya menunggu pola komplain user untuk mengonfirmasi bahwa ada sesuatu yang salah.

Di Mailtarget, ini adalah salah satu percakapan yang paling sering kami lakukan bersama tim yang sedang dalam proses evaluasi. Bukan hanya soal fitur atau harga, tapi soal level kontrol dan visibility seperti apa yang dibutuhkan untuk use case spesifik mereka.

Kalau Anda ingin tahu apakah infrastruktur email yang sekarang masih fit untuk scale dan use case yang ada, tim Mailtarget bisa bantu audit singkat. Jadwalkan quick call di sini.