E-posta talebi takibi: basit bir hizmet masası oluşturma

E-posta taleplerini yönetmek neden zorlaşır?

E-posta, talepler az olduğunda ve bunlarla tek bir kişi ilgilendiğinde işe yarar. Birden fazla kişi aynı gelen kutusunu paylaştığında veya talepler sıradan yazışmaların arasına karıştığında sorunlar başlar.

Gelen kutusu gerçek iş yükünü gizler. On yeni mesaj, on küçük görev anlamına gelebilir. Ya da biri acil olmak üzere dokuz rutin sorudan oluşabilir. Yöneticiler, konuşmaları tek tek açmadan hangi talebin kimde olduğunu göremez.

Sorumluluk kolayca belirsizleşir. Bir kişi, son talebi ele alan çalışma arkadaşının bu kez de yanıt vereceğini varsayabilir. Yoğun bir günün ardından bir mesaj, uzun bir yanıt zincirinde okunmadan kalabilir. Talep sahibi yanıt beklerken ekip işin halledildiğini düşünebilir.

Benzer yanıtlar da başka bir sorun yaratır. İki kişi aynı soruya biraz farklı bilgilerle yanıt verebilir. Bu da talep sahibinin hangi yanıtı izleyeceğini bilememesine neden olur. Gelen kutusu işaretleri bu sorunu nadiren çözer, çünkü tüm ekibe değil, tek tek kullanıcılara aittir.

Öncelik de kaybolur. Parola sıfırlama işleminin bugün ele alınması gerekebilirken gelecekte hazırlanacak bir rapor önerisi bekleyebilir. Gelen kutusunda bu iki mesaj da aynı derecede acil görünebilir. Son takibini en yüksek sesle yapan kişi, başka bir talebin daha yakın bir son tarihi olsa bile önce ilgi görebilir.

E-posta talebi takibi, her talebi ortak bir iş kaydına dönüştürür. Her kayıtta açık bir açıklama, adı belli tek bir sorumlu, güncel bir durum ve yanıt veya tamamlanma tarihi bulunmalıdır.

E-postanın tamamen ortadan kalkması gerekmez. İnsanlar uygun olduğunda e-posta kullanmaya devam edebilir. Değişen şey, ekibin tekrarlanan talepleri tek bir yerde kaydetmesi ve bunları dağınık konuşmalar yerine iş olarak yönetmesidir. Basit bir iç hizmet masası kuyruğu görünür kılar, tekrarlanan yanıtları azaltır ve talep sahiplerine sırada ne olduğunu gösterir.

Önce hangi talepleri taşıyacağınızı seçin

Sık gelen ve benzer bir yol izleyen taleplerle başlayın. Bu mesajlar uzun yazışmaların arasında kaybolabilir, tekrar tekrar yönlendirilebilir veya kimin sorumlu olduğu bilinmediği için bekleyebilir.

Birkaç haftalık gelen kutusu trafiğini inceleyin. Yaygın adaylar arasında ortak bir araca veya müşteri hesabına erişim, ekipman ve yazılım lisansı talepleri, başka bir ekibin katkısını gerektiren müşteri sorunları, satın alma onayları ve iletişim bilgilerini güncelleme veya ekibe yeni bir kişi ekleme gibi rutin değişiklikler bulunur.

Her talep türü için kimin ilgileneceğine ve ne kadar hızlı harekete geçmesi gerektiğine karar verin. Erişim talebi BT ekibine gidebilir ve aynı gün yanıt gerektirebilir. Satın alma onayı bir yöneticiye gidebilir ve birkaç iş günü sürebilir. Böylece her talep, sahibi olmayan tek bir kuyruğa düşmez.

İlk sürümü küçük tutun. Net sorumluları, tekrarlanan adımları ve form oluşturmayı haklı çıkaracak kadar yoğunluğu olan iki ila dört talep türü seçin. Bir destek ekibi, şirketten gelen her e-postayı kapsamaya çalışmak yerine müşteri eskalasyonları, hesap erişimi ve iade onaylarıyla başlayabilir.

Nadir görülen, alışılmadık veya hassas durumları başlangıçta e-postada bırakın. Bir kerelik hukuki soru ya da uzun bir görüşme gerektiren talep, sabit bir iş akışına uymaz. Aynı durum düzenli olarak ortaya çıkmaya başladığında yeni bir talep türü ekleyin.

Oluşturmaya başlamadan önce her süreci sade bir dille yazın. Talebi alacak ekibi, beklenen aciliyeti ve ilk adımı belirtin. «BT, erişim taleplerini bir iş günü içinde inceler» ifadesi yön gösterir. «BT erişimle ilgilenir» ifadesi göstermez.

