Webhook ile workflow tetikleme: dış sistemden CRM'i harekete geçirmek

Salı sabahı 09:12. Abonelik tahsilatını yürüten ödeme sağlayıcısı, gece 03:40'ta yedi kartın çekilemediğini bildirmiş; bildirim paylaşımlı bir e-posta kutusuna düşmüş ve orada beklemiş. Operasyon sorumlusu bunu ancak kutuyu açtığında görüyor. Aradaki beş buçuk saatte yedi müşteriden hiçbirine ulaşılmamış, tek bir görev açılmamış, ikisi bu arada hesabını kapatmış. Kimse hata yapmadı: bilgi sistemde vardı, yalnızca CRM'e girmedi.

Bu yazı o beş buçuk saati ortadan kaldıran bağlantıyı anlatıyor: dış bir sistemin bildirdiği olayın CRM'de doğrudan bir iş akışı başlatması. Önce gelen isteğin ne olduğunu ve ne olmadığını netleştiriyoruz; sonra hangi olayların akış açmayı hak ettiğini, webhook ile zamanlı çekme arasında nasıl seçim yapıldığını, gövdedeki alanların kayıtlara nasıl eşlendiğini, göndericinin nasıl doğrulandığını, aynı olayın ikinci kez gelmesinin neden beklenen bir durum olduğunu, hata alan çalıştırmaların nasıl toparlandığını, akışın yayına çıkmadan nasıl denendiğini, ani yığılmaların müşteriye nasıl yansımadığını ve otomasyonun nerede durup insanı çağırması gerektiğini sırayla ele alıyoruz.

Gelen webhook bir bildirim midir, emir midir?

Dış sistemin gönderdiği istek, dünyaya dair bir iddiadır: "şu anda şu oldu". Emir değildir. Bu ayrım kulağa felsefi geliyor ama kurulumun tamamını belirler. Emir kabul eden bir uç nokta, karşı sistemin her hatasını sizin verinize yazar; test ortamından kaçan bir istek gerçek müşteriye mesaj gönderir. İddia kabul eden bir uç nokta ise önce sorar: bu kayıt bizde var mı, durumu zaten bu mu, bu olay bizi gerçekten ilgilendiriyor mu.

Pratikte bu, akışın ilk adımının bir aksiyon değil bir koşul olması demektir. Workflow Builder'ın Koşullu Dallanma adımı tam burada çalışır: gelen gövdedeki durum alanı "başarısız" ise bir kol, "iade" ise başka bir kol, tanımadığınız bir değer ise hiçbir kol açılmaz ve akış sessizce biter. Koşulu en başa koymak, akışın geri kalanını yazarken elinizi rahatlatır; kuralların nasıl kurgulandığını daha geniş çerçevede koşullu kurallarla süreçleri otomatikleştirmek başlığı altında ele almıştık.

Bu yaklaşımın ikinci faydası, karşı sistemin sözleşmesini değiştirdiği gün ortaya çıkar. Alan adı değişir, yeni bir durum değeri eklenir, gövdeye bir katman daha sarılır. Emir kabul eden akış yanlış işi doğru bir şekilde yapar; iddia kabul eden akış eşleşme bulamaz ve durur. Duran akışı fark etmek, yanlış çalışanı fark etmekten çok daha kolaydır.

Hangi dış olaylar CRM'de akış açmayı hak eder?

Her olay bir akışa değmez. İyi bir eleme ölçütü şudur: bu olay geldiğinde bir insanın davranışı değişecek mi? Değişmeyecekse olay bir kayıt satırıdır, tetikleyici değil. Ödeme başarısız oldu, deneme süresi bitti, destek talebi ikinci kez açıldı, sözleşme yenileme tarihine otuz gün kaldı — bunların hepsinde birinin bir şey yapması gerekir. Buna karşılık "kullanıcı profil fotoğrafını değiştirdi" bilgisi CRM'e yazılabilir ama kimseyi harekete geçirmemelidir.

İkinci ölçüt zamanlamadır. Olayın değeri saatler içinde eriyorsa webhook doğru araçtır; günler içinde eriyorsa gece çalışan bir senkron da işi görür. Bir rezervasyon aracının doldurduğu takvim kaydı ilk gruba girer, çünkü müşteri o randevuyu birkaç saat içinde iptal edebilir; nasıl kurulduğunu takvimden doğrudan CRM'e kayıt akan rezervasyon linki yazısında adım adım anlatmıştık.

