Müşteri şikayeti çözüm iş akışı: atama ve takip

Şikayetlerin bir sorumlusu olmadığında

Ortak bir gelen kutusu her şikayeti alabilir, ancak vakalar yine de sahipsiz kalabilir. Herkes yanıtı başka birinin vereceğini düşünür. Elektronik tablolar da aynı riski yaratır: biri satır ekler, başka biri durumu değiştirir ve bir sonraki adımdan kimse sorumlu olmaz.

Müşteriler bunu sessizlik veya karmaşa olarak yaşar. Farklı vaatler içeren iki yanıt alabilir ya da bir devir tesliminden sonra aynı sorunu yeniden anlatmak zorunda kalabilirler. Geciken bir yanıt, müşterinin kimsenin konuyla ilgilenip ilgilenmediğini anlayamaması nedeniyle çoğu zaman ilk sorundan daha kötü hissettirir.

Müşteri şikayeti çözüm iş akışı, her vakaya görünür bir sorumlu atar. Bu kişinin her bölümü tek başına çözmesi gerekmez. Ancak vakayı ilerletmesi, doğru ekipten bilgi istemesi, müşteriyi bilgilendirmesi ve nihai sonucu doğrulaması gerekir.

Vaka kaydında sorumlu kişi, kabul zamanı, bir sonraki yanıt son tarihi ve mevcut durum görünmelidir. Kaydı açan herkes ekibin bugün harekete geçmesi mi yoksa bilgi beklemesi mi gerektiğini anlayabilmelidir.

Örneğin bir müşteri siparişinin ulaşmadığını bildirir. Destek ekibi şikayeti kaydeder ve Maya'ya atar. Maya teslimat bilgilerini kontrol eder ve operasyon ekibinden güncelleme ister. Kayıtta Maya'nın saat 15.00'e kadar yanıt vermesi gerektiği görülür. Yanıt başka bir ekipten gelse bile müşteriye gönderilecek bir sonraki mesajdan Maya sorumlu olmaya devam eder.

Görünür bir kayıt, ilk özürden sonra unutulan takip işlerini de önler. Sorumlu kişi vakayı kapatmadan önce not ekleyebilir, destekleyici bilgileri iliştirebilir ve sonraki adımı belirleyebilir. Bu müşteri şikayeti kayıtları ne olduğunu, ekibin ne vaat ettiğini ve bu işi tamamlayıp tamamlamadığını açıklamalıdır.

Şikayetleri «destek» veya «operasyon» gibi etiketlere atamaktan kaçının. Bu etiketler bir grubu gösterir, bir kişiyi değil. Belirli bir sorumlu atayın ve her devir teslimini vaka geçmişine kaydedin. Açık sorumluluk, tekrarlanan işleri azaltır ve müşterilere tutarlı bir yanıt verilmesini sağlar.

Şikayeti doğru ayrıntılarla kaydedin

Bir şikayet kaydı, başka bir çalışanın müşteriden sorunu yeniden anlatmasını istemeden konuyu anlayabilmesi için yeterli bilgi içermelidir. Müşterinin adı, hesap veya sipariş bilgisi, iletişim bilgileri ve tercih ettiği yanıt kanalıyla başlayın. Müşteri e-posta ile güncelleme istiyorsa önceden haber vermeden telefon etmeyin.

İç notları eklemeden önce sorunu müşterinin kendi sözleriyle kaydedin. «Yedek parçam gelmedi ve altı gündür makineyi kullanamıyorum» gibi doğrudan bir açıklama, müşteriyi neyin rahatsız ettiğini korur. İç notlarda ise ekibin bulduğu depo gecikmesi veya yanlış adres gibi ayrıntılar açıklanabilir.

Her vakayı ilgili ürün veya hizmetle ilişkilendirin. İşletmeye göre şunları ekleyin:

• Ürün adı, modeli veya abonelik planı
• Sipariş, fatura, destek talebi veya hesap numarası
• Satın alma, teslimat veya hizmet randevusu tarihi
• Ekran görüntüleri, fotoğraflar, e-postalar veya müşterinin sunduğu diğer kanıtlar

Bu bilgiler, çalışanların aynı temel bilgileri farklı gelen kutularında, elektronik tablolarda ve sipariş sistemlerinde aramasını önler.

Aciliyeti müşteri üzerindeki etkiye göre sınıflandırın

Çalışanların tutarlı biçimde uygulayabileceği az sayıda aciliyet seviyesi kullanın. Aciliyeti, müşterinin mesajı ne kadar sert yazdığına göre değil, ortaya çıkan zarara ve işletmenizin verdiği yanıt sözüne göre belirleyin.

Ücretli hesabına erişemeyen bir müşterinin acil yanıta ihtiyacı olabilir, çünkü güvendiği bir hizmeti kullanamıyordur. Küçük bir kozmetik kusur da hızlı yanıtı hak eder, ancak genellikle aynı süre içinde çözülmesi gerekmez. Çalışanlar vakayı oluştururken aciliyet seviyesini ve ilk yanıt son tarihini eklemelidir.

Dört seviye çoğu durumda işe yarar: acil, yüksek, normal ve düşük. Her seviyeyi kısa bir kuralla tanımlayın. Örneğin «acil», hizmetin kullanılamaması veya şikayetin güvenlik, hukuk ya da ödeme riski içermesi anlamına gelebilir. Çalışanlar «önemli» gibi belirsiz etiketleri yorumlamak zorunda kalmamalıdır.

Eksiksiz bir ilk kayıt, incelemeyi yapacak kişiye kullanılabilir bir başlangıç noktası sunar. Ayrıca sorumluluğu görünür kılar: inceleyenler sorunu kimin bildirdiğini, ne olduğunu, hangi işlemle ilgili olduğunu ve ekibin ne kadar hızlı yanıt vermesi gerektiğini görebilir.

Her vakaya net bir sorumlu atayın

Ekip vakayı kaydeder kaydetmez bir inceleme sorumlusu belirleyin. Bu kişi faturalandırma, teslimat veya başka bir destek ekibinden yardım alsa bile sonraki adımdan sorumludur.

İnceleme sorumlusunun her iadeyi veya istisnayı onaylama yetkisi olması gerekmez. Görevi gerçekleri incelemek, eksik bilgileri istemek, doğru çalışma arkadaşına ulaşmak ve üzerinde anlaşılan son tarihe kadar müşteriyi bilgilendirmektir.

Ekibin her gün kullandığı görünümde sorumlu kişinin adını vaka durumunun yanında gösterin. Durumları basit tutun: yeni, inceleniyor, müşteriden yanıt bekleniyor, iç yanıt bekleniyor, çözüldü ve kapatıldı. Bir çalışma arkadaşı uzun bir mesaj dizisini açmadan sıradaki adımı kimin atacağını görebilmelidir.

İncelemeyi onaydan ayırın

Eskalasyonlar ve normal politikanın dışındaki kararlar için yöneticilere ayrı bir rol verin. Bir destek çalışanı geciken teslimatı inceleyebilir, yönetici ise olağan sınırı aşan bir iadeyi onaylayabilir. Böylece inceleme sorumluları kararı kimin verebileceğini bilmedikleri için vakaları bekletmez.

Çalışanların tartışmadan uygulayabileceği eskalasyon kuralları belirleyin. Güvenlik endişesi, hukuki tehdit, tekrarlanan hizmet sorunu veya politika dışı bir çözüm talebi varsa vakayı yöneticiye gönderin. Yönetici resmi olarak devralana kadar müşterinin iletişim kişisi inceleme sorumlusu olmalıdır.

Yeniden atamaları görünür kılın

Bazen bir vakanın başka bir kişiye aktarılması gerekir. İlk sorumlu izinli olabilir veya bir uzman gerçeklere daha iyi erişebilir. Adı sessizce değiştirmeyin. Eski sorumluyu, yeni sorumluyu, nedeni ve zaman bilgisini içeren kısa bir yeniden atama notu ekleyin.

Örneğin: «Priya Shah'dan Daniel Lee'ye aktarıldı, 14 Mayıs, 10.30. Daniel taşıyıcı talepleriyle ilgileniyor.» Bu kayıt, sorumluluğu korur ve bir yanıt son tarihi kaçırıldığında yöneticilere açık bir geçmiş sunar.

Bir yönetici devraldığında hem sorumluyu hem de durumu hemen güncelleyin. İki kişi aynı şikayetten kendini sorumlu sandığı için müşteriler çelişkili yanıtlar almamalıdır.

Uygulanabilir yanıt son tarihleri belirleyin

Kayıtta yalnızca «açık» yazıyorsa vaka hiç işleme alınmadan kalabilir. Bir çalışan şikayeti kaydettiği anda ilk yanıt için son tarih ekleyin. Bu son tarih, gerçek bir kişinin sorunu kabul etmesi, ekibin şikayeti aldığını doğrulaması ve müşterinin daha kapsamlı bir güncellemeyi ne zaman bekleyebileceğini söylemesi anlamına gelir.

İlk yanıtın her şeyi çözmesi gerekmez. Hızlı ve faydalı olması yeterlidir. Örneğin: «Çift ücretlendirme bildirimini aldık. Sam konuyu inceliyor ve yarın saat 15.00'e kadar sizi bilgilendirecek.» Bu mesaj, belirsiz bir vaat yerine müşteriye bir isim ve tarih verir.

Birkaç açık aşama kullanın. Her aşamanın bir sorumlusu, son tarihi ve tamamlanma ölçütü olmalıdır:

• İlk yanıt: Şikayeti kabul edin ve sorumluyu doğrulayın.
• İnceleme: Kayıtları toplayın, ilgili çalışanlarla görüşün veya işlemi kontrol edin.
• Müşteri güncellemesi: Müşteri ekibin peşine düşmeden mevcut durumu açıklayın.
• Çözüm kararı: İade, değişim, düzeltme veya başka bir işlemi onaylayın.
• Kapatma: Sonucu müşteriye bildirin ve vaka notlarını tamamlayın.

Her şikayete aynı süreyi vermeyin. Güvenlik bildirimi hemen ele alınmalıdır. Şüpheli bir ödeme hatası parayı ve güveni etkilediği için çoğu zaman hızlı yanıt gerektirir. Rutin bir hizmet şikayeti inceleme için daha fazla zaman alabilir. Bu kategorileri şikayet takip sürecinize yazın; böylece çalışanlar her seferinde aciliyeti baştan değerlendirmek zorunda kalmaz.

Bir ekip güvenlik sorunları için bir saat içinde, ödeme şikayetleri için bir iş günü içinde ve standart hizmet sorunları için iki iş günü içinde alındı onayı isteyebilir. İnceleme ve nihai karar için ayrı son tarihler belirleyin. Hızlı bir alındı onayı faydalıdır, ancak bir hafta boyunca ilerlemeyen bir vakayı gizlememelidir.

Hatırlatmaları son tarih geçtikten sonra değil, öncesinde gönderin. Son tarih geçtiğinde yöneticiyi uyarın. Eskalasyon, işi engeli kaldırabilecek, istisnayı onaylayabilecek veya ek destek atayabilecek bir kişiye taşımalıdır.

Yanıt son tarihi takibini şikayetle aynı kayıtta tutun. Vaka listesinde sorumlu, sonraki aşama, son tarih ve gecikme durumu görünmelidir. AppMaster ile kodsuz bir vaka uygulaması bu alanları saklayabilir, acil kategorileri doğru kişiye yönlendirebilir ve son tarih yaklaşmadan hatırlatma mesajları gönderebilir. Böylece ekip bugün güncelleme bekleyen müşterileri görebilir.

