Sigorta Müşteri Portali Yazılım Fiyatı ve TCO Analizi

Kısa cevap: Sigorta müşteri portali yazılımı için ödeyeceğiniz rakam, sadece lisans bedeli değil; entegrasyon, TSB uyumluluğu ve operasyonel değişim maliyetlerini içeren toplam sahip olma maliyeti (TCO) olarak değerlendirilmelidir. Küçük-orta ölçekli sigorta şirketleri için piyasadaki hazır SaaS çözümlerinin aylık abonelik bedeli 1.500 TL ile 4.000 TL aralığında başlasa da, poliçe motorunuzla tam entegrasyon ve KVKK uyum süreçleri eklendiğinde ilk yıl maliyeti 50.000 TL ile 120.000 TL bandına çıkabilir. Bu nedenle tekil bir "aylık fiyat" sorusundan ziyade, 3 yıllık TCO simülasyonu üzerinden karar vermek, bütçenizi korumanın en sağlıklı yoludur.

Geçen ay, 500'den fazla acente temsilcisi işletmenizdeki müşteri şikayetlerine baktığınızda, 'hasar ihbarı' ve 'prim sorgulama' taleplerinin %70'inin aslında otomasyonla çözülebilecek basit veriler olduğunu fark ettiniz. Soru şu: Bu basit verileri insan gücüyle işlemeye devam etmenin aylık maliyeti, size sunulmuş o 'ucuz' yazılım paketinin fiyatından kaç kat fazla?

Gizli Maliyet Tuzağı: Neden Fiyat Listesi Size Yeterli Değil?

Piyasada "aylık 990 TL'den başlayan sigorta portali" gibi başlıklar cazip görünse de, bu rakamlar genellikle sadece temel erişim katmanını (login, profil görüntüleme) kapsar. Sigorta sektöründe gerçek maliyet, müşterinin sistemle etkileşime geçtiği an başlar. Bir poliçe sorgusu yaparken arka planda poliçe motorunuzla (core system) kurulan API hattı, veri dönüşüm katmanları ve hata yönetimi mekanizmaları, standart bir e-ticaret sitesinin kat be kat daha yüksek bir mühendislik gerektirir. Birçok sigorta şirketi, yazılım tedarikçisinden gelen ilk teklif mektubundaki rakamlara odaklanıp, "entegrasyon ücreti" satırını küçük puntolarla veya "ayrıca faturalanacaktır" notuyla görmezden gelir. Oysa sigorta poliçe motorları (örneğin Amalya, Sigortam.net altyapıları veya yerli/yerel core sistemler) standart REST API'ler sunmaz; çoğu durumda özel protokol veya middleware gerektirir. Bu entegrasyon aşaması, projenin toplam maliyetinin %30-40'ını oluşturabilir. 10.000 TL'lik bir aylık lisans bedeli, 30.000-40.000 TL'lik bir entegrasyon geliştirme maliyeti ile birlikte geldiğinde, aslında satın aldığınız şey "yazılım" değil, "yazılım + mühendislik emeği" paketi olur. Dikkat etmeniz gereken diğer bir gizli maliyet kalemi de "kullanıcı limiti" ve "veri saklama kapasitesidir." Sigorta şirketlerinde poliçe geçmişi uzun yıllara yayılır. 5 yıllık poliçe arşivini portala taşımak, standart SaaS paketlerinde ek depolama ücreti tetikleyebilir. Ayrıca, acente temsilcileri ve sigorta eksperleri de bu portalı kullandığında, "son kullanıcı" tanımı genişler. 50 acente temsilcisi için ek lisans ücreti talep edilip edilmediğini teklif aşamasında netleştirmelisiniz; aksi halde operasyon büyüdükçe maliyetler lineer olarak artar.

Doğru Eşik: Ne Zaman Altyapıyı Kendi İmkanınızla Kurmak Daha Ucuz?

