Več prijav in skupinski incidenti

Označite vrstice v seznamu zahtevkov in kliknite »Multiple report«. Gumb postane uporaben od dveh označenih vrstic naprej.

Pogovorno okno najprej vpraša: »Which ticket stays?« Vnaprej je izbran najstarejši zahtevek, tako da rok teče od prvega stika vlagatelja in ne od njegovega drugega poskusa. Izberete lahko drugega.

Pod tem stoji smer z obema številkama: »#11 will be closed and moved into #10.« Tako je že pred klikom jasno, kateri zahtevek ostane.

Zraven gre vse: komentarji, priloge in opis druge prijave. Opis postane komentar na izvirniku, s svojim izvirnim avtorjem in svojim datumom. Pogovorno okno števila navede vnaprej.

Zabeleženi čas se premakne, ne prekopira. Sicer bi isti trud stal na dveh zahtevkih in bil dvakrat zaračunan.

Druga prijava ni izbrisana. Zaprta je in od takrat kaže na izvirnik, njena številka pa ostane veljavna.

Vlagatelj ne dobi posebne e-pošte. Je na izvirniku in tam vidi vse. Zaprta prijava nosi komentar, ki navede izvirnik in ga lahko prebere.

Razveljavitve ni. Zato vse stoji v pogovornem oknu, preden kliknete »Merge«.

Zatem zgodovina obeh zahtevkov zabeleži, kdo je kaj združil in kdaj.

Vlagatelj ima v svojem nabiralniku staro številko zahtevka. O tem, da sta bili dve prijavi združeni, ne ve ničesar, in odgovori na sporočilo, ki ga ima.

Ta odgovor pristane v izvirniku. Sistem sledi sklicu, ki ga nosi zaprta prijava.

Zato združena prijava ni nikoli izbrisana. Brez nje sklic ne bi obstajal in odgovor ne bi prispel nikamor.

Kdor je bil udeležen pri stari prijavi, sme pisati tudi na izvirnik. Preverjanje se zgodi na zahtevku, ki je naveden v sporočilu.

Če izberete zahtevke različnih oseb, jih pogovorno okno ne vzame zraven. Vsako zavrnjeno vrstico in njen razlog navede pred klikom.

Razlog se glasi: »Different requester — this is an incident, not a multiple report.« Pove tudi, kam naj greste namesto tega.

To je najpomembnejši varuh celotne funkcije. Če bi združili trideset prijav tridesetih ljudi, bi devetindvajset od njih izgubilo svoj zahtevek in nikoli več ne bi ničesar slišalo.

Kdo je vlagatelj, najprej določa e-poštni naslov na zahtevku. Če ga ni, odloča tuje ime v polju »User«, isto ime pa šteje kot ista oseba. Sicer šteje račun, ki je zahtevek ustvaril.

Zato varuh drži tudi pri telefonskih klicih. Če agent zabeleži dva klica, je oba zahtevka ustvaril on. Različna klicatelja vseeno ostaneta različna, ker sta njuni imeni v polju.

Če vlagatelja na eni strani ni mogoče ugotoviti, je prav tako zavrnjeno. Neznano ni isto kot ista oseba.

V istem okvirčku se pokažejo še drugi razlogi. Skupinskega incidenta ni mogoče združiti. Zaprt izvirnik ne sprejme več ničesar. In prijava, ki že ima svoje prijave, ne gre zraven, tako da ne nastajajo verige.

Ko datotečni strežnik odpove, to prijavi dvajset ljudi. Vsaka od teh prijav je svoj primer s svojim vlagateljem. Združevanje bi bilo tu napačno, ker bi devetnajst ljudi izgubilo svoj zahtevek.

Označite prijave in kliknite »Group into incident«. Pogovorno okno ponudi tri poti: dodajte jih k skupinskemu incidentu, ki je že odprt, enega izmed izbranih zahtevkov razglasite za skupinski incident ali ustvarite nov skupinski incident z lastnim naslovom.

Če ima ekipa že odprt skupinski incident, je ta pot izbrana vnaprej. Pogostejša je: motnja je že dolgo znana, prihajajo samo nove prijave.

Vsak povezani zahtevek ohrani svojega vlagatelja, svoje stanje in svoj rok. Nič ne izgine. Skupinski incident združi samo odgovor.

Vse prijave enega skupinskega incidenta morajo pripadati isti ekipi. Če motnja zadeva dve ekipi, vsaka dobi svoj skupinski incident. Sicer bi rešitev ene ekipe izpraznila čakalno vrsto druge.

Zamudnike lahko pripnete tudi pri posameznem zahtevku. Če ima ekipa odprt skupinski incident, se na vrhu pokaže namig z »Assign« in »Not related«. Sistem sam nikoli ničesar ne pripne: napačno pripet zahtevek bi dobil rešitev, ki ga ne zadeva, in bil mimogrede zaprt.

Zahtevek skupinskega incidenta navede, koliko prijav je nanj pripetih. Povezani zahtevki pa nosijo številko svojega skupinskega incidenta, v seznamu in v kartici na desni.

»Resolve incident« zapre skupinski incident in naenkrat odgovori na vse prijave. Besedilo rešitve je obvezno: v njem je celoten smisel te funkcije, saj gre vsem prizadetim.

Vsak povezani zahtevek dobi besedilo kot javni komentar, dobi izbrano stanje, njegov vlagatelj pa prejme svojo e-pošto. Brez skupinskega sporočila, ker bi to razkrilo naslove vseh prizadetih.

Sporočilo zatem navede, koliko zahtevkov je bilo zaprtih in koliko vlagateljev je bilo obveščenih. Številki stojita ločeno, ker zahtevek brez dosegljivega naslova dobi komentar in stanje, ne pa e-pošte.

Zahtevek, na katerega ste medtem sami odgovorili in ga zaprli, ostane nedotaknjen. Ni zaprt drugič in ni znova popisan.

Dokler na skupinskem incidentu visijo odprte prijave, ga ni mogoče zapreti z običajno spremembo stanja. Sicer bi dvajset ljudi tiho ostalo brez odgovora.

Pogovorno okno in zahtevek skupinskega incidenta nosita potrditveno polje »Also show as a banner on the sign-in page«. Z njim vsi izvedo za motnjo, preden napišejo še en zahtevek.

Pasica stoji na prijavni strani in po prijavi znotraj sistema. Navede »Known incident« in naslov skupinskega incidenta, zato je ta naslov besedilo za stranke.

Če je dejavnih več obvestil, stojijo drugo pod drugim. Vzdrževanje, napovedano za soboto, ne odrine današnje motnje, in obratno.

Če kdo vseeno ustvari nov zahtevek, samodejni odgovor navede skupinski incident. To velja za zahtevek, ki je že povezan, in za vsak nov zahtevek te ekipe, dokler je skupinski incident odprt in napovedan. Za to je potrebna odhodna e-pošta.

Ko je skupinski incident rešen, pasica izgine sama. Nikomur se ni treba spomniti, da bi jo znova izklopil.

Na strani »Maintenance and incident notices« vidite, kateri skupinski incident trenutno teče kot pasica. Stikalo na tej strani pripada načrtovanemu vzdrževanju in za skupinske incidente ne velja.