Ortak e-posta takma adlarını vaka yönetimi uygulamasıyla değiştirin

Ortak takma adlar neden karmaşa yaratır?

support@ veya it@ gibi ortak bir adres basit görünür. Ekipteki herkes gelen mesajları okuyup yanıtlayabilir. Ancak gelen kutusu çoğu zaman bir talebin kime ait olduğunu, çalışmanın ne zaman başladığını veya sırada ne olduğunu göstermez.

İnsanlar bu boşluğu alışkanlıklarla doldurur. Biri e-postayı işaretler, bir başkası klasöre taşır, üçüncü kişi de mesaj gelen kutusunun üstünden kaybolduğu için bir başkasının ilgilendiğini varsayar. Bu işlemlerin hiçbiri bir sorumlu belirlemez.

Hizmetin tutarlılığı bozulur. Doğru kişi talebi gördüğü için basit bir isteğe birkaç dakika içinde yanıt verilebilir. Daha acil bir talep ise herkes başka birinin ilgilendiğini düşündüğü için günlerce bekleyebilir.

E-posta sorumluluğu gizler

E-posta dizileri işi değil, mesajları takip eder. Bir talep yöneticinin onayını, başka bir sistemde kontrol yapılmasını ve talep sahibine son bir güncelleme gönderilmesini gerektirebilir. Dizi, bu işlemlerin yalnızca bazı parçalarını yanıtların, iletilen mesajların ve özel notların arasında gösterir.

Ekipler çoğu zaman "[Atanan: Mia]" gibi konu etiketlerini veya "Devam ediyor" adlı klasörleri dener. Bu yöntemler yalnızca herkes her seferinde aynı rutine uyduğunda işe yarar. İş başka birine devredildiğinde veya katkı sunması gereken birkaç ekip olduğunda sistem dağılır.

Vaka yönetimi uygulaması her talep için görünür tek bir kayıt oluşturur. Bu kayıtta sorumlu, öncelik, durum, son tarih ve geçmiş gösterilebilir. Çalışanların artık okunmamış işaretlerinden veya bir iş arkadaşının belirsiz yanıtından tahmin yürütmesi gerekmez.

Çift yanıtlar zaman ve güven kaybettirir

Özellikle yoğun bir sabahın veya hafta sonunun ardından iki kişi aynı yeni e-postayı açabilir. İkisi de yanıt vermeden önce incelemeye başlayabilir. Talep sahibi daha sonra bazen birbiriyle çelişen iki mesaj alır.

Talep sahibi yalnızca tek bir yanıt görse bile çift çalışma zaman kaybettirir. İki çalışan aynı hesabı sıfırlamak veya aynı ayrıntıları toplamak için 20'şer dakika harcarsa ekip 20 dakika kaybeder ve diğer talepler daha uzun süre bekler.

Vaka yönetimi uygulaması, biri talebi üzerine aldığında onu atar. Diğer ekip üyeleri dahili not ekleyebilir veya bir görevde yardımcı olabilir, ancak son yanıtı kimin göndereceğini herkes görebilir.

Talep sahipleri de bu karmaşayı yaşar. E-posta gönderir, otomatik bir alındı mesajı alır ve sonra hiçbir şey duymazlar. Ekibin daha fazla bilgiye ihtiyacı olup olmadığını, talebin onaylanıp onaylanmadığını veya gözden kaçıp kaçmadığını bilemezler. Birçoğu takip e-postaları gönderir; bu da ek diziler ve daha fazla çift çalışma ihtimali yaratır.

Net talep durumu takibi bu deneyimi değiştirir. "Alındı", "Onay bekleniyor", "Devam ediyor" ve "Tamamlandı" gibi etiketler insanlara doğrudan yanıt verir. Ekipler ortak e-posta takma adlarını vaka kayıtlarıyla değiştirdiğinde her talebin bir yeri, belirli bir sorumlusu ve tamamlanmaya giden görünür bir yolu olur.

Vaka yönetimiyle ne değişir?

