Müşteri başarısı sağlık puanı: Yapay zekâ olmadan net sinyaller

Belirsiz hesap puanları neden sorun çıkarır

Kırmızı, sarı veya yeşil bir etiket basit görünür, ancak bir hesabın neden ilgi gerektirdiğini gizleyebilir. Bir müşteri ürün kullanımının düşmesi, yenileme tarihinin yaklaşması veya bir destek sorununun çok uzun süre açık kalması nedeniyle kırmızı görünebilir. Bu durumların her biri farklı bir görüşme gerektirir.

Kimse bir puanı açıklayamadığında müşteri başarısı yöneticileri ona güvenmeyi bırakır. Geçici bir giriş sorununa sahip bir hesabın peşinden giderken haftalık kullanımı iki aydır düşen sessiz bir müşteriyi gözden kaçırabilirler. Etiket alarm verir, ancak bundan sonra ne yapılacağını söylemez.

Belirsiz puanlar müşteri görüşmelerini de zorlaştırır. Bir yönetici, arkasındaki gerçekleri açıklayamadan «Hesabınız risk altında» diyemez. Müşteriler belirli bir gözleme daha iyi yanıt verir: «Ekibiniz geçen aydan beri yeni bir rapor oluşturmadı. Süreciniz değişti mi?» Böylece insanlar savunmaya geçmek yerine pratik bir görüşmeye başlar.

Müşteri başarısı sağlık puanı, ekibe ilgi gerektiren hesapları fark etmek için ortak bir yöntem sunmalı. Geleceği tahmin etmesi veya yöneticinin kararının yerini alması gerekmez. Son ürün etkinliğini, çözümlenmemiş destek taleplerini, yenileme zamanlamasını ve belgelenmiş hesap değişikliklerini içeren görünür sinyalleri bir araya getirmeli.

Her sinyalin yöneticinin kontrol edebileceği, sade dilli bir kuralı olmalı. Örneğin belirsiz bir risk numarası vermek yerine, haftalık aktif kullanıcılar dört hafta boyunca yarıya düşerse hesabı işaretleyin. Yönetici etkinliği doğrulayabilir, hesap notlarını okuyabilir ve arayıp aramama, eğitim materyali gönderme veya hesabı olduğu gibi bırakma kararını verebilir.

Şeffaflık ekip incelemelerini de geliştirir. «Puan doğru mu?» diye tartışmak yerine ekip gerçekleri konuşabilir ve kötü alarmlar oluşturan bir kuralı değiştirebilir. İnsanların anladığı basit bir puan, kimsenin güvenmediği gizemli bir etiketten müşteri tutundurma takibi açısından daha değerlidir.

Ekibinizin açıklayabileceği sinyalleri seçin

Bir müşteri başarısı sağlık puanı ancak bir yönetici hesabın neden bu puanı aldığını açıklayabiliyorsa işe yarar. Dört sinyal grubuyla başlayın: ürün kullanımı, destek etkinliği, yenileme zamanlaması ve hesap notları. Bunlar birlikte müşterinin ürünü nasıl kullandığını, nerede yardıma ihtiyaç duyduğunu, hangi ticari son tarihin yaklaştığını ve ekibin gerçek görüşmelerden neler öğrendiğini gösterir.

Gerçekleri görüşlerden ayrı tutun. Bir gerçek, hesabın bu ay üç aktif kullanıcısı olduğunu, iki destek talebi açtığını veya 45 gün sonra yenileneceğini söyleyebilir. Bir görüş ise hesabın ilgisini kaybetmiş göründüğünü ya da yeni kişinin mutsuz konuştuğunu belirtebilir. Görüşler yararlı olabilir, ancak bir sorumlusu, tarihi ve gerekçesi olmalı.

İnsanların düzenli olarak toplayabileceği sinyalleri seçin

Ekibin aynı şekilde güncelleyebileceği ölçümleri seçin. Bir yönetici girişi ürün kullanımı sayarken diğeri tamamlanmış bir görevi esas alırsa puan zamanla tutarsızlaşır. Her sinyal için kısa bir tanım yazın ve veri kaynağını belirtin.

Basit bir şeffaf hesap sağlığı sinyalleri seti şunları içerebilir:

