Bir kesinti yaşandığında teknik ekip sorunu çözmeye odaklanırken, kullanıcılar başka bir soruyla meşguldür: Ne oluyor ve ne zaman düzelecek? Bu soruya cevap verilmediğinde belirsizlik, kesintinin kendisinden daha fazla rahatsızlık yaratabilir. Acente çalışanları tekrar tekrar giriş yapmayı dener, destek hattı aynı soruyla dolar, müşterilere ise ne söyleneceği bilinmez.
Bu yazıda yazılım sağlayıcısı ile acente arasındaki kesinti iletişimini ve acentenin kendi ekibi ile müşterilerine yönelik iletişimini birlikte ele alıyor, her iki taraf için uygulanabilir bir çerçeve sunuyoruz.
İletişimin üç katmanı
Bir hizmet kesintisinde bilgi üç farklı kitleye, üç farklı ihtiyaçla ulaşmalıdır:
- Sağlayıcıdan acenteye: Sorunun kapsamı, etkilenen işlevler, tahmini süre ve geçici çözüm önerileri.
- Acente yöneticisinden ekibe: Hangi işlerin bekleyeceği, hangi işlerin alternatif yöntemlerle sürdürüleceği ve kimin neyi takip edeceği.
- Acenteden müşteriye: Müşterinin talebinin kayıt altında olduğu ve ne zaman geri dönüleceği.
Bu katmanlar birbirine bağlıdır. Sağlayıcıdan net bilgi gelmezse acente yöneticisi ekibine yön veremez; ekibe yön verilmezse müşteriye tutarlı bir mesaj iletilemez.
Sağlayıcı tarafında durum sayfası
Durum sayfası, bir hizmetin bileşenlerinin anlık durumunu ve yaşanan olayların gelişimini gösteren, ana sistemden bağımsız çalışan bir bilgilendirme sayfasıdır. Bağımsızlık kritik bir özelliktir: Ana sistem erişilemez olduğunda durum sayfası da erişilemez olursa, en çok ihtiyaç duyulduğu anda işe yaramaz.
İyi bir durum sayfasında şu özellikler bulunur:
- Bileşen bazında durum gösterimi; örneğin giriş, müşteri kayıtları, teklif akışları, belge üretimi ve mobil uygulama servisleri ayrı ayrı.
- Olay güncellemelerinin zaman damgasıyla yayınlanması: tespit, inceleme, çözüm çalışması, izleme ve çözüldü aşamaları.
- Planlı bakımların önceden duyurulması.
- E-posta ya da benzeri kanallarla abonelik imkânı.
- Geçmiş olayların arşivi.
Güncelleme mesajlarının içeriği
Kesinti mesajlarında en sık yapılan hata, ya hiçbir şey söylememek ya da teknik ayrıntıya boğulmaktır. Kullanıcının ihtiyaç duyduğu bilgi sınırlıdır ama nettir. Her güncellemede şu dört unsur yer almalıdır:
- Ne etkileniyor: "Kasko teklif akışında bazı şirketlerden sonuç alınamıyor" gibi somut bir ifade.
- Ne etkilenmiyor: "Müşteri kayıtları, trafik ve DASK teklifleri normal çalışıyor" bilgisi, kullanıcının işine devam edip edemeyeceğine karar vermesini sağlar.
- Ne yapılıyor: Sorunun incelendiği ya da çözüm uygulandığı bilgisi.
- Bir sonraki güncelleme ne zaman: Sorun çözülmemiş olsa bile belirli aralıklarla bilgi verileceğinin söylenmesi, belirsizliği azaltır.
Tahmini çözüm süresi verirken dikkatli olunmalıdır. Tutturulamayan bir süre güveni zedeler; emin olunmadığında "bir sonraki güncelleme saatini" paylaşmak daha doğrudur.
Acente içinde ekip bildirimi
Sağlayıcıdan gelen bilginin acente içinde hızla ve tutarlı biçimde dağıtılması, yöneticinin ya da önceden belirlenmiş bir iletişim sorumlusunun görevidir. Bunun için birkaç basit hazırlık yeterlidir:
- Ekibin tamamının bulunduğu, acente yazılımından bağımsız bir mesajlaşma grubu.
- Kesinti duyurusu için hazır bir kısa mesaj şablonu.
- Hangi işlerin bekletileceği ve hangilerinin elle kayıt altına alınacağına dair önceden belirlenmiş bir liste.
- Sahadaki temsilcilerin, ofisteki ekiple aynı bilgiye aynı anda ulaşması.
Bu hazırlık, çalışanların her birinin ayrı ayrı destek hattını araması yerine tek bir kişinin sağlayıcıyla iletişimde olmasını ve bilgiyi ekibe aktarmasını sağlar.
Müşteriye ne söylenmeli?
Kesinti çoğu zaman müşterinin doğrudan fark ettiği bir şey değildir; ancak beklediği bir teklif ya da işlem geciktiğinde etkisi hissedilir. Bu durumda müşteriye yapılacak açıklama kısa, dürüst ve çözüm odaklı olmalıdır.
Teknik ayrıntı yerine taahhüt
Müşteri için önemli olan, sistemin neden çalışmadığı değil, talebinin ne zaman sonuçlanacağıdır. "Talebinizi kaydettik, bugün saat şu civarında size dönüş yapacağız" gibi bir ifade, teknik açıklamadan daha güven vericidir.
Süresi kritik işlerde alternatif yol
Bitiş tarihi bugün olan bir poliçe söz konusuysa, acente sigorta şirketinin kendi kanallarını kullanmak gibi alternatif yolları değerlendirebilir. Bu tür durumlar için hangi yolun kullanılacağının önceden bilinmesi, kriz anında zaman kazandırır.
Geri dönüşün takibi
Kesinti süresince söz verilen geri dönüşler bir yerde not edilmeli ve sistem geri geldiğinde ilk iş olarak tamamlanmalıdır. Bu noktada görev ve hatırlatma özellikleri olan bir acente CRM yapısı, takibin kaybolmamasını sağlar.
Kesinti sonrası iletişim
Sorun çözüldüğünde iletişim bitmez. Sağlayıcının kısa bir olay özeti paylaşması, neyin yaşandığını ve tekrarını önlemek için ne yapıldığını anlatması güveni pekiştirir. Acente tarafında da ekibe kısa bir bilgilendirme yapılması ve kesinti süresince tutulan kayıtların sisteme işlenmesi süreci tamamlar.
Hazırlık kontrol listesi
- Sağlayıcınızın durum sayfası adresini ve bildirim aboneliğini ekipteki yetkililerle paylaşın.
- Acente yazılımından bağımsız bir ekip iletişim kanalı oluşturun.
- Ekip ve müşteri için kısa mesaj şablonlarını önceden yazın.
- Süresi kritik işler için alternatif yol listesini güncel tutun.
- Kesinti sonrası takip edilecek işler için bir sorumlu belirleyin.
InsureHub bakış açısı
InsureHub, sigorta acentelerine yazılım sağlayan bir şirket olarak kesinti iletişimini teknik müdahale kadar önemli bir süreklilik bileşeni olarak görür. Teklif akışlarının trafik, kasko ve DASK için ayrı yürütülmesi, bir sorun yaşandığında hangi işlevin etkilendiğini açıkça ifade etmeyi de kolaylaştırır. Web acente paneli ve mobil sigorta uygulaması hakkında daha fazla bilgi almak ya da hizmet iletişimine ilişkin sorularınızı iletmek için demo talebi oluşturabilirsiniz.
Sonuç
Kesinti iletişimi, sorunun kendisini çözmez ama etkisini belirgin biçimde küçültür. Sağlayıcının net ve düzenli güncellemeleri, acente içinde önceden kurulmuş bir bildirim düzeni ve müşteriye verilen tutarlı taahhütler, zor bir saatin kontrollü biçimde geçirilmesini sağlar.