IOSOR

IOSOR Rehber

B2B için SMS teslim edilebilirliği: durumlar, DLR ve tek ops/finans gerçeği

Ciddi ekiplerin delivered ile sent’i nasıl ayırdığı, webhook bağladığı, koridor gecikmesini izlediği ve ön ödemeli hacimde sahte “başarıyı” nasıl engellediği.

“Gönderildi”, “teslim edildi” değildir. OTP, uyarılar ve işlem trafiğinde teslim edilebilirlik; dönüşüm ile sessiz kaybı ayırır. Bu rehber ürün, ops ve finansın ortak dil ihtiyacı olan B2B ekipler içindir — başka bir markanın portalında yaşamak zorunda kalmadan.

IOSOR white-label ön ödemeli mesajlaşma sunar: sonuçlar hesabınızda ve callback’lerde görünür; hatalar kullanılabilir ve marka güvenlidir. Hesabı tutmak için zorunlu platform aboneliği yoktur; ön ödeme ritmi belirler.

Ayarlamadan önce başarıyı tanımlayın

  1. Kullanıcı — kodlar ve uyarılar dönüşüm SLA’sı içinde.
  2. Ops — queued / sent / delivered / failed bilet olmadan görünür.
  3. Finans — yeniden deneme ve ölü hedefler cüzdanı sessizce yakmaz.

Tedarikçi yalnızca yeşil gönder düğmesi gösteriyorsa boşluklar gerçek hacimde çıkar.

Finansın güvenebileceği durum modeli

Durum Anlam Neden önemli
Accepted / queued Platform işi aldı İstemci hatasını borudan ayırır
Sent / submitted Canlı rotaya verildi Cihaza teslim kanıtı değildir
Delivered Pozitif DLR / uç başarı Dönüşüm düzeyinde sinyal
Failed Kullanılabilir nedenli uç başarısızlık Retry ve hedef kararlarını sürer

Webhook veya doğrulanabilir olaylar isteyin. Saat 02:00’deki başka bir konsol ekran görüntüsü ölçeklenmez.

DLR ve webhook kontrol listesi

  • İmzalı veya kimlik doğrulamalı gelen olaylar
  • Idempotent işleme
  • Korelasyon kimlikleri: gönderim → durum → defter
  • Arızada ürün içinde son teslimatları inceleme

White-label yine de operasyon kanıtı vermelidir — ekibi başka bir markanın ops arayüzüne itmeden.

Gecikme bir koridor sorunudur

OTP dönüşümü coğrafyaya duyarlıdır. Tek bir “dünya ortalaması” değil, hedef sınıfına göre gecikme bantlarını izleyin. Koridor bozulduğunda ürün, kullanıcılar geçici çözüm bulmadan önce bilmelidir.

Kontrolsüz yeniden denemeler ön ödemeyi şişirir ve kullanıcı hâlâ başarısızken “trafik” gibi görünür.

  • Otomatik retry tavanı ve sahibi
  • Kullanıcı yeniden gönderimini sistem retry’sından ayırın
  • Ölü hedefleri bombalamadan önce lookup / liste hijyeni

Aylık platform kullanımı yaklaşık USD 1.000+ olduğunda teslim edilebilirlik metrikleri ticari kanıt olur: düzenli başarısız hedefler umut değil, ücret ve yol incelemesi ister.

Pazar hâlâ kurulumda ise live teslim edilebilirlik diye satmayın. Boş yetenek; yeşil rozet gösterisinden iyidir.

Kırmızı bayraklar

  • Yalnızca “sent”; delivered/failed yok
  • Callback’ler “sonra”
  • Mock koridorları üretim hazırlığı gibi sunmak
  • Upstream marka veya ham yük döken hatalar
  • Ön ödeme görünürlüğü olmayan retry fırtınaları

IOSOR ile başlayın

IOSOR konsolunu açın ve aktif rotalarınız için imzalı durum geri çağrımlarını etkinleştirmek üzere Webhook Ayarları bölümüne gidin. Her gönderim yükünde iletilen ilişkilendirme kimliğini kullanarak terminal durum olaylarını doğrudan dahili veritabanınıza eşleyin.

IOSOR özeti

SMS teslim edilebilirliği, varsayımlara değil açık durum geçişlerine dayanan tek bir operasyonel ve finansal doğruluk kaynağı gerektirir. Sisteminizi eşdeğer DLR webhook ları ve ilişkilendirme kimlikleriyle donatmak, mühendislik, operasyon ve muhasebe birimlerinin aynı işlem durumlarını görmesini sağlar.

Terminal DLR olaylarını —teslim edildi veya başarısız oldu gibi— varış koridoruna göre doğrudan defterinize ve gecikme izleme araçlarınıza eşleyin. Gönderildi durumunu cihaz teslimatının kanıtı olarak kabul etmeyin ve sistemik teslimat arızalarını gizleyen ham yukarı akış hata dökümlerine göz yummayın.

Bu rehber yardımcı oldu mu?

İlgili rehberler