SLA takip aracı: son tarihleri, beklemeleri ve ekip raporlarını oluşturun

Müşteri operasyonları ekipleri SLA son tarihlerini neden kaçırıyor

Müşteri operasyonları ekipleri bir SLA'yı genellikle birinin tarihi görmezden gelmesi yüzünden kaçırmaz. Son tarihler değişir, biletler farklı kişilere devredilir ve müşterilerin yanıtları çalışmayı günlerce durdurabilir. Her değişiklikten sonra güncellenmesi gereken tek bir son tarih sütununa sahip elektronik tablo kısa sürede yetersiz kalır.

İlk sorun, her SLA hedefini tek bir son tarih olarak görmektir. İlk yanıt hedefi, bir temsilcinin yeni bir talebi ne kadar hızlı karşıladığını ölçer. Çözüm hedefi ise ekibin sorunu çözmek için ne kadar süresi olduğunu gösterir. Bir bilet 15 dakika içinde yanıt hedefini karşılayabilir, ancak üç gün sonra çözüm hedefini kaçırabilir. Tek bir son tarih hangi taahhüdün yerine getirilmediğini gösteremez.

Sorumluluk da başka bir sorun yaratır. Bir temsilci yanıt verebilir, bir uzman inceleme yapabilir ve bir yönetici düzeltmeyi onaylayabilir. Aktif SLA zamanlayıcısının sahibi yoksa herkes onu başka birinin izlediğini düşünebilir. Bilet, süresi dolana kadar kuyrukta kalır.

Saat 10:00'da bildirilen bir hesap erişimi sorununu düşünün. Temsilci 10:12'de yanıt vererek 30 dakikalık yanıt hedefini karşılar, ardından 10:20'de ekran görüntüsü ister. Müşteri ertesi öğleden sonra yanıt verir. Takip aracı bu bekleme süresini çözüm hedefine dahil ederse, desteği kullanamayacağı bir zaman için sorumlu tutar. Zamanlayıcıyı durdurur ancak yeniden başlatmazsa sonuç bu kez ters yönde hatalı olur.

Bir takip aracı her bilet için ortak bir operasyon kaydı sunmalıdır: sorumlu kişi, ekip, öncelik, yanıt ve çözüm son tarihleri, zamanlayıcı durumu, bekleme nedeni ve değişiklik geçmişi. Böylece temsilciler ihlale yaklaşan işlere odaklanabilir, yöneticiler de personel yetersizliği, devirler veya müşteri bekleme süresinden kaynaklanan gecikmeleri görebilir.

Elle tutulan tablolar küçük ve istikrarlı bir kuyruk için işe yarayabilir. Son tarihler önceliğe, çalışma saatlerine, yeniden atamaya ve beklemelere bağlı olmaya başladığında takip aracının tutarlı kurallara ihtiyacı vardır.

Her SLA kaydının ihtiyaçlarını belirleyin

Her bilet, kimin sorumlu olduğunu, hangi taahhüdün geçerli olduğunu ve zamanlayıcının çalışıp çalışmayacağını açıklayacak kadar ayrıntı içermelidir. Temel bilgilerle başlayın: müşteri veya hesap, öncelik, atanmış ekip, bilet sorumlusu ve mevcut durum.

Ardından son tarihi kontrol eden alanları ekleyin:

• "Standart destek" veya "Öncelikli destek" gibi SLA politikası
• Başlangıç zamanı
• İlk yanıt son zamanı ve çözüm son zamanı
• Bekleme nedeni ve beklemenin başlangıç zamanı
• Devam zamanı veya toplam bekleme süresi

İlk yanıtı ve tam çözümü ayrı tutun. Bir ekip dört iş saati içinde ilk yanıtı vermeyi taahhüt ederken çözüm için iki iş gününe sahip olabilir. Tek bir son tarih, hızlı bir yanıtın çözülmemiş bir bileti gizlemesine yol açar.

Temsilcilerden "ihlal edildi" seçeneğini elle işaretlemelerini istemeyin. Bunu mevcut zamana, son tarihe, bilet durumuna ve geçerli beklemelere göre hesaplayın. Örneğin bir bilet, son tarihi geçmiş, açık kalmış ve zamanlayıcı aktifse çözüm SLA'sını ihlal eder.