Üçüncüsü sahiplik. Olayın karşılığında yapılacak iş belirli bir kişiye düşmüyorsa akış kurmayın; kimsenin sahiplenmediği bildirim üç hafta içinde gürültüye dönüşür. Site formunuz kendi altyapınızda duruyor ve doğrudan CRM'e yazamıyorsa webhook aradaki köprüdür; bu köprünün dönüşüme etkisini ziyaretçiyi lead'e çeviren açılış sayfası tarafında da görürsünüz, çünkü form ile ilk temas arasındaki dakika sayısı doğrudan düşer.

Webhook mu, zamanlı çekme mi, elle giriş mi?

Üç yöntem birbirinin alternatifi değil, farklı işlerin doğru aracıdır. Webhook karşı sistemin size haber vermesidir; zamanlı çekme sizin belirli aralıklarla sormanızdır; elle giriş ise hacmi düşük, kuralı belirsiz durumlar içindir. Karar verirken bakılacak ölçütler kısadır:

Ölçüt	Webhook (olay itilir)	Zamanlı çekme (veri sorulur)
Gecikme	Saniyeler	Tarama aralığı kadar
Kaçan olay	İstek düşerse kaybolur; yeniden deneme şart	Sonraki turda yine görülür
Yük	Yalnız olay olduğunda	Olay olmasa da her turda
Kurulum	Karşı sistemde uç nokta ve imza tanımı	Yetkilendirme, sayfalama, son okuma damgası
Uygun olduğu iş	Anında tepki gereken tekil olaylar	Toplu senkron ve gün sonu mutabakatı

Pratikte olgun kurulumlar ikisini birden kullanır: webhook hızı verir, gecelik çekme ise düşen istekleri yakalayan güvenlik ağıdır. Araçları birbirine bağlamanın farklı yolları ve hangisinin ne zaman tercih edildiği için CRM entegrasyonlarında API ve webhook seçenekleri karşılaştırmasına bakabilirsiniz.

Gövdedeki alanları CRM kayıtlarına nasıl eşlersiniz?

Eşleme, kurulumun en sıkıcı ve en belirleyici adımıdır. Önce kimlik: gelen gövdedeki hangi alan sizin kaydınıza karşılık geliyor? E-posta adresi kolay ama kırılgandır; aynı kişi iki farklı adresle kayıt olabilir. Karşı sistemin kendi kimlik numarasını CRM'de bir alanda saklamak ve eşlemeyi onun üzerinden yapmak, altı ay sonra çıkacak sorunların yarısını baştan siler.

Sonra dönüşüm: para birimi kuruş cinsinden mi geliyor, tarih hangi saat diliminde, durum değerleri büyük harfli mi. Bu üç sorunun yanıtını akışa yazmadan önce not alın, çünkü hepsi sessizce yanlış çalışabilen türden şeylerdir. Bir de eksik alan davranışı: telefon numarası gelmediğinde akış duracak mı, yoksa boş bırakıp devam mı edecek?

Son olarak, eşlemeyi tek yerde toplayın. Aynı dış sistemden gelen beş farklı olay tipi için beş ayrı akışta aynı alan dönüşümünü tekrar yazarsanız, sağlayıcı bir alanı yeniden adlandırdığında beş yeri birden düzeltmeniz gerekir. Workflow Builder'ın Alt Akış Çağırma adımı ortak eşleme adımlarını tek akışta toplayıp diğerlerinden çağırmanıza izin verir; döngü ve derinlik koruması da bu zincirin kendi kendini çağırmasını engeller.

Gönderenin gerçekten o sistem olduğunu nasıl bilirsiniz?

Bir webhook uç noktası internete açıktır. Adresi tahmin edilmesi zor olabilir ama gizli değildir: bir kere sızdığında, o adrese istek gönderen herkes sizin CRM'inizde akış başlatabilir. Bu yüzden gövdenin içeriğine değil, isteğin taşıdığı imzaya bakılır. Sağlayıcı gövdeyi paylaşılan bir sırla imzalar, siz aynı hesabı tekrarlar ve sonuç tutmuyorsa isteği hiç işlemezsiniz.

İmzanın yanına iki şey daha eklenir: zaman damgası kontrolü ve olay kimliği. Zaman damgası, bir saldırganın daha önce yakaladığı geçerli isteği aylar sonra tekrar göndermesini engeller; dar bir pencerenin dışındaki her istek reddedilir. Bu mekanizmanın ayrıntılarını imza doğrulama ve tekrar saldırısını önleme yazısında ayrı ayrı ele almıştık.

Üçüncü katman yetkidir. İmza isteğin kimden geldiğini söyler, ne yapabileceğini söylemez. Ödeme sağlayıcısından gelen bir olayın satış hunisinde aşama değiştirmesi mantıklıdır; aynı olayın kullanıcı silmesi mantıklı değildir. Akışın yapabileceklerini olayın kaynağına göre daraltmak, bir sırrın sızması durumunda hasarı sınırlar.