İlk yanıttan kapanışa kadar işi takip edin

Bir şikayet, biri inceleme yaparken hareketsiz görünebilir. Durumlar görünür değilse yöneticiler müşteriye yanıt verilip verilmediğini, ekibin daha fazla bilgiye ihtiyaç duyup duymadığını veya vakanın unutulup unutulmadığını anlayamaz.

Ekibin çalışma biçimine uyan durumları kullanın:

• Yeni: Ekip şikayeti aldı ancak henüz incelemedi.
• İnceleniyor: Atanan kişi kayıtları kontrol ediyor, çalışanlarla görüşüyor veya ne olduğunu test ediyor.
• Müşteriden yanıt bekleniyor: Ekibin bir yanıta, fotoğrafa, sipariş numarasına veya başka bir ayrıntıya ihtiyacı var.
• Çözüldü: Ekip iade, değişim, düzeltme veya açıklama gibi bir işlemi kararlaştırıp tamamladı.
• Kapatıldı: Ekip son güncellemeyi gönderdi ve başka bir işlem kalmadı.

Her durumun açık bir kuralı olmalıdır. Bir kişi vakayı inceleyip «Teslimat taramasını kontrol et ve taşıyıcıyla iletişime geç» gibi ilk adımı yazdıktan sonra Yeni durumundan İnceleniyor durumuna geçin. Müşteriye belirli bir talep gönderildikten sonra Müşteriden yanıt bekleniyor durumunu kullanın. Bu durumu kimsenin başlamadığı işleri park etmek için kullanmayın.

Her vakada iki ayrı kayıt tutun. Müşteri güncellemelerinde açık ve kibar bir dil kullanın: «Teslimat kaydını kontrol ediyoruz ve salı günü sizi bilgilendireceğiz.» İç notlarda sipariş kontrolleri, çalışan yorumları, politika kararları ve seçilen çözümün nedeni yer alabilir. Bu ayrım, aceleyle yazılmış bir iç mesajın müşteriye gitmesini önler.

Her değişikliğin geçmişini saklayın. Zamanı, durumu değiştiren kişiyi ve kısa nedeni kaydedin. Maya bir değişim gönderildikten sonra vakayı Çözüldü durumuna alırsa kayıt bunu belirtmelidir. Böylece bir çalışma arkadaşı tüm vaka geçmişini başkalarına sormadan takip edebilir.

Ekip yalnızca iç görevini tamamladı diye şikayeti kapatmayın. Müşteri sonucu aldıktan, ekip yapılan işlemi kaydettikten ve sorumlu kişi vaat edilen başka bir takip işi kalmadığını kontrol ettikten sonra kapatın.

Sonucu ileride başvurmak üzere belgeleyin

Kapatılan bir vakanın açık bir kaydı olmalıdır. Müşteri yeniden iletişime geçebilir, yönetici kararı inceleyebilir veya gelecek ay benzer bir şikayet ortaya çıkabilir. Eksiksiz müşteri şikayeti kayıtları, sonraki kişinin eski gelen kutularını karıştırmadan ne olduğunu anlamasını sağlar.

Zaman çizelgesini gerçeklere dayanarak tutun. İnceleme sorumlusunun kontrol ettiği sipariş bilgileri, ekran görüntüleri, teslimat taramaları, arama notları veya e-posta mesajları gibi kanıtları ekleyin. İadeler, değişimler, hesap değişiklikleri ve müşteriye verilen sözler dahil her işlemi kaydedin. İadelerde tutarı, yöntemi ve onaylayan kişiyi belirtin.

Vaka açıkken neden hakkında tahminde bulunmayın. Gerçekleri kontrol edin, kanıtları karşılaştırın ve ardından kısa bir neden açıklaması yazın. «Çalışanlar güncel olmayan ürün etiketini kullandığı için depo yanlış ürünü paketledi» ifadesi, ekibin düzeltebileceği bir sorunu gösterdiği için «sipariş hatası» ifadesinden daha faydalıdır.

Nihai kararı anlaşılır bir dille kaydedin. Ekibin şikayeti kabul edip etmediğini, kısmen kabul ettiğini veya herhangi bir hata bulmadığını belirtin. Müşterinin kararı aldığı tarih ve saati, iletişim kanalını ve kapanıştan sonra hâlâ yapılması gereken bir işlem varsa bunu ekleyin.

Kapanış notunda incelenen kanıtlar, doğrulanan neden, nihai karar, vaat edilen işlem, son yanıt tarihi ve ürün, hizmet alanı ile sorun türü etiketleri yer almalıdır.

Etiketler tek tek vakaları örüntülere dönüştürür. Birkaç şikayette «geciken teslimat» ve «depo etiketi» gibi etiketler varsa yöneticiler bunları sayabilir ve temel süreci inceleyebilir. Vaka kapatılmadan önce bu etiketleri zorunlu hale getirin.

Kapanış sonucunu kısa ama belirli tutun. «İade yapıldı, müşteri 14 Mayıs'ta bilgilendirildi, depo etiketi operasyon tarafından düzeltildi» ifadesi, müşteri yeniden iletişime geçerse veya aynı hata tekrarlanırsa çalışma arkadaşına gerçek bir başlangıç noktası verir.

Geciken teslimat örneği

Bir müşteri salı sabahı desteğe şu mesajı gönderir: «Siparişim dün teslim edilmeliydi, ancak hâlâ ulaşmadı.» Destek çalışanı bir vaka açar ve sipariş numarasını, vaat edilen teslimat tarihini, iletişim bilgilerini ve müşterinin tercih ettiği çözümü kaydeder. Çalışan ayrıca ilk mesajı saklar.

Vaka destek lideri Maya'ya atanır. Müşteriyle iletişimden Maya sorumludur ve saat 14.00'e kadar ilk yanıtı göndermelidir. Yanıtında şikayeti doğrular, kaçırılan tarih için özür diler ve net bir güncelleme zamanı verir: «Teslimat durumunu kontrol edip bugün saat 16.00'ya kadar sizi bilgilendireceğim.»

Maya, teslimat kontrolünü operasyon ekibinden Daniel'e saat 15.00 son tarihiyle atar. Daniel kargo kaydını inceler ve paketin yerel depoya ulaştığını, ancak teslimat aracına yüklenmediğini bulur. Bu bilgiyi, takip numarasını ve ekran görüntüsünü vakaya ekler. Kargodan teslimatı çarşamba günü önceliklendirmesini ister.

Saat 15.30'da Maya, Daniel'in güncellemesini görür ve söz verdiği saat gelmeden müşteriyle iletişime geçer. Gecikmeyi anlaşılır bir dille açıklar ve üzerinde anlaşılan çözümü sunar: ertesi gün öncelikli teslimat ve teslimat ücretinin iadesi. Teklifi, müşterinin kabulünü ve yeni teslimat tarihini kaydeder.

Çarşamba öğleden sonra Daniel kargo kaydını yeniden kontrol eder ve paketin teslim edildiğini görür. Maya kısa bir onay mesajı gönderir ve siparişin iyi durumda ulaşıp ulaşmadığını sorar. Müşteri teslim aldığını doğrular.

Maya nihai sonucu kaydettikten sonra şikayeti kapatır: teslimat tamamlandı, teslimat ücreti iade edildi, müşteri teslim aldığını doğruladı. Nedeni «depo çıkışının atlanması» olarak etiketler. Operasyon ekibi haftalık incelemede aynı nedenin başka vakalarda da görülüp görülmediğini kontrol edebilir ve depo sürecinin dikkat gerektirip gerektirmediğine karar verebilir.