"Her şeyi kendimiz yapalım" yaklaşımı, sigorta sektöründe genellikle bir yanılgıdır. Ancak belirli eşik değerlerde, dışarıdan hazır paket almak yerine mevcut IT ekibinizle veya freelance geliştiricilerle özelleştirme yapmak daha rasyonel olabilir. Bu eşik, şirketinizin aylık işlem hacmi ve mevcut altyapısının esnekliğine bağlıdır. Eğer şirketiniz ayda 1.000'den az poliçe işlemi yapıyorsa ve müşteri kitleniz büyük ölçüde B2B (kurumsal) müşterilerden oluşuyorsa, karmaşık bir self-servis portalına yatırım yapmak yerine, mevcut CRM sisteminize basit bir "müşteri bildirim modülü" eklemek daha verimli olabilir. Kurumsal müşterileriniz genellikle hasar ihbarını telefonla veya e-posta ile yapmak ister; onlar için karmaşık bir arayüz sunmaktansa, e-posta üzerinden otomatik prim dökümü ve hasar durumu raporu göndermek, maliyeti %80 azaltır. Bu senaryoda, aylık 500-1.000 TL'lik bir e-posta otomasyon servisi ve mevcut CRM'inize yapılacak küçük bir API entegrasyonu, yıllık 50.000 TL'lik bir portal aboneliğinden daha ucuz ve hızlıdır. Ancak, aylık işlem hacminiz 5.000'in üzerindeyse ve bireysel (B2C) müşteri kitleniz genişliyorsa, durum değişir. Bireysel müşterilerin "primim ne zaman düştü?", "hasar dosyam nerede?" gibi tekrarlayan soruları, çağrı merkezinizi boğar. Bu noktada, kendi imkanınızla portal yazmak, sürekli artan destek taleplerini karşılamaktan daha pahalıya mal olur. Kendi yazılımınızı geliştirme maliyeti (geliştirici maaşları, test süreçleri, güvenlik denetimleri) ve bu yazılımı 7/24 ayakta tutma maliyeti, hazır SaaS çözümlerinin yıllık maliyetini 18-24 ay içinde aşar. Karar verirken şu basit formülü kullanabilirsiniz:

• Aylık Otomatik Çözülebilecek Talep Sayısı x Ortalama İşlem Maliyeti = Portala Geçiş Eşiği.
• Ortalama bir çağrı merkezi operatörünün bir hasar sorgusu için harcadığı süre 4-6 dakika ise ve saatlik maliyeti (SGK dahil) 250 TL civarındaysa, her otomatik çözülen talepte 15-20 TL tasarruf edersiniz.
• Aylık 1.000 otomatik talep çözerse, yıllık 180.000-240.000 TL tasarruf potansiyeli doğar. Bu rakam, orta segment bir sigorta portalının 3 yıllık TCO'sundan (yaklaşık 100.000-150.000 TL) fazlaysa, dış kaynaklı çözüme geçmek finansal olarak mantıklıdır.

Entegrasyon Gerçeği: Poliçe Motorunuza Dokunmadan Bağlanmak Mümkün mü?

Sigorta teknolojisinin en kritik sorusu şudur: Müşteri portalı, poliçe verilerini "gerçek zamanlı" mı okur, yoksa "gecikmeli" mi? Çoğu hazır SaaS çözümü, poliçe motorunuzla doğrudan canlı bağlantı kurmak yerine, günlük veya saatlik veri aktarımı (batch processing) kullanır. Bu, maliyeti düşürür ama müşteri deneyimini ciddi şekilde etkiler. Müşteri, sabah 09:00'da primini ödediğinde, portal 09:05'te "ödeme alındı" demez; "sistem güncelleniyor, lütfen bekleyin" der. Bu gecikme, özellikle hasar ihbarı anında kriz yaratır. Müşteri, kaza anında hasar bildirimi yapmak isterken, sistemde poliçesinin "aktif" görünmemesi veya güncel prim borcunun görülmemesi, güven kaybına ve şikayete dönüşür. Gerçek zamanlı entegrasyon (real-time API), poliçe motorunuzun güncel veri tabanına doğrudan sorgu atmayı gerektirir. Bu durum, sigorta şirketleri için ekstra maliyet kalemleri doğurur:

• API Lisans Ücretleri: Bazı core sistem tedarikçileri, dışarıdan gelen her API çağrısı için ek ücret talep edebilir veya API kullanım haklarını kısıtlar. Bu, aylık 500-2.000 TL arasında değişen ek bir lisans bedeli anlamına gelebilir.
• Güvenlik ve Kimlik Doğrulama: Gerçek zamanlı bağlantı, OAuth2 veya JWT gibi standartları gerektirir. Bu güvenlik katmanlarının kurulumu ve test edilmesi, entegrasyon maliyetini artırır.
• Veri Tutarlılık Sorunları: Poliçe motorunuzda bir düzeltme yapıldığında (örneğin adres değişikliği), portalın bu değişikliği anında yansıtması gerekir. Aksi halde, müşteri eski adresine ait bir rapor indirdiğinde, sigorta şirketi "yanlış veri" sorunuyla karşı karşıya kalır.

Peki, poliçe motorunuza "dokunmadan" bağlanmak mümkün mü? Teknik olarak evet, ama kısıtlıdır. Eğer poliçe motorunuzun veritabanına doğrudan erişim (read-only) izniniz varsa, bir "veri katmanı" (data layer) yazarak bu verileri portala aktarabilirsiniz. Bu yöntem, poliçe motorunun performansını etkilemez ve en düşük maliyetli entegrasyon yoludur. Ancak, poliçe motorunuzun veritabanı şeması karmaşık ve dokümantasyonu yetersizse, bu "dokunmadan" bağlantı, aslında en çok hata veren ve en pahalı bakım gerektiren yapı haline gelebilir. Önerimiz, entegrasyon stratejisini belirlerken şu üç senaryoyu maliyet ve risk açısından karşılaştırmanızdır:

• Senaryo A: Doğrudan Veritabanı Erişimi (Read-Only): En düşük kurulum maliyeti, orta düzey risk (veritabanı yapısı değişirse kırılma), düşük aylık bakım maliyeti.

Kısa cevap: Sigorta müşteri portali yazılım fiyatı, sadece lisans bedelinden ibaret değildir; asıl maliyet, mevcut poliçe motorunuzla entegrasyon süresi ve operasyonel verimlilik kaybıdır. Küçük-orta ölçekli sigortacılar için hazır SaaS çözümleri başlangıçta ucuz görünse de, özelleştirme gereksinimleri arttıkça toplam sahip olma maliyeti (TCO), mevcut sektörel altyapıya ek modül geliştirilmesinin üzerine çıkabilir. Doğru karar, çağrı merkezinizin "prim sorgulama" ve "hasar durumu" gibi tekrarlayan taleplerdeki dakikalarını ölçerek, bu dakikaların maliyetini yazılım yatırımına karşı koymaktan geçer.

ROI Hesabı: Çağrı Merkezi Dakikalarını Portale Nasıl Dönüştürürsünüz?

Sigorta sektöründe müşteri deneyiminin en kritik kırılma noktası, operasyonel yükün dağılımıdır. Birçok sigorta şirketi, yazılım yatırımını "müşteri memnuniyeti artıracak" soyut bir iyileştirme olarak görür. Oysa finansal gerçeklik çok daha somuttur: Çağrı merkezindeki her dakikanın bir maliyeti vardır ve bu maliyet, portalın sunduğu self-servis özellikleri ile doğrudan orantılı olarak düşer. Bir sigorta acentesi temsilcisinin veya çağrı merkezi operatörünün ortalama iş gücü maliyeti (SGK dahil) saat bazında yaklaşık 150-250 TL aralığında seyreder. Bir "prim sorgulama" veya "polise ekleme" işlemi ortalama 3-5 dakika sürüyorsa, tek bir çağrının maliyeti 75-125 TL civarındadır. Günde 500 gelen çağrının %40'ı bu tip basit sorgularlarsa, günlük sadece bu işlemlere harcanan 3.000-5.000 TL, aylık bazda 90.000-150.000 TL'lik bir "görünmez" maliyete dönüşür.

