Poliçe ve Yenileme

Yenileme Otomasyonunda Tetikleyici, Kural ve Aksiyon Tasarımı

InsureHub Ekibi
11 Eylül 2026

Yenileme otomasyonu denince akla genellikle "bitişe şu kadar gün kala hatırlatma gönder" gibi tek bir kural gelir. Bu kural faydalıdır ama bir otomasyon sistemi değildir. Gerçek ihtiyaç, farklı durumlara farklı tepki veren, bakımı yapılabilen ve ekibin güvenebileceği bir yapı kurmaktır. Bu yazı, yenileme otomasyonunu üç katmanda ele alır: tetikleyici, kural ve aksiyon. Amaç, hangi hatırlatmanın ne zaman gideceğini anlatmak değil, otomasyonu nasıl tasarlayacağınızı göstermektir.

Üç katmanlı düşünmek

Her otomasyon üç soruya cevap verir:

  • Tetikleyici: Otomasyon ne zaman çalışmaya başlar?
  • Kural (koşul): Hangi kayıtlar için ve hangi şartlar altında devam eder?
  • Aksiyon: Ne yapılır?

Bu ayrım, otomasyonların karmaşıklaştıkça yönetilebilir kalmasını sağlar. Bir aksiyonu değiştirmek tetikleyiciyi bozmaz; bir koşulu daraltmak aksiyonları yeniden yazmayı gerektirmez.

Tetikleyiciler: Zaman, olay ve durum

Zamana bağlı tetikleyiciler

En bilinen tetikleyici türüdür. Bitiş tarihine belirli bir süre kalması, belirli bir günün gelmesi veya bir görevin belirli süre açık kalması bu gruba girer. Zamana bağlı tetikleyicilerin düzenli aralıklarla çalışan bir kontrol mekanizmasıyla işletilmesi gerekir.

Olaya bağlı tetikleyiciler

Bir kaydın oluşturulması veya değişmesiyle çalışır. Yeni bir poliçe kaydedildiğinde, bir zeyil işlendiğinde veya bir teklif müşteri tarafından reddedildiğinde tetiklenen otomasyonlar bu türdendir. Olay tetikleyicileri, zamanlı kontrolleri beklemeden anında tepki verilmesini sağlar.

Duruma bağlı tetikleyiciler

Bir kaydın belirli bir durumda kalmasına bağlıdır. Örneğin yenileme görevi "müşteriye ulaşılamadı" durumunda belirli bir süre beklerse yöneticiye bildirim gitmesi bu türe örnektir.

Kurallar: Kapsamı doğru daraltmak

Kurallar, otomasyonun hangi kayıtlara uygulanacağını belirler. İyi tasarlanmış kurallar otomasyonun gereksiz yere çalışmasını önler. Yenileme otomasyonlarında sık kullanılan koşullar şunlardır:

  • Poliçe durumu yürürlükte mi?
  • Poliçeye bağlı bir yenileme kaydı zaten oluşturuldu mu?
  • Branş nedir? Trafik, kasko ve DASK için ayrı kural setleri gerekebilir.
  • Müşteri iletişim izni var mı ve hangi kanal için?
  • Sorumlu kullanıcı atanmış mı?
  • Müşteri kurumsal mı, bireysel mi?

İkinci koşul özellikle önemlidir. Zaten yenilenmiş bir poliçe için hatırlatma gönderilmesi, hem müşteri hem ekip açısından güveni zedeler. Bu nedenle her yenileme otomasyonunun ilk koşulu "bu iş zaten yapılmış mı?" sorusu olmalıdır.

Aksiyonlar: İç ve dış olarak ayırmak

Aksiyonları iki gruba ayırmak tasarımı netleştirir:

İç aksiyonlar

  • Sorumlu kullanıcıya görev oluşturmak
  • Yöneticiye bildirim göndermek
  • Kaydın durumunu güncellemek
  • Kayda etiket eklemek

Dış aksiyonlar

  • Müşteriye hatırlatma mesajı göndermek
  • Müşteriye bilgilendirme e-postası iletmek

Dış aksiyonlar müşteriye dokunduğu için daha sıkı koşullara bağlanmalıdır. İletişim izni, doğru taraf seçimi ve gönderim saatleri gibi konular dış aksiyonların tasarımında öncelikli olarak ele alınmalıdır. Başlangıçta yalnızca iç aksiyonlarla çalışmak ve dış aksiyonları ekip otomasyona güvendikten sonra devreye almak daha güvenli bir yoldur.