• Ürün kullanımı: aktif kullanıcılar ve ana iş akışının tamamlanması.
• Destek: çözümlenmemiş talepler, tekrarlanan sorun türleri ve son yanıttan beri geçen süre.
• Yenileme zamanlaması: yenilemeye kalan gün sayısı, sözleşme değişiklikleri ve yenileme görüşmesinin başlayıp başlamadığı.
• Hesap notları: doğrulanmış bir müşteri savunucusu değişikliği, belirtilen bir iş hedefi veya belgelenmiş bir risk.

Yazılımınız topluyor diye bir metriği listeye eklemeyin. Toplam giriş sayısı etkileyici görünebilir, ancak müşterilerin sonuç alıp almadığı hakkında çok az şey söyleyebilir. Talep sayısı da yanıltıcı olabilir. Ürünü daha geniş bir ekibe sunan ilgili bir müşteri, kullanmayı bırakmış sessiz bir hesaptan daha fazla soru sorabilir.

Her metrik için ekibin bir sonraki eylemini değiştirip değiştirmediğini sorun. Kimse bu sayı yüzünden hesapla iletişime geçmeyecek, eğitim sunmayacak, bir sorunu çözmeyecek veya yenilemeye hazırlanmayacaksa metriği çıkarın. Gerçek bir görüşmeyi yönlendiren daha küçük bir puan, insanların görmezden geldiği kalabalık bir puan kartından daha iyidir.

AppMaster, bu sinyalleri tek yerde tutan ve her puanlamanın arkasındaki kuralları gösteren kodsuz bir müşteri portalı veya dahili araç oluşturmanıza yardımcı olabilir.

Ürün kullanımını bağlam içinde ölçün

Kullanım verileri yalnızca müşterinin yapmayı amaçladığı işi açıklıyorsa işe yarar. Sadece giriş sayılarına bakmak yanıltıcı olabilir. Bir kişi her gün giriş yapıp sonuç sağlayan iş akışını hiç tamamlamayabilir.

Gerçek ilerlemeyi gösteren eylemleri seçin. Bir destek portalında bu, temsilcilerin talepleri çözmesi, yöneticilerin raporları incelemesi veya müşterilerin istek göndermesi olabilir. Dahili operasyon uygulamasında çalışanlar onay adımlarını tamamlayabilir veya kayıtları güncelleyebilir. AppMaster kullanan ekipler, ölçmek istedikleri eylemler etrafında iş süreçleri oluşturabilir.

Son 30 gün gibi sabit bir dönem kullanın. Tamamlanan eylemleri ve aktif ekip üyelerini sayın, ardından bunları hesabın son dönemdeki düzeniyle karşılaştırın. Genellikle ayda 400 iş akışı tamamlayan bir ekibin bu ay 80 akışta kalması ilgi gerektirir. Düzenli olarak 20 akış tamamlayan küçük bir ekip ise sağlıklı olabilir.

Her müşteriyi tek bir evrensel hedefle karşılaştırmayın. Beş lisanslı kullanıcısı olan bir hesabın, 500 kullanıcılı bir hesapla aynı etkinlik düzeyine ulaşması gerekmez. Müşteri hedefleri, yaygınlaştırma aşamaları ve mevsimsel işler normal kullanımın nasıl göründüğünü etkiler.

Kullanım sinyalini açıklamayı kolaylaştırın:

• Etkinlik, önceki 30 güne kıyasla sabit veya yükseliyor.
• Etkinlik iki inceleme döneminde belirgin biçimde düştü.
• Daha az aktif kullanıcı bir yaygınlaştırma, erişim veya kadro sorununa işaret edebilir.
• Temel eylemlerin hiç tamamlanmaması doğrudan bir hesap kontrolü gerektirir.

Düşük kullanım inceleme gerektirir. Tek başına bir karar vermez. Bir okul tatil sırasında etkinliği duraklatabilir veya bir şirket izinleri güncellerken işleri başka bir ekibe aktarabilir. Hesabın durumunu düşürmeden önce yenileme aşamasını, son destek taleplerini ve hesap notlarını kontrol edin. Ardından «Ekibinizin ürünü kullanma biçiminde bir şey değişti mi?» diye sorun.

Müşterileri suçlamadan destek etkinliği ekleyin

Destek kayıtları sürtüşme noktalarını gösterebilir, ancak yüksek talep sayısı hesabın mutsuz olduğu anlamına gelmez. Bir müşteri ürünü daha büyük bir ekibe yaygınlaştırırken dikkatli sorular sorabilir. Ayrıntılar bir soruna işaret etmiyorsa bunu etkileşim olarak değerlendirin.

