Har du nogensinde siddet med en ServiceNow-sag, der var så tynd på fakta, at den var umulig at løse – eller så lang og rodet, at ingen gad læse den? Resultatet er det samme: spildtid, eskalerende frustration og forretningskritiske deadlines, der glider.

I en tid hvor hver eneste minut tæller på bundlinjen, er evnen til at formulere en knivskarp sag ikke en skriveøvelse – det er en konkurrencefordel. På få linjer skal du oversætte kaos til klarhed, så både servicedesk, specialister og forretning kan træffe de rigtige beslutninger, første gang.

Denne guide viser dig, trin for trin, hvordan du forvandler vage beskrivelser til præcise handlingsplaner – fra forberedelsen inden du trykker “Create”, til den endelige lukning med læring og forbedring. Læs videre, og lær at skrive ServiceNow-sager, der sparer penge, beskytter SLA’er og får dine kolleger til at klappe i hænderne i stedet for at rive sig i håret.

Fra kaos til klarhed: Forberedelse før du opretter en ServiceNow-sag

Før du klikker på “Submit” i ServiceNow, kan ti minutters forarbejde spare timer – og ofte dage – i den efterfølgende sagsbehandling. Nedenfor finder du en praktisk guide til, hvordan du forvandler oprydningskrævende information til et knivskarpt beslutningsgrundlag.

1. Vælg den rigtige sagstype

Sagstype Hvornår? Målet Eksempel
Incident Drift eller service påvirket uventet Genopret normal drift hurtigst muligt SAP FI posteringsfejl stopper fakturering i PROD
Service Request Foruddefineret levering af adgang, hardware, rapport m.m. Levering iht. katalog/SLA Ny bruger ønsker adgang til Jira Cloud
Problem Gentagne incidents eller ukendt grundårsag Årsagsanalyse + langsigtet løsningsforslag Intermitterende printer-timeouts på kontorer i EU
Change Planlagt ændring af infrastruktur, kode eller konfiguration Kontrolleret udrulning uden at bryde drift Opgradering af SQL-cluster til v14

2. Definér målet med sagen

  • Genopret drift: Få systemet tilbage i normal tilstand.
  • Adgang: Opret, ændr eller fjern rettigheder.
  • Ændring: Få godkendt og planlagt en deployment.
  • Årsagsanalyse: Identificér rodårsag og forebyg gentagelser.

3. Kortlæg hvem og hvor mange der er berørt

  • Roller/funktioner: Back-office, sælgere, kunder, eksterne partnere …
  • Antal brugere eller transaktioner: 10 brugere, hele webshoppen, 3 produktionslinjer …
  • Geografi og kanaler: APAC portal, mobile app i DK, call-center i Århus …

4. Angiv system, ci og miljø

Sørg for entydigt at pege på den berørte konfigurations-enhed (CI):

  • System/Applikation/Service + modul (fx SAP FI / Billing).
  • Miljø: PROD, TEST, UAT, DEV.
  • Version/build og eventuelle feature-flagtoggles.

5. Få tidslinjen på plads

  • Første observerede fejl: 2023-05-12 14:37 CEST
  • Seneste kendte OK: 2023-05-12 14:11 CEST
  • Tidszone (UTC, CET, EST …) – undgå misforståelser i globale teams.

6. Beskriv forretningspåvirkningen

  • SLA-brud (Response, Resolution).
  • Omsætning pr. time, tab af churn-risiko.
  • Compliance eller lovkrav (GDPR, SOX, PCI-DSS).
  • Kundeløfter / experience (NPS, uptime-garantier).

7. Dokumentér kendte workarounds

Har brugerne allerede et midlertidigt fix? Angiv skridt, varighed og begrænsninger:

1. Kør job ResyncOrders manuelt hver time 2. Brug VPN via site B (frem for site A)

8. Tjek ændringer umiddelbart før hændelsen

  • Deployments, patches, feature toggles.
  • Netværks- eller firewall-ændringer.
  • Konfigurationsopdateringer (CMDB, parametre).

9. Link til relaterede sager og vidensartikler

  • Tidligere incidents (INC001234), problems (PRB000567).
  • Change-records (CHG001678) der kan have påvirket miljøet.
  • KB-artikler – både dem der hjalp, og dem der ikke gjorde.

10. Pas på dataetik og informationssikkerhed

  • Ingen følsomme person- eller betalingsdata (PII), maskér hvor nødvendigt.
  • Undgå at kopiere adgangskoder, tokens og private keys.
  • Del logfiler via sikre links med tidsbegrænset adgang.