Aynı olay iki kez geldiğinde ne olmalı?

Tekrar bir arıza değil, normal işleyişin parçasıdır. Sağlayıcı yanıtınızı zamanında alamazsa isteği yeniden gönderir; ağ kesintisi, yeniden başlatma ya da sizin tarafınızdaki yavaşlık aynı olayın iki, bazen üç kez düşmesine yol açar. Akış bunu hesaba katmıyorsa müşteri aynı mesajı iki kez alır, aynı görev iki kez açılır, aynı fırsat ikiye bölünür.

Çözüm, olayın kendi kimliğini kullanmaktır. Sağlayıcının gönderdiği benzersiz olay numarasını CRM tarafında saklarsınız; akışın ilk koşulu "bu numara daha önce işlendi mi" sorusudur ve yanıt evetse akış hiçbir şey yapmadan biter. Numara gelmiyorsa kayıt kimliği ile olay tipini ve dakikaya yuvarlanmış zaman damgasını birleştirerek kendi anahtarınızı üretirsiniz.

Bu kontrol, tekrarlayan işi tetikleyicilere devretmenin ön koşuludur; aksi halde otomasyon tasarruf ettiği zamanı temizlik yaparak geri harcar. Görev tarafındaki karşılığını tekrarlayan işi kodsuz tetikleyicilerle kaldırmak yazısında somutlaştırmıştık: aynı görev iki kez açıldığında temsilci otomasyona güvenmeyi bırakır ve el yordamına döner.

Akış ortasında bir adım hata verirse kim toparlar?

Webhook'la başlayan bir akış, dış dünyaya bağımlı olduğu için hata alma olasılığı en yüksek akış tipidir. Mesaj sağlayıcısı yanıt vermez, bir alan beklenmedik biçimde boş gelir, karşı servis geçici olarak kapanır. Önemli olan hatanın olmaması değil, hatanın görünür olması ve toparlanabilmesidir.

Workflow Builder'ın Çalıştırma Geçmişi ve Yeniden Deneme özelliği her koşunun kaydını tutar; hata alan çalıştırmaları tek tek değil toplu olarak yeniden denersiniz. Bu, sağlayıcı tarafında yarım saat süren bir kesintiden sonra kırk çalıştırmayı elle açmak yerine tek işlemle kurtarmak demektir. Yarıda kalmış koşular da sistemde birikmez: Takılan Akışları Temizleme onları tespit edip süpürür, böylece geçmiş listesi gerçekten bakılabilir bir yer olarak kalır.

Yeniden deneme her hata için doğru yanıt değildir. Geçici bir ağ hatası tekrar denemeyi hak eder; "bu müşteri sistemde yok" hatası denemekle düzelmez, birinin bakması gerekir. İkinci grubu insana taşımanın düzenini SLA aşılmadan doğru kişiye ileten yükseltme kurguları içinde tarif etmiştik; aynı mantık teknik hatalar için de geçerlidir.

Akışı yayına almadan nasıl denersiniz?

Webhook akışlarının sinsi tarafı, ilk gerçek koşunun aynı zamanda ilk testiniz olmasıdır. Gerçek bir müşteri, gerçek bir mesaj, geri alınamayan bir gönderim. Bunu kırmanın yolu, akışı örnek bir gövdeyle baştan sona yürütmektir.

Kuru Çalıştırma Testi tam bunun için vardır: örnek veriyle akışı adım adım gösterir, hangi koşulun hangi kola gittiğini yazar ve gerçek e-posta, WhatsApp ya da SMS göndermez. Test gövdesini uydurmayın; sağlayıcının belgelerindeki örneği ya da daha iyisi, gerçek bir isteğin kaydını kullanın. İkisi arasındaki küçük farklar genellikle sorunun ta kendisidir.

Yayına aldıktan sonra da geri dönüş kapısı açık kalmalıdır. Her kayıt bir sürüm olarak saklandığı için, bozulan akışı tek tıkla eski sürüme döndürebilirsiniz; geri alma öncesindeki mevcut hali de saklanır, yani düzeltmeye çalışırken elinizdeki tek çalışan kopyayı kaybetmezsiniz. Bu güvenlik ağı, canlı bir akışa dokunma cesaretini belirleyen şeydir.

Ani bir webhook yığını geldiğinde müşteri bunu hisseder mi?

Dış sistemler toplu iş yapar. Gece çalışan bir tahsilat turu, bir içe aktarma ya da sağlayıcı tarafındaki bir kesinti sonrası birikmiş kuyruğun boşalması, birkaç dakika içinde yüzlerce isteğin düşmesi anlamına gelir. Akış her isteğe sadakatle uyarsa aynı kişi arka arkaya üç mesaj alır ya da bir temsilcinin listesine kırk görev birden düşer.

