İnsanların anlayabileceği bir talep önceliklendirme sistemi oluşturun

Talepler net kurallar olmadan neden adaletsiz görünür?

Talepler nadiren tek bir yerde toplanır. Bir yönetici e-posta gönderir, biri ekip sohbetine yazar, bir çalışma arkadaşı da toplantıdan sonra «küçük bir düzeltme» ister. Her talep o anda acil görünebilir. Ortak bir talep toplama süreci olmadığında, çoğu zaman en yüksek sesle konuşan veya en çok ısrar eden kişi önce dikkate alınır.

Bu durum kısa sürede karmaşa yaratır. Satış ekibi bir müşteri portalı güncellemesi için iki hafta beklerken ekip aynı gün küçük bir dahili rapor hazırlayabilir. İş bekleyen kişiler bu kararın arkasındaki tercihleri göremez. Önce sessizlikle, ardından başkasını kayırıyor gibi görünen bir sonuçla karşılaşırlar.

Gizli kararlar, normal gecikmeleri kişisel bir mesele gibi hissettirir. Talep sahipleri ekiplerinin mesajlarını kaybettiğini, sorunu yanlış anladığını veya etkili kişilere özel muamele yaptığını düşünebilir. Mantıklı bir karara bile kimse onu inceleyemediğinde güvenmek zordur.

Bir talep önceliklendirme sistemi her talebe aynı başlangıç noktasını verir. İşleri karşılaştırmak için gereken bilgileri toplar: kimlerin etkilendiği, iş beklerse ne olacağı, ne kadar çaba gerektirdiği ve gerçekten bir son tarih bulunup bulunmadığı. Amaç uzun bir form veya kararları otomatik veren karmaşık bir formül değildir. Amaç, seçim yapmanın tutarlı ve görünür bir yolunu oluşturmaktır.

Örneğin bir destek lideri, müşterilerin parolalarını sıfırlayamadığını bildirir. Pazarlamadan bir çalışma arkadaşı ise gelecek aydan önce yeni bir gösterge tablosu filtresi ister. Her iki talep de önemlidir, ancak ilki hesabına erişemeyen kişileri etkiler. Açık talep puanlama kuralları bu gerekçeyi görünür kılar.

Şeffaf bir talep toplama süreci, ekiplerin anlaşmazlıkları daha sakin biçimde ele almasına da yardımcı olur. Talep sahibi eksik bilgileri düzeltebilir veya son tarihin neden değiştiğini açıklayabilir. Özel konuşmaların peşinden koşmasına ya da işinin «daha acil hissettirdiğini» savunmasına gerek kalmaz.

Her talep şu üç soruyu yanıtlamalıdır:

• Bu talep hangi sorunu çözüyor ve bundan kim etkileniyor?
• Ekip beklerse ne olur?
• Bu talep neden diğer işlerin önünde veya arkasında yer alıyor?

Ekiplerin yine de değerlendirme yapması gerekir. Büyük bir kesinti, hukuki konu veya ani bir müşteri taahhüdü istisna gerektirebilir. Gerekçeyi kaydedin ve etkilenen talep sahipleriyle paylaşın. İnsanlar kuralı, kanıtı ve istisnanın nedenini görebildiğinde daha düşük önceliği genellikle kabul eder.

Dahili araçlar ve müşteri portalları için kodsuz bir talep portalı, bu ayrıntıları gelen kutularına dağılmak yerine tek ve görünür bir yerde tutar. İnsanlar talep gönderebilmeli, durumunu görebilmeli ve ekibin karara nasıl ulaştığını anlayabilmelidir.

İnsanların anlayabileceği dört faktör seçin

Bir talep önceliklendirme sistemi, herkes kriterlerini günlük dille açıklayabildiğinde en iyi şekilde çalışır. Çoğu ekip dört faktörden yararlanabilir: aciliyet, etki, çaba ve son tarihler. Bunları ayrı tutun, yoksa herkes her şeyi acil olarak puanlar.

Aciliyet, birinin ne kadar kısa sürede harekete ihtiyaç duyduğunu anlatır. Çalışanların maaş ödemelerini engelleyen bir bordro hatası acildir, çünkü insanlara hemen zarar verir. Gelecek çeyrekten önce yeni bir rapor istemek önemli olabilir, ancak bugün acil değildir.