Tjekliste før du trykker “create”

  1. Rigtig sagstype valgt?
  2. Klart formål beskrevet?
  3. Berørte brugere/områder identificeret?
  4. Korrekt CI og miljø noteret?
  5. Fuldt tidsstempel inkl. tidszone?
  6. Konkrete forretningskonsekvenser kvantificeret?
  7. Kendt workaround dokumenteret?
  8. Seneste ændringer listet?
  9. Alle relaterede records/KB linket?
  10. Ingen følsomme data i teksten eller vedhæftningerne?

Med ovenstående forberedelse sikrer du, at næste led – triage-teamet, udvikleren eller change manageren – modtager præcis den information, de behøver, og ikke bruger spildtid på at jagte basale fakta.

Skriv skarpt: Struktur, felter og sprog i en effektiv ServiceNow-sag

1. Giv sagen en titel der kan scannes på to sekunder

Brug 7-12 ord og følgende mønster:

[App/Service/CI] Problem - Impact - Miljø
  • Dårlig: “Systemet virker ikke!”
  • God: “SAP FI: Bogføring fejler – stopper fakturering – PROD”

Fordel: Titelcellen i listevisningen fortæller straks hvad, hvem og hvor.

2. Krops­beskrivelsen – Copy/paste denne skabelon

Formålet er, at enhver 3.-parts kollega kan reproducere og løse hændelsen uden at ringe til dig.

  1. Kontekst / baggrund: “Eksportkørsel køres hver nat kl. 02:00 UTC …”
  2. Forventet vs. faktisk adfærd: “Forventet: fil skrives på SFTP. Faktisk: job fejler med exit-kode 1.”
  3. Trin til at reproducere:
    1. Log på SAP FI (PROD).
    2. Åbn transaktion F110.
    3. Kør program Z_EXPORT med parameter X.
  4. Omfang / impact: “Alle 87 danske salgsfakturaer er blokeret; est. 4 mio. kr. omsætning/døgn.”
  5. Miljø & version: “SAP FI 7.50 SP18, Linux kernel 4.18, DB2 11.5.”
  6. Tidsstempler (UTC): 2024-05-16 00:57-01:02. Correlation-ID: a3f9-…-12.
  7. Fejlbesked ordret: 
    ERROR TXN_EXPORT: RFC_ABAP_RUNTIME_FAILURE (TIME_OUT)
  8. Vedhæftninger: Renset loguddrag (.txt), HAR-fil, screenshot af step 3.
  9. Kendt workaround: “Manuel eksport via SM37 lykkes hver gang.”
  10. Begrundet Impact/Urgency: “Stopper fakturering > 1 mio. kr./h. SLA INC-P1.”

Kopier skabelonen ind som default i Description; så skal analyseteamet blot fylde felterne.

3. Felter der styrer workflowet – Udfyld dem rigtigt fra start

Felt Best practice Tjekspørgsmål
Category / Subcategory Vælg nærmeste for systemet (fx “Finance > Invoicing”). Styrer routing & statistik – er valget entydigt?
Short description Kopier titlen; brug altid ensartet format. Kan en on-call se meningen på mobilen?
Description Indsæt skabelon fra pkt. 2. Er alle bullets besvaret?
Caller / Requester Den, der rammes – ikke sagsopretter. Skal de modtage status-mails?
Assignment group Kendt support-team, ikke person. Har gruppen kompetence til første handling?
Service / CI Vælg den konkrete CI (fx “SAP-FI-PROD”). Viser impact-kortet korrekt afhængigheder?
Impact / Urgency → Priority Dokumentér omsætning, SLA eller compliance-risiko. Ville en P1-escalation bestå revision?
Affected users / location Skriv tal og geografi, ikke “flere”. Understøtter data governance og rapporter?
Due date / deadline Kun når forretningen har objektiv frist. Er fristen forankret hos business owner?
Approvals Tilknyt før arbejdet starter. Ved godkenderne, hvad de siger ja til?
Related records Link til Problem, Change, Knowledge. Giver linket læring eller dobbeltarbejde?
Tags Brug aftalte labels (“Regulatory”, “Customer-Facing”). Gør tagget filtrering + analytics lettere?

4. Sprog og stil – Sådan bliver du læst (og taget alvorligt)

  • Ét problem per sag. Ellers bryder SLA-tiden sammen.
  • Aktiv form, konkrete tal: “Job fejler hver nat kl. 02:00 UTC”, ikke “Nogle gange opleves fejl”.
  • Brug fulde ord før forkortelse: “Business Warehouse (BW)”. Efterfølgende kan forkortelsen stå alene.
  • Ingen “haster” uden evidens: Dokumentér tabt omsætning, SLA eller lovkrav.
  • Målrettet til næste led: Skriv som om modtageren ikke kender dit domæne.
  • Ingen følsomme data: Maskér personnumre, kundedata, API-nøgler.