Vaka yönetimi uygulaması her talebi net bir sorumlusu, güncel durumu ve eksiksiz geçmişi olan tek bir vakaya dönüştürür. Talepler formlardan, e-postalardan veya başka bir ekipten gelen mesajlardan başlayabilir. Uygulamaya girdikten sonra çalışanlar kopyaları gelen kutusunda dolaştırmak yerine aynı kayıt üzerinden çalışır.

Ortak takma ad, her mesajı ayrı bir olay gibi ele alır. Biri yanıtlar, diğeri diziyi iletir, üçüncüsü özel bir sohbete not ekler. Talep sahibi iki yanıt alabilir veya hiç yanıt alamayabilir. Çalışanlar kimin ne yapmayı kabul ettiğini bulmak için uzun dizileri aramak zorunda kalır.

Vaka kaydı bağlamı tek bir yerde tutar. İş ekipler arasında ilerlerken sorumluluk değişebilir, ancak vaka aynı kalır. "Yeni", "Devam ediyor", "Talep sahibi bekleniyor" ve "Kapalı" gibi durumlar çalışanlara ve talep sahiplerine sürecin nerede olduğunu gösterir.

Birden fazla dizi yerine tek kayıt

Bir çalışanın finans klasörüne erişim istediğini düşünün. Ortak posta kutusunda yöneticinin onayı bir e-postada, BT'nin sorusu başka bir e-postada ve son doğrulama üçüncü bir e-postada olabilir. Sonradan ekibe katılan herkes hikâyeyi yeniden kurmak zorunda kalır.

Vakada erişim talebi çalışanın bilgilerini, onayı, dahili notları, ekleri ve tüm durum değişikliklerini içerir. BT sorumlusu işlem yapmadan önce kaydın tamamını görür. Yardım etmesi gereken bir iş arkadaşı yeni bir e-posta zinciri başlatmak yerine vakaya not ekler.

Her vaka, bir sonraki işlemin kimde olduğunu göstermelidir. Hiç kimse sahiplenmediyse ekip lideri boşluğu hızla fark edebilir. Sorumlunun görüşe ihtiyacı varsa talebi gelen kutusuna gömmek yerine görev atayabilir veya vakayı bekleme durumuna taşıyabilir.

Notlar ve geçmiş taleple birlikte kalır

Dahili notlar, talep sahiplerinin görmemesi gereken ayrıntıların çalışanlar arasında konuşulmasını sağlar. Herkese açık güncellemeler ise talep sahibine ekibin daha fazla bilgiye ihtiyaç duyduğunu, talebi onayladığını veya belirli bir tarihe kadar tamamlamayı beklediğini bildirebilir. Çalışanların hassas görüşmeleri dışarı gönderilen bir e-postaya kopyalaması gerekmez.

Geçmiş, atamaları, yanıtları ve durum değişikliklerini kaydeder. Talep sahibi iki hafta sonra takip ettiğinde veya sorumlu izne çıktığında bu kayıt yardımcı olur. Vaka yönetimi uygulamasıyla iş tek bir kişinin posta kutusuna değil, ekibe ait olur.

Bugün aldığınız talepleri haritalayın

Uygulamayla değil, gelen kutusuyla başlayın. Her ortak takma adın aldığı dört ila sekiz haftalık mesajları inceleyin. Amaç, formları varsayımlara göre tasarlamak yerine insanların gerçekte ne istediğini öğrenmektir.

Benzer e-postaları talep türlerinde gruplayın. Bir BT gelen kutusunda erişim, donanım, yazılım sorunları, hesap değişiklikleri ve basit sorular bulunabilir. Her tür için ayrı iş akışı gerekmez, ancak her türün net bir kategorisi olmalıdır.

E-posta kalıplarını vaka türlerine dönüştürün

Her kategori için ekibin işe başlamadan önce ihtiyaç duyduğu bilgileri listeleyin. Uygulama erişimi talebinde çalışanın adı, departmanı, yönetici onayı, uygulama adı ve erişim gerekçesi bulunabilir. Dizüstü bilgisayar sorununda ise cihaz, hata mesajı ve aciliyet gibi farklı bilgiler gerekir.