Normal yanıt sürenizi aşarak açık kalan sorunlarla başlayın. Özellikle aynı şirkette farklı kişilerin aynı konu hakkında talepler oluşturduğu tekrarlanan isteklere dikkat edin. Karmaşık bir izin ayarıyla ilgili üç talep, kısa bir parola sıfırlama sorusundan daha fazla bilgi verir.

Herkesin destek etkileşimlerini tutarlı kaydetmesi için küçük ve ortak bir ölçek kullanın:

• Olumlu: müşteri yanıtın işe yaradığını doğrular veya ekibe teşekkür eder.
• Nötr: müşteri bilgiye ihtiyaç duyar ve hayal kırıklığı göstermez.
• Endişe verici: müşteri engellenen bir görev, gecikme veya tekrarlanan bir karışıklık bildirir.
• Acil: iş durmuştur, bir son tarih risk altındadır veya sorun birkaç kullanıcıyı etkiler.

Puanı müşterinin üslubuna değil, soruna bağlayın. Bir kişi sinirli konuşsa da makul bir istekte bulunabilir. Sorun sürdüğünde, tekrarlandığında veya önemli bir işi engellediğinde hesap ilgi gerektirir.

Teknik sorunu eğitim eksikliğinden ayırın. Teknik bir sorun hata, başarısız bir entegrasyon veya yapılandırıldığı gibi çalışmayan bir AppMaster uygulaması içerebilir. Bu durumu inceleyebilecek kişiye aktarın ve çözülene kadar takip edin. Müşteri bir hata bildirdi diye puanını düşürmeyin.

Eğitim eksikliği farklı görünür. Kullanıcılar bir iş sürecinin nasıl oluşturulacağını, rollerin nasıl ayarlanacağını veya ihtiyaç duydukları ekranı nerede bulacaklarını sorabilir. Kısa bir anlatım veya pratik bir örnek sunun. Yardımdan sonra aynı soru yeniden gelirse müşteriyi zor biri gibi görmek yerine hesabı daha anlaşılır bir başlangıç eğitimi için işaretleyin.

Destek etkinliği basit bir soruya yanıt vermeli: Bu müşteri ilerlemeye devam edebilir mi? Açık engeller ve çözümlenmemiş tekrarlar sinyali düşürmeli. Düşünülmüş sorular, başarılı çözümler ve aktif öğrenme çoğu zaman ters yönde bir işarettir.

Yenileme zamanlamasını ve hesap değişikliklerini takip edin

Yenileme tarihi, sözleşme bitmeden çok önce harekete geçmeyi sağlamalı. Yenilemeden yedi gün önce kırmızıya dönen bir puan ekibi çok geç uyarır. Hesap sorumlusunun yararlı bir görüşme için zamanı olması amacıyla yenilemeden 120, 90, 60 ve 30 gün önce sinyaller belirleyin.

Tarih müşterinin mutsuz olduğunu göstermez. Yalnızca ticari bir kararın yaklaştığını bildirir. Bu bölümü ürün kullanımı, destek geçmişi ve memnuniyet notlarından ayrı tutun. Sağlıklı ve aktif bir müşteri, finans ekibi bütçeyi henüz onaylamadığı için yenilemeyi geciktirebilir.

Plan ve sözleşme ayrıntılarını yalnızca takip işini değiştirdiğinde kullanın. Örneğin yıllık büyük bir planın 60 günlük bildirim süresi varsa küçük bir aylık abonelikten daha erken incelenmesi gerekebilir. Daha yüksek sözleşme değerini otomatik olarak daha acil saymayın. Sinyal, müşterileri gelire göre sıralamak yerine sorumlu kişiye ne yapacağını söylemeli.

Bir yenileme kaydı şunları içerebilir:

• Yenileme tarihi ve bildirim son tarihi.
• Güncel plan, sözleşme süresi ve zamanlamayı etkileyen koşullar.
• Müşteri ve şirket tarafındaki belirlenmiş yenileme sorumlusu.
• Bütçe incelemesi, birleşme veya liderlik değişikliği gibi bilinen risk.
• Planlanan sonraki görüşme ve tarihi.