AppMaster, teknik olmayan çalışanların sıfırdan uygulama geliştirmesine gerek kalmadan tekrarlanan talepleri iç formlara ve takip edilen kayıtlara dönüştürmesine yardımcı olabilir. Zaten gelen kutusunda tekrar tekrar iş oluşturan taleplerle başlayın ve ilk iş akışları iyi çalıştıktan sonra kapsamı genişletin.

E-posta mesajlarını kullanışlı formlara dönüştürün

Kısa bir form, iş başlamadan önce ekibin ihtiyaç duyduğu bilgileri toplar. Uzun bir başvuru gibi hissettirmemelidir. Basit bir talebi göndermek on dakika sürerse insanlar e-postaya döner.

Çalışanların takip mesajlarında tekrar tekrar istediği bilgilerle başlayın. Ekipman talebi için kişinin adı, departmanı, istediği ürün, teslimat konumu ve gereken tarih gerekebilir. İşi etkilemeyen alanları çıkarın. Talep sahibi hizmet masası üzerinden güncelleme alıyorsa telefon numarası çok az değer katar.

Talep türü, sorumlu ekip, aciliyet ve konum gibi tekrarlanan yanıtlar için açılır menüler kullanın. Bunlar talepleri tutarlı hale getirir ve sıralamayı kolaylaştırır. Çalışanların kullandığı ifadeleri tercih edin. Bir kişi «sistem desteği» ile «teknik sorun» seçeneklerinden hangisini seçeceğini anlayamıyorsa form, gelen kutusu sorununu yeniden yaratmış demektir.

Ek soruları yalnızca gerektiğinde gösterin

Farklı talep türleri farklı ayrıntılar gerektirir. Koşullu alanlar, her talep sahibini ilgisiz soruları yanıtlamaya zorlamadan formları kısa tutar.

Bir erişim talebi uygulamanın adını, erişim düzeyini, yönetici onayını ve erişimin sona ereceği tarihi sorabilir. Tesis talebi oda numarasını, sorun türünü ve problemin güvenliği etkileyip etkilemediğini sorabilir.

Yalnızca işin başlamasını engelleyen bilgileri zorunlu tutun. İsteğe bağlı alanları açıkça belirtin. Ek açıklama için serbest metin alanı, «Ne oldu ve ne zaman başladı?» gibi belirli bir soru sorduğunda faydalıdır. Sadece «Açıklama» adını taşıyan boş bir alan, kullanıcıya pek yol göstermez.

Talebi açıkça onaylayın

Gönderimden sonra talep sahibine ne olduğunu gösterin. Talep numarasını, talep türünü, talebi alan ekibi ve ekipte böyle bir hedef varsa ilk yanıt için beklenen süreyi ekleyin.

Örneğin: «SR-1042 numaralı talep IT Access ekibine gönderildi. Ekip bir iş günü içinde inceleyecek. Yeni bir e-posta göndermek yerine ek bilgileri bu talebe ekleyin.»

Kodsuz bir uygulama, başvuru formlarını ortak bir portalda tutabilir ve her gönderimi doğru kuyruğa yönlendirebilir. Böylece çalışanlar e-postaları çözümlemek yerine talepleri sonuçlandırmaya daha fazla zaman ayırır.

İnsanların uygulayabileceği sorumluluk kuralları belirleyin

Bir talep, tek bir kayıt ve adı belli tek bir sorumlu olduğunda görmezden gelinmesi zorlaşır. İki kişi aynı sorunu bildirse bile her form gönderimi için bir kayıt oluşturun. Her kaydın kendi geçmişi, durumu ve son tarihi olmalıdır.

İşi yalnızca «BT ekibi» veya «Operasyon» gibi genel bir gelen kutusuna atamayın. Herkes talebi görebilir, ancak kimsenin harekete geçmesi gerektiği net olmaz. Bir kişiye atayın. Bu kişi yardım isteyebilir, ancak talebi ilerletmekten veya açık biçimde devretmekten yine o sorumlu kalır.

Örneğin bir erişim talebi BT ekibindeki Priya'ya gidebilir. Priya'nın yönetici onayına ihtiyacı varsa onayın gelmesini yine o takip eder ve talep sahibini bilgilendirir.