Hız ve Mesai Sınırları bu yığını yumuşatır: saat, gün veya hafta başına çalıştırma tavanı koyarsınız, kişi bazlı bir sınır tanımlarsınız, adımlar arasına bekleme eklersiniz ve mesai penceresi dışındaki gönderimleri sabaha bırakırsınız. Gece 03:40'ta düşen bir tahsilat hatası CRM'e o an girer ama müşteriye giden mesaj 09:00'ı bekler. Aynı pencere mantığını, hatırlatmaların hangi saatte gideceğine karar verirken de kullanırsınız.

Bir de yanıt gelince duran akışlar var: kişi cevap verdiğinde ya da lead kapandığında bekleyen adımlar iptal olur. Otomatik dizilerin bu tür frenlerle nasıl dengelendiğini tetiklenen akışlarla ölçekli kişiselleştirme yazısında ayrıntılandırmıştık; webhook kaynaklı akışlarda bu frenler daha da kritiktir, çünkü tetikleyicinin hacmini siz kontrol etmiyorsunuz.

Otomasyon nerede durup insanı çağırmalı?

Webhook kurulumu olgunlaştıkça akışlar uzar ve bir noktada dışarıdan gelen bir istek, ciddi sonuçları olan bir adımı tetikler hale gelir: hesabı askıya almak, sözleşmeyi iptal olarak işaretlemek, iade başlatmak. Bu adımların otomatik olması gerekmez; hızlı olması yeter.

Onay Bekle adımı akışı riskli adımdan önce durdurur, seçtiğiniz kişiye bildirim gider ve süre dolduğunda akış onaysız ilerlemez. Böylece bilgi saniyeler içinde CRM'e girer, karar ise insanda kalır. Nerede durmak gerektiğine dair ölçütleri otomasyonu nerede durdurup insanı bırakmalı yazısında tartışmıştık; webhook tarafında pratik kural şudur: geri alınamayan her adımın önünde bir insan olsun.

Kurulumun sağlığını gözden kaçırmamak için Otomatik Teşhis'i düzenli olarak açın. Kopuk bir adım, hiç tetiklenmemiş bir akış ya da bağlanmamış bir kanal genellikle sessiz arızalardır; kimse şikayet etmez, çünkü kimse beklenen şeyin olmadığını fark etmez. Hiç tetiklenmemiş bir webhook akışı, çoğu zaman karşı sistemde uç noktanın yanlış adrese yazıldığı anlamına gelir.

Kendi dış sisteminizden gelen bir olayla akış kurmayı denemek isterseniz Rocketly hesabınızı açıp ilk uç noktanızı birkaç dakikada tanımlayabilirsiniz.

Sıkça sorulan sorular

Webhook uç noktasını kim oluşturur, teknik ekip şart mı?

Uç nokta CRM tarafında akışı kurarken üretilir; Çoklu Tetikleyici seçenekleri arasından webhook seçildiğinde adres hazır gelir. Teknik destek genellikle karşı sistemde gerekir: o adresi hangi olay tipine bağlayacağınız ve imza sırrını nereye yazacağınız sağlayıcının paneline bağlıdır.

Karşı sistem imza desteklemiyorsa ne yapmalı?

İki telafi yöntemi var. Uç nokta adresine tahmin edilmesi zor bir bileşen koyarsınız ve gövdedeki verinin CRM'deki mevcut kayıtla tutarlı olmasını şart koşarsınız. Bu ikisi imzanın yerini tam olarak tutmaz; bu yüzden imzasız kaynaklardan gelen olaylara geri alınamayan adımlar bağlamamak daha doğrudur.

Bir webhook birden fazla akışı tetikleyebilir mi?

Evet, ama önerilen kurgu tek bir giriş akışı ve onun içinden çağrılan alt akışlardır. Aynı uç noktaya bağlı üç bağımsız akış, hangisinin hangi sırayla çalıştığını takip edilemez hale getirir; tek giriş noktası ise koşulu bir kez değerlendirip işi doğru alt akışa devreder.

Gelen olay CRM'de karşılığı olmayan birine aitse ne olur?

Bunu baştan karara bağlayın. İki geçerli yol var: eksik kaydı olayın gövdesindeki bilgilerle oluşturup akışa devam etmek ya da akışı durdurup bir inceleme görevi açmak. Yanlış olan üçüncü yol, akışın sessizce hiçbir şey yapmadan sonlanmasıdır; o olay bir daha gelmez ve kimse eksiği fark etmez.