Hesap değişiklikleri için ayrı alanlar kullanın. Yönetici sponsoru ayrılırsa tarihi, biliniyorsa yeni irtibat kişisini ve ilişkiyi yeniden kurmak için sonraki adımı kaydedin. Hesabı otomatik olarak «sağlıksız» diye etiketlemeyin. Liderlik değişikliği belirsizlik yaratır, ancak kullanım ve destek sinyalleri hâlâ iyi görünebilir.

Bilinen riskleri tahmin değil, gerçek olarak ele alın. «Müşteri, satın alma ekibinin mayısta bütçe incelemesi başlatacağını söyledi» ifadesi sorumluya takip için bir gerekçe verir. «Yenilemeyebilir» ifadesi hiçbir şeyi açıklamaz ve müşteri tutundurma takibini bozabilir.

Bir AppMaster müşterisinin dahili bir aracı pilot aşamasından daha geniş bir operasyon ekibine taşıma planı, uygulama iyi çalışsa bile yenileme zamanlamasını etkileyebilir. Yaygınlaştırma kararını, kararı kimin onaylayacağını ve karar tarihini kaydedin. Böylece ekip belirsiz bir uyarı yerine somut bir işle ilgilenir.

Her yenileme görüşmesinden sonra bu alanları inceleyin. Tarih, risk veya irtibat kişisi değiştiğinde kaydı aynı gün güncelleyin. Şeffaf puanlama güncel gerçeklere dayanır.

Hesap notlarını net kurallarla kullanın

Manuel notlar, ürün verilerinin sağlayamayacağı bağlamı ekler. Girişlerdeki düşüş endişe verici görünebilir, ancak son görüşme müşterinin ekibinin planlı bir ofis taşıma sürecinde çalışmayı duraklattığını açıklayabilir. Notlar yeni bir hedefi, sponsor değişikliğini veya toplantıda dile getirilen bir endişeyi kaydedebilir.

İnsanların kullanması için formatı kısa tutun. Her notta ne olduğunu, müşterinin neye ihtiyaç duyduğunu ve kararlaştırılan sonraki adımı belirtin. «İyi görüşme» veya «müşteri mutsuz görünüyor» gibi girişlerden kaçının. Başka bir ekip arkadaşı bu ifadelerden hesabı adil biçimde değerlendiremez.

Basit bir format işe yarar:

• Tarih ve hesap sorumlusu.
• Görüşme veya iletişim nedeni.
• Müşterinin sade dille ifade edilen hedefi, endişesi veya değişikliği.
• Kararlaştırılan eylem, sorumlu kişi ve son tarih.

Örneğin: «12 Mayıs, Priya. Üç aylık inceleme. Operasyon lideri, bir onay akışını 1 Haziran'dan önce kullanıma almak istiyor. İki yöneticinin hâlâ erişimi olmadığını söylediler. Priya erişim listesini 14 Mayıs'a kadar gönderecek.» Sonraki hesap sorumlusu bu nota göre hareket edebilir. Bir AppMaster müşteri portalında ekip notu kullanım, destek ve yenileme ayrıntılarının yanında tutabilir.

Manuel notlara puan içinde sınırlı bir rol verin. Güncel ve belirli bir risk notu puanı düşürebilir veya kontrol görüşmesi başlatabilir. Doğrulanmış olumlu bir sonuç güveni artırabilir. Kişisel izlenimler, çözümlenmemiş destek vakaları veya aktif bir karar vereni olmayan yaklaşan yenileme gibi kanıtların önüne geçmemeli.

Puanı etkileyen notlar için bir sona erme kuralı belirleyin. 90 gün önce yazılmış bir endişe, ekip sorunu çözmüşse ve yeni kanıtlar bunu desteklemiyorsa hesabı risk durumunda tutmamalı. Her puan güncellemesinden önce sorumlu kişi eski notları çözümlenmiş, hâlâ geçerli veya artık ilgisiz olarak işaretlemeli.

Sade dil hem müşteriyi hem ekibi korur. «Müşteri, finans incelemesi bitene kadar yaygınlaştırmayı ertelemek istedi» yazın, «zor hesap» yazmayın. Gerçekleri, doğrudan talepleri ve kararlaştırılan eylemleri kaydedin. Niyet veya kişilik hakkındaki varsayımları dışarıda bırakın.

Puanı adım adım oluşturun