Her kayıtta talep sahibinin adı ve iletişim bilgileri, talep türü, gönderim tarihi ve saati, adı belli sorumlu, yedek sorumlu ve güncel durum bulunmalıdır. Yedek sorumluyu biri izinli olduğunda aramak yerine talep türünü oluştururken belirleyin. Yedek sorumlunun yanıt verebilmesi, işi yeniden atayabilmesi veya talebi kapatabilmesi için yeterli erişimi ve bağlamı olmalıdır.

Devirlerde de aynı netlik gerekir. Bir talep İK'dan BT'ye geçtiğinde ilk sorumlu, adı belli bir kişiyi atamalı, neler olduğunu kısaca not etmeli ve durumu güncellemelidir. Yeni sorumlu devri kabul etmelidir. Sadece durumun değişmesi, birinin işi gördüğünü göstermez.

AppMaster kayıtları sorumlu, yedek sorumlu, gönderim zamanı, tür ve durum alanlarıyla modelleyebilir. Görsel iş süreci araçları, form gönderimlerini ekibin belirlediği kurallara göre yönlendirebilir. Yönlendirme boşluklarının işlerin gece boyunca beklemesine neden olmaması için atanmamış talepleri her iş günü inceleyin.

Neler olduğunu gösteren durumları kullanın

Başlangıçtaki durum kümesini küçük tutun: yeni, devam ediyor, beklemede, çözüldü ve kapatıldı. Bu etiketler talep sahiplerine işin hangi aşamada olduğunu gösterir ve ekibin ilgi gerektiren işleri fark etmesine yardımcı olur.

Yeni bir talep hizmet masasına ulaşmıştır, ancak henüz kimse kabul etmemiştir. Bir kişi sorumluluğu alıp işe başladığında durumu devam ediyor olarak değiştirin. Ekip istenen işi tamamlayıp talep sahibine bilgi verdiğinde çözüldü olarak işaretleyin. Talep sahibi sonucu onayladıktan veya ekibin belirlediği inceleme süresi sona erdikten sonra kapatın.

Beklemede durumunu açıklayın

«Beklemede» durumu, işin neden durduğunu ve sırada kimin harekete geçmesi gerektiğini belirtmelidir. Başlangıçta kayda «talep sahibinden yanıt bekleniyor» veya «BT güvenliği bekleniyor» gibi bir neden ekleniyorsa tek bir bekleme durumu yeterli olabilir.

Yoğunluk arttıkça talep sahibinden yanıt bekleme ile başka bir ekipten yanıt beklemeyi ayırın. Atanan sorumlu; ad, onay, ekran görüntüsü veya başka bir eksik bilgi göndermemiş talep sahibine hatırlatma yapmalıdır. Başka bir ekibin yanıtını bekleyen talep için iç eskalasyon gerekebilir. Her iki durum da görünür kalmalıdır.

Her durum için kısa bir kural yazın. Ekip üyesi bir talebi üstlendiğinde yeni durumundan devam ediyor durumuna geçirir. Bir yanıt veya dışarıdan bir işlem gerektiğinde beklemeye alır. İşi tamamlayıp sonucu açıkladığında çözüldü durumuna geçirir.

Farklı bir günlük karar gerektirmiyorsa «kuyrukta», «atandı» veya «inceleniyor» gibi ek etiketlerden kaçının. Çok fazla seçenek tutarsız güncellemelere yol açar ve talep sahiplerinin kafasını karıştırır.

İşe uygun yanıt süresi hedefleri oluşturun

Yanıt süresi hedefleri, talep sahiplerine ne zaman yanıt bekleyebileceklerini söyler. Ayrıca kuyruk sözde acil mesajlarla dolmadan önce ekibin işleri sıralamasına yardımcı olur.

Talep türüne göre farklı hedefler belirleyin. Kilitli bir hesap için bir saat içinde yanıt gerekebilirken yeni bir rapor talebi bir sonraki iş gününe kadar bekleyebilir. Her talebe aynı son tarihi vermek rutin işleri acil gösterir ve gerçekten acil sorunların beklemesine neden olur.

İlk yanıtı tamamlanmış talepten ayırın

İki süreyi takip edin. İlk yanıt, birinin sorumluluğu ne kadar hızlı doğruladığını veya eksik bilgi istediğini ölçer. Çözüm süresi ise ekibin işi tamamlamasının ne kadar sürdüğünü gösterir.

Hızlı yanıt, talebin tamamlandığı anlamına gelmez. Yazılım erişimi isteyen bir kişi iki saat içinde «Bu talebi aldım, yönetici onayı gerekiyor» yanıtını alabilir. Onay ve hesap kurulumu ayrı işlemler olduğu için talebin tamamı iki iş günü sürebilir.

Ekibin karşılayabileceği hedefler kullanın. Örneğin:

• Erişim veya hesap kilitlenmesi: ilk yanıt 1 iş saati içinde, çözüm 8 iş saati içinde
• Bordro veya müşteri sorunu: ilk yanıt 4 iş saati içinde, çözüm 2 iş günü içinde
• Standart ekipman veya rapor talebi: ilk yanıt 1 iş günü içinde, çözüm 5 iş günü içinde
• Planlı değişiklik talebi: ilk yanıt 2 iş günü içinde, incelemeden sonra üzerinde anlaşılacak bir çözüm tarihi

Çalışma günleri, mesai saatleri ve tatiller dahil olmak üzere iş saatlerini tanımlayın. Cuma günü geç gönderilen bir talep, hafta sonu kimse çalışmadığı halde cumartesi günü gecikmiş görünmemelidir.

Son tarih geçmeden önce sorumlulara uyarı gönderin. İzin verilen sürenin %75'i veya %80'i dolduğunda gönderilen bir hatırlatma, sorumluya talep sahibini güncelleme, yardım isteme veya işi yeniden atama fırsatı verir. Net güncellemeler gereksiz takip e-postalarını çoğu zaman önler.

AppMaster'da ekip, talep türünü, aciliyeti, sorumluyu, durumu ve hedef süreleri tek bir kodsuz uygulamada saklayabilir. Bir iş süreci, seçilen talep türüne göre son tarihleri hesaplayabilir ve son tarih yaklaşırken sorumluya uyarı gönderebilir. Gerçek talep verilerini birkaç hafta inceledikten sonra hedefleri ayarlayın.

Örnek: bir erişim talebini ele almak

Yeni bir satış koordinatörünün pazartesiden önce ekibin satış aracına erişmesi gerekiyor. Ortak bir gelen kutusuna e-posta göndermek yerine iç hizmet masası formunu dolduruyor. Talep, hem çalışanın hem de destek ekibinin daha sonra bulabileceği bir referans numarası alıyor.

Formda çalışanın adı ve iş e-postası, satış aracı ve erişim düzeyi, departmanı, yöneticisinin adı ve erişimin gerektiği tarih soruluyor.

Hizmet masası talebi operasyon desteğine yönlendiriyor ve adı belli bir sorumlu atıyor. Rol hassassa iş akışı, çalışanın yöneticisine bir onay görevi gönderiyor.

Sorumlu, dört iş saati içinde talebi kabul ediyor: «Talebiniz onay için yöneticinize iletildi. Yanıt verdiğinde sizi bilgilendireceğiz.» Durum beklemede olarak değişiyor ve neden «onay bekleniyor» şeklinde kaydediliyor. Hizmet masası belirlenen sürenin ardından yöneticiye hatırlatma gönderebilir, ancak talebin sorumluluğu yine ilk kişide kalır.

Onaydan sonra sorumlu doğru rolü veriyor ve çalışan erişimi test ederken talebi yeniden devam ediyor durumuna getiriyor. Çalışan giriş yapabildiğini ve beklenen izinleri gördüğünü onayladığında sorumlu talebi çözüyor ve kapatıyor. Bir sorun varsa aynı kayıt açık kalıyor. Kimsenin eski e-posta zincirlerini araması gerekmiyor.

Taleplerin gözden kaçmasına neden olan hatalar

Kuralları eski gelen kutusundan daha fazla çaba gerektiriyorsa hizmet masası da işleri kaybedebilir. Uzun formlar, belirsiz sorumluluk ve erken kapatma yaygın nedenlerdir.

Her e-posta ayrıntısını forma kopyalamayın. Bir erişim talebi için ekip genellikle sistem adını, istenen erişim düzeyini, erişime ihtiyaç duyan kişiyi ve nedeni bilmelidir. Uzun bir e-posta konu alanı veya yinelenen iletişim adresi pek değer katmaz. Ek soruları yalnızca talep türü gerektirdiğinde gösterin.

Bir grup talebi alabilir, ancak sıradaki işlemden tek bir kişi sorumlu olmalıdır. Yardıma ihtiyaç duyarsa talebi yeniden atayabilir. Yanıt beklerken işi atanmamış bırakmamalıdır. Atanmamış ve gecikmiş işleri gösteren günlük bir görünüm, talep sahipleri ekibe e-posta ile ulaşmadan önce sorunları yakalar.

Ekip yalnızca iç görevini tamamladığında talebi çözülmüş olarak işaretlemeyin. Bir yönetici hesap oluşturmuş olabilir, ancak kullanıcı erişim talimatlarını alana veya giriş yapabildiğini onaylayana kadar talep açık kalmalıdır.