Kısa bir listeyle başlayın. Çok fazla kategori formu kullanmayı zorlaştırır ve insanları yeniden e-postaya yönlendirir. Ekip tekrarlanan bir ihtiyaç görürse geniş bir kategoriyi daha sonra bölebilirsiniz.

• Talep türü ve kısa açıklama
• Talep sahibinin sağlaması gereken ayrıntılar
• Olağan sorumlu veya sorumlu ekip
• Durum aşamaları ve beklenen yanıt süresi
• Gerekli onay, güvenlik incelemesi veya devir

Bu harita, her vaka kuyruğa girdiğinde yeterli bağlamı taşır. Ayrıca çalışanların her talep sahibine aynı takip sorularını sormasını önler.

Her talebe bir yer verin

Birden fazla kişi işi tamamlayabilse bile her kategori için sorumlu ekibi veya rolü belirleyin. "BT" çoğu zaman fazla geniştir. "Kimlik yöneticisi", "cihaz desteği" ve "finans onaycısı" gibi etiketler yararlı yönlendirme kurallarını destekler ve beklentileri netleştirir.

Bazı talepler ekip sınırlarını aşar. Tek bir vaka tutun, tek bir güncel sorumlu atayın ve devirleri kaydın içinde tutun. Cihaz desteği, satın alma ekibinin donanım sipariş etmesi gerekene kadar yeni dizüstü bilgisayar talebinin sorumlusu olabilir. Satın alma ekibine ayrı bir e-posta dizisi değil, görev veya devir gönderilir.

İlk değiştireceğiniz takma adları hacme ve karmaşaya göre seçin. it-support@ veya access@ gibi tekrarlanan talepler alan ve birden fazla kişinin yanıt verdiği bir gelen kutusuyla başlayın. Ekip süreç üzerinde anlaşana kadar alışılmadık veya hassas talepleri sonraya bırakın.

Vaka yönetimi uygulaması bu haritayı yaygın talepler için formlar, yönlendirme kuralları ve görünür talep durumu takibiyle günlük kullanıma taşıyabilir. AppMaster'da ekipler gereken alanları modelleyebilir, onay adımları oluşturabilir ve kod yazmadan talep sahipleri ile çalışanlar için ayrı görünümler hazırlayabilir.

İlk uygulama sürecinde özgün takma adı etkin tutun, ancak yeni talepleri vaka formuna yönlendirin. Birkaç hafta boyunca yeni vakaları gelen e-postalarla karşılaştırın. Çalışanlar değişim sürecinde insanlara yardımcı olmaya devam ederken eksik kategoriler ve belirsiz alanlar ortaya çıkar.

Uygulamayı adım adım kurun

Talep formuyla başlayın. İnsanların kullanacağı kadar kısa, ekibin takip e-postaları zinciri olmadan işe başlayabileceği kadar kapsamlı olsun. Tesis talebinde ofis konumu, sorun türü, aciliyet ve kısa açıklama istenebilir. BT erişim talebinde çalışanın departmanı, gereken uygulama, yöneticisi ve erişim tarihi gerekebilir.

Alanları yalnızca ekip onlarsız çalışamayacaksa zorunlu yapın. Uzun formlar insanları ayrıntıların tutarsız biçimlerde geldiği e-postaya geri iter.

İnsanların anlayacağı bir durum akışı oluşturun

Her talebe, mevcut durumunu sade bir dille açıklayan bir durum verin. Basit bir başlangıç akışı çoğu ekip için yeterlidir:

• Yeni: uygulama talebi aldı, ancak kimse çalışmaya başlamadı.
• Devam ediyor: bir sorumlu talep üzerinde çalışıyor.
• Bekliyor: sorumlu başka birinden bilgi, onay veya işlem bekliyor.
• Kapalı: ekip talebi tamamladı veya yapılacak bir işlem olmadığını doğruladı.

Talep sahibi için ilgili durumu gösterin. Böylece ortak gelen kutusuna "Bir gelişme var mı?" diye yazmak yerine ilerlemeyi kontrol edebilir. Ekibin ne yaptığını anlaması için kısa bir kapanış notu ekleyin.

Yönlendirme ve yeniden atama kuralları ekleyin

Her talep türünü kimin alacağına karar verin. Kurallar departman, kategori, konum veya aciliyet gibi form yanıtlarını kullanabilir. Finans yazılımlarına erişim talepleri finans sistemleri sorumlusuna, dizüstü bilgisayar sorunları masaüstü desteğine gidebilir.

Birden fazla kişi katkı sunsa bile her vakaya tek bir isimli sorumlu atayın. Bu, sorumluluğu netleştirir ve çift çalışmayı önlemeye yardımcı olur. İş arkadaşları ikinci bir yanıt yazmadan önce birinin vakayı zaten aldığını görebilir.

Sorumluların basit bir yeniden atama seçeneğine de ihtiyacı vardır. İnsanlar izne çıkar, iş yükleri değişir ve bazı talepler yanlış kuyruğa girer. Sorumludan yeni sorumluyu seçmesini ve "BT erişim verebilmeden önce bunun bordro onayı alması gerekiyor" gibi kısa bir dahili not bırakmasını isteyin. Böylece geçmiş, talep sahibine dahili görüşmeleri göstermeden devri açıklar.

AppMaster ekiplerin formları, durum akışlarını ve yönlendirme kurallarını görsel olarak modellemesini sağlar. Ekipler ayrıca talep sahipleri için güncel durum ve herkese açık güncellemelerin bulunduğu bir sayfa, çalışanlar için de atama ve dahili görüşmelerin yer aldığı ayrı bir alan oluşturabilir.

Şirketin tamamını davet etmeden önce akışı beş gerçekçi taleple test edin. Her talebin bir sorumlu aldığını, durum değişikliklerinin doğru göründüğünü ve yeniden atanan işin geçmişini koruduğunu doğrulayın. Buradaki küçük düzeltmeler ilk haftanın karmaşasını önler.

Çalışmayı çift yanıt olmadan yönlendirin

Çift yanıtlar genellikle basit bir boşlukla başlar: iki kişi aynı e-postayı görür ve diğerinin başlayıp başlamadığını bilmez. Vaka yönetimi uygulaması her talebi tek sorumlusu olan görünür bir kayda dönüştürerek bu boşluğu kapatır.

Yeni bir talep geldiğinde talep sahibinin e-posta adresini açık vakalarda arayın. Çalışanlar eşleşme bulursa yeni bir vaka oluşturmadan önce mevcut vakayı görmelidir. Not ekleyebilir, yeni mesajı iliştirebilir veya talep sahibine özgün vakanın zaten devam ettiğini bildirebilirler.

Her vakanın üst kısmında sorumluyu ve durumu gösterin. Yeni, Atandı, Talep sahibinden bilgi bekleniyor, Devam ediyor ve Kapalı gibi net etiketler kullanın. Kuyruğu tarayan herkes talebi kimin yönettiğini ve işlem yapması gerekip gerekmediğini hızla görebilmelidir.

Basit bir atama kuralı da yardımcı olur. Hesap erişimiyle ilgili bir talep BT destek kuyruğuna gidebilir ve bir destek çalışanı talebi üzerine alabilir. Üzerine alındığında vaka o kişinin adını gösterir ve atanmamışlar listesinden çıkar. Diğer ekip üyeleri kaydı okuyabilir, ancak sorumlu yeniden atamadıkça ayrı bir yanıt göndermemelidir.

Ekip görüşmelerini talep sahibiyle iletişimden ayrı tutun. Her vakada bağlam, devirler, sorun giderme ve iş arkadaşlarına sorular için dahili notlar bulunmalıdır. Ayrıca talep sahibinin okuyabileceği mesajlar için talep sahibi güncellemeleri yer almalıdır. Böylece eksik bir onayla ilgili özel yorumların talebi oluşturan çalışana gitmesi önlenir.

Net bir takip kuralı belirleyin: Birkaç iş arkadaşı dahili not eklese bile bir sonraki dış yanıtı sorumlu gönderir. Bir yöneticinin devralması gerekiyorsa önce vakayı yeniden atar. Bu alışkanlık çelişkili yanıtları önler ve talep sahibine güvenilir tek bir iletişim noktası verir.

