Nødkontakter og eskalation: hosting, bureau og betalingsudbyder

Kort svar: En eskalationsplan for dit website består af to dele: en nødkontaktliste og en eskalationstrappe. Listen har én linje pr. leverandør (hosting, domæne/DNS, bureau, betalingsudbyder, mail og systemer) med fire felter: hvad de ejer, kontaktvej og åbningstid, kundenummer og hvad aftalen lover. Trappen bestemmer rækkefølgen – internt tjek, hosting, udvikler, systemleverandør – og en præcis supporthenvendelse gør, at du hurtigere får det rigtige svar.

Fagligt gennemgået: 2. oktober 2026

Under et nedbrud går den første tid ofte med at lede: efter hostingens supportnummer, kundenummeret, bureauets akutaftale og login til betalingsudbyderen. Et website er en kæde af leverandører, og når noget fejler, er spørgsmålet sjældent „hvem kan hjælpe?“ – men „hvem har ansvaret for præcis dét led, og hvordan får jeg fat i dem nu?“.

Denne guide bygger nødkontaktlisten og trappen, der besvarer begge dele, før behovet opstår.

1. Kortlæg leverandørkæden

Kæden er længere, end de fleste tror, og hvert led kan vælte på sin egen måde:

• Hosting: Serveren, PHP, databasen – og ofte SSL og backup.
• Domæne og DNS: Registrator og DNS-udbyder er ikke altid det samme firma, og DNS-fejl kan ligne alt muligt andet. Se når domænet peger forkert.
• Bureau eller udvikler: Koden, temaet og integrationer – gerne med en akutaftale, som beredskabsguiden beskriver.
• Betalingsudbyder: Gateway og indløser. Når kort afvises, ligger fejlen ofte hos dem.
• Mailudbyder: Når formularer og ordremails forsvinder.
• Systemleverandører: Booking, fragt, nyhedsbrev, kassesystem – alt det, sitet afhænger af.
• CDN eller proxy: fx Cloudflare, hvis du bruger det. Fejl som 52x-koderne kan ligge mellem CDN og server.

Skriv for hvert led i én sætning, hvad de ejer. Netop den sætning afgør under nedbruddet, hvem der kontaktes først – og forhindrer runddansen, hvor alle henviser til hinanden.

2. Nødkontaktlisten: fire felter

Pr. leverandør udfylder du fire felter:

• Ejer: Én sætning – „server og SSL“, „DNS-zonen“, „betalingsgateway“.
• Kontaktvej og åbningstid: Telefon, mail eller portal – og hvad der gælder uden for normal arbejdstid: døgnsupport, akutformular eller ingenting.
• Verifikation: Kundenummer, domænenavn eller konto-id – det, supporten spørger om først. At lede efter sit kundenummer kl. 23 er netop det, listen skal forhindre.
• Aftalen: Hvad er lovet – responstid, døgndækning, akut-timepris – så forventningerne er kendt, før du ringer.

Sådan kan listen se ud i praksis:

Leverandør	Ejer	Kontakt og åbningstid	Verifikation	Aftale
Hosting	Server, PHP, database, SSL, backup	[telefon/mail/portal]	Kundenr. og domæne	[responstid]
Domæne/DNS	Registrering og DNS-zone	[kontaktvej]	Domænenavn og konto	[aftale]
Bureau	Kode, tema, integrationer	[akutnummer]	Aftalenr.	[akutpris og responstid]
Betaling	Gateway og indløsning	[support]	Forretningsnr.	[aftale]
Mail	Postkasser og levering	[support]	Konto-id	[aftale]

Listen hører hjemme i driftsdokumentationen og deles med alle, der har en rolle i nedbrudsplanen.

Vigtigt: Ingen kodeord på listen – kun hvem og hvor. Adgangene ligger i password manageren, jf. adgangsoversigten.

3. Eskalationstrappen

Trappen sætter rækkefølgen, så ingen springer til det dyreste trin først – eller bliver hængende på det billigste for længe:

1. Trin 0 – det interne kvarter: Bekræft fejlen udefra (anden enhed, andet netværk), tjek hostingens og eventuelle CDN-udbyderes driftsstatus, og rul den seneste ændring tilbage, hvis fejlen startede lige efter.
2. Trin 1 – hostingen: Når sporet peger på server, SSL, mail-levering eller „alt er nede“. Tag observationerne fra trin 0 med.
3. Trin 2 – bureau eller udvikler: Når fejlen ligger i kode, tema eller integrationer – typisk efter en ændring, eller når I ikke selv har fundet årsagen efter en aftalt tid (fx 30-45 minutter).
4. Trin 3 – systemleverandøren: Når én funktion fejler isoleret. Betalinger afvises → gatewayen. Bookinger forsvinder → bookingsystemet.