İnsanların kâğıt üzerinde hesaplayabileceği bir puanla başlayın. 0 ile 100 arası bir aralık tanıdık gelir, ancak tam ölçekten çok arkasındaki yazılı kurallar önemlidir. Her sinyale sınırlı sayıda puan verin ve puan kazanmasının veya kaybetmesinin nedenini kaydedin.

Ürün kullanımı 30, destek etkinliği 20, yenileme zamanlaması 25 ve hesap notları 25 puan katkı sağlayabilir. Yönetici bir hesabı açıp «21 gündür hiçbir haftalık aktif kullanıcı giriş yapmadığı için -10» gibi bir değişiklik görebilmeli. Sistem kanıtı göstermiyorsa «etkileşim riski» gibi etiketlerden kaçının.

Alarmları bağlamdan ayrı tutun. 45 gün sonra yenilenecek bir sözleşme aciliyet yaratır, ancak hesabın sağlıksız olduğu anlamına gelmez. Buna karşılık aktif kullanıcı sayısındaki ani düşüş, çözümlenmemiş bir destek sorunuyla birleştiğinde kontrol alarmı başlatabilir. Böylece puan, ilgi gerektiren durumlara odaklanır.

Her biri net bir eyleme sahip puan aralıkları oluşturun:

• 80-100: normal başarı planına devam edin ve genişleme fırsatlarını değerlendirin.
• 60-79: bir sonraki planlı temas noktasında son hesap etkinliğini inceleyin.
• 40-59: müşteriye beş iş günü içinde ulaşması için bir sorumlu belirleyin.
• 0-39: müşteriye ulaşmadan önce dahili bir inceleme yapın ve toparlanma planında anlaşın.

İlk sürümü müşteri başarısı, destek ve satış ekipleriyle birlikte oluşturun. Her ekip hesabın farklı bir bölümünü görür. Destek ekibi yalnızca talep sayısının neden zayıf bir uyarı olduğunu açıklayabilir. Satış ekibi ise yenileme riskini etkileyen bütçe değişikliğini veya yeni karar vereni bildirebilir.

Kodsuz bir müşteri portalı veya dahili araç puanı, puan geçmişini, notları ve atanan eylemi tek yerde gösterebilir. AppMaster ile ekip hesap verilerini modelleyebilir, görsel iş süreçlerinde puanlama kuralları belirleyebilir ve süreç geliştikçe bunları değiştirebilir.

Her kural güncellemesi için bir değişiklik günlüğü tutun. Tarihi, eski kuralı, yeni kuralı ve nedeni kaydedin. Daha sonra puan değiştiğinde müşteri davranışının mı yoksa puanlama yönteminin mi değiştiğini anlayabilirsiniz.

Örnek: Kontrol görüşmesi gerektiren bir hesap

Bir müşteri başarısı ekibi 42 aktif kullanıcısı olan bir hesabı yönetiyor. Birkaç ay boyunca yaklaşık 30 kişi ürünü her hafta kullandı. Bu hafta haftalık aktif kullanıcı sayısı 18'e düştü, çünkü raporları hazırlayan ve çalışma arkadaşlarını eğiten ekip üyesi müşterinin şirketinden ayrıldı.

Hesapta ayrıca iki açık destek talebi var. Biri ayrılıktan sonra kullanıcı izinlerinin nasıl güncelleneceğini soruyor. Diğeri planlanmış veri dışa aktarımının başarısız olduğunu bildiriyor. Yenileme 75 gün sonra. Bağlam olmadan bakıldığında bu karışım acil ve kırmızı bir puan oluşturabilir.

Son görüşme notu ekibe farklı bir tablo sunuyor. Müşterinin operasyon yöneticisi, yeni kişinin gelecek ay başlayacağını söyledi. Kısa bir eğitim oturumu istedi ve yeni çalışan gelmeden önce dışa aktarma sorununun çözülmesini bekliyor. Müşteri bütçe kesintilerinden, memnuniyetsizlikten veya ayrılma planından söz etmedi.

Tek bir puanın ayrıntıları gizlemesine izin vermek yerine her sinyali görünür tutun:

• Kullanım: belirlenmiş bir çalışan ayrılığından sonra haftadan haftaya %40 düştü.
• Destek: biri rutin bir süreci etkileyen iki açık talep.
• Yenileme: 75 gün sonra, harekete geçmek için zaman var.
• Hesap notu: müşteri, yeni çalışan için başlangıç desteği istedi.