Self-servis portalın ROI (yatırım getirisi) hesabı, tam olarak bu kayıp dakikaların kurtarılmasına dayanır. Ancak burada kritik bir eşik değeri vardır: Portal, ancak müşterinin %30-40'ının bu işlemleri kendisi yapmaya istekli olduğu senaryoda etkili olur. Eğer arayüz karmaşıksa veya güven vermiyorsa, müşteri yine arar. Bu nedenle, "kaç çağrı azaldı" yerine "kaç işlem dijital kanaldan tamamlandı" metriği izlenmelidir. Bir orta ölçekli sigorta şirketi için, aylık 10.000 dijital işlem hacmi hedefi, yılda yaklaşık 1.2 milyon TL tasarruf potansiyeli demektir (işlem başına ortalama 100 TL maliyet varsayımıyla). Bu rakam, yıllık 150.000-300.000 TL aralığında bir yazılım lisans ve bakım maliyetinin 3-4 yıl içinde kendini amorti etmesini sağlar. Ancak bu hesaplama, entegrasyonun sorunsuz çalıştığı ve sistemin 7/24 erişilebilir olduğu varsayımına dayanır.

Çağrı Merkezi Yükünü Azaltan Kritik Eşikler

• Düşük Eşik (Aylık 5.000 altı işlem): Eğer dijital kanal hacminiz bu seviyede kalıyorsa, dışarıdan hazır bir SaaS almanın maliyeti, kendi iç kaynaklarınızla basit bir şifreli sorgulama sayfası geliştirmenin maliyetinin üzerine çıkabilir. Bu durumda, mevcut CRM'inize basit bir "sorgu" modülü eklemek daha rasyoneldir.
• Orta Eşik (Aylık 5.000 - 50.000 işlem): Bu aralık, özelleştirilmiş SaaS veya hibrit çözümlerin en verimli olduğu bölgedir. Çağrı merkezi operatörleri artık sadece hasar ihbarı, itiraz ve yeni poliçe satışı gibi karmaşık işlemlerle uğraşır. Basit sorgular otomasyona devredilir.
• Yüksek Eşik (Aylık 50.000+ işlem): Bu hacimde, hazır SaaS'ların ölçeklendirme limitlerine takılma riski artar. Kendi sunucunuzda barındırılan (on-premise) veya özel bulut altyapısında kurulan çözümler, veri transferi ve performans optimizasyonu açısından daha düşük bir birim maliyet sunar.

Özellik vs. Zorunluluk: Hangi Modüller İçin Gerçekten Para Ödemelisiniz?

Yazılım tekliflerini incelediğinizde, sayfalarca özellik listesiyle karşılaşırsınız: "Yapay zeka destekli hasar öngörüsü", "Blockchain tabanlı poliçe sertifikası", "Sesli asistan entegrasyonu". Bir karar verici olarak, bu özelliklerin hangilerinin "zorunlu" (regülasyon veya operasyonel hayatta kalma gereği) ve hangilerinin "lüks" (pazarlama amaçlı) olduğunu ayırt etmeniz gerekir. Sigorta sektöründe, TSB (Türkiye Sigorta Birliği) standartları ve KVKK (Kişisel Verilerin Korunması Kanunu) uyumluluğu, pazarlanabilen bir özellik değil, yasal bir zorunluluktur. Bu iki başlıkta eksiklik, yazılımın ne kadar "akıllı" olursa olsun, sizi hukuki riskle karşı karşıya bırakır.

Bir sigorta müşteri portalının temel mimarisini üç katmana ayırabiliriz: Zorunlu Çekirdek, Operasyonel Geliştirme ve Pazarlama Katmanı. Zorunlu çekirdek; kimlik doğrulama (SMS/e-Devlet), poliçe listeleme, prim ödeme (havale/EFT/credit card), hasar dosyası oluşturma ve takip modülleridir. Bu modüller olmadan portal, bir "broşür sitesinden" farksızdır ve müşteri güveni kazanılamaz. Operasyonel geliştirme katmanı ise; poliçe iptali/geri alma, teminat değişikliği, acente portalı senkronizasyonu gibi süreçleri içerir. Pazarlama katmanı ise; sadakat programları, anketler, kişiselleştirilmiş teklif motorları gibi unsurlardır. Pek çok şirket, pazarlama katmanına ödediği parayı operasyonel katmandan keserek, asıl acı çektikleri noktayı (karmaşık süreçler) çözmemiş olur.