Parallelt med alle trin løber kommunikationen: statussiden og eventuelle kunder opdateres, uanset hvor langt teknikken er nået.

4. Hvem kontakter du ved hvilket symptom?

Symptom	Første kontakt
Hele sitet er nede, eller fejl 500/503/504	Hosting (efter trin 0)
„Din forbindelse er ikke privat“ eller SSL-fejl	Hosting – eller CDN, hvis du bruger proxy
Domænet viser ingenting eller forkert side	DNS-udbyder/registrator
Fejl kun på én side eller efter en opdatering	Bureau/udvikler
Kort afvises, eller ordrer står som „afventer betaling“	Betalingsudbyder
Mails kommer ikke frem	Mailudbyder (og hostingen, hvis mail sendes fra sitet)

Tabellen er et udgangspunkt – trin 0 afgør ofte, hvilken række der gælder. Se fx 500 Internal Server Error og WooCommerce betaling fejler for den videre diagnose.

5. Den gode supporthenvendelse

Forskellen på et hurtigt og et langsomt supportsvar ligger ofte i henvendelsen. Skriv:

• Hvad der fejler: „Checkout viser fejl 500 efter betalingstrinnet“ – ikke „siden virker ikke“.
• Hvornår det startede: Klokkeslæt – og hvad der skete lige før: opdatering, DNS-ændring eller kampagnestart.
• Hvad I har prøvet: Rullet tilbage, tømt cache, testet fra et andet netværk.
• Fejlbeskeden ordret: Gerne med linjer fra fejlloggen og et skærmbillede.

Læg verifikationen (kundenummer og domæne) i første besked, og angiv forretningskonsekvensen nøgternt – „webshop, ingen ordrer kan gennemføres“ – så sagen kan prioriteres rigtigt. Gem en skabelon i driftsdokumentationen:

Emne: [domæne] – [kort symptom] siden [klokkeslæt]

Kundenr./domæne:
Hvad fejler:
Startede: [dato, klokkeslæt] – lige efter:
Prøvet:
Fejlbesked/log:
Konsekvens:
Kontakt mig på: [telefon]

Under pres skriver ingen godt fra bunden – men alle kan udfylde en skabelon.

6. Hold listen levende

Nødlisten forældes i samme tempo, som leverandørerne skiftes. Giv den to faste berøringspunkter:

• Opdatering ved skift: Nyt bureau, ny gateway eller flyttet DNS? Ret listen i samme arbejdsgang som linjen i ændringsloggen.
• Den årlige verifikation: På årsdagen tjekker du, at numre, portaler og aftaleniveauer stadig passer – og at de navngivne kontaktpersoner stadig arbejder de pågældende steder.

Færre led giver en lavere trappe

Jo færre leverandører, desto kortere liste og lavere trappe. Hos Hostious ligger server, SSL og backup hos samme udbyder, og der er dansk support døgnet rundt. Fra WP StartUp er WordPress serviceaftalen også inkluderet, så opdateringer og sikkerhed ligger samme sted. En god nødliste mærkes ikke på sin længde, men på hvor sjældent du når trin 3.

Læs også

• Hub: Driftshåndbogen
• Nedbrudsplanen: hvem gør hvad, når sitet er nede kl. 23?
• Beredskab uden vagtordning: realistiske aftaler for små teams
• Driftsdokumentation: den ene side, en vikar kan drive sitet fra
• WordPress hosting hos Hostious – dansk support døgnet rundt

Ofte stillede spørgsmål om nødkontakter og eskalation

Hvem ringer jeg til først, når noget er nede?

Efter det interne kvarter (bekræft fejlen, tjek driftsstatus, rul seneste ændring tilbage): hostingen ved server, SSL eller „alt er nede“, bureauet ved kode og integrationer, og systemleverandøren, når én funktion fejler isoleret.

Hvad skal der stå i supporthenvendelsen?

Hvad der fejler (konkret), hvornår det startede, hvad I har prøvet og fejlbeskeden ordret – plus kundenummer og forretningskonsekvens. Så kan supporten gå direkte i gang i stedet for at stille opklarende spørgsmål.

Hvor skal nødkontaktlisten ligge?

I driftsdokumentationen – uden for sitet selv, delt med alle i nedbrudsplanens roller og tilgængelig fra telefonen. Uden kodeord: de ligger i password manageren.

Hvor ofte skal nødkontaktlisten opdateres?

Hver gang en leverandør skiftes, og derudover én gang om året, hvor du tjekker numre, portaler, aftaler og kontaktpersoner.