Geçiş sırasında ekipler çoğu zaman eski adresi kullanmaya devam eder. Gelen kutusundan yanıt vermek yerine her e-postayı uygulamaya gönderin ve görüşmeyi vaka kaydından yönetin. Ortak adres talep sahipleri için tanıdık kalırken arkasındaki çalışma görünür hale gelir.

Örnek: dahili bir BT erişim talebi

Maya satış ekibine katılmıştır ve ilk müşteri görüşmesinden önce bir raporlama aracına erişmesi gerekir. Ortak bir BT takma adı kullandığında kısa bir e-posta gönderip bekleyebilir. Birkaç kişi bunu görebilir, hiç kimse üzerine almayabilir ve Maya iki gün sonra tekrar yazabilir.

Vaka yönetimi uygulamasında Maya bir "Erişim talebi" formu açar. Raporlama aracını seçer, iş gerekçesini yazar, yöneticisini seçer ve talebi gönderir. Uygulama IT-1042 vakasını oluşturur ve durumunu "Gönderildi" olarak gösterir.

Vaka net bir yol izler:

1. Uygulama vakayı onay için Maya'nın yöneticisine gönderir.
2. Onayın ardından yönlendirme kuralları vakayı BT erişim kuyruğuna gönderir.
3. Bir BT çalışanı vakayı üzerine alır ve sorumlusu olur.
4. Sorumlu erişimi verir, işlemi kaydeder ve vakayı kapatır.

Her kişi kendisine ait görevi görür. Yönetici bir e-posta dizisi yerine onay talebi alır. BT sorumlusu, Maya'nın seçtiği araç ve gerekçeyle birlikte onaylanmış talebi alır. Diğer BT çalışanları IT-1042'nin bir iş arkadaşına ait olduğunu görebilir. Böylece erişimi iki kez vermez veya başka bir yanıt göndermezler.

Maya talep sayfasını açıp mevcut aşamayı kontrol edebilir. Yöneticisi inceleme yaparken sayfada "Yönetici onayı bekleniyor" yazar. Onaydan sonra "BT'ye atandı" görünür. Sorumlunun daha fazla bilgiye ihtiyacı olursa Maya vaka içinden bir mesaj alır ve aynı yerde yanıt verir.

Vaka geçmişi talebi kimin onayladığını, kimin tamamladığını ve her durumun ne zaman değiştiğini kaydeder. BT daha sonra Maya'nın neden erişim aldığını veya talebin ne kadar sürdüğünü açıklayabilir.

Ekipler genellikle erişim talepleriyle başlar, çünkü iş akışı tanıdık ve ölçülmesi kolaydır. AppMaster'da ekipler formu, onay adımlarını, sahiplik kurallarını, durum sayfasını ve bildirimleri görsel araçlarla oluşturabilir. Aynı yapı daha sonra donanım taleplerini, hesap değişikliklerini ve işe alım görevlerini de destekleyebilir.

Geçiş sırasında sık yapılan hatalar

Gelen mesajları vaka yönetimi uygulamasına taşımak tek başına yeterli değildir. Ekipler eski alışkanlıkları yeni araçta yeniden oluşturabilir: çalışanlar işi sohbette üzerine alır, durumlar kişiden kişiye farklı anlamlara gelir ve talep sahipleri iş tamamlanana kadar hiçbir şey duymaz.

Sorumluluğu görünür tutun

Bir vakayı hafıza, sözlü anlaşma veya gayriresmî sohbet mesajıyla atamayın. Bu yöntemler biri izin aldığında, görüşme hızlandığında veya iki kişi aynı talebi okuduğunda ortadan kaybolur. Her açık vakanın uygulamada isimli tek bir sorumlusu olmalıdır.

Öncelikler değiştiğinde bir destek lideri vakayı yeniden atayabilir, ancak kayıt şu anda kimin sorumlu olduğunu göstermelidir. Bir çalışan finans klasörüne erişim istediğinde vaka hizmet masasından güvenlik onaycısına geçebilir. Çalışan talebin nereye gittiğini tahmin etmek zorunda kalmamalıdır.

