Müşteri sağlığı skoru nedir, nasıl kurulur?
Müşteri sağlığı skoru nasıl kurulur? Sonuca ilerleme, kullanım ve çözülemeyen sorunlarla başlayın; eksik veriyi ayırın, riski sorumlu kişiye ve işe bağlayın.

Müşteri sağlığı skoru nedir?
Müşteri sağlığı skoru (customer health score), kullanım, hizmet ve ilişki sinyallerini birlikte okuyarak hangi müşteride hangi adımın gerektiğini belirlemeye yarayan bir değerlendirmedir. İlk hedef tek bir puan üretmek değil, ekibin doğru müşteriye zamanında müdahale etmesidir. Bu rehberin başlangıç önerisi üç sinyali yan yana izlemektir.
Bir müşteri her gün sisteme giriyor ama satın aldığı sonuca ulaşamıyor olabilir. Ya da destek talebi azaldığı için sağlıklı görünebilir; oysa ürünü kullanmayı bırakmıştır. GitLab’ın açık sağlık skoru yöntemi kullanımın yanında risk, müşteri sonucu, geri bildirim ve ilişkiyi de ele alıyor. Bu bir uygulama örneği; ağırlıklarını her şirkete taşımak için gerekçe değil.
1. Önce hangi kararı vereceğinizi yazın
“Müşteriyi daha iyi anlayalım” yerine “Önümüzdeki 90 günde sözleşmesi yenilenecek hesaplarda çözüm planını nerede başlatacağız?” sorusuyla başlayın. Sonra aynı yaşam evresindeki tek bir müşteri grubunu seçin. Yeni başlayan bir müşteriyle üç yıldır çalışan bir müşterinin kullanımını aynı eşikle değerlendirmeyin. Ekibinizin ölçüm ve yönetişim hazırlığını görmek için Nord CX’in ücretsiz CX olgunluk testini kullanabilirsiniz.
2. Müşteri sağlığı skoru için üç sinyalle başlayın
Aşağıdaki tablo, Türkiye’de kurumsal müşterilere hizmet veren bir ekip için önerdiğimiz başlangıç tasarımıdır. Doğrulanmış bir sektör standardı ya da kayıp tahmin modeli değildir.
| Sinyal | İlk bakılacak kayıt | Gerekirse yapılacak iş |
|---|---|---|
| Beklenen sonuca ilerleme | Müşteriyle kararlaştırılmış iş sonucunun son durumu | Müşteriyle tek bir engel ve tamamlanma tarihi belirleyin. |
| Kullanım ya da hizmetten yararlanma | Müşterinin kendi başlangıç düzeyine göre değişim | Kullanımdaki düşüşün mevsimsellik mi, erişim sorunu mu olduğunu görüşmeyle doğrulayın. |
| Çözülemeyen sürtünme | Aynı konuda yeniden açılan talepler ve açık kritik işler | Sorunu sahiplenen kişiyi, müşteri için sonucu ve kontrol tarihini yazın. |
Her sinyal için yeşil, sarı ve kırmızının hangi somut kayda dayanacağını ekipçe tanımlayın. Örneğin “ilişki zayıf” yerine “müşteri tarafındaki iş sahibi değişti, yeni sorumlu henüz belirlenmedi” yazın. Eşiklerin yanına veri kaynağını ve son güncellenme tarihini koyun. Anket sinyallerini de kullanacaksanız NPS, CSAT ve CES farklarını ölçüm planınızda netleştirin.
3. Bilinmeyeni ayrı gösterin
Eksik veri, olumlu sonuç sayılmaz. Veri akışı durmuş bir hesabı yeşile boyamak yerine “veri yok” olarak işaretleyin. GitLab’ın yönteminde de eksik bir ölçü kırmızı sayılmıyor; ağırlığı verisi olan ölçülere dağıtılıyor. Siz bir adım daha atın: raporunuzda verisi eksik hesapların oranını görünür tutun. Böylece puanın kapsamadığı müşteriler gözden kaybolmaz.
4. Skoru bir iş listesine bağlayın
İlk sürümde tek bir bileşik puan zorunlu değil. Üç sinyali yan yana göstermek ve kritik bir engeli ayrıca işaretlemek, ortalama bir puanın saklayabileceği ayrıntıyı korur. Her risk kaydı için dört alan açın: müşteri için sorun, sorumlu kişi, yapılacak adım, yeniden kontrol tarihi.
Müşteri sağlığı skoru nasıl hesaplanır?
Her şirkete uygun tek bir ağırlık ya da eşik yoktur; Gainsight da model seçimini kurumun ihtiyacına bağlıyor. Sayısal bir model seçerseniz önce sinyal puanlarını ortak bir ölçeğe dönüştürün, ardından ağırlıkları ve hesap yöntemini açıkça yazın. Ağırlıklı ortalama kullanılan bir modelde hesap şöyledir:
Skor = (Sinyal puanı × ağırlık) toplamı ÷ ağırlıkların toplamı
Bu, kullanılabilecek yöntemlerden biridir. Eksik verinin hesabı nasıl değiştirdiğini ayrıca açıklayın. Toplam puanın yanında sinyalleri de gösterin; kritik bir engel ortalamada kaybolmasın.
5. Sonuçlarla sınayın
Her değerlendirmeyi tarih damgasıyla saklayın. Sonraki dönemde yenileme, iptal ve sözleşme küçültme sonuçlarına bakın: Kırmızı dediğiniz hesaplarda gerçekten daha fazla sorun var mı? Yeşil dediğiniz hangi müşterileri kaçırdınız? Sonucu gördükten sonra puanları geriye dönük değiştirerek modeli başarılı göstermeyin. Müdahale ettiğiniz hesapları ayrıca kaydedin; müdahale, gözlediğiniz sonucu değiştirmiş olabilir. Müdahalenin maliyetini ve getirisini birlikte değerlendirmek için müşteri deneyimi yatırımlarında getiri hesabı yazısına bakabilirsiniz.

Bu hafta yapılacak iş
On müşteri seçin. Üç sinyali, veri tarihini ve tek bir sonraki adımı aynı tabloda toplayın. Ekip tabloyu okuyarak kime neden döneceğini anlayabiliyorsa ilk sürüm işini yapıyor demektir.
Örnek değerlendirme kaydı. Aşağıdaki kayıt yöntemi göstermek için hazırlanmış bir tasarım örneğidir; gerçek müşteri verisi içermez.
| Alan | Örnek |
|---|---|
| Gözlenen durum | Müşteri tarafındaki iş sahibi değişti; yeni sorumlu henüz belirlenmedi. |
| Veri kaynağı | Hesap yöneticisinin son görüşme notu |
| Veri tarihi | Görüşme notunun girildiği gün |
| Müşteri için sorun | Kararlaştırılmış işin yeni sorumlusu belirsiz. |
| Ekipte sorumlu | Hesabın müşteri başarı yöneticisi |
| Sonraki adım | Müşteriyle yeni sorumluyu ve tek bir sonraki işi belirlemek |
| Kontrol tarihi | Görüşmeden iki hafta sonra |
Sık sorulan sorular
Müşteri sağlığı skoru ile NPS aynı mı?
Hayır. NPS müşterinin tavsiye etme eğilimini sorar. Bu rehberde önerilen sağlık değerlendirmesi ise beklenen sonuca ilerlemeyi, kullanım değişimini ve çözülemeyen sorunları birlikte inceler. NPS, sinyallerden biri olarak kullanılabilir ama tek başına sağlık değerlendirmesinin yerini tutmaz. İlk sürümde tek puan üretmek zorunlu değildir; her sinyalin yanında ekibin yapacağı iş görünmelidir.
Müşteri sağlığı skoru için tek bir formül var mı?
Her şirkete taşınabilecek tek bir ağırlık ya da eşik yoktur. Önce kararınızı ve müşteri grubunuzu seçin. Sayısal model kullanacaksanız sinyal puanlarını ortak bir ölçeğe dönüştürün ve ağırlıklandırma yöntemini açıklayın; ağırlıklı ortalama seçeneklerden biridir. Sonucu yenileme, iptal ve sözleşme küçültme kayıtlarıyla sınayın; ağırlıkları doğrulanmış bir standart gibi sunmayın.
Eksik veri müşteri sağlığı skorunda nasıl ele alınır?
Eksik veri, müşterinin sağlıklı olduğunu göstermez. Veri akışı durmuş bir hesabı “veri yok” diye işaretleyin. GitLab’ın uygulamasında eksik ölçünün ağırlığı verisi bulunan ölçülere dağıtılıyor; bu yöntemi kullanırsanız hangi ölçülerin eksik olduğunu da gösterin. Verisi eksik hesapların oranını raporlamak, değerlendirmenin kapsamadığı müşterileri görünür tutar.
Müşteri sağlığı skorunun doğru çalıştığı nasıl anlaşılır?
Her değerlendirmeyi tarih damgasıyla saklayın ve sonraki dönemde yenileme, iptal ve sözleşme küçültme sonuçlarıyla karşılaştırın. Riskli dediğiniz hesaplarla kaçırdığınız sorunlu hesapları birlikte inceleyin. Sonucu gördükten sonra geçmiş puanları değiştirmeyin. Müdahale edilen müşterileri ayrıca kaydedin; ekibin yaptığı iş, daha sonra gözlenen sonucu değiştirmiş olabilir.
Arka plan için: Müşteri sağlığını izlemek ile olup biteni raporlamak arasındaki fark.
Müşteri deneyimindeki haber ve araştırmaları Türkçe, özgün kaynaklarıyla ve Türkiye’den bakan yorumlarla takip etmek için The CX Brief bültenine ücretsiz abone olun.