Etki, ekip talebi tamamladığında veya tamamlamadığında neyin değişeceğini anlatır. Etki; etkilenen müşteri ya da çalışan sayısını, kazanılan veya kaybedilen parayı, hukuki ya da güvenlik riskini ve ortadan kaldırılan manuel çalışma saatlerini kapsayabilir.

İnsanların tahmin yürütmeden uygulayabileceği kısa bir ölçek kullanın:

• Düşük etki, tek bir kişiyi veya küçük bir kolaylığı etkiler.
• Orta etki, bir ekibi, bir müşteri grubunu veya tekrarlanan birkaç saatlik işi etkiler.
• Yüksek etki, çok sayıda müşteriyi, önemli geliri, uyumluluğu, güvenliği veya temel bir iş sürecini etkiler.

Çabanın amacı farklıdır. Büyük bir iş, daha uzun sürdüğü için otomatik olarak geride kalmamalıdır. Çaba, ekibin kapasitesini planlamasına ve seçenekleri karşılaştırmasına yardımcı olur. Bir hesap erişimi sorununu düzeltmek bir saat sürebilir ve 20 kullanıcıya yardımcı olabilir. Bir onay akışını yeniden oluşturmak iki hafta sürebilir ve 200 kullanıcıya yardımcı olabilir. Her ikisi de ilgi gerektirebilir, ancak ekip bunları farklı zamanlara planlayabilir.

Sahte bir kesinlik yerine yaklaşık bir tahmin isteyin. İnceleme öncesinde küçük, orta ve büyük seçenekleri yeterlidir. Talep sahibi beklenen işi açıklayabilir, teslim ekibi de tahmini doğrular.

Son tarihlerin kanıtı olmalıdır. Gerçek bir son tarihin tarihi ve açık bir sonucu bulunur: «Yeni vergi kuralı 1 Temmuz'da yürürlüğe giriyor ve bu alan olmadan beyannameleri gönderemeyiz.» «Lütfen cuma gününe kadar tamamlayın» ise talep sahibi cumadan sonra ne olacağını açıklamadığı sürece yalnızca bir tercihtir.

Bu yaklaşım, son tarihlerin gereğinden fazla kullanılmasını önler. Her talebin acil bir tarihi varsa tarihler, gelen taleplere öncelik verme konusunda ekibe yardımcı olmaktan çıkar. Şeffaf bir talep toplama formu tarihi, bu tarihin kaçırılması halinde doğacak sonucu ve geçici bir çözüm bulunup bulunmadığını sorabilir.

Açıklaması kolay bir puanlama modeli oluşturun

Bir talep önceliklendirme sistemine güvenmek, talep sahibi inceleme öncesinde sonucu kabaca tahmin edebildiğinde daha kolaydır. Her faktör için 1 ile 5 arasında bir ölçek kullanın. Daha geniş aralıklar, kimsenin savunamayacağı küçük farklar üzerine tartışmalara yol açar.

Etki, aciliyet, son tarih baskısı ve çabayı kullanın. Her sayıyı günlük dille tanımlayın ve bu tanımları talep formunda bulundurun.

Hesaplamayı görünür tutun:

Öncelik puanı = (Etki x 2) + Aciliyet + Son tarih baskısı + (6 - Çaba)

Bu hesaplama etkiye daha fazla ağırlık verir. Benzer fayda sunan iki talep arasında daha kısa süren işe küçük bir avantaj sağlar. Puanlar 5 ile 25 arasında değişir. Ekip üyesi sonucu basitçe açıklayabilir: «Bunu önce ele aldık, çünkü çok sayıda kişiyi etkiliyor, sabit bir tarihi var ve diğer seçeneğe göre daha az çalışma gerektiriyor.»

İstisnaları formülün içine gizlemeyin. Müşteri sözü, güvenlik endişesi veya başka bir projeye bağlılık sırayı değiştirebilir. Kısa bir «inceleme bağlamı» alanı ekleyin ve değerlendiricinin puanı neden değiştirdiğini kaydetmesini zorunlu tutun.

Örneğin satış ekibi puanı 18 olan bir rapor ister. Bir destek sorunu 16 puan alır, ancak bir müşteri ücretli siparişi tamamlayamaz. Değerlendirici destek sorununu öne alabilir ve şu notu yazabilir: «Bir müşteri için aktif ücretli sipariş engeli.» Böylece karar kişisel olmaktan çıkar ve incelenebilir hale gelir.

AppMaster, form ve toplamı hesaplayan iş mantığıyla bu tür bir kodsuz talep portalını destekleyebilir. Talep sahiplerinin de değerlendiricilerle aynı kuralları kullanması için faktör açıklamalarını her alanın yanında tutun.

Her talep için gereken ayrıntıları toplayın

Bir talep önceliklendirme sistemi her iş için aynı temel bilgilere ihtiyaç duyar. Kısa bir toplama formu, «lütfen bunu kısa sürede yapın» gibi belirsiz mesajların belgelenmiş bir iş ihtiyacı olan taleplerin önüne geçmesini engeller.

Çoğu ekip için beş zorunlu alan yeterlidir:

• Sorunun veya istenen değişikliğin günlük dille açıklaması
• Sonucu kullanacak kişiler veya grup
• Sonucun ne sıklıkta kullanılacağı
• Ekip işi geciktirirse ne olacağı
• Varsa istenen teslim tarihi

Beklemenin sonucunu somut biçimde sorun. «Bu faydalı olur» aciliyeti açıklamaz. Talep sahibi, destek temsilcilerinin her vaka için iki sistem arasında veri kopyaladığını veya bir alan portala eklenene kadar müşterinin siparişi tamamlayamadığını anlatabilir. Bu ayrıntılar ekibe adil bir puanlama için temel sağlar.

Kullanım sıklığı da önceliği değiştirir. Her sabah 40 satış çalışanının kullandığı bir rapor, bir yöneticinin üç ayda bir kullandığı benzer bir rapordan daha geniş etkiye sahiptir. İnsanlardan kendi puanlarını vermelerini istemek yerine gerçekleri sorun. Kurallar bu gerçekleri tutarlı bir sonuca dönüştürebilir.

Son tarihleri bağlam gerektiren iddialar olarak ele alın

Tek başına bir tarih aciliyeti kanıtlamaz. Son tarih seçen herkes nedenini belirtmelidir. Yararlı nedenler arasında imzalanmış bir müşteri taahhüdü, hukuki veya uyumluluk tarihi, planlanmış bir etkinlik ya da başka bir ekibe bağlılık bulunur.

Tercih ettiği için «Cuma» yazan kişiyle, ödeme süreci cuma günü duracak olan kişi aynı puanı almamalıdır. «Bu tarihe kadar hazır olmazsa ne olacak?» diye sorun. Açık bir yanıt, son tarihi değerlendirmeyi kolaylaştırır. Zayıf bir yanıt ise ekibe tarihi düzeltmek için gerekçe verir.

Eksik talepleri hızlıca geri gönderin

Yarım bırakılmış bir talebin kuyrukta beklemesine izin vermeyin. Şu tür net bir notla geri gönderin: «Lütfen kullanıcı grubunu belirtin ve iki haftalık gecikmenin etkisini açıklayın.» Bu, süreci adil tutar ve ekibin varsayım üretmesini engeller.

Kodsuz bir talep portalı alanları zorunlu kılabilir ve yalnızca gerektiğinde takip soruları gösterebilir. Örneğin son tarih sorusu, biri bir tarih girdikten sonra görünebilir. AppMaster kullanan bir ekip formlar, iş kuralları ve «Açıklama gerekli» durumuyla bir talep uygulaması oluşturabilir. Böylece talep sahipleri uzun bir e-posta zinciri olmadan eksik bilgileri tamamlayabilir.

Net bir toplama süreci bürokrasi değildir. Sessiz kişilerden gelen talepler de ikna edici kişilerden gelen talepler de dahil olmak üzere her talebe aynı talep puanlama kurallarını uygulamak için yeterli kanıt sağlar.

Yarışan talepleri aynı kurallarla karşılaştırın

Satış ekibi bir müşteri portalında değişiklik ister. Birkaç aktif müşteri mevcut hizmet durumunu göremez ve satış ekibi bu değişikliğin cuma günü yapılacak bir yenileme görüşmesini etkileyebileceğini söyler. Aynı zamanda operasyon ekibi haftalık destek ve satış rakamlarını birleştiren dahili bir rapor ister.

