Flera anmälningar och samlingsärenden

Bocka i raderna i ärendelistan och klicka på ”Multiple report”. Knappen blir användbar från två ibockade rader och uppåt.

Dialogen frågar först: ”Which ticket stays?” Det äldsta ärendet är förvalt, så att tidsfristen löper från anmälarens första kontakt i stället för från deras andra försök. Du kan välja ett annat.

Under det står riktningen med båda numren: ”#11 will be closed and moved into #10.” Så är det klart före klicket vilket ärende som blir kvar.

Allt följer med: kommentarer, bilagor och den andra anmälans beskrivning. Beskrivningen blir en kommentar på originalet, med sin ursprungliga författare och sitt datum. Dialogen anger antalen i förväg.

Registrerad tid flyttas, den kopieras inte. Annars skulle samma arbetsinsats ligga på två ärenden och faktureras två gånger.

Den andra anmälan raderas inte. Den stängs och pekar från och med då på originalet, och dess nummer förblir giltigt.

Anmälaren får inget separat e-postmeddelande. De står på originalet och ser allt där. Den stängda anmälan bär en kommentar som nämner originalet, och den kan de läsa.

Det finns ingen ångerknapp. Därför står allt i dialogen innan du klickar på ”Merge”.

Efteråt registrerar båda ärendenas historik vem som slog ihop vad och när.

Anmälaren har det gamla ärendenumret i sin brevlåda. De vet ingenting om att två anmälningar har slagits ihop och svarar på meddelandet de har.

Det svaret hamnar i originalet. Systemet följer referensen som den stängda anmälan bär.

Det är därför en sammanslagen anmälan aldrig raderas. Utan den skulle referensen inte finnas och svaret skulle inte komma fram någonstans.

Den som deltog i den gamla anmälan får också skriva på originalet. Kontrollen sker på ärendet som nämns i meddelandet.

Markerar du ärenden från olika personer tar dialogen inte med dem. Den namnger varje avvisad rad och dess skäl innan du klickar.

Skälet lyder: ”Different requester — this is an incident, not a multiple report.” Det säger också vart du ska gå i stället.

Det här är hela funktionens viktigaste spärr. Slog du ihop trettio anmälningar från trettio personer skulle tjugonio av dem förlora sitt ärende och aldrig höra något mer.

Vem anmälaren är avgörs i första hand av e-postadressen på ärendet. Finns ingen avgör ett externt namn i fältet ”User”, och samma namn räknas som samma person. Annars räknas kontot som skapade ärendet.

Det är därför spärren också håller för telefonsamtal. Registrerar en agent två samtal är båda ärendena skapade av dem. Olika uppringare förblir ändå olika uppringare, eftersom deras namn står i fältet.

Går anmälaren inte att fastställa på ena sidan avvisas det också. Okänd är inte samma sak som samma person.

Fler skäl visas i samma ruta. Ett samlingsärende går inte att slå ihop. Ett stängt original tar inte emot något mer. Och en anmälan som redan har egna anmälningar följer inte med, så att inga kedjor bildas.

När filservern går ner anmäler tjugo personer det. Var och en av de här anmälningarna är ett eget fall med sin egen anmälare. Att slå ihop vore fel här, eftersom nitton personer skulle förlora sitt ärende.

Bocka i anmälningarna och klicka på ”Group into incident”. Dialogen erbjuder tre vägar: lägga till dem i ett samlingsärende som redan är öppet, förklara ett av de markerade ärendena som samlingsärendet, eller skapa ett nytt samlingsärende med en egen titel.

Har teamet redan ett öppet samlingsärende är den vägen förvald. Det är den vanligare: driftstörningen är sedan länge känd, det är bara nya anmälningar som fortsätter komma in.

Varje kopplat ärende behåller sin anmälare, sin status och sin egen tidsfrist. Ingenting försvinner. Samlingsärendet buntar bara svaret.

Alla anmälningar i ett samlingsärende måste tillhöra samma team. Berör en störning två team får vart och ett sitt eget samlingsärende. Annars skulle ett teams lösning tömma det andra teamets kö.

Du kan också koppla på eftersläntrare på det enskilda ärendet. Har teamet ett öppet samlingsärende dyker ett tips upp överst med ”Assign” och ”Not related”. Systemet kopplar aldrig på något av sig självt: ett felaktigt påkopplat ärende skulle få en lösning som inte rör det, och skulle stängas på vägen.

Samlingsärendet anger hur många anmälningar som är kopplade till det. Kopplade ärenden bär i sin tur sitt samlingsärendes nummer, i listan och i kortet till höger.

”Resolve incident” stänger samlingsärendet och besvarar alla anmälningar på en gång. Lösningstexten är obligatorisk: den är hela poängen med funktionen, eftersom den går till alla berörda.

Varje kopplat ärende får texten som en offentlig kommentar, sätts till den valda statusen, och dess anmälare får ett eget e-postmeddelande. Inget gruppmeddelande, eftersom det skulle blotta adresserna till alla berörda.

Meddelandet efteråt anger hur många ärenden som stängdes och hur många anmälare som aviserades. Båda talen står isär, eftersom ett ärende utan en nåbar adress får en kommentar och en status men inget e-postmeddelande.

Ett ärende du själv har besvarat och stängt under tiden lämnas orört. Det stängs inte en andra gång och skrivs inte till igen.

Så länge öppna anmälningar hänger på ett samlingsärende går det inte att stänga via den vanliga statusändringen. Annars skulle tjugo personer tyst bli utan svar.

Både dialogen och samlingsärendet bär kryssrutan ”Also show as a banner on the sign-in page”. Med den får alla veta om störningen innan de skriver ännu ett ärende.

Bannern står på inloggningssidan och inuti systemet när man är inloggad. Den nämner ”Known incident” och samlingsärendets titel, så den titeln är en text för kunder.

Är flera meddelanden aktiva står de under varandra. Underhåll som aviserats för lördagen tränger inte undan dagens störning, och tvärtom.

Skapar någon ändå ett nytt ärende nämner autosvaret samlingsärendet. Det gäller för ett ärende som redan är kopplat och för varje nytt ärende i det teamet, så länge samlingsärendet är öppet och aviserat. Det här kräver utgående e-post.

När samlingsärendet väl är löst försvinner bannern av sig själv. Ingen behöver komma ihåg att stänga av den igen.

På sidan ”Maintenance and incident notices” ser du vilket samlingsärende som just nu körs som banner. Reglaget på den sidan hör till planerat underhåll och gäller inte samlingsärenden.