Çoklu bildirimler ve toplu olaylar

Talep listesinde satırları işaretleyin ve “Multiple report” düğmesine tıklayın. Düğme, iki işaretli satırdan itibaren kullanılabilir olur.

Pencere önce sorar: “Which ticket stays?” En eski talep önceden seçilidir, böylece son tarih talep edenin ikinci denemesinden değil, ilk temasından itibaren işler. Başka birini seçebilirsiniz.

Altında yön iki numarayla birlikte durur: “#11 will be closed and moved into #10.” Böylece tıklamadan önce hangi talebin kalacağı bellidir.

Her şey birlikte gelir: ikinci bildirimin yorumları, ekleri ve açıklaması. Açıklama, özgün yazarı ve tarihiyle birlikte asıl talebin bir yorumu olur. Pencere sayıları önceden belirtir.

Kaydedilen süre kopyalanmaz, taşınır. Yoksa aynı emek iki talepte durur ve iki kez faturalanırdı.

İkinci bildirim silinmez. Kapatılır ve o andan sonra asıl talebe gönderme yapar, numarası geçerli kalır.

Talep eden ayrı bir e-posta almaz. O, asıl talebin üzerindedir ve her şeyi orada görür. Kapatılan bildirim, asıl talebi adlandıran ve onun okuyabileceği bir yorum taşır.

Geri alma yoktur. Bu yüzden “Merge” düğmesine tıklamadan önce her şey pencerede durur.

Sonrasında iki talebin geçmişi kimin neyi ne zaman birleştirdiğini kaydeder.

Talep edenin posta kutusunda eski talep numarası vardır. İki bildirimin birleştirildiğinden haberi yoktur ve elindeki postayı yanıtlar.

O yanıt asıl talebin içine düşer. Sistem, kapatılan bildirimin taşıdığı göndermeyi izler.

Birleştirilmiş bir bildirimin hiçbir zaman silinmemesinin nedeni budur. O olmadan gönderme var olmazdı ve yanıt hiçbir yere ulaşmazdı.

Eski bildirimde yer alan kişi asıl talebe de yazabilir. Denetim, postada adı geçen talepte yapılır.

Farklı kişilerin taleplerini seçerseniz pencere onları almaz. Siz tıklamadan önce geri çevrilen her satırı ve nedenini adlandırır.

Neden şöyle okunur: “Different requester — this is an incident, not a multiple report.” Ayrıca size bunun yerine nereye gitmeniz gerektiğini söyler.

Bu, işlevin tamamının en önemli korumasıdır. Otuz kişiden gelen otuz bildirimi birleştirseydiniz yirmi dokuzu talebini kaybeder ve bir daha haber almazdı.

Talep edenin kim olduğuna önce talepteki e-posta adresi karar verir. Yoksa “User” alanındaki yabancı bir ad karar verir ve aynı ad aynı kişi sayılır. O da yoksa talebi oluşturan hesap sayılır.

Korumanın telefon görüşmeleri için de geçerli olmasının nedeni budur. Bir temsilci iki çağrı kaydederse iki talebi de o oluşturmuştur. Farklı arayanlar yine farklı arayan kalır, çünkü adları alandadır.

Bir tarafta talep eden belirlenemiyorsa bu da geri çevrilir. Bilinmeyen, aynı kişiyle aynı şey değildir.

Aynı kutuda başka nedenler de görünür. Bir toplu olay birleştirilemez. Kapanmış bir asıl talep artık hiçbir şey almaz. Ve kendi bildirimleri olan bir bildirim birlikte gelmez, böylece zincir oluşmaz.

Dosya sunucusu çöktüğünde yirmi kişi bunu bildirir. Bu bildirimlerin her biri kendi talep edeniyle kendi işidir. Burada birleştirmek yanlış olurdu, çünkü on dokuz kişi talebini kaybederdi.

Bildirimleri işaretleyin ve “Group into incident” düğmesine tıklayın. Pencere üç yol sunar: onları zaten açık bir toplu olaya eklemek, seçilen taleplerden birini toplu olay ilan etmek ya da kendi başlığıyla yeni bir toplu olay oluşturmak.

Ekibin zaten açık bir toplu olayı varsa o yol önceden seçilidir. Daha sık olan yoldur: arıza çoktan bilinmektedir, yalnızca yeni bildirimler gelmeye devam eder.

Bağlı her talep kendi talep edenini, kendi durumunu ve kendi son tarihini korur. Hiçbir şey kaybolmaz. Toplu olay yalnızca yanıtı toplar.

Bir toplu olayın tüm bildirimlerinin aynı ekibe ait olması gerekir. Bir arıza iki ekibi etkiliyorsa her biri kendi toplu olayını alır. Yoksa bir ekibin çözümü öbür ekibin kuyruğunu boşaltırdı.

Sonradan gelenleri tek talepte de ekleyebilirsiniz. Ekibin açık bir toplu olayı varsa üstte “Assign” ve “Not related” düğmeleriyle bir ipucu belirir. Sistem hiçbir zaman kendiliğinden bir şey eklemez: yanlış eklenmiş bir talep, kendisini ilgilendirmeyen bir çözüm alır ve bu arada kapatılırdı.

Toplu olay talebi kendisine kaç bildirimin bağlı olduğunu belirtir. Bağlı talepler ise toplu olaylarının numarasını taşır, hem listede hem sağdaki kartta.

“Resolve incident” toplu olayı kapatır ve tüm bildirimleri tek seferde yanıtlar. Çözüm metni zorunludur: işlevin bütün anlamı odur, çünkü etkilenen herkese gider.

Bağlı her talep metni açık bir yorum olarak alır, seçilen duruma getirilir ve talep edeni kendi e-postasını alır. Toplu posta yoktur, çünkü o, etkilenen herkesin adresini açığa çıkarırdı.

Sonrasındaki ileti kaç talebin kapatıldığını ve kaç talep edenin bilgilendirildiğini belirtir. İki sayı ayrı durur, çünkü ulaşılabilir adresi olmayan bir talep bir yorum ve bir durum alır, ama e-posta almaz.

Bu arada kendiniz yanıtlayıp kapattığınız bir talebe dokunulmaz. İkinci kez kapatılmaz ve yeniden yazılmaz.

Bir toplu olaya açık bildirimler asılı olduğu sürece o, olağan durum değişikliğiyle kapatılamaz. Yoksa yirmi kişi sessizce yanıtsız kalırdı.

Pencere ve toplu olay talebi, ikisi de “Also show as a banner on the sign-in page” onay kutusunu taşır. Onunla herkes, bir talep daha yazmadan önce arızayı öğrenir.

Şerit, oturum açma sayfasında ve oturum açıldıktan sonra sistemin içinde durur. “Known incident” ifadesini ve toplu olayın başlığını adlandırır, yani o başlık müşteriler için bir metindir.

Birden çok duyuru etkinse alt alta dururlar. Cumartesi için duyurulmuş bakım bugünün arızasını itmez, tersi de olmaz.

Biri yine de yeni bir talep oluşturursa otomatik yanıt toplu olayı adlandırır. Bu, zaten bağlı bir talep için ve toplu olay açık ve duyurulmuş olduğu sürece o ekibin her yeni talebi için geçerlidir. Bunun için giden e-posta gerekir.

Toplu olay çözüldüğünde şerit kendiliğinden kaybolur. Kimsenin onu yeniden kapatmayı akılda tutması gerekmez.

“Maintenance and incident notices” sayfasında şu anda hangi toplu olayın şerit olarak çalıştığını görebilirsiniz. O sayfadaki anahtar planlı bakıma aittir ve toplu olaylar için geçerli değildir.