CRM'i Webhook'larla Omnichannel Gelen Kutusuna Bağlama

Bu rehber; CRM'lerinin ve omnichannel gelen kutularının müşteriye dair tek bir görünümü paylaşmasını isteyen CTO'lar, çözüm mimarları ve CRM yöneticileri içindir. Hangi olayların senkronize edileceğini, yeniden denemelere ve mükerrer kayıtlara dayanıklı bir webhook alıcısının nasıl kurulacağını, kişilerin WhatsApp, Instagram ve e-posta arasında nasıl eşleştirileceğini ve tasarımı hangi gizlilik kurallarının şekillendirdiğini açıklar.

CRM ve omnichannel gelen kutusu neleri değiş tokuş etmeli?

Gelen kutusu CRM'e size kimin, hangi kanaldan, ne hakkında ulaştığını ve sonucun ne olduğunu söylemelidir. CRM de gelen kutusuna müşterinin kim olduğunu, sahibinin kim olduğunu ve temsilcilerin hangi bağlama ihtiyaç duyduğunu söylemelidir.

Gerçek bir iş akışını destekleyen en küçük kümeyle başlayın. Her mesaj gövdesini CRM'e senkronize etmek nadiren gerekir ve gizlilik riskini artırır.

Hangi webhook olaylarına abone olmalısınız?

Yalnızca mesajlara değil, yaşam döngüsü olaylarına abone olun. Tam olay adları platformlar arasında farklılık gösterir; bu yüzden bunları şu kategorilere eşleyin:

• Konuşma oluşturuldu — bir müşterinin herhangi bir kanaldan gönderdiği ilk mesaj.
• Mesaj alındı — kanal ve gönderen tanımlayıcısıyla birlikte gelen müşteri mesajı.
• Mesaj gönderildi — giden temsilci veya şablon mesajı.
• Mesaj durumu — kanal bildirdiği ölçüde gönderildi, iletildi, okundu veya başarısız.
• Konuşma atandı — sahip veya kuyruk değişti.
• Konuşma çözüldü veya yeniden açıldı — durum geçişleri.
• Kişi güncellendi — tanımlayıcılar veya öznitelikler gelen kutusunda değişti.

WhatsApp için Meta'nın kendi webhook'ları gelen mesajları ve giden mesajların durum güncellemelerini platforma iletir; gelen kutusu sağlayıcınız ise kendi olaylarını sistemlerinize sunar.

Güvenilir bir webhook alıcısı nasıl kurulur?

Hızlı kabul edin, doğrulayın, bir kez kaydedin, sonra işleyin. İletim sorunlarının çoğu, CRM işinin webhook isteği içinde yapılmasından kaynaklanır.

Adım adım alıcı tasarımı

1. Ortam başına, örneğin /webhooks/inbox gibi tek bir HTTPS uç noktası sunun.
2. Gerçekliği doğrulayın. İmzayı (genellikle RFC 2104'te tanımlandığı üzere paylaşılan bir gizli anahtarla ham gövdenin HMAC'i) veya göndericinin belgelediği belirteci kontrol edin. JSON'u ayrıştırmadan önce ham baytlar üzerinde hesaplayın.
3. Güncelliği kontrol edin. Bir zaman damgası varsa, tekrar saldırılarını sınırlamak için kısa bir toleransın dışındaki olayları reddedin.
4. Mükerrer kayıtları ayıklayın. Olay kimliğini benzersiz kısıtlamalı bir tabloya ekleyin. Kimlik zaten var olduğu için ekleme başarısız olursa başarı döndürün ve durun.
5. Kuyruğa alın. Olayı bir kuyruğa koyun ve hemen 2xx yanıtı döndürün.
6. Eşzamansız işleyin. Bir çalışan kuyruğu okur, kişiyi eşleştirir ve upsert'lerle CRM'e yazar.
7. Geri çekilmeyle yeniden deneyin. CRM kapalıysa kuyruğunuzdan üstel geri çekilmeyle yeniden deneyin; göndericinin yeniden denemelerine güvenmeyin.
8. Ölü mektup kuyruğu. Birkaç başarısızlıktan sonra olayı bir ölü mektup kuyruğuna taşıyın ve bir kişiyi uyarın.
9. Mutabakat yapın. Son gelen kutusu konuşmalarını CRM kayıtlarıyla karşılaştıran ve boşlukları gelen kutusu API'sinden dolduran periyodik bir iş çalıştırın.

Idempotency ve sıralama neden önemli?

Webhook göndericileri genellikle zamanında başarı yanıtı alamadıklarında yeniden dener; bu da teslimi en az bir kez yapar. Aynı olay iki kez gelebilir ve bir "çözüldü" olayı son "mesaj alındı" olayından önce ulaşabilir. Bunu şöyle ele alın:

• Olay kimliğini mükerrer kayıt ayıklama anahtarı olarak kullanın.
• CRM'de konuşma veya mesaj kimliğine dayalı upsert'ler kullanın.
• Olay zaman damgalarını veya sıra numaralarını karşılaştırın ve daha eski durumu yok sayın.

CRM iş akışınız mesaj göndermek için gelen kutusu API'sini çağırdığında, API destekliyorsa bir idempotency anahtarı geçin; Idempotency-Key HTTP başlığı için hazırlanan IETF taslağı yaygın deseni açıklar.

Kişiler kanallar arasında nasıl eşleştirilmeli?

Normalleştirilmiş tanımlayıcılarla eşleştirin, deterministik eşleşmeleri tercih edin ve belirsizliği bir kişiye yönlendirin.

Karar kuralları:

1. Tek bir tam eşleşme: bağlayın.
2. Eşleşme yok: kaynak kanalla birlikte bir potansiyel müşteri veya "eşleşmemiş kişi" oluşturun.
3. Birden fazla eşleşme: bir temsilci için işaretleyin, otomatik birleştirmeyin.
4. Müşteri konuşmada başka bir tanımlayıcıyı doğruluyor: kanıtın notuyla birlikte bağlayın.

CRM entegrasyonunda veri gizliliği nasıl ele alınır?

Her sistemin yalnızca ihtiyaç duyduğu veriyi taşıyın, nedenini belgeleyin ve silmenin iki sistemde de çalışmasını sağlayın.

• Veri minimizasyonu. CRM'de konuşma bağlantılarını, sonuçları ve özetleri saklayın; tanımlı bir amaç yoksa dökümlerin tamamını gelen kutusunda tutun.
• Hukuki dayanak ve izin. Pazarlama opt-in'ini kanal başına kaydedin; bir destek konuşması pazarlama şablonları için izin değildir.
• Saklama. Saklama sürelerini gelen kutusu, CRM, kuyruklar ve günlüklerde hizalayın; webhook yük günlükleri çoğu zaman unutulur.
• Erişim kontrolü. CRM'de mesaj içeriğini ve ekleri kimlerin görebileceğini sınırlayın.
• Silme ve erişim talepleri. Bir sistemdeki talebin diğerine yayılmasını sağlayın.
• Sınır ötesi aktarımlar. Her sistemin veriyi nerede sakladığını kontrol edin. GDPR, AB'deki kişilerin kişisel verileri için geçerlidir; BAE ve Suudi Arabistan'ın da kendi kişisel veri koruma yasaları vardır. Güncel yükümlülükleri ilgili düzenleyici ve hukuk ekibinizle teyit edin.

Referans mimari nasıl görünür?

Metin biçiminde akış şöyledir: kanallardan gelen kutusuna, gelen kutusundan alıcıya, alıcıdan kuyruğa, kuyruktan çalışana, çalışandan CRM'e ve CRM iş akışlarından gelen kutusu API'sine geri.

Uygulamalı örnek: Cidde'de bir klinik grubu

Suudi Arabistan'da kurgusal bir sağlık grubu olan "Wahat Clinics", hasta randevuları için bir CRM'i, WhatsApp ve e-posta için bir gelen kutusunu kullanıyor.

• Bir hasta WhatsApp'tan mesaj yazıyor. Gelen kutusu bir konuşma oluşturuldu olayı yayar; alıcı doğrular, kaydeder ve kuyruğa alır.
• Çalışan numarayı E.164'e normalleştirir, tek bir hasta kaydı bulur ve mesaj metnini değil, konuşmaya bir bağlantıyı içeren bir etkinlik kaydeder.
• CRM hastanın tercih ettiği dili Arapça olarak gösterir ve gelen kutusuna iletir; gelen kutusu da Arapça kuyruğuna yönlendirir.
• Randevu CRM'de alındığında bir iş akışı, gelen kutusu API'sini çağırarak onaylı bir bilgilendirme (Utility) şablon onayı gönderir; yeniden deneme iki onay göndermesin diye idempotency anahtarı olarak randevu kimliğini geçirir.
• Gelen kutusunun "mesaj iletildi" olayı randevu kaydını günceller.

Sık yapılan hatalar nelerdir?

• Zaman aşımlarına, yeniden denemelere ve mükerrer kayıtlara yol açan CRM yazmalarını webhook isteği içinde yapmak.
• Mükerrer etkinlik ve kişi oluşturan mükerrer kayıt ayıklamanın olmaması.
• +971 ve 0 biçimlerinin hiç buluşmamasına yol açan normalleştirilmemiş telefon numaralarıyla eşleştirmek.
• İsme veya kısmi eşleşmelere göre otomatik birleştirmek.
• Tüm mesaj içeriğini amaç veya saklama kuralı olmadan CRM'e kopyalamak.
• Kaçırılan bir olayın kalıcı sapmaya dönüşmesine yol açan mutabakatın olmaması.
• Kaynak kodda gizli anahtarlar ve bir döndürme planının olmaması.

OmniChannels.ai nasıl yardımcı olur?

BroadNet Technologies tarafından desteklenen OmniChannels.ai; WhatsApp, Instagram, Messenger, Telegram ve e-posta konuşmalarını temsilci atama ve etiketlemeyle tek bir Omni Inbox'ta toplar; ayrıca Meta Embedded Signup ile WhatsApp kurulumunu ve değişkenli, medyalı ve butonlu onaylı şablonları sunar. CRM entegrasyonu için REST API OpenAPI 3.1 şemasıyla herkese açık biçimde belgelenmiştir; webhook'lar iletim durumlarını (SENT, DELIVERED, READ, FAILED ve daha fazlası) tek bir normalleştirilmiş biçimde bildirir. Filtreli ve CSV dışa aktarımlı iletim raporları mutabakatı destekler. Geliştiriciler sayfasından başlayın.