Çakışmaları ve tekrarları önlemek

Otomasyon sayısı arttıkça aynı kayıt için birden fazla kuralın çalışması ihtimali doğar. Bir poliçe için hem "bitişe yaklaşıyor" hem "görev açık kaldı" otomasyonu aynı gün bildirim üretebilir. Bunu önlemek için:

  1. Her otomasyonun aynı kayıt için kaç kez çalışabileceğini sınırlayın.
  2. Otomasyonlara öncelik sırası verin; yüksek öncelikli olan çalıştığında düşük öncelikliyi atlayın.
  3. Her çalışmayı kaydın geçmişine yazın; böylece hangi otomasyonun ne yaptığı izlenebilir.

Test ve devreye alma

Bir otomasyonu doğrudan tüm portföyde çalıştırmak risklidir. Yeni bir kural önce sınırlı bir kayıt grubu üzerinde, yalnızca iç aksiyonlarla denenmelidir. Bu aşamada "bu kural bugün çalışsaydı hangi kayıtları etkilerdi?" sorusuna cevap veren bir önizleme, hataları devreye almadan önce yakalamayı sağlar. Önizlemede beklenmedik kayıtlar görünüyorsa, koşulların gözden geçirilmesi gerekir.

Bakım: Otomasyonlar da eskir

Ekip yapısı değişir, yeni branşlar eklenir, iletişim tercihleri farklılaşır. Bir yıl önce kurulan bir otomasyon bugün gereksiz veya hatalı olabilir. Otomasyonlar için basit bir bakım rutini oluşturmak önerilir:

  • Her otomasyonun bir sahibi olsun.
  • Belirli aralıklarla hangi otomasyonların ne sıklıkla çalıştığı gözden geçirilsin.
  • Hiç çalışmayan veya sürekli iptal edilen otomasyonlar sorgulansın.
  • Kural değişiklikleri tarih ve gerekçeyle kayıt altına alınsın.

Örnek bir otomasyon tasarımı

Katmanların birlikte nasıl çalıştığını görmek için basit bir senaryo düşünelim. Amaç, kasko poliçesi bitişine yaklaşan bireysel müşteriler için sorumlu kullanıcıya hazırlık görevi açmaktır.

  • Tetikleyici: Günlük zamanlı kontrol; bitiş tarihi belirlenen hazırlık penceresine giren poliçeler.
  • Koşullar: Branş kasko, durum yürürlükte, müşteri bireysel, bağlı yenileme kaydı yok, sorumlu kullanıcı atanmış.
  • Aksiyonlar: Sorumlu kullanıcıya önceki dönem teminat kontrolünü içeren bir görev açılır, kayda "yenileme hazırlığı" etiketi eklenir, işlem kaydın geçmişine yazılır.

Bu tasarımda müşteriye hiçbir mesaj gitmez; otomasyon yalnızca ekibin işini düzenler. Görev belirli bir süre açık kalırsa devreye giren ikinci bir otomasyon, duruma bağlı tetikleyiciyle yöneticiye bildirim gönderebilir. Böylece iki basit otomasyon, birbirine karışmadan bir süreç zinciri oluşturur.

Aynı mantıkla trafik ve DASK için ayrı otomasyonlar kurulabilir. Her branşın hazırlık adımları farklı olduğundan, tek bir genel otomasyon yerine branşa özgü kural setleri tercih edilmelidir. Bu ayrım, trafik, kasko ve DASK'ın teklif tarafında ayrı sorgu akışlarına sahip olmasıyla da uyumludur.

InsureHub bakış açısıyla

InsureHub, acentelere sunduğu yazılımda poliçe, müşteri ve görev kayıtlarını aynı veri yapısında tutmayı hedefler. Otomasyonların güvenilir çalışması bu bütünlüğe bağlıdır; çünkü her kural doğru durum, doğru sorumlu ve doğru iletişim bilgisine ihtiyaç duyar. Müşteri iletişim tercihleri ve görev akışlarının acente CRM içinde yer alması, kuralların bu bilgilerle çalışmasını mümkün kılar. Genel platform yapısını sigorta acentesi yazılımı sayfasında bulabilirsiniz.