Bu durum planlı bir takip gerektirir, acil müdahale değil. Müşteri başarısı yöneticisi iki iş günü içinde dışa aktarma talebinin durumunu doğrulamalı, ardından yeni çalışan için 30 dakikalık bir eğitim oturumu önermeli.

Yeni kişi başladıktan üç hafta sonrası için bir inceleme tarihi belirleyin. Haftalık kullanımın yükselip yükselmediğini, iki talebin de kapanıp kapanmadığını ve yeni kullanıcının yaygın görevleri tamamlayıp tamamlayamadığını kontrol edin. Ekip daha sonra şeffaf hesap sağlığı sinyallerini varsayımlarla değil, kanıtlarla güncelleyebilir.

Açık bir kayıt, müşteri tutundurma takibindeki yaygın bir hatayı önler: her etkinlik düşüşünü yenileme riski saymak. Burada kullanım düşüşü ilgi gerektiriyor, ancak görüşme notu bunu açıklıyor ve ekibe pratik bir yanıt sunuyor.

Yaygın puanlama hataları

Müşteri başarısı sağlık puanı karar vermek değil, yararlı bir görüşme başlatmak için kullanılmalı. Ekipler kullanımındaki her düşüşü müşteri kaybı riski olarak gördüğünde yanlış alarmlar oluşturur. Aylık bir kullanıcı bir projeyi tamamladıktan sonra daha seyrek giriş yapabilir. Bir operasyon ekibi ise aynı uygulamayı her gün yalnızca birkaç dakika kullanabilir.

Kullanımı müşterinin normal düzeni ve güncel hedefleriyle birlikte okuyun. Keskin bir düşüş, çözümlenmemiş bir destek sorunu, kaçırılmış bir yaygınlaştırma kilometre taşı veya yaklaşan bir yenilemeyle birlikte ortaya çıktığında daha önemlidir.

Kuralları görünür tutun. Karmaşık ve gizli formüller içeren bir elektronik tablo tek bir kişinin kontrolündeyse, başka hiç kimse hesabın neden sarıya döndüğünü açıklayamaz. Her sinyali ağırlığı, veri kaynağı ve başlatması gereken eylemle birlikte sade dille yazın.

Destek verileri için bir zaman sınırı belirleyin. Ekip sorunu çözdükten ve müşteri sonucu doğruladıktan sonra eski bir talep hesabın puanını düşürmeye devam etmemeli. Açık sorunlara çözümlenmiş sorunlardan daha fazla ağırlık verin ve belirlenen bir süreden sonra etkilerini azaltın. İki ay önce kapatılmış bir faturalandırma sorusu, bugünkü düzenli ürün kullanımından daha ağır basmamalı.

Sözleşme değeri değerlendirmeyi bozabilir. Büyük bir hesap ilgi gerektirebilir, ancak gelir açık sürtüşmeyi ortadan kaldırmaz. Kullanıcılar önemli bir görevi tamamlamayı bıraktıysa, bir yönetici tekrarlanan endişeler dile getirdiyse ve yenileme yaklaşıyorsa hesap büyüklüğünden bağımsız olarak ekibin bir plana ihtiyacı vardır.

Harekete geçmeden önce güncelliği kontrol edin

Eski verilere dayanan bir puan gereksiz iş çıkarır. Ürün etkinliğini, talep durumunu, yenileme ayrıntılarını ve hesap notlarını düzenli bir programa göre yenileyin. Sorumludan yeni sponsor, küçülen ekip veya duraklatılmış proje gibi önemli değişiklikleri doğrulamasını isteyin.

Düşük puana göre harekete geçmeden önce kullanım değişikliğinin hesabın normal düzeninden farklı olup olmadığını, destek sorunlarının hâlâ açık ve günlük işi etkileyip etkilemediğini ve yenileme ayrıntılarının güncel olup olmadığını kontrol edin. Bağlam için en yeni hesap notunu okuyun. Ekipteki herkes bir formül açmadan puanı açıklayabilmeli.

Şeffaf bir puan, insanların şimdi iletişim gerektiren hesaplara odaklanmasına yardımcı olur. Hesap sorumlusunun kararının yerini almamalı.

Hızlı inceleme kontrol listesi

Sağlık puanı ancak ekip onu hızlıca kontrol edebiliyor ve gördüklerine güveniyorsa işe yarar. Haftalık inceleme, küçük boşlukların yenileme zamanı yaklaşırken sürprize dönüşmesini önler. Ayrıca insanların bir renk veya sayıyı tüm hikâye sanmasını engeller.