Sigorta Portali TCO Karşılaştırma Tablosu

Aşağıdaki tablo, farklı mimari yaklaşımların 3 yıllık toplam sahip olma maliyetlerini (TCO) ve gizli maliyet risklerini karşılaştırmaktadır. Rakamlar, piyasa ortalamalarına dayalı tahmini aralıklardır ve projenin kapsamına, mevcut altyapının durumuna ve entegrasyon karmaşıklığına göre değişkenlik gösterir.

Kısa cevap: Sigorta müşteri portalı projelerinde en büyük sürpriz, sözleşme imzalandıktan sonraki 6-12 ay içinde ortaya çıkan 'gizli' operasyonel maliyetlerdir. KVKK uyumu, sunucu altyapısı (hosting) ve kesintisiz destek talepleri, başlangıç lisans ücretinin %30 ile %50'si arasında ek bir bütçe gerektirebilir. Bu bölümde, bu kalemlerin neden 'sebebiyet' olarak sınıflandırıldığını ve 3 yıllık TCO (Toplam Sahip Olma Maliyeti) tablosunda nerede yer alması gerektiğini somut rakamlarla ele alacağız.

Gizlenmiş Maliyetler: KVKK, Hosting ve 7/24 Destek Gerçeği

Sigorta sektöründe müşteri verisi, KVKK (Kişisel Verilerin Korunması Kanunu) kapsamında "özel nitelikli veri" olarak sınıflandırılır. Poliçe detayları, hasar kayıtları ve iletişim bilgileri, standart e-ticaret verilerinden çok daha yüksek bir güvenlik ve izleme standardı gerektirir. Birçok yazılım tedarikçisi, teklif aşamasında "KVKK uyumlu altyapı" ifadesini kullanır ancak bu ifadenin arkasındaki teknik detayları genellikle gizler. KVKK Uyum Maliyetinin Anatomisi KVKK uyumlu bir portal için sadece kod yazmak yetmez; veri akışını izleyen, yetkilendirmeyi (authorization) yöneten ve logları en az 6 yıl saklayan bir altyapı kurmanız gerekir. Eğer mevcut poliçe yönetim sisteminiz (PMS) ile portal arasındaki entegrasyonda veri maskeleme (masking) yapılmıyorsa, her API çağrısında hassas veriler açıkta dolaşır. Bu durumda, KVKK denetimlerinde karşılaştığınız risk, sadece idari para cezası değil, operasyonel duruş riskidir.

• Veri İşleme Anlaşması (DİA) ve Teknik Altyapı: Portal sağlayıcınızla imzalanacak DİA'nın teknik ekleri, veri saklama süresini, yedekleme sıklığını ve veri silme prosedürlerini netleştirmelidir. Bu sürecin hukuki ve teknik danışmanlık maliyeti, küçük ölçekli sigortacılar için genellikle 50.000 TL ile 150.000 TL aralığında seyreder.
• Loglama ve İzlenebilirlik: Her müşteri işlemi (prim sorgulama, poliçe indirme, hasar bildirimi) kim tarafından, ne zaman ve hangi IP adresinden yapıldıysa, bu logların merkezi bir sistemde toplanması zorunludur. Bu loglama altyapısının aylık maliyeti, veri hacmine bağlı olarak değişmekle birlikte, ortalama 3.000 TL - 8.000 TL aralığındadır.

Hosting ve Sunucu Gerçeği: "Yeterli" mi, "Yeterli mi?" Sigorta portalları, özellikle hasar sezonu veya poliçe yenileme dönemlerinde ani trafik sıçramaları yaşar. Standart "paylaşımlı hosting" veya düşük konfigürlü VPS (Sanal Özel Sunucu) çözümleri, bu yük altında çöker. Çökme süresi her 1 saat, çağrı merkezine binlerce aramayı yönlendirir.