AppMaster bu mantığı tek bir yerde tutabilir. Data Designer bilet alanlarını modelleyebilir, görsel Business Process ise bir temsilci bilet oluşturduğunda veya güncellediğinde son tarihleri ve ihlal durumunu hesaplayabilir.

Takip aracını oluşturmadan önce SLA kurallarını belirleyin

Net kurallar SLA sonuçlarını adil hale getirir. Formülleri veya raporları oluşturmadan önce her bilet kategorisinin hedefini tanımlayın. Aksi halde iki temsilci aynı talebi farklı biçimde ele alabilir ve ihlal sayısının anlamı kalmaz.

Çoğu ekip hedefleri önceliğe, müşteri planına ve talep türüne göre değiştirir. İlk sürümü küçük tutun. Örneğin acil üretim olayları için bir saat içinde ilk yanıt, ücretli planlardaki erişim sorunları için dört iş saati ve rutin sorular için iki iş günü belirlenebilir.

Her kuralı sade bir dille yazın. "Premium müşterinin yüksek öncelikli faturalandırma sorusuna iki iş saati içinde ilk yanıt verilmelidir" ifadesi, hangi verilerin saklanacağını açıkça gösterir: öncelik, plan, talep türü, oluşturulma zamanı ve ilk yanıt zamanı.

Çalışma takvimini tanımlayın

Hedeflerin günün her saatinde mi, yoksa yalnızca destek saatlerinde mi çalışacağına karar verin. Destek pazartesiden cumaya 09:00-17:00 arasında çalışıyorsa, cuma 16:30'da alınan ve iki saatlik hedefi olan bir biletin son tarihi cuma akşamı değil, pazartesi 10:30'dur.

Çalışma günlerini, destek saatlerini, saat dilimini, tatilleri ve ayrı bir 7/24 olay takvimi olup olmadığını belgeleyin. Mümkün olduğunda her politika için adlandırılmış tek bir takvim kullanın. Farklı ülkelerde müşterileri olan ekipler bölgesel takvimlere ihtiyaç duyabilir, ancak her müşteri için ayrı bir takvim gereksiz bakım yükü oluşturur.

Başlangıç noktalarını ve politika sorumluluğunu belirleyin

Zamanlayıcının tam olarak ne zaman başlayacağını seçin. Yeni biletler genellikle sistem onları aldığında başlar. Yeniden açılan biletler için ayrı bir kural gerekir: kalan süre devam mı edecek, ilk zamanlayıcı yeniden mi başlayacak, yoksa yeni bir hedef mi oluşturulacak? Bir yöntem seçin ve tutarlı biçimde uygulayın.

Politika değişikliklerini bir kişiye veya küçük bir gruba atayın. Temsilciler bilet verilerini düzeltebilir, ancak ihlali kaldırmak için hedef sürelerini değiştirmemelidir. Politika sürümünü her kayıtta saklayın, onaylı istisnaları neden ve tarih bilgisiyle kaydedin.

Bir AppMaster uygulaması politikaları tek bir yönetim alanında tutabilir ve bilet sisteme girdiğinde eşleşen kuralı uygulayabilir. Böylece ayrı elektronik tablo formüllerinin yerini tutarlı bir zamanlayıcı alır.

Takip aracının arkasındaki verileri modelleyin

İlk sürümü, bir operasyon sorumlusunun bileti inceleyip son tarihinin neden değiştiğini anlayabileceği kadar basit tutun.

Bir biletler tablosuyla başlayın. Bu tabloda kimlik, konu, müşteri, öncelik, durum, oluşturulma zamanı, ilk yanıt zamanı, çözülme zamanı, son tarihler, atanmış sorumlu ve sorumlu ekip bulunsun. Birden fazla kişi yorum yapsa bile her biletin tek bir mevcut sorumlusu ve tek bir ekibi olmalıdır.

Ekipler ve SLA politikaları için ayrı kayıtlar oluşturun. Ekip kaydında ad ve çalışma saatleri takvimi tutulabilir. Her politika hangi biletleri kapsadığını, yanıt ve çözüm hedeflerini, zamanlayıcı türünü ve müşteri bekleme süresinin zamanlayıcıyı durdurup durdurmadığını belirtmelidir.

Tarih, ilgili ekip veya konum ve kısa bir etiketi içeren bir tatiller kaydı ekleyin. Tüm zaman damgalarını tutarlı bir saat diliminde, genellikle UTC'de saklayın, gerektiğinde arayüzde yerel saati gösterin. Farklı saat dilimleri hafta sonları ve yaz saati değişiklikleri çevresinde hatalara neden olur.

