Zgłoszenia wielokrotne i awarie zbiorcze

Zaznacz wiersze na liście zgłoszeń i kliknij „Multiple report”. Przycisk staje się użyteczny od dwóch zaznaczonych wierszy.

Okno pyta najpierw: „Which ticket stays?” Najstarsze zgłoszenie jest wybrane z góry, więc termin biegnie od pierwszego kontaktu zgłaszającego, a nie od jego drugiej próby. Możesz wybrać inne.

Pod spodem stoi kierunek z obydwoma numerami: „#11 will be closed and moved into #10.” Przed kliknięciem jasne jest więc, które zgłoszenie zostaje.

Wszystko idzie razem: komentarze, załączniki i opis drugiego zgłoszenia. Opis staje się komentarzem przy pierwotnym zgłoszeniu, ze swoim pierwotnym autorem i swoją datą. Okno podaje liczby z góry.

Zapisany czas jest przenoszony, a nie kopiowany. Inaczej ten sam nakład pracy siedziałby przy dwóch zgłoszeniach i zostałby rozliczony dwa razy.

Drugie zgłoszenie nie jest usuwane. Zostaje zamknięte i od tej pory wskazuje na pierwotne, a jego numer pozostaje ważny.

Zgłaszający nie dostaje osobnego e-maila. Jest przy pierwotnym zgłoszeniu i tam widzi wszystko. Zamknięte zgłoszenie niesie komentarz nazywający pierwotne, który może przeczytać.

Nie ma cofnięcia. Dlatego wszystko stoi w oknie, zanim klikniesz „Merge”.

Potem historia obu zgłoszeń zapisuje, kto, co i kiedy scalił.

Zgłaszający ma w swojej skrzynce stary numer zgłoszenia. Nic nie wie o scaleniu dwóch zgłoszeń i odpowiada na wiadomość, którą ma.

Ta odpowiedź trafia do pierwotnego zgłoszenia. System idzie za odwołaniem, które niesie zamknięte zgłoszenie.

Dlatego scalone zgłoszenie nigdy nie jest usuwane. Bez niego nie istniałoby odwołanie, a odpowiedź nie dotarłaby nigdzie.

Kto brał udział w starym zgłoszeniu, może też pisać przy pierwotnym. Sprawdzenie odbywa się na zgłoszeniu wymienionym w wiadomości.

Jeśli zaznaczysz zgłoszenia od różnych osób, okno ich nie weźmie. Nazywa każdy odrzucony wiersz i jego powód, zanim klikniesz.

Powód brzmi: „Different requester — this is an incident, not a multiple report.” Mówi też, dokąd pójść zamiast tego.

To najważniejszy strażnik całej funkcji. Gdybyś scalił trzydzieści zgłoszeń od trzydziestu osób, dwadzieścia dziewięć z nich straciłoby swoje zgłoszenie i nigdy nie dostałoby odpowiedzi.

O tym, kto jest zgłaszającym, decyduje najpierw adres e-mail przy zgłoszeniu. Jeśli go nie ma, decyduje obca nazwa w polu „User”, a ta sama nazwa liczy się jako ta sama osoba. W przeciwnym razie liczy się konto, które zgłoszenie utworzyło.

Dlatego strażnik obowiązuje też przy rozmowach telefonicznych. Jeśli agent zapisze dwie rozmowy, oba zgłoszenia utworzył on. Różni dzwoniący i tak zostają różnymi dzwoniącymi, bo ich nazwiska stoją w polu.

Jeśli po jednej stronie nie da się ustalić zgłaszającego, zgłoszenie też jest odrzucane. Nieznany to nie to samo co ta sama osoba.

W tym samym polu pojawiają się kolejne powody. Awarii zbiorczej nie da się scalić. Zamknięte zgłoszenie pierwotne nic już nie przyjmuje. A zgłoszenie, które ma już własne zgłoszenia, nie idzie razem, żeby nie powstawały łańcuchy.

Kiedy pada serwer plików, zgłasza to dwadzieścia osób. Każde z tych zgłoszeń jest osobną sprawą z własnym zgłaszającym. Scalanie byłoby tu błędem, bo dziewiętnaście osób straciłoby swoje zgłoszenie.