• Yük Dengeleyici (Load Balancer) ve Otomatik Ölçeklendirme: TSB (Türkiye Sigorta Birliği) uyumlu çözümlerde, sistemlerin 7/24 erişilebilir olması beklenir. Bu, basit bir sunucu kiralama değil; otomatik ölçeklenme (auto-scaling) yeteneğine sahip bulut altyapıları (AWS, Azure veya yerli bulut sağlayıcılar) gerektirir.
• Maliyet Aralığı: Aylık 10.000 TL - 25.000 TL aralığında bir bulut altyapı maliyeti, orta ölçekli bir sigorta şirketi için normaldir. Bu rakam, trafik arttıkça dinamik olarak değişebilir. Ancak "sabit fiyat" vaat eden tedarikçilerde, bu artışlar genellikle "ek kaynak tahsisi" adı altında aylık faturaya yansır.

7/24 Destek: Sözleşmede Yazmayan Saatler Sigorta müşterisi, saat 03:00'te araba çarpışması yaşadıysa, portalın "bakımdayız" mesajı göstermesini kabul etmez. 7/24 teknik destek, "telefonu açma" garantisi değil, "sorunu 4 saat içinde çözme" SLA'sı (Service Level Agreement) demektir.

• SLA Cezaları ve Ücretleri: Standart destek paketleri genellikle "iş saatleri içinde" hizmet verir. 7/24 kesintisiz destek için ek ücret ödersiniz. Bu ek ücret, temel lisans bedelinin %15'i ile %40'ı arasında olabilir.
• Gizli Maliyet Notu: Destek ekibinin, sigorta sektörüne özel terminoloji ve PMS entegrasyonlarına hâkim olması gerekir. Genel amaçlı IT destek firmaları, poliçe motoru ile ilgili bir hatayı teşhis edemeyebilir. Bu durumda, sorun çözülene kadar geçen süre (MTTR - Mean Time to Repair), sizin operasyonel kaybınız olarak kalır.

Karar Çerçevesi: 3 Yıllık TCO (Toplam Sahip Olma Maliyeti) Simülasyonu

Sigorta müşteri portali yazılım fiyatı araştırırken, çoğu karar verici "aylık abonelik bedeli"ne odaklanır. Ancak 3 yıllık perspektife bakıldığında, en ucuz seçenek her zaman en az maliyetli olan değildir. Aşağıdaki tablo, Türkiye piyasasındaki (tahmini) aralıklara dayalı, üç farklı modelin 36 aylık toplam maliyetini karşılaştırmaktadır. Not: Aşağıdaki rakamlar, orta ölçekli (5.000-50.000 aktif poliçeli) bir sigorta şirketi için piyasa ortalamasıdır. Kurumsal ölçeklerde bu rakamlar katlanabilir.

Sigorta Portali TCO Karşılaştırma Tablosu (36 Aylık)

Tablo Yorumu ve Kritik Eşikler

• Model A (Hazır SaaS): Küçük ölçekli, acente ağı dar olan sigortacılar için en düşük giriş bariyerine sahiptir. Ancak, poliçe motorunuz standart API'ler sunmuyorsa, entegrasyon maliyeti beklenenden yüksek çıkar. Ayrıca, "marka uyumu" sınırlıdır; müşteriniz portala girdiğinde "özel" bir deneyim değil, "jenerik" bir panel görür.
• Model B (Özelleştirilmiş SaaS): En yüksek başlangıç maliyetine sahip olmakla birlikte, 3. yıldan itibaren bakım ve destek maliyetleri stabilize olur. Eğer dijital dönüşüm stratejiniz, müşteri sadakati ve yüksek LTV (Life Time Value) hedefine odaklıysa, bu model uzun vadede en riskli olmayan seçenektir.
• Model C (Mevcut Altyapıya Ekleme): En sık yapılan hata, "zaten poliçe sistemimiz var, üzerine ekletelim" düşüncesiyle bu modeli seçmektir. Ancak, mevcut PMS'nin API dokümantasyonu eksik veya eskiyse, entegrasyon maliyeti Model B'ye yaklaşabilir. Bu durumda, "ucuz" görünen seçenek, en pahalı ve uzun süren projeye dönüşebilir. Karar öncesi mevcut sisteminizin API olgunluğunu mutlaka teknik bir ekibe doğrulatın.