Følger du ovenstående, når du hele vejen rundt om de tre mål:

  1. Alle forstår hændelsen hurtigt.
  2. Alle kan gengive fejlen.
  3. Løsningen kan implementeres uden tidskrævende afklaringer.

Det er kernen i en skarp ServiceNow-sag.

Hold momentum: Opfølgning, samarbejde og lukning med læring

  1. @Mention og tildel rigtigt
    Brug @navn til at hive den rigtige vagt/betragtning ind, og sæt Assignment group med det samme. Alt, der er uklart, koster SLA-tid.
  2. Work notes vs. Comments
    • Work notes er interne: teknik-snak, IP-adresser, fejlsøgning.
    • Comments er kundevendte: status, næste skridt, forventet tidspunkt.

    Får kunden for meget støj, mister du tillid. Får teknikeren for lidt, mister du tempo.

  3. Tjekliste for manglende data
    Post et kort skema, som brugeren kan kopiere og udfylde: 
    • Hvad skulle du gøre? • Hvad skete der? • Tidsstempel (dd-mm-åååå hh:mm TZ) • Miljø (PROD/TEST/UAT) • Antal berørte brugere/ordrer/kroner • Skærmbillede eller log (renset)

    Gør det nemt for spørgeren at svare rigtigt første gang.

Sla-styring – Hold tempo og forventninger synkroniseret

  • Bekræft modtagelse (f.eks. inden for 30 min.) og gentag kort hvordan sagen måles: “SLA 4 t. – vi er på sagen.”
  • Forventet næste opdatering: Skriv konkret klokkeslæt. Overskrid aldrig din egen deadline; opdatér inden.
  • Eskalér på fakta: “Impact er nu 400 ordrelinjer/time > 250 threshold – hæver Impact til High og eskalerer til on-call DBA.”
  • Next action & owner: Afslut hver work note med WHO + WHAT + WHEN.
    Next: Jens (DBA) tjekker indeks - update senest 14:45 CEST

Samarbejde – Én definition af “færdig”

  1. Acceptance criteria
    En linje, alle kan se: “Faktura-batch kører uden fejl og alle 7.000 linjer bogføres.”
  2. Testplan & evidens
    Angiv hvem der tester, hvilke steps og hvilke skærmbilleder/logs der beviser succeskriteriet.
  3. Koordinér med Change
    • Book deploy-vindue tidligt (CAB, blackout, rollback-plan).
    • Link Change-sagen til Incident/Request for sporbarhed.

Lukning – Gør fremtidens fejlfinding lettere

  • Opsummering: årsag + løsning + varighed.
    Root cause: Manglende indeks på ORD_HDR. Fix: Oprettet og deployet via CHG012345. Downtime: 37 min.
  • Correct closure code: “Solved (Workaround)” hvis permanent fix mangler.
  • Brugerbekræftelse: få “OK” på mail, chat eller i kommentarfeltet.
  • Link til KB/Problem: Opret/prioritér Problem hvis roden ikke er fjernet.
  • Registrér workaround: kopiér step-for-step til Knowledge Base – gem tid næste gang.

Kontinuerlig forbedring – Mål, lær, gentag

Indfør en letvægtet kvalitetsmåling pr. sag (0-5):

Kriterium Krav for score 5
Data-komplethed Alle obligatoriske felter + reproducerbare steps
SLA-overholdelse Ingen brud; alle opdateringer inden for lovede tider
Kommunikation Klar adskillelse af interne/eksterne noter; ingen jargon
Læringsværdi Lukke-note med årsag, fix & link til KB/Problem

Hold micro-retros på 10 min. efter større sager:

  1. Hvad virkede?
  2. Hvad skabte friktion?
  3. Hvilken skabelon/KB skal opdateres?
Do Don’t
Ét emne pr. sag Blande login-fejl og printer-fejl i samme ticket
Kopiér tekst, ikke screenshots af tekst Upload JPG med Command Prompt-vindue
Nøjagtige tidsstempler (UTC eller angiv TZ) Skrive “i går efter frokost”
Angiv miljø (PROD/TEST) Antage, at alle ved det
Maskér PII og sikkerheds-info Dele CPR-numre i Comments

Når disse discipliner sidder på rygraden, forvandles ServiceNow fra støjkanal til vidensmotor – og både brugere, teknikere og forretning vinder på hastighed og klarhed.

By På arbejdspladsen