Her iki talep için de aynı formülü kullanın: (Etki x 2) + Aciliyet + Son tarih baskısı + (6 - Çaba).

Bu aşamada rapor önce gelir. Operasyon yöneticisinin planlanmış pazartesi incelemesi için rapora ihtiyacı olduğundan doğrulanmış bir son tarihi vardır. Portal talebi müşterileri etkiler, ancak satış ekibi cuma gününün önemli olduğunu söylemekle yetinmiştir. Çalışanlar hizmet durumunu yine e-posta ile gönderebilir ve kimse bir yenilemenin bu değişikliğe bağlı olduğunu göstermemiştir.

Bir gün sonra satış ekibi kanıt ekler: Bir müşterinin cuma günü yenileme görüşmesi vardır, hesap yöneticisi görüşme davetini ekler ve müşteri bu görüşmeden önce portal erişimi ister. Son tarih puanı 1'den 5'e çıkar.

Portal talebi artık 17 puan alır ve raporun önüne geçer. Rapor daha az yararlı hale gelmemiştir. Portal değişikliğinin önce gelen, doğrulanmış bir müşteri tarihi vardır.

Son tarih kanıtının ayrı bir kurala ihtiyaç duymasının nedeni budur. «Acil» yazmak veya keyfi bir tarih belirtmek puan kazandırmamalıdır. Müşteri taahhüdü, hukuki son tarih, planlanmış toplantı veya aktif kullanıcıları etkileyen hizmet sorunu gibi başka bir kişinin doğrulayabileceği kanıtları kabul edin.

Notu puanın yanında kısa tutun: «Cuma günü yenileme görüşmesi doğrulandı; 18 aktif müşteri bu portalı kullanıyor.» Kuyruğu inceleyen herkes sıranın neden değiştiğini görebilir ve operasyon ekibi net bir karara göre plan yapabilir.

Talep sahiplerine kararların nasıl verildiğini gösterin

İnsanlar herkesin uyguladığı kuralları görebildiğinde daha düşük önceliği daha kolay kabul eder. Her puanı etkileyen faktörleri yayınlayın: aciliyet, etki, çaba ve son tarih baskısı. Her sayının ne anlama geldiğini tanımlayın. Örneğin 5 aciliyet puanı, birkaç kişinin işinin durduğu anlamına gelebilirken 2 puan, talebin rutin bir işi kolaylaştıracağı anlamına gelebilir.

Sürecin öngörülebilir bir inceleme takvimine de ihtiyacı vardır. Ekibin yeni talepleri ne zaman, örneğin her salı ve perşembe, daha geniş birikmiş işleri ne zaman incelediğini belirtin. Talep sahibi tarihi bildiğinde incelenmeyi bekleyen bir talep kaybolmuş gibi hissettirmez.

Kuyruğu görünür kılın

Her talep sahibi güncel durumu ve planlanan inceleme tarihini görebilmelidir. Basit etiketler iyi çalışır: Yeni, Bilgi gerekli, İnceleniyor, Planlandı, Devam ediyor ve Planlanmadı. Sırada ne olduğunu kimsenin bilmediği durumlarda «beklemede» gibi etiketlerden kaçının.

Örneğin bir satış yöneticisi müşteri portalına alan eklenmesi için talep gönderir. Portal, talebin incelendiğini, 11 puan aldığını ve 14 Mayıs'ta görüşüleceğini gösterebilir. Yönetici sonuçtan yine memnun olmayabilir, ancak sessizlik yerine gerçek bilgilere sahip olur.

Bir puan değiştiğinde günlük dille kısa bir yorum ekleyin:

• «Son tarih gelecek çeyreğe alındı, bu nedenle aciliyet 4'ten 2'ye düştü.»
• «Destek ekibi bu sorundan 60 müşterinin etkilendiğini doğruladı, bu nedenle etki 2'den 5'e çıktı.»
• «Ekip mevcut bir API buldu, bu nedenle çaba 4'ten 2'ye düştü.»