Her kuyruk için yedek bir sorumlu belirleyin. Atanan kişi kararlaştırılan süre içinde işlem yapmadıysa yedek sorumlu bir uyarı alır ve devralıp devralmayacağına karar verir. Bu kural izinlerde, hastalık günlerinde ve yoğun dönemlerde yardımcı olur.

Durum etiketlerini tutarlı kullanın

Uzun durum menüleri karmaşa yaratır. Etiketleri sade tutun ve her birini net biçimde tanımlayın:

• Yeni: ekip talebi aldı, ancak henüz incelemedi.
• Devam ediyor: bir sorumlu aktif olarak üzerinde çalışıyor.
• Talep sahibinden bilgi bekleniyor: sorumlunun bilgiye veya onaya ihtiyacı var.
• Başka bir ekip bekleniyor: iş başka birine bağlı.
• Kapalı: talep sahibi sonucu veya net bir son güncellemeyi aldı.

Çalışanların vakaları sessizce kapatmasına izin vermeyin. Kapatmadan önce sorumlu ne olduğunu, talep sahibinin bundan sonra ne yapması gerektiğini ve gerekiyorsa erişim veya hizmetin ne zaman hazır olacağını açıklayan kısa bir güncelleme göndermelidir. Vaka yalnızca işlemi yapan ekip için değil, talepte bulunan kişi için de tamamlanmış hissettirmelidir.

Çalışanlar uygulamayı isteğe bağlı görüp eski takma ad üzerinden yanıt vermeye devam ettiğinde çift çalışma da geri döner. Bir geçiş tarihi belirleyin, yeni talepleri uygulamaya yönlendirin ve e-posta takibini eşleşen vakaya kaydedin. İki kişi çalışmaya başlarsa devam edecek kişiyi isimli sorumlu belirlemeli ve kısa bir not eklemelidir.

AppMaster bu kuralları uygulamanın içine yerleştirebilir. Görsel bir iş süreci çalışmaya başlamadan önce sorumlu atanmasını zorunlu kılabilir, kapanıştan önce talep sahibine güncelleme gönderebilir ve asıl atanan kişi uygun olmadığında vakayı yedek sorumluya taşıyabilir.

Başlatmadan önce hızlı kontroller

Ortak e-posta takma adlarını herkes için değiştirmeden önce gerçek taleplerle kısa bir test yapın. Birkaç çalışandan vaka göndermelerini, atamalarını, durumlarını değiştirmelerini ve kapatmalarını isteyin. Bu, risk düşükken belirsiz alanları veya eksik bildirimleri ortaya çıkarır.

Her yeni talebin tek bir isimli sorumlusu olmalıdır. Bir kuyruk atanmamış vakaları kısa süre tutabilir, ancak çalışma başlamadan önce birinin sorumluluk alması gerekir. İki kişi birbirinin etkinliğini görmeden aynı vaka üzerinde çalışabiliyorsa çift yanıtlar geri döner.

Atama kurallarını yaygın taleplerle karşılaştırın. Parola sıfırlama doğrudan BT desteğine gidebilir, yeni yazılım lisansı ise önce onay gerektirebilir. Yanlış kuyruğa giren vakalar için çalışanlara basit bir yedek kural verin.

Her kişinin görünümünü test edin

Çalışanların her kaydı açmadan açık vakaların listesini, durumunu, sorumlusunu, alınma tarihini ve talep sahibini net biçimde görmesi gerekir. Yeni, Talep sahibinden bilgi bekleniyor, Devam ediyor ve Kapalı gibi ekibin kullandığı dil ile uyumlu durum adları kullanın.

Uygulama görünür bir geçmiş tutmalıdır. Bir vakayı devralan herkes önceki mesajları, onayları ve durum değişikliklerini görmelidir. Bu kayıt, talep sahiplerinin aynı sorunu her yeni kişiye yeniden anlatmasını önler.

Anlamlı bir değişiklik olduğunda talep sahiplerinin güncelleme aldığını doğrulayın. Birinin vakayı kabul ettiği, ekibin daha fazla ayrıntıya ihtiyaç duyduğu ve işin tamamlandığı zamanlarda mesaj gönderin. Her dahili düzenleme için uyarı göndermeyin; çok fazla bildirim insanların uyarıları görmezden gelmesine neden olur.

