Der findes helpdesksystemer med europæisk kontraktpart og hosting i Europa, både som abonnement og som open source, I kan drive selv. Det vanskelige ved skiftet er sjældent selve systemet. Det er sagshistorikken, de automatiske regler og de kanaler, kunderne allerede bruger til at skrive til jer.
Et helpdesksystem samler mails, chat, formularer og nogle gange telefoni i én kø af sager. Hver sag kan rumme kundens navn, ordrer, klager og vedhæftede filer. Derfor er det et system, hvor ejer og hosting betyder noget, og hvor overgangen skal planlægges sag for sag.
Hvad I vurderer på hvert led
Hvert produkt bliver vurderet på de samme punkter: hvem der ejer det og skriver under, hvor det kører, og hvem der driver det, hvilken licens koden har, hvordan der betales, og hvad skiftet kræver. Er et felt ikke oplyst af selskabet selv, står det her, og så er det jeres spørgsmål at stille i tilbudsrunden.
Nedenfor står to daterede eksempler. Begge er med, fordi selskaberne selv oplyser nok til at udfylde en del af felterne. Orden og antal er tilfældige.
Zammad, pr. november 2026
Ejer og kontraktpart. Kontraktparten er Zammad GmbH, registreret i handelsregistret i Charlottenburg i Berlin. Hvem der ejer Zammad GmbH, fremgik ikke af selskabets sider i november 2026.
Hosting og drift. Den hostede udgave kører ifølge Zammad på selskabets servere i tyske datacentre. Hvilken udbyder der ejer datacentrene, er ikke læst. En udgave, I driver selv, findes også.
Kode og licens. Koden er åben under licensen AGPL-3.0. Hvad licensen betyder for jer, hvis I selv ændrer i koden, er et spørgsmål til den, der skal drive systemet.
Erhvervsplan og prismodel i ord. Den hostede udgave er et abonnement med prøveperiode og mulighed for årlig fakturering. Den åbne kode kan drives selv uden licensbetaling. Om abonnementet afregnes pr. medarbejder i kundeservice, fremgik ikke entydigt.
Dixa, pr. november 2026
Ejer og kontraktpart. Dixa er grundlagt i København i 2015 og har kontorer i København og London. Selskabets egen side nævner en kapitalrunde i 2021 ledet af General Atlantic. Hvem der ejer flertallet i dag, og hvem der er kontraktpart, er ikke læst.
Resten af målestokken. Dixas egne sider gav ikke svar på hosting, licens og afregning, da vi læste dem i november 2026.
Eksemplet viser, at dansk oprindelse er én oplysning blandt flere. Ejerkreds og hosting skal stadig stå med dato i jeres vurdering.
Det, der skal over i det nye system
Åbne sager. Beslut, om de åbne sager skal flyttes eller lukkes ned i det gamle system. Mange vælger at lade de åbne sager køre færdige der, mens nye sager oprettes i det nye. Det kræver en periode med to systemer og en klar regel for, hvem der svarer hvor.
Lukket historik. Kundeservice slår gamle sager op, når en kunde skriver igen. Spørg, om eksporten tager tråde, interne noter, vedhæftede filer og tidsstempler med. Kommer historikken ikke med, så gem en læsbar kopi, så den kan findes.
Kanaler. Mailadresser videresendes, chatvinduet på hjemmesiden udskiftes, og eventuel telefoni kobles om. Kunderne mærker skiftet her, så gør det på én dag med en plan for, hvad der sker med mails, der lander undervejs.
Regler og automatik. Fordeling af sager, svarskabeloner, servicemål og automatiske svar ligger som opsætning og følger sjældent med. Skriv dem ned, før I begynder.
Integrationer. Ordrer fra webshoppen, kundekort fra CRM’et og fakturaer fra økonomisystemet vises ofte inde i sagen. Hver kobling skal findes i det nye system eller bygges.
Hjælpecenter. Har I artikler til kunderne i det gamle system, skal de flyttes, og gamle adresser skal pege det rigtige sted hen, så søgninger og links ikke ender blindt.
Persondata i sagerne kræver en databehandleraftale med den nye leverandør.
Hvad det kræver, og hvad det koster at lade være
Skiftet kræver en ansvarlig i kundeservice, en person med adgang til mail og hjemmeside og tid fra de medarbejdere, der svarer kunderne. Sæt timer på kortlægning af regler og skabeloner, prøveimport af historik, opsætning af kanaler, oplæring og perioden med to systemer. Driver I selv den åbne udgave, kommer drift, opdatering og backup oveni som løbende arbejde.
Uden et skifte fortsætter kundeservice som i dag. Men historikken vokser hver dag, og jo flere integrationer der kommer til, desto længere bliver overgangen den dag, beslutningen alligevel skal tages.
Det skal I lade være med
- At flytte kanalerne før systemet er afprøvet · kunderne må ikke opleve, at deres mail forsvinder.
- At antage, at historikken følger med · spørg konkret til noter, filer og tidsstempler.
- At glemme hjælpecentrets gamle adresser · ellers peger links fra mails og søgninger forkert.
Det skal valget kunne vise
- ☐ Kontraktpart og ejer med dato.
- ☐ Hvor sager og vedhæftede filer opbevares.
- ☐ Om historikken kan importeres med noter og filer.
- ☐ En plan for åbne sager i overgangen.
- ☐ Prismodel i ord og hvem der driver systemet.
Kilder
Senest gennemgået: november 2026.
Næste skridt
Tæl jeres kanaler, regler og integrationer i det nuværende helpdesksystem. Listen er grundlaget for både valget og tidsplanen.
Læs også: Open source: hvem står bag koden, og hvem står bag driften? · Hvem ringer I til? Support efter skiftet
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