Her hesap için yenileme tarihini doğrulayın. Hesap sabit bir programa göre yenilenmiyorsa ay ay yenilenen anlaşma veya pasif sözleşme gibi nedeni kaydedin. En son ürün etkinliğini açık destek öğeleriyle birlikte kontrol edin ve müşteriyle iletişime geçmeden önce en yeni hesap notunu okuyun. Yakın tarihli bir görüşme kadro değişikliğini, ertelenen lansmanı veya takip gerektiren bir isteği açıklayabilir.

Her puan değişikliğinin sade dilli bir nedeni olmalı. «Ekip yöneticisini kaybettikten sonra kullanım düştü» yararlıdır. «Puan güncellendi» değildir. Bir sonraki eylemi tek bir kişiye atayın ve son tarih ekleyin. Ortak sorumluluk çoğu zaman kimsenin hesapla iletişime geçmemesine yol açar.

Bir hesap 21 gün boyunca kimse giriş yapmadığı için düşük puan gösterebilir. Sahibi bir uyarı e-postası göndermeden önce açık bir destek talebi ve müşterinin tek oturum açma kurulumu için beklediğini belirten bir not bulabilir. Doğru takip, genel bir kullanım mesajı değil, bu kurulumla ilgili durum güncellemesidir.

Bu alışkanlık puanın denetlenmesini kolaylaştırır. Ekipteki herkes neyin, neden değiştiğini ve sırada kimin olduğunu görebilir. Kodsuz bir müşteri portalı veya dahili hesap aracı bu alanları tek ekrana yerleştirebilir, ancak net sorumluluk ve düzenli inceleme yine de önemlidir.

Puanı günlük işlerinize dahil edin

Puan, yalnızca ekibin bir sonraki eylemini değiştiriyorsa yararlıdır. İlk sürümü küçük tutun. Bir grup hesap seçin, aynı kuralları bir ay boyunca uygulayın ve sonuçları hesap yöneticilerinin görüşmelerden ve e-postalardan bildikleriyle karşılaştırın.

Yöneticilerden iki uyumsuzluğu işaretlemelerini isteyin: sağlıklı görünen ancak riskli hissettiren bir hesap ve riskli görünen ancak aslında istikrarlı olan bir hesap. Bu örnekler mevsimsel kullanım düşüşü veya henüz başlamamış planlı bir yaygınlaştırma gibi eksik bağlamları ortaya çıkarır.

Basit bir haftalık rutin kullanın:

• Önceki haftadan beri puanı değişen hesapları inceleyin.
• Bir sorumlu ve son tarih içeren tek bir takip işi atayın.
• Eylemin nedenini hesap notlarına kaydedin.
• Puan uyumsuzluklarını ekip toplantısında ele alın.
• Gecikmiş takip işlerinin sonraki hafta yeniden görünüp görünmediğini kontrol edin.

Her seferinde tek bir kuralı değiştirin. Çözümlenmemiş destek taleplerine daha fazla ağırlık verirseniz eski kuralı, yeni kuralı, tarihi ve nedeni kaydedin. Ardından etkisini birkaç hafta izleyin. Aynı anda birden fazla değişiklik yapmak, hangi kuralın puanı iyileştirdiğini ve hangisinin gürültü oluşturduğunu anlamayı zorlaştırır.

AppMaster bu süreci kodsuz bir dahili araca dönüştürebilir. Ekipler kullanım verileri, destek etkinliği, yenileme tarihleri, manuel notlar ve puan geçmişi için hesap kayıtları oluşturabilir. Görsel iş süreçleri puanı hesaplayabilir ve hesap seçilen bir eşiği geçtiğinde takip görevi oluşturabilir. Ekip üyeleri görüşmelerden sonra notları özel elektronik tablolarda tutmak yerine web veya mobil arayüzden güncelleyebilir.

Ekibin zaten güvendiği verilerle başlayın. Son kullanım, açık destek sorunları, yenileme zamanlaması ve net bir yönetici notuna dayanan temel bir puan, kimsenin açıklayamadığı karmaşık bir modelden daha yararlıdır. Bir ay sonra gerçek hesap koşullarıyla örtüşen kuralları koruyun, örtüşmeyenleri çıkarın.