E-postanın ne zaman hâlâ uygun olduğunu kararlaştırın. E-posta kısa görüşmeler, genel duyurular ve mevcut bir vaka bildirimine yanıt vermek için kullanılabilir. Bir talep sorumlu, son tarih, onay veya ilerleme kaydı gerektirdiğinde çalışanlar vaka açmalıdır.

Bu başlatma kontrolünü kullanın:

• Normal ve alışılmadık durumları içeren beş test talebi gönderin.
• Her vakanın beklenen süre içinde bir sorumlu aldığını doğrulayın.
• Çalışan görünümünü Yeni, Devam ediyor ve gecikmiş vakalara göre filtreleyin.
• Talep sahibinin net durum mesajları aldığını kontrol edin.
• E-posta taleplerini uygulamaya taşıma konusunda çalışanlara yazılı tek bir kural verin.

AppMaster bu iş akışını görsel veri modeli, yönlendirme mantığı ve web veya mobil ekranlarla destekler. İlk sürümü ekibin her hafta aldığı talepler etrafında oluşturun, ardından birkaç günlük kullanımdan sonra alanları ve kuralları düzenleyin.

Sıradaki adımlarınızı seçin

Düzenli karmaşa yaratan tek bir ortak takma ad ve yazılım erişimi, fatura soruları veya ekipman talepleri gibi net bir yolu olan tek bir talep türüyle başlayın. Dar kapsamlı bir ilk uygulama, tüm gelen kutularını aynı anda aksatmadan ekibin süreci öğrenmesini sağlar.

Seçtiğiniz takma ad için basit bir kural belirleyin: yeni talepler vaka yönetimi uygulamasına girer ve çalışanlar özel bir e-posta dizisi yerine vakadan yanıt verir. Her vakaya tek bir sorumlu, görünür bir durum ve bir sonraki işlemin kısa açıklamasını verin. Talep sahipleri ekibin talebi alıp almadığını, üzerinde çalışıp çalışmadığını, daha fazla bilgiye ihtiyaç duyup duymadığını veya talebi tamamlayıp tamamlamadığını görebilmelidir.

AppMaster, ekiplerin özel kodla başlamadan kodsuz bir vaka yönetimi uygulaması oluşturmasına yardımcı olabilir. Vaka ve talep sahibi ayrıntılarını modellemek için Veri Tasarımcısı'nı, işleri atamak ve durumları değiştirmek için İş Süreci Düzenleyicisi'ni kullanın. Bir web veya mobil ekran talep sahiplerine kendi vakalarının ilerlemesini gösterebilir.

İlk iş akışına pratik alanlar ekleyin:

• Talep başlığı ve açıklaması
• Talep sahibinin adı ve iletişim bilgileri
• Atanan sorumlu
• Durum ve ekip kullanıyorsa son tarih
• Talep sahiplerinin göremeyeceği dahili notlar

İlk haftadan sonra vakaları yöneten kişilerle belirsiz atamaları gözden geçirin. Sorumlular arasında gidip gelen, güncelleme olmadan bekleyen veya iki yanıta yol açan talepleri arayın. Yönlendirme kuralını düzeltin veya eksik bir form alanı ekleyin. Her alışılmadık durumu ilk günden çözmeniz gerekmez.

İş akışı güvenilir biçimde çalıştığında başka bir talep türü ekleyin, ikinci bir ekibi dahil edin veya otomatik durum bildirimleri başlatın. Aynı alışkanlıkları koruyun: vaka başına tek sorumlu, güncel durum için tek yer ve kararların kayıtlı geçmişi.

Ortak e-posta takma adlarını değiştirmek, uygulama bilgilerin kopyalandığı başka bir yer olmak yerine ekibin normal iş kuyruğu olduğunda işe yarar. Çalışanların tutarlı biçimde kullandığı küçük bir süreç, kaçındıkları büyük bir uygulamadan daha iyi sonuç verir.