Maya müşteri görüşmesinden, Daniel teslimat incelemesinden sorumludur ve her son tarih aynı vaka kaydında görünür.

Şikayetlerin çözümünü zorlaştıran hatalar

Bir şikayeti «Destek» veya «Operasyon»a atamak herkesin haberdar olmasını sağlar, ancak müşteriye veya ekibe sıradaki adımı kimin atacağını söylemez. Birden fazla kişinin yardım etmesi gerekse bile tek bir inceleme sorumlusu belirleyin.

Sorumlunun her bölümü tek başına çözmesi gerekmez. Ancak güncellemeleri istemesi, müşteriyi bilgilendirmesi ve vaat edilen işlemin gerçekleşmesini sağlaması gerekir. Yöneticiler de son tarih geçmeden önce bekleyen vakaları fark edebilir.

Yaygın bir başka hata, yanıt gönderildikten sonra vakayı kapatmaktır. Mesajda değişimin gönderileceği, iadenin ulaşacağı veya teknik ekibin inceleme yapacağı söylenebilir. Vaat edilen işlem tamamlanana ve sorumlu kişi kanıtı kaydedene kadar vakayı açık tutun.

İlk müşteri şikayeti kayıtlarının da korunması gerekir. Özellikle özet sorunu yumuşatıyor veya talebi dışarıda bırakıyorsa müşterinin sözlerini kısa bir iç özetle değiştirmeyin. İlk mesajı saklayın ve ekip için ayrı bir özet ekleyin.

Özel notlar sonraki kişiye yardımcı olacak kadar ayrıntılı olmalıdır. «Depoyla konuşuldu» veya «müşteriyle çözüldü» ifadeleri fazla belirsizdir. İletişim zamanını, karar veren kişiyi, üzerinde anlaşılan işlemi ve son tarihi, destekleyici kanıtı ve gecikmenin ya da plan değişikliğinin nedenini kaydedin.

Her açık vakada mevcut sorumlu, sonraki adım ve yanıt son tarihi görünmelidir. Bu alanlar yoksa ekipler hafızaya ve özel mesajlara güvenir. Şikayetler de çoğunlukla bu noktada bekler.

«Yanıt gönderildi», «işlem sürüyor» ve «kapatıldı» durumlarını ayrı kullanın. Kayıt, ekibin sorunu çözüp çözmediğini, yalnızca kabul edip etmediğini değil, göstermelidir.

Hızlı haftalık vaka kontrolü

Haftalık inceleme, açık şikayetlerin bir gelen kutusunda kaybolmasını önler. Bir ekip lideri vaka listesini 20-30 dakika içinde inceleyebilir ve toplantı bitmeden takip işlerini atayabilir.

Tüm açık vakalarla başlayın. Her kayıtta belirli bir sorumlu ve net bir sonraki adım bulunmalıdır. «Teslimat taramasını incele» açıktır. «Yakında takip et» açık değildir.

Bir sonraki müşteri güncellemesinin tarihini planlanan kapanış tarihi kadar dikkatle kontrol edin. Bir şikayetin çözülmesi birkaç gün sürebilir, ancak müşteriler sessizce beklememelidir. Değişim gönderisinin ulaşması bir hafta sürecekse sorumlu iki gün sonra işin sürdüğünü doğrulayan bir güncelleme gönderebilir.

İnceleme sırasında her açık vakanın sorumlusunu ve sonraki adımını doğrulayın, geciken müşteri güncellemelerini kontrol edin, kaçırılan son tarihlerin nedenlerini kaydedin ve kapatılan vakalarda sonucun ve müşteriye ne söylendiğinin yer aldığından emin olun.

Geciken tarihi vakayı hızla kapatmak için bir neden olarak görmeyin. Nedeni bulun. İnceleme sorumlusu kargo yanıtını, yönetici onayını veya müşteri bilgisini bekliyor olabilir. Nedeni kaydedin, yeni bir tarih belirleyin ve bir sonraki güncellemeyi kimin göndereceğine karar verin.