Hedefler gerçek personel kapasitesi yerine ideal iş yükünü yansıttığında da başarısız olur. Küçük bir destek ekibinin başka görevleri de varken her talep için bir saatlik söz vermek, kaçırılan son tarihlere yol açar. Hedefleri son dönemdeki talep hacmine ve kullanılabilir saatlere göre belirleyin, ardından ilk birkaç haftadaki gecikmeleri inceleyin. Tekrarlanan gecikmeleri formları sadeleştirerek, kapsamı genişleterek veya ekibin tutarlı biçimde karşılayabileceği bir hedef belirleyerek düzeltin.

Yayına almadan önce hızlı kontroller

İş akışını talepler için standart yol haline getirmeden önce küçük bir grupla test edin. Gerçek talepleri baştan sona inceleyin.

Her yeni kayıtta bir sonraki işlemden sorumlu adı belli bir kişi bulunmalıdır. Talep onay bekliyorsa ilk sorumluyu görünür tutun ve kimin yanıt vermesi gerektiğini kaydedin. Birkaç gün içinde uzun bir yazışmayı açmadan şu üç soruyu yanıtlayabilmelisiniz: bunun sorumlusu kim, hangi durumda ve ne zaman harekete geçilmesi gerekiyor?

Her durumun yanına kısa tanımlar yazın. İki veya üç çalışandan aynı örnek talepleri sınıflandırmasını isteyin. Farklı durumlar seçerlerse insanların tahmin yürütmesini beklemek yerine tanımları gözden geçirin.

Gecikmiş ve bekleyen talepleri her hafta inceleyin. İnsanların boş bıraktığı bir alan, sürekli onay gerektiren bir görev veya kapasitesinden fazla iş alan bir ekip olup olmadığına bakın. Tekrarlanan bir gecikmeyi yalnızca hatırlatıcılar genellikle çözmez.

Talep sahiplerine formun anlaşılır olup olmadığını sorun. Uygulama adı, erişim düzeyi, yönetici veya gereken tarih bilgilerini içeren takip e-postaları göndermeye devam ediyorlarsa bu alanları ekleyin veya netleştirin.

Hizmet masanızı günlük kullanıma alın

Yazılım erişimi, ekipman veya tesis sorunları gibi sık görülen tek bir talep türüyle ve tek bir ekiple başlayın. Sınırlı bir ilk sürüm, insanların forma alışması ve ekibin eksikleri pratik biçimde bulması için zaman kazandırır.

Talep sahiplerine işi nereye göndereceklerini ve hangi bilgileri ekleyeceklerini anlatın. Kısa bir geçiş dönemi için eski ortak gelen kutusunu açık tutun, ancak her e-posta talebinin bir sorumlusu ve durumu olması için çalışanların bu talepleri hizmet masasına eklemesini sağlayın. Ardından formu standart yol haline getirin.

İlk ayın kayıtlarını inceleyin. Kullanılmayan alanları kaldırın, sık sık yeniden atamaya yol açan kategorileri araştırın ve gerçek çabayla uyuşmayan hedefleri değiştirin. Bir sorunun yanıtı, talebi kimin ele alacağını veya ne yapması gerektiğini değiştirmiyorsa o soruyu eklemeyin.

Basit bir pano günlük yönetime yardımcı olur. Türe göre yeni talepleri, ilk yanıt ve tamamlanma sürelerini, sorumlu ve duruma göre açık işleri, gecikmiş öğeleri ve yeniden açılan talepleri takip edin. Sayıları kısa bir haftalık toplantıda değerlendirin. Erişim talepleri, hepsini tek bir yöneticinin onaylaması nedeniyle hedefleri kaçırıyorsa yedek bir onaylayan ekleyin veya iş akışını değiştirin.

AppMaster; başvuru formlarını, sorumluluk iş akışlarını, durum kurallarını ve panoları tek bir uygulamada bir araya getiren kodsuz iç hizmet masalarını destekler. Ekipler web erişimi sunabilir ve çalışanların masa başında değilken talep göndermesi veya güncellemesi gerektiğinde yerel mobil uygulamalar oluşturabilir.

Yayına aldıktan sonra süreci geliştirmeye devam edin. Talep sahiplerine formun anlaşılır olup olmadığını, taleplerle ilgilenen kişilere ise işlerin nerede takıldığını sorun. Gerçek kayıtlara dayanan küçük değişiklikler, hizmet masasının başka bir gelen kutusuna dönüşmek yerine işe yaramaya devam etmesini sağlar.