Geçmişi üzerine yazmak yerine durum geçmişini tutun. Her kayıt bilet kimliğini, eski ve yeni durumu, olay zamanını ve değişikliği yapan kişi veya kuralı içermelidir. "Müşteri bekleniyor", "Müşteri yanıt verdi", "Atandı" ve "Çözüldü" gibi olayları kaydedin.

Bu geçmiş son tarih değişikliklerini açıklar. Son tarih salı sabahından salı öğleden sonrasına kayarsa yönetici, ekibin müşteri beklenirken SLA'yı üç saat durdurduğunu görebilir. AppMaster'ın görsel Data Designer aracı bu ilişkili kayıtları modelleyebilir, Business Process Editor ise durum değişikliklerinden sonra son tarihleri güncelleyebilir.

Bilet son tarihlerini hesaplayın

Zamanlayıcıyı destek biletinin sistem tarafından alınması gibi net bir olayla başlatın. Birinin bileti tesadüfen görüntülemesini beklemeyin. Başlangıç zamanını kaydedin, böylece sonraki tüm hesaplamalar aynı referans noktasını kullanır.

Ardından müşteri planı, bilet türü, öncelik veya bölgeye göre eşleşen SLA politikasını seçin. Son tarihi şu şekilde hesaplayın:

1. Biletin hedefini okuyun, örneğin dört saatlik yanıt süresini.
2. Yalnızca politikanın izin verdiği çalışma süresini ekleyin.
3. Politika bunları hariç tutuyorsa kapalı saatleri, hafta sonlarını ve tatilleri atlayın.
4. Son tarihi bilete kaydedin.
5. Öncelik, plan veya kategori değiştiğinde farklı bir politika seçiliyorsa yeniden hesaplayın.

Çalışma saatleri konuyu göründüğünden daha karmaşık hale getirir. Dört saatlik SLA 16:00'da başlıyor ve destek 09:00-17:00 arasında çalışıyorsa o gün için bir saat kalır. Bilet 20:00'de değil, sonraki iş günü öğle saatinde sona erer.

Bir biletin önceliği değiştiğinde ilk başlangıç zamanını koruyun ve belgelenmiş yükseltme kuralını uygulayın. Bazı ekipler acil hedefi ilk başlangıçtan itibaren uygular, bazıları ise bilet yükseltildiğinde yeni bir hedef başlatır. Herkes aynı yöntemi izlediği sürece iki yaklaşım da işe yarayabilir.

Hem kesin son tarihi hem de kalan süreyi gösterin. "2 sa 15 dk kaldı", "1 gün içinde sona eriyor" ve "35 dk gecikti" gibi etiketler temsilcilerin kuyruğu zaman damgalarından daha hızlı taramasına yardımcı olur. Sağlıklı biletler için nötr, son tarih yaklaşırken uyarı ve süre geçtikten sonra net bir ihlal durumu kullanın.

Müşteri yanıtları için zamanlayıcıları durdurun

Zamanlayıcıyı yalnızca ekip müşteriden bir şey almadan bileti ilerletemiyorsa durdurun. Yaygın nedenler bilgi, onay, erişim, izin veya dosya beklemektir. Bir iş arkadaşını beklemek gibi iç gecikmeler SLA'yı durdurmamalıdır.

Kısa ve net bir durum listesi kullanın:

• Müşteri bilgisi bekleniyor
• Müşteri onayı bekleniyor
• Müşteri erişimi bekleniyor
• Müşterinin göndereceği dosyalar bekleniyor

Temsilci bu durumlardan birini seçtiğinde kesin bekleme zamanını ve nedeni kaydedin. Ayrıca müşterinin yanıtını isteyen mesajı veya olayı da kaydedin. Böylece yöneticiler beklemenin gerekçeli olup olmadığını doğrulayabilir.

Müşteri yanıt verdiğinde zamanlayıcıyı yanıt zamanında yeniden başlatın. Bekleme süresini total paused time alanına ekleyin, ardından çalışma saatleri kurallarına göre kalan süreyi yeniden hesaplayın. Müşterinin 90 dakika beklemesi, kapalı saatler dikkate alınarak son tarihi 90 dakika ileri taşır.

Bekleme süresini bilet görünümünde gösterin. Temsilciler bir biletin 15 dakikadır mı, üç gündür mü beklediğini bilmeli, yöneticiler de bekleme durumuna tekrar tekrar dönen biletleri görebilmelidir.

Bekleme nedenlerini SLA politikasında izin verilenlerle sınırlayın. Bir beklemeyi kabul etmeden önce müşteriden yanıt isteyen bir olayın bulunmasını zorunlu kılın. AppMaster'da bir Business Process yeni durumu kontrol edebilir, bekleme başlangıç zamanını kaydedebilir ve SLA kaydını güncellemeden önce geçersiz değişiklikleri reddedebilir.

Otomatik bir "mesajınızı aldık" e-postası zamanlayıcıyı yeniden başlatmamalıdır. Gelen müşteri mesajını veya temsilcinin onayladığı yanıtı kullanın ve tüm bekleme geçmişini biletle birlikte saklayın.

Müşteri desteği örneğini inceleyin

Bir müşteri salı günü saat 10:00'da şu faturalandırma sorusunu gönderiyor: "Faturam neden iki ücret gösteriyor?" Takip aracı B-184 numaralı bileti oluşturuyor, bileti Destek ekibine atıyor ve faturalandırma SLA'sını uyguluyor. Ekibin ilk yararlı yanıt için dört iş saati, çözüm için sekiz iş saati süresi var.

Destek ekibi pazartesiden cumaya 09:00-17:00 arasında çalışıyor. Saat 10:35'te bir temsilci hesabın kontrol edildiğini doğruluyor. İlk yanıt zamanlayıcısı 35. dakikada duruyor ve 3 saat 25 dakika kalıyor. Bilet ilk yanıt hedefini karşılıyor.

Saat 11:00'de temsilci bir fatura numarasına ihtiyaç duyuyor ve bileti "Müşteri bekleniyor" olarak işaretliyor. Bir saatlik aktif çalışmanın ardından çözüm zamanlayıcısı duruyor. Takip aracı beklemenin başlangıcını ve nedenini kaydediyor.

Müşteri 15:30'da yanıt veriyor. Takip aracı 4 saat 30 dakikalık bekleme süresini son tarihe ekliyor. İlk çözüm son tarihi salı 18:00 olduğundan, kalan süre sonraki iş gününe taşınıyor ve düzeltilmiş son tarih çarşamba 14:30 oluyor.

Bir temsilci sorunu çarşamba 15:10'da çözüyor. Bilet 40 dakika gecikmiş durumda. Destek ekibi için bir gecikmiş çözüm olarak sayılıyor, ilk yanıt ise zamanında kalıyor.

Bir ihlal raporu ayrımı açıkça göstermelidir: Destek ekibi bir faturalandırma bileti aldı, ilk yanıt hedefini karşıladı, çözüm hedefini 40 dakika kaçırdı ve müşteriyi 4 saat 30 dakika bekledi. Yalnızca biletin toplam yaşı yanlış bir tablo sunardı.

SLA ihlallerini ekiplere göre raporlayın

Gerekli işlem gerçekleşmeden son tarih geçtiğinde bilet SLA'sını ihlal eder. Geçerli müşteri beklemelerinden sonra düzeltilmiş son tarihi kullanın.

Açık ve gecikmiş biletleri geç çözülen biletlerden ayrı tutun. Açık ve gecikmiş biletler hemen ilgilenilmesi gereken işlerdir. Geç çözülen biletler performans raporlamasına aittir. Bunları birleştirmek acil işleri gizler ve raporun kullanımını zorlaştırır.

Her dönem için sonuçları, son tarih geçtiğinde biletten sorumlu olan ekibe göre gruplayın. Politika, öncelik ve tarih aralığına göre filtreleyin. Dört saatlik yanıt politikası olan bir faturalandırma ekibi, iki iş günlük çözüm politikası olan teknik bir yükseltme ekibiyle doğrudan karşılaştırılmamalıdır.

Oranların yanında sayıları da kullanın:

• Aktif SLA'ya sahip toplam bilet sayısı
• Hedef içinde çözülen biletler
• Açık ve gecikmiş biletler
• Son tarihten sonra çözülen biletler
• SLA'ya sahip biletler içindeki ihlaller olarak hesaplanan ihlal oranı