Kapatılan vakalar da kısaca kontrol edilmelidir. Kayıtta ne olduğu, ekibin ne yaptığı ve müşterinin son mesajı ne zaman aldığı yazmalıdır. Örneğin: «Paket taşıma sırasında kayboldu. Değişim onaylandı ve 14 Mayıs'ta gönderildi. Müşteri 14 Mayıs'ta e-posta ile bilgilendirildi.»

AppMaster bu işi vaka listesi, atanmış inceleme sorumlusu, yanıt son tarihleri, güncelleme tarihleri ve kapanış notlarıyla tek bir kurum içi uygulamada tutabilir. Haftalık görünüm geciken vakaları en üste çıkarabilir; böylece ekip gecikmeleri aramak yerine çözmeye zaman ayırır.

Her yeni işlemi bir kişiye atayıp tarih belirleyerek bitirin. Toplantıdan sonra vaka listesinde her çözülmemiş şikayet için açık müşteri güncellemeleri ve sorumlu bir kişi bulunmalıdır.

İş akışını günlük kullanıma alın

Geciken siparişler veya faturalandırma hataları gibi yaygın bir şikayet türüyle başlayın. Çalışanların bugün ne yaptığını haritalayın: mesajlar nerede geliyor, kim okuyor, kim inceliyor ve müşteriler vakanın kapandığını nasıl öğreniyor? Bu çalışma, hafızaya veya özel gelen kutularına dayanan devir teslimlerini ortaya çıkarır.

Her şikayet için tek bir ortak vaka kaydı oluşturun. Alanları pratik tutun: müşteri bilgileri, sorun özeti, kanıtlar, atanmış sorumlu, son tarihler, durum, güncellemeler ve nihai sonuç. İş akışı ancak yetkili çalışanlar mevcut sorumluyu ve gerekli sonraki adımı görebildiğinde işe yarar.

Vakalar gelmeden önce atama kurallarını belirleyin. Teslimat şikayetleri operasyon inceleme sorumlusuna, ödeme şikayetleri ise finans ekibine gidebilir. Sorumlu vakayı çözemiyorsa belirsiz bir durumda bırakmak yerine not ekleyerek yeniden atamalıdır.

İlk sürümde tutarlı bir durum akışı bulunmalıdır:

• Yeni: Ekip şikayeti aldı.
• Atandı: Bir kişi incelemeden sorumlu.
• Bekliyor: Vaka müşteriden veya başka bir ekipten bilgi bekliyor.
• Yanıt bekleniyor: Sorumlu belirlenen tarihe kadar güncelleme göndermeli.
• Kapatıldı: Ekip kararı ve müşteri yanıtını kaydetti.

AppMaster bunu kurum içi bir şikayet uygulaması olarak destekleyebilir. Data Designer vaka kaydını oluşturabilir, Business Process Editor ise atama kurallarını uygulayabilir, yanıt son tarihlerini takip edebilir ve bir son tarih yaklaşırken çalışanlara bildirim gönderebilir. Ekipler vakaları e-posta ve elektronik tablolara dağıtmak yerine aynı kayıtlar üzerinde web ve mobil arayüzler oluşturabilir.

Ekibin tamamından kullanmasını istemeden önce süreci üç veya dört örnek vakayla test edin. Bir yeniden atama, müşteriden kanıt bekleyen bir vaka ve kaçırılmış bir son tarih ekleyin. Çalışanların sorumluyu bulup bulamadığını, durumu anlayıp anlamadığını ve ek talimat olmadan sonucu kaydedip kaydedemediğini kontrol edin.

Testten sonra kullanılmayan alanları kaldırın ve kafa karışıklığı yaratan durumları netleştirin. Erken yapılan küçük değişiklikler, vaka sayısı arttıkça sorumluluğu korumayı kolaylaştırır.