Bu notlar ekibin geçmiş kararları açıklamasına yardımcı olur. Puanların en yüksek sesle konuşan kişiyi değil, güncel bilgileri yansıttığını gösterir.

İnsanların kaydı düzeltmesine izin verin

Talep sahiplerinin eksik veya yanlış bilgileri düzeltmesinin bir yolu olmalıdır. Şeffaf talep toplama formuna yorum alanı veya «Daha fazla bilgi sağlayın» işlemi ekleyin. Puanı etkileyen kullanıcı sayısı, sözleşmeye bağlı son tarih veya geçici çözüm gibi kanıtları isteyin.

Talep sahipleri bilgi sağlayabilir, ancak kendi puanlarını değiştirmemelidir. Önceliklendirmeden sorumlu kişi veya ekip puanı günceller ve değişikliği açıklar. Bu yaklaşım, insanlara gerçek bir söz hakkı verirken süreci adil tutar.

Güveni zedeleyen hatalar

Bir talep önceliklendirme sistemi, odadaki en yüksek sesli kişiyi ödüllendirdiğinde güvenilirliğini kaybeder. Talep sahibi bir işi kendi son tarihini etkilediği için acil olarak adlandırabilir, ancak aciliyetin sabit bir tarih, müşteri taahhüdü, uyumluluk sorunu veya hizmet kesintisi gibi kanıtlara ihtiyacı vardır. Kırmızı bir «acil» etiketi koymayı kabul etmek yerine bu kanıtı isteyin.

Zor ama gerekli işlere çabayı ceza olarak uygulamayın. Büyük bir güvenlik düzeltmesi veya karmaşık bir müşteri portalı değişikliği basit bir rapordan daha uzun sürebilir, ancak sağladığı fayda bu çalışmayı haklı çıkarabilir. Çaba, seçenekleri karşılaştırmaya yardımcı olur. Karmaşık işleri sonsuza kadar geriye itmemelidir.

Belirsiz etki iddiaları da aynı sorunu yaratır. «Bu herkese yardımcı olacak» ifadesi değerlendiriciye puan verecek bir şey sunmaz. Talep sahiplerinden kimlerin faydalanacağını ve neyin değişeceğini açıklamalarını isteyin. «Destek temsilcileri 40 haftalık vakanın her biri için verileri kopyalamaya 15 dakika harcıyor» ifadesi, ekibe etkiyi tahmin etmek için pratik bir temel verir.

Yaygın güven kaybettiren uygulamalar şunlardır:

• Son tarih veya açık bir zarar olmadan her talebin acil olarak işaretlenmesine izin vermek
• Daha fazla çalışma gerektirdiği için karmaşık taleplere düşük puan vermek
• Kullanıcı grubu, sayı veya örnek içermeyen geniş etki iddialarını kabul etmek
• Yönetim taleplerini aynı sürece kaydetmeden öne almak
• Son tarih, müşteri ihtiyacı veya iş hedefi değiştiğinde puanları güncellememek

Yönetim çalışmasının gizli olması gerekmez. Bir yöneticinin imzalanmış müşteri taahhüdü veya hukuki son tarih gibi bir işi öne almak için geçerli bir nedeni olabilir. Talebi aynı listeye ekleyin, nedeni belirtin ve bunun puanı veya sırayı nasıl etkilediğini gösterin.

Puanların geçerliliği de sona erer. Bir kampanya bitebilir, müşteri sorunu başka bir yolla çözebilir veya son tarih geçebilir. Aktif talepleri iki haftada bir veya talep sahibi ayrıntıları değiştirdiğinde inceleyin. Kuyruk sahibi puanı güncellemeli ve değişikliği açıklayan kısa bir not bırakmalıdır.

Tutarlı davranış, karmaşık bir formülden daha önemlidir. Ekip acil, zor ve yönetim kaynaklı işlere aynı kuralları uyguladığında talep sahipleri bir puanın anlam taşıdığını öğrenir.

Süreci kullanıma almadan önce test edin

Talep önceliklendirme sistemini ekibin varsayılan süreci haline getirmeden önce kısa bir deneme yapın. Sistemi tasarlamayan üç kişiden gerçekçi talepler göndermelerini isteyin. Formu tamamlayamıyor ve yönlendirme olmadan puan tahmini yapamıyorlarsa ifadeleri basitleştirin veya bir alanı kaldırın.

İki değerlendiriciye aynı örnek talepleri ve normal bir talep sahibinin sağlayacağı bilgileri verin. Toplamlarının birebir aynı olması gerekmez, ancak büyük farklar belirsiz kuralları ortaya çıkarır. «Yüksek etki» gibi ifadeleri «50'den fazla müşteriyi etkiler» veya «finans ekibinin ay kapanışını yapmasını engeller» gibi açıklamalarla değiştirin.

Belirtilen her tarihi kontrol edin. Bir son tarihin açık bir sonucu olmalıdır: hukuki bildirim tarihi, süresi dolan sözleşme, müşteri taahhüdü veya planlanmış etkinlik. «Yakında lazım» bir tercihtir, son tarih değildir.

Kullanıma almadan önce şunları doğrulayın:

• Talep sahipleri puanlarını, durumlarını ve değişikliklerin nedenini görebiliyor
• Değerlendiriciler hesaplanan puanı değiştirdiklerinde not kaydediyor
• Ekip bekleyen talepleri sabit bir takvimde inceliyor
• Form etkiyi, çabayı, aciliyeti ve son tarihleri değerlendirmek için yeterli ayrıntıyı topluyor
• Kuyruğun sahibi olan ve puanlarla ilgili soruları yanıtlayan bir kişi bulunuyor

Daha büyük bir sorun geldiği için bir talep geriye düşerse bunu kısa bir güncellemeyle açıklayın. «Yeni bir güvenlik talebi müşteri erişimini engellediği için geriye alındı» ifadesi sessiz bir durum değişikliğinden daha fazla güven verir.

AppMaster bu tür bir kodsuz talep portalı oluşturmak için uygundur. Ekipler bir toplama formu oluşturabilir, yanıtlardan puan hesaplayabilir, talep sahiplerine durumu gösterebilir ve değerlendirici notlarını e-posta zincirlerinde kaybetmek yerine her talebin yanında tutabilir.

Küçük başlayın ve süreci görünür tutun

Hata düzeltmeleri, erişim talepleri ve raporlama değişiklikleri gibi az sayıda talep türüyle tek bir ekipte başlatın. Dar kapsamlı bir deneme, her departman sürece bağlanmadan önce kafa karıştıran soruları fark etmeyi kolaylaştırır.

İlk sürümü basit tutun. Puanlama kurallarını uygulamak için gereken ayrıntıları toplayın, puanı hesaplayın ve mevcut durumu gösterin. Onayları, hatırlatıcıları ve karmaşık yönlendirmeleri yalnızca gerçek bir sorun gerektirdiğinde ekleyin.

İlk ay boyunca gerçek gönderimleri her hafta inceleyin. İnsanların aynı durum için farklı yanıtlar seçip seçmediğine ve herkes kurallara uyduğu halde mantıksız görünen puanlara bakın. Her iki sorun da tanımların daha açık bir dille yazılması gerektiğini gösterir.

Birden fazla talep sahibi küçük bir kolaylığı «acil» olarak adlandırıyorsa tanımı değiştirin. Acil, hizmetin kullanılamaması, müşterinin ücretli bir işi tamamlayamaması veya sabit bir tarihin iki iş günü içinde olması anlamına gelebilir. İnsanlar ekibin öncelikleri özel olarak nasıl tartıştığını bilmeden bir yanıt seçebilmelidir.

Gönderimden sonra talep sahipleri şunları görebilmelidir:

• Puan veya öncelik seviyesi
• Bu sonucu oluşturan faktörler
• Mevcut durum ve sorumlu kişi
• Ekip işi planlamadıysa bir sonraki inceleme tarihi

Görünürlük, her talebin hemen ele alınacağı anlamına gelmez. Talebin alındığını, aynı kuralların uygulandığını ve belirli bir zamanda inceleneceğini görmeleri anlamına gelir. Öncelik değiştiğinde nedeni açık bir dille kaydedin.

Denemeden sonra insanların anladığı bölümleri koruyun ve kimsenin kullanmadığı alanları kaldırın. İnsanların takip edebileceği basit bir süreç, yalnızca oluşturanların anlayabildiği ayrıntılı bir iş akışından daha fazla güven kazanır.