Zaznacz zgłoszenia i kliknij „Group into incident”. Okno oferuje trzy drogi: dodać je do już otwartej awarii zbiorczej, ogłosić jedno z zaznaczonych zgłoszeń awarią zbiorczą albo utworzyć nową awarię zbiorczą z własnym tytułem.

Jeśli zespół ma już otwartą awarię zbiorczą, ta droga jest wybrana z góry. Jest ona częstsza: awaria jest znana od dawna, tylko wciąż przychodzą nowe zgłoszenia.

Każde powiązane zgłoszenie zachowuje swojego zgłaszającego, swój status i własny termin. Nic nie znika. Awaria zbiorcza łączy tylko odpowiedź.

Wszystkie zgłoszenia jednej awarii zbiorczej muszą należeć do tego samego zespołu. Jeśli awaria dotyka dwóch zespołów, każdy dostaje własną awarię zbiorczą. Inaczej rozwiązanie jednego zespołu opróżniłoby kolejkę drugiego.

Spóźnione zgłoszenia możesz dopiąć także przy pojedynczym zgłoszeniu. Jeśli zespół ma otwartą awarię zbiorczą, na górze pojawia się podpowiedź z przyciskami „Assign” i „Not related”. System nigdy nie dopina niczego sam: źle dopięte zgłoszenie dostałoby rozwiązanie, które go nie dotyczy, i zostałoby przy okazji zamknięte.

Zgłoszenie awarii zbiorczej podaje, ile zgłoszeń jest do niego dopiętych. Powiązane zgłoszenia z kolei niosą numer swojej awarii zbiorczej, na liście i na karcie po prawej.

„Resolve incident” zamyka awarię zbiorczą i odpowiada na wszystkie zgłoszenia naraz. Tekst rozwiązania jest obowiązkowy: to cały sens tej funkcji, bo trafia on do wszystkich dotkniętych.

Każde powiązane zgłoszenie dostaje ten tekst jako komentarz publiczny, przechodzi na wybrany status, a jego zgłaszający dostaje własnego e-maila. Bez wiadomości zbiorczej, bo ta odsłoniłaby adresy wszystkich dotkniętych.

Komunikat po wykonaniu podaje, ile zgłoszeń zamknięto i ilu zgłaszających powiadomiono. Obie liczby stoją osobno, bo zgłoszenie bez osiągalnego adresu dostaje komentarz i status, ale nie wiadomość.

Zgłoszenie, na które sam w międzyczasie odpowiedziałeś i je zamknąłeś, zostaje nietknięte. Nie jest zamykane drugi raz i nie pisze się do niego ponownie.

Dopóki przy awarii zbiorczej wiszą otwarte zgłoszenia, nie da się jej zamknąć zwykłą zmianą statusu. Inaczej dwadzieścia osób zostałoby po cichu bez odpowiedzi.

Okno i samo zgłoszenie awarii zbiorczej niosą pole wyboru „Also show as a banner on the sign-in page”. Dzięki niemu każdy dowiaduje się o awarii, zanim napisze kolejne zgłoszenie.

Baner stoi na stronie logowania i wewnątrz systemu po zalogowaniu. Nazywa „Known incident” i tytuł awarii zbiorczej, więc ten tytuł jest tekstem dla klientów.

Jeśli aktywnych jest kilka ogłoszeń, stoją jedno pod drugim. Prace serwisowe zapowiedziane na sobotę nie spychają dzisiejszej awarii, i odwrotnie.

Jeśli ktoś mimo to założy nowe zgłoszenie, automatyczna odpowiedź nazywa awarię zbiorczą. Dotyczy to zgłoszenia już powiązanego i każdego nowego zgłoszenia tego zespołu, dopóki awaria zbiorcza jest otwarta i ogłoszona. Potrzebna jest do tego wysyłka poczty.

Gdy awaria zbiorcza zostanie rozwiązana, baner znika sam. Nikt nie musi pamiętać, żeby go wyłączyć.

Na stronie „Maintenance and incident notices” widzisz, która awaria zbiorcza działa właśnie jako baner. Przełącznik na tej stronie należy do zaplanowanych prac serwisowych i awarii zbiorczych nie dotyczy.