I tvister om IT-leverancer, drift og support er ticketsystemet ofte den mest detaljerede kilde til, hvad der skete. Her blev fejl meldt, prioriteret, kommenteret og lukket. Her blev ændringsønsker oprettet og godkendt. Systemer som Jira, Zendesk, ServiceNow og Freshdesk gemmer ikke bare den aktuelle status, men også historikken bag. Den historik er ofte mere værd end den pæne oversigt, der fremlægges.
Denne artikel ser på, hvordan advokaten får fat i den rigtige del af ticketsystemet, og hvilke faldgruber der er. Den overordnede bevisførelse i leverancesager er beskrevet i Mangler ved IT-leverancer: dokumentation i retssagen.
Hvad en ticket indeholder
En typisk sag, også kaldet en ticket eller et issue, indeholder:
- titel og beskrivelse,
- hvem der oprettede den og hvornår,
- status, fx åben, under behandling, venter på kunde, løst, lukket,
- prioritet og eventuelt alvorlighed,
- hvem sagen var tildelt,
- kommentarer, både synlige for kunden og interne,
- vedhæftede filer, fx skærmbilleder og logfiler,
- tidsregistreringer,
- koblinger til andre sager, versioner og leverancer.
Dertil kommer historikken: en log over hver ændring af hvert felt med tidspunkt og bruger. Det er her, de fleste afgørende oplysninger findes.
Hvad historikken kan afsløre
Prioritet og alvorlighed
I tvister om SLA er prioriteten ofte afgørende for, hvilken svartid der gjaldt. Historikken viser, hvilken prioritet sagen fik ved oprettelsen, og om den senere blev ændret. En fejl, der blev oprettet som kritisk og nedgraderet en time senere, fortæller en anden historie end den aktuelle status. → SaaS-tvister: oppetid, SLA og logdata
Statusskift og SLA-ure
Mange systemer har ure, der måler svartid og løsningstid. Urene sættes typisk på pause i bestemte statusser, fx “venter på kunde”. Hvis en sag gentagne gange er sat i den status, kan det have flyttet den beregnede løsningstid betydeligt. Historikken viser, hvornår og af hvem.
Lukning og genåbning
En sag kan være lukket automatisk efter en periode uden svar, eller lukket af leverandøren og genåbnet af kunden. Forløbet kan vise, om fejlen reelt blev løst.
Interne kommentarer
Interne kommentarer er kun synlige for leverandørens medarbejdere. De kan indeholde vurderinger af fejlens årsag, alvor eller ansvar, som aldrig blev delt med kunden. I en editionssag kan de være de mest relevante dele af systemet.
Redigerede og slettede kommentarer
Nogle systemer gemmer tidligere versioner af redigerede kommentarer. Andre gør ikke. Sletning kan være mulig for administratorer og efterlader ikke altid spor.
Tidsregistreringer og fakturering
Mange leverandører registrerer tid direkte på sagerne, og registreringerne bruges som grundlag for fakturering. I tvister om timeforbrug og fakturaer kan de være centrale. Vær opmærksom på, at tidsregistreringer kan være indtastet bagud, rettet efterfølgende eller fordelt på sager efter et skøn. Historikken over registreringerne viser, hvornår de blev indtastet og ændret. En registrering, der er oprettet samme dag som fakturaen, for arbejde udført måneder tidligere, er ikke nødvendigvis forkert, men den er svagere end en løbende registrering.
Det, der ikke står i systemet
Ticketsystemet er sjældent hele historien. En del af kommunikationen foregår i mails, chatkanaler som Teams og Slack, telefonopkald og møder. En sag kan se stille ud i systemet, fordi alt blev aftalt i en chat. Omvendt kan en kommentar i sagen henvise til en aftale, der ikke er dokumenteret andre steder.
Sammenstil derfor ticketsystemets forløb med mails og chat fra samme periode. En tidslinje, hvor alle kilder er lagt sammen, viser ofte huller og modsigelser, som ingen af kilderne viser alene. → Tidslinjer som bevis
Hvem har systemet?
Ticketsystemet tilhører typisk den ene part, oftest leverandøren. Kunden har måske adgang via en portal, men ser kun de felter og kommentarer, der er gjort synlige for kunder. Historikken er ofte ikke synlig i portalen.
Er klienten kunden, har klienten derfor kun en del af billedet. Det, klienten kan se, bør sikres med det samme, og resten må typisk indhentes hos modparten. Er klienten leverandøren, har klienten hele systemet, men også en forpligtelse til at håndtere det korrekt. → Når klienten er IT-leverandøren: egen dokumentation
Eksport: hvad der går tabt
Den hurtigste eksport er ofte et regneark med en række pr. sag. Det mister typisk:
- historikken over ændringer,
- interne kommentarer,
- vedhæftede filer,
- koblinger mellem sager.
En fuld eksport via systemets programmeringsgrænseflade eller en administratoreksport indeholder mere. Den kræver dog teknisk bistand og skal dokumenteres, så det kan vises, hvad der er trukket ud. Skærmbilleder af enkelte sager er nyttige som supplement, men de viser kun det, der er synligt i den aktuelle visning. Vedhæftede logfiler og skærmbilleder i sagerne bør eksporteres som originalfiler, så deres egne metadata bevares.
Opsætningen ændrer sig over tid
Ticketsystemer konfigureres løbende. Nye statusser kommer til, prioritetsdefinitioner ændres, og automatiske regler lukker eller flytter sager. En status, der i dag betyder én ting, kunne betyde noget andet for et år siden. Bed derfor om dokumentation af opsætningen i den relevante periode, herunder automatiseringsregler og SLA-definitioner.
Sikring tidligt
Ticketsystemer i skyen har ofte regler for opbevaring og sletning. Når et kundeforhold ophører, kan kundens portaladgang lukkes og data arkiveres eller slettes. Klienten bør derfor sikre sin adgang og sine data, før samarbejdet afsluttes, og modparten bør anmodes om at bevare systemet. → Bevarelsespligt og litigation hold
Hvad advokaten bør bede om
- Fuld eksport af de relevante sager med historik, interne kommentarer og vedhæftninger.
- Dokumentation af statusser, prioriteter og SLA-regler i perioden.
- Oversigt over automatiseringsregler, der kan have ændret sager.
- Brugerliste med roller, så det fremgår, hvem der kunne ændre hvad.
- Oplysning om, hvordan eksporten er lavet, og af hvem.
Afgræns efter projekt, periode, sagstype eller kunde, så udtrækket ikke rummer hele leverandørens kundeportefølje. Det gør begæringen lettere at imødekomme og sparer tid ved gennemgangen.
Spørgsmål til den, der har lavet udtrækket
Når modparten fremlægger data fra ticketsystemet, er det ofte en medarbejder eller en sagkyndig, der har trukket dem ud. Følgende spørgsmål kan afklare, hvor meget udtrækket kan bære:
- Hvilke projekter, perioder og sagstyper er medtaget, og med hvilke filtre?
- Er sager, der er slettet, flyttet til et andet projekt eller arkiveret, med i udtrækket?
- Er interne kommentarer og historik medtaget, eller kun de felter, kunden kunne se?
- Er tidsstempler angivet i dansk tid eller i UTC?
- Hvilke brugere havde rettigheder til at redigere eller slette kommentarer i perioden?
- Er systemets felter, statusser eller arbejdsgange ændret, siden sagerne blev oprettet?
Svarene afgør, om udtrækket kan bruges som et fuldstændigt billede, eller om det skal suppleres. → Skabelon: spørgsmål til modpartens sagkyndige
Typiske fejl
- At nøjes med et regneark uden historik.
- At læse den aktuelle prioritet som den oprindelige.
- At overse, at SLA-ure kan være sat på pause.
- At glemme interne kommentarer, som kunden aldrig så.
- At lade portaladgangen lukke, før kundens data er sikret.
- At overse automatiske regler, der har lukket eller flyttet sager.
Tjekliste
- ☐ Ticketsystemet og dets ejer er identificeret
- ☐ Klientens egen adgang er sikret
- ☐ Historik, interne kommentarer og vedhæftninger er efterspurgt
- ☐ Opsætningen i perioden er dokumenteret
- ☐ Eksportmetoden er beskrevet
- ☐ Modparten er anmodet om at bevare data
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT
