WhatsApp bildirimleri, e-posta ile karşılaştırıldığında farklı bir yerde okunur: müşterinin zaten açık olan sohbet uygulamasına düşer, bir kutuda beklemez. Bu yüzden açılma oranları yüksektir — ve aynı sebeple yanlış kurgulandığında rahatsız edici olur.
Bu yazı, T-Soft altyapısındaki bir mağazada WhatsApp entegrasyonunun nasıl kurulduğunu anlatıyor: olayların nasıl taşındığı, şablon onayının neden kurulumun başında yapılması gerektiği, telefon numarası biçiminin yarattığı sessiz hata ve T-Soft'un şablon erişiminin izin yönetiminde sağladığı avantaj.
T-Soft WhatsApp entegrasyonu nasıl çalışır?
Kurgu üç parçadan oluşur ve üçü birbirinden bağımsız düşünülmelidir:
- Olay kaynağı: T-Soft tarafındaki sipariş ve üye verisi. "Sipariş alındı", "kargoya verildi", "yeni üye kaydoldu" gibi olaylar buradan okunur.
- Karar katmanı: Hangi olayda, kime, hangi şablonla, ne zaman mesaj gideceği. İzin kontrolü de burada yapılır.
- Gönderim: WhatsApp Business API üzerinden onaylı şablonun gönderilmesi.
Bu ayrımın pratik bir faydası var: karar katmanı ve şablonlar platformdan bağımsız tarafta durur. Altyapı değiştirirseniz şablonlarınızı ve izin geçmişinizi baştan kurmanız gerekmez; yalnızca birinci parça, yani mağazadan veri okuyan bağlantı yeniden yapılandırılır.
Şablon onayı neden kurulumun ilk işi?
WhatsApp Business API'de, müşteri size yazmadan önce gönderilen her mesaj onaylı bir şablon olmak zorundadır. Şablonlar Meta tarafından incelenir ve onay süresi birkaç dakikadan birkaç güne kadar değişebilir.
Bunun proje planına etkisi doğrudan: kampanya sabahı yazılan bir şablon o gün çalışmayabilir. Bu yüzden şablonlar kurulumun başında hazırlanıp onaya gönderilir, teknik bağlantı onay beklenirken kurulur.
İkinci bir ayrıntı daha var: şablon metnindeki değişkenlerin sayısı ve sırası onaydan sonra değiştirilemez. "Sayın {{1}}, {{2}} numaralı siparişiniz kargoya verildi" şeklinde onaylanmış bir şablona sonradan üçüncü bir değişken ekleyemezsiniz; yeni şablon açıp yeniden onaya göndermeniz gerekir. Bu yüzden hangi bilginin mesajda geçeceği baştan kararlaştırılmalıdır.
Hangi olaylarda mesaj gitmeli?
Teknik olarak her sipariş durumu değişikliğinde mesaj gönderebilirsiniz. Pratikte bu, müşteriyi rahatsız eder ve engellenmeye yol açar. Anlamlı eşikler:
| Olay | Mesaj gitmeli mi | Gerekçe |
|---|---|---|
| Sipariş alındı | Evet | Müşteri ödemenin geçtiğini teyit etmek ister. |
| Hazırlanıyor | Genelde hayır | Müşteri için yeni bilgi taşımaz. |
| Kargoya verildi | Evet | Takip numarası ilk kez burada anlamlı olur. |
| Dağıtıma çıktı | Duruma göre | Evde bulunma ihtimalini artırır, başarısız teslimatı azaltır. |
| Teslim edildi | Evet | Süreci kapatır; değerlendirme istemek için de doğru an. |
| Her ara durum | Hayır | Bildirim yorgunluğu yaratır ve engellenme riskini yükseltir. |
Telefon numarası: en sık görülen sessiz hata
Kurulumdan sonra "mesajlar gitmiyor" diye gelen sorunların büyük çoğunluğu numara biçiminden kaynaklanır. Müşteriler numarayı olabilecek her biçimde girer: başında sıfırla, boşluklu, parantezli, tireli, ülke kodsuz.
WhatsApp ise uluslararası biçim bekler. Normalize edilmemiş numaralar için gönderim hata vermeden başarısız olur; panelde her şey yolunda görünür, mesaj ulaşmaz. Bu yüzden numaralar gönderim öncesi tek biçime çevrilmelidir: baştaki sıfır kaldırılır, noktalama temizlenir, ülke kodu yoksa eklenir.
Kurulumdan sonra bakılacak ilk sayı gönderim sayısı değil, teslim oranıdır. Gönderilen ile ulaşan arasındaki fark, numara biçimi sorununun büyüklüğünü gösterir.
T-Soft'un şablon erişimi izin yönetiminde ne kazandırıyor?
T-Soft barındırılan bir altyapıdır ama tema şablon dosyalarına panel üzerinden erişim verir. WhatsApp tarafında bunun iki somut karşılığı var.
Birincisi izin kutusunun yeri. Ticari mesaj göndermek için açık rıza gerekir ve bu rızanın alındığı yer önemlidir. Yalnızca JavaScript alanı sunan kapalı sistemlerde izin kutusu, form elemanlarının sınıf adları tahmin edilerek araya sokulur; tema değişince kutu yanlış yere düşebilir veya kaybolabilir. T-Soft'ta kutu üyelik ve sipariş formunun istenen yerine doğrudan yerleştirilir.
İkincisi WhatsApp düğmesi. Müşterinin size yazmasını sağlayan düğme, ürün sayfasında ve sepette anlamlıdır. Şablon erişimi sayesinde düğme tam olarak istenen konuma konur; sayfanın üzerine sonradan yapıştırılmış gibi durmaz.
Bu avantajın bedeli tema güncellemesi riskidir. Azaltmanın yolu, şablona yalnızca tek satırlık bir çağrı bırakıp mantığı dışarıdan yüklenen dosyada tutmaktır: güncelleme sonrası tek satırın geri konması yeterli olur.
İzin kaydı: metin değil, kayıt önemli
İzin konusunda sık yapılan hata, izin metnini yazıp bırakmaktır. Asıl önemli olan kaydın kendisidir: hangi müşteri, hangi tarihte, hangi metinle, hangi kanaldan onay verdi.
Sonradan bir itiraz veya denetim geldiğinde dayanağınız bu kayıttır. İzin kaydı tutmayan bir kurgu, izin metni ne kadar iyi yazılmış olursa olsun eksiktir. Kaydın müşteri silinse bile makul bir süre saklanması, geri alma (opt-out) taleplerinin de aynı yerde işlenmesi gerekir.
Geri alma tarafı çoğu zaman atlanır: müşteri "artık mesaj istemiyorum" dediğinde bunun otomatik işlenmesi gerekir. Elle işlenen bir opt-out, er ya da geç unutulur ve unutulduğu anda gönderilen mesaj hem şikâyete hem numaranın kalitesinin düşmesine yol açar.
Mesaj bedeli modül ücretine dahil değildir
Baştan netleşmesi gereken bir ayrım: modül bedeli yazılımın kullanım ücretidir. Mesajın kendisini Meta faturalandırır ve ayrıca mesaj paketi alınması gerekir.
Bu ayrım söylenmediğinde fatura beklenenden yüksek görünür ve satış sonrası en sık yaşanan anlaşmazlık budur. Planlama yaparken aylık tahmini mesaj adedi üzerinden bir bütçe çıkarmak doğru olur: sipariş sayısı × senaryo başına mesaj adedi, artı kampanya gönderimleri.
Kurulumdan sonra sessizce bozulan üç şey
- Şablon reddi. Meta bir şablonu sonradan devre dışı bırakabilir. O senaryodaki mesajlar durur ve bunu fark etmenin tek yolu gönderim raporuna bakmaktır.
- Numara kalitesi. Çok sayıda engellenme veya şikâyet, gönderici numaranın kalite puanını düşürür ve günlük gönderim limitini kısar. Bildirim sıklığını abartmamak teknik bir gereklilik.
- Değişken kayması. Sipariş durumu adları T-Soft tarafında yeniden adlandırıldığında, o duruma bağlı otomasyon eşleşmeyi kaybedebilir. Durum adları değiştiğinde otomasyon kuralları gözden geçirilmelidir.
Özet
T-Soft'ta WhatsApp entegrasyonu, kurgunun üç parçaya ayrılmasıyla sağlam kurulur: olay kaynağı, karar katmanı, gönderim. Şablonlar onay süresi öngörülemediği için ilk işte hazırlanır; telefon numaraları gönderim öncesi normalize edilir, aksi halde mesajlar hata vermeden ulaşmaz.
T-Soft'un tema şablonuna erişim vermesi, izin kutusunun ve WhatsApp düğmesinin doğru yere konmasını kapalı sistemlere göre belirgin kolaylaştırır. İzin tarafında ise metinden çok kaydın ve otomatik işlenen bir geri alma akışının önemli olduğunu unutmamak gerekir.