İki biletten birinin gecikmesiyle oluşan %50 ihlal oranı, 100 biletin 50'sinin gecikmesiyle oluşan %50 oranından farklı bir anlam taşır. Eğilimleri bilet ayrıntılarıyla birlikte inceleyin. Sık yaşanan yüksek öncelikli ihlaller, genel iş yükünden çok yükseltme kurallarına veya devirlere işaret edebilir.

Yararlı bir rapor, yöneticinin geç biletler listesini açmasına, politikayı ve önceliği görmesine ve ihlal anındaki sorumluluğu kontrol etmesine izin verir. Amaç ekipleri biletleri gereğinden erken kapattıkları için ödüllendirmek değil, düzeltilmesi gereken işleri pratik biçimde incelemektir.

Temsilciler ve yöneticiler için görünümler oluşturun

Temsilcilerin eski biletlerle dolu bir rapora değil, kısa bir çalışma listesine ihtiyacı vardır. Her açık bilet sorumluyu, ekibi, önceliği, son tarihi, zamanlayıcı durumunu ve kalan süreyi göstermelidir. Bir bilet ekipler arasında taşındığında sorumluluk değişikliklerini hemen kaydedin.

Sade zamanlayıcı etiketleri kullanın. "Aktif", bir sonraki işlemden ekibin sorumlu olduğu anlamına gelir. "Duraklatıldı - müşteri bekleniyor", saatin durduğu anlamına gelir. Kullanıcıların bir biletin neden birkaç gündür açık kaldığını anlayabilmesi için aktif süreyi bekleme süresinden ayrı gösterin.

Temsilci görünümünde sonraki dört saat içinde sona erecek biletler, gecikmiş biletler, müşteri yanıtı bekleyen biletler ve bugün yeniden atanan biletler bulunabilir. Son tarihten önce uyarı gönderin. Dört saatlik yanıt hedefi, üç günlük çözüm hedefinden daha erken hatırlatmalar gerektirir.

Yöneticilerin farklı bir görünüme ihtiyacı vardır. Haftalık rapor, gecikmiş biletleri ekibe göre gruplayabilir ve ihlal sayısını, karşılanan hedef yüzdesini, ortalama gecikme süresini ve son tarihinden sonra hâlâ açık olan biletleri gösterebilir. Her gecikmiş kayıt için sorumluyu ve son güncellemeyi ekleyin.

Politika değişiklikleri için denetim kaydı tutun. Operasyon ekibi bir hedefi sekiz saatten 12 saate çıkarırsa değişikliği kimin, ne zaman yaptığını ve hangi yeni biletlerin kuralı kullandığını kaydedin. Geçmiş sonuçlar, her bilet başladığında geçerli olan kuralı korumalıdır.

AppMaster, aynı bilet verilerini ve iş kurallarını korurken temsilciler ve yöneticiler için ayrı web görünümleri oluşturmanıza olanak tanır.

SLA sonuçlarını bozan hatalar

Temiz grafikler, temel kurallar yanlış olduğunda yine de yanlış bir hikâye anlatabilir.

Zaman kurallarını kelimesi kelimesine uygulamak

Sözleşme çalışma saatlerini belirtiyorsa takvim saatleriyle hesaplama yapmayın. Cuma 16:30'da açılan ve sekiz iş saatlik yanıt hedefi olan bir bilet cumartesi 00:30'da ihlal edilmiş sayılmaz. Yalnızca politikada tanımlanan çalışma saatlerini ve tatilleri sayın.

Beklemelerde de aynı özeni gösterin. "Müşteri bekleniyor" durumu yalnızca ekip net bir talep gönderdiyse ve yanıt gelmeden devam edemiyorsa SLA'yı durdurmalıdır. Bu etikete sahip her bileti durdurmak ekibe ait gecikmeleri gizler.

Her sonucu açıklayan tarihleri koruyun: ilk son tarih, kullanılan politika, her beklemenin başlangıç ve bitiş zamanı, bekleme nedeni, düzeltilmiş son tarih, çözüm zamanı ve bileti kapatan kişi. Bu geçmiş olmadan hiç kimse bir biletin neden zamanında göründüğünü doğrulayamaz.

Sorumluluğu bir kez saymak

Ekip raporlamasında tek bir sorumluluk kuralı kullanın. Destek bir bileti Faturalandırma ekibine devrederse aynı ihlali iki ekip için saymayın. Sonuçları son tarih geçtiğinde bilete sahip olan ekibe atayabilir, devirleri ayrıca raporlayabilirsiniz.

Bir bileti kapatmadan önce çözüm zaman damgası isteyin. Kapatılmış durumu işin ne zaman bittiğini kanıtlamaz. Örneğin bilet 14:00'te Destek'ten Faturalandırma'ya geçer ve 15:00'te ihlal edilirse, ihlal anındaki sorumluluk kuralına göre ihlal Faturalandırma ekibine aittir. Rapor, ikinci bir ihlal eklemeden önceki Destek devrini yine gösterebilir.

Takip aracını kullanıma almadan önce kontrol edin

Temsilciler takip aracına güvenmeden önce her SLA politikasını inceleyin. Her politikanın dört saatlik ilk yanıt veya iki iş günlük çözüm gibi net bir hedefi ve bu hedefe uygulanan takvimi olmalıdır. Müşteri, plan veya öncelik kuralıyla eşleşmeyen biletler için varsayılan bir politika belirleyin.

Yalnızca olağan durumları değil, zor zamanlama örneklerini de test edin:

• İş günü bitmeden kısa süre önce bir bilet oluşturun ve kalan sürenin sonraki iş gününe taşındığını doğrulayın.
• Hafta sonu veya tatil öncesinde bir bilet oluşturun ve son tarihin kapalı dönemi atladığını doğrulayın.
• Bir bileti müşteri yanıtı için durdurun, yanıt ekleyin ve zamanlayıcının doğru biçimde devam ettiğini doğrulayın.
• Bir bileti ekipler arasında taşıyın ve daha sonraki bir ihlalden hangi ekibin sorumlu olduğunu kontrol edin.
• Bir bileti son tarihinden sonra kapatın ve takip aracının ihlali kaydettiğini doğrulayın.

Pano toplamlarını arkasındaki bilet listesiyle karşılaştırın. Rapor Ekip A'da 12 ihlal olduğunu söylüyorsa kayıtları filtreleyip bunları sayın. Bu işlem yinelenen biletleri, eksik ekip atamalarını ve iki kez sayılan yeniden açılmış biletleri ortaya çıkarır.

Yayınlamadan önce erişim kurallarını belirleyin. Temsilciler ilgilendikleri biletleri güncelleyebilmeli, yöneticiler ekip raporlarına erişebilmeli ve yöneticiler politika ayarlarını kontrol etmelidir. AppMaster'da her rolü ayrı bir hesapla test edin; böylece bir yöneticinin SLA ihlali raporlarını incelemek için yönetici erişimine ihtiyacı olmaz.

Küçük başlayın ve iş akışını geliştirin

Tek bir bilet türü ve tek bir SLA politikasıyla başlayın. Bir destek ekibi standart e-posta talepleri ve 24 saatlik ilk yanıt hedefiyle başlayabilir. Bu, son tarihleri, onaylı beklemeleri ve ihlal kayıtlarını test etmek için yeterlidir.

Birkaç müşteri operasyonu çalışanından gerçek biletleri iş akışından geçirmelerini isteyin. Buna normal bir durum, müşteri bekleme durumu ve kaçırılmış son tarih dahil olsun. Belirli geri bildirimler toplayın. Temsilciler müşteri beklemek ile başka bir ekibi beklemek için ayrı durumlara ihtiyaç duyabilir. Yöneticiler genel bir "duraklatıldı" etiketinin fazla bilgi gizlediğini görebilir.

Bir elektronik tablo süreci sınırlamaya başladığında takip aracını AppMaster'da kodsuz bir uygulama olarak oluşturun. Bilet formları oluşturabilir, zamanlayıcı mantığını görsel Business Process Editor'da tanımlayabilir ve temsilcilerle yöneticilere ayrı panolar sunabilirsiniz. Takip aracının paylaşılan bir tablonun ötesinde çalışması gerektiğinde AppMaster arka ucu, web uygulamasını ve yerel mobil uygulamayı oluşturabilir.

İlk aşamada raporlamayı sınırlı tutun: açık biletler, ihlale yaklaşan biletler, bekleyen biletler ve ekiplere göre ihlaller. Örnek son tarihlerini elle yapılan kontrollerle karşılaştırın, ihlal edilen biletleri ve bekleme dönemlerini inceleyin, yeniden test etmeden önce her seferinde tek bir kuralı değiştirin. Çalışanlar hesaplamalara güvendiğinde başka bir bilet türü veya öncelik politikası ekleyin ve aynı kontrolleri tekrarlayın.