Eget bookingsystem eller standardløsning? Sådan vælger du

Et eget bookingsystem betaler sig først når dine bookingregler er en del af det der gør din forretning anderledes, og et standardsystem kun kan følge med via manuelle omveje. For de fleste frisører, klinikker, personlige trænere og mindre træningscentre er en standardløsning til et par hundrede kroner om måneden det rigtige valg. Grænsen går typisk ved ressourcer, priser og kapacitet der følger dine helt egne regler, eller når bookingerne skal hænge tæt sammen med resten af dine systemer.

Jeg udvikler selv webapps og platforme, så læs med det forbehold. Fitness er mit gennemgående eksempel, fordi det er en branche hvor bookinglogikken hurtigt bliver kompliceret: hold, instruktører, klippekort, ventelister og medlemskaber på én gang.

Den korte version

Min beslutningsregel: Kan du beskrive dine bookingregler på fem linjer, og ligner de dine konkurrenters, så vælg en standardløsning. Fylder reglerne en hel side, og bruger du allerede regneark og manuelle rettelser for at få systemet til at passe, så kig på mellemvejen eller et eget system. Er du i tvivl om booking overhovedet er den rigtige platformtype at starte med, giver min guide til at lave din egen platform det store overblik.

Hvad et standardsystem klarer fint

Et moderne bookingsystem dækker det de fleste har brug for. Kunden vælger en ydelse og en tid, betaler eller reserverer og får en bekræftelse og en påmindelse. Medarbejderne har hver deres kalender, du kan oprette hold med et fast antal pladser, og en aflysning inden for fristen frigiver pladsen igen. Mange systemer har også gavekort, rabatkoder, simple klippekort, synkronisering med Google- eller Outlook-kalenderen og en app til kunderne.

Prisen er lav i forhold til hvad det ville koste at bygge. SimplyBook.me koster ca. 14-60 euro om måneden ved månedlig betaling (omkring 100-450 kr.), afhængigt af antal bookinger og medarbejdere, og har en gratis plan til de helt små. Danske EasyPractice tager 315 kr. pr. aktiv behandler pr. måned ekskl. moms ved månedligt abonnement. Priserne ændrer sig, så tjek dem selv, men for de fleste mindre virksomheder ligger niveauet på et par hundrede til et par tusinde kroner om måneden.

For pengene får du også alt det usynlige: sikkerhedsopdateringer, oppetid, support og nye funktioner fra en leverandør der har set mange virksomheder med de samme behov som dig. Det kan et system bygget til én kunde sjældent hamle op med.

Det fører til det vigtigste argument. Kan dine regler udtrykkes med systemets indstillinger, er der ingen grund til at bygge noget selv. Så er standardløsningen hurtigere, billigere og bedre afprøvet end noget jeg eller andre kan bygge til dig.

Hvor standardsystemer typisk kommer til kort

Problemerne opstår sjældent på dag ét. De kommer snigende, når forretningen vokser og reglerne bliver flere. Et træningscenter er et godt eksempel, fordi det tit har brug for flere af de her ting på samme tid.

Ressourcer der skal bookes sammen

Et spinninghold kræver en sal, en instruktør og et antal cykler. En PT-session kræver en træner og måske et bestemt lokale. De fleste standardsystemer tænker i én ressource pr. booking, typisk en medarbejder. Skal to eller tre ting være ledige samtidig, ender mange med at holde styr på resten i et regneark eller i hovedet.

Priser og rettigheder pr. kundetype

Et medlem med fuldt medlemskab booker gratis, et medlem med formiddagskort må kun booke før kl. 15, et firmamedlem har sin egen aftale, og en drop-in-kunde betaler pr. gang. Standardsystemer kan som regel klare to-tre af den slags regler. Når kombinationerne bliver mange, ender det i manuelle undtagelser.

Kapacitet og ventelister med dine egne regler

Hvor mange pladser skal medlemmerne have, før drop-in åbner? Skal en ledig plads gå automatisk til den første på ventelisten, eller skal vedkommende bekræfte inden for en time? Hvad sker der med en kunde der er udeblevet tre gange i træk? Det er regler mange centre har. Det er også netop i den slags detaljer at systemerne adskiller sig, og der du hurtigt rammer loftet.

Bookingen er kun en del af flowet

Bookingen skal måske styre adgangen til døren, sende omsætning videre til økonomisystemet, opdatere kundens træningsprogram eller hænge sammen med et medlemskab der trækkes hver måned. Er medlemskab, betaling og indhold den egentlige kerne, er det i virkeligheden en medlemsplatform med booking indbygget du står med, og så skal du vurdere den som sådan.

Et fælles tegn på alle fire: medarbejderne bruger tid hver uge på at rette op efter systemet. Jeg har beskrevet de signaler i tegn på at virksomheden er vokset ud af Excel, og de fleste af dem gælder også for et bookingsystem der er blevet for lille.

Hvad koster de to veje over tre år?

Et standardsystem er billigst at komme i gang med, men regningen vokser med antallet af medarbejdere, sms'er og betalinger. Et eget system er dyrt at bygge, men bliver ikke dyrere af at du ansætter flere instruktører. Derfor skal sammenligningen laves over flere år.

Et regneeksempel: Har et center otte instruktører i et system der koster 315 kr. pr. medarbejder om måneden, bliver det 2.520 kr. om måneden, eller omkring 90.000 kr. over tre år ekskl. moms. Oveni kommer sms-pakker og gebyrer til betalingsudbyderen, men dem betaler du også med et eget system.

Et eget bookingsystem er en webapp, og prisen følger antallet af timer. LønRadar angiver 800-1.200 kr. i timen ekskl. moms for en senior freelance-udvikler i Danmark i 2026. Efter min vurdering kræver en afgrænset første version med login, kalender, betaling og administration ofte 150-400 timer. Det giver et groft spænd på 120.000-480.000 kr. ekskl. moms, før drift er regnet med. En almindelig tommelfingerregel er at sætte 15-20 % af udviklingsprisen af om året til vedligehold og mindre forbedringer. Hvad der trækker prisen op og ned, har jeg gennemgået i prisniveauer for en webapp.

På ren pris vinder standardløsningen derfor næsten altid de første år. Et eget system skal betale sig på en anden måde:

• Det fjerner manuelt arbejde, som du kan sætte timer og kroner på.
• Det giver omsætning som standardsystemet står i vejen for, fx bedre udnyttelse af holdene eller en prismodel dine konkurrenter ikke kan tilbyde.
• Bookingen er selve dit produkt, fx hvis du vil sælge systemet videre til andre i branchen.

Kan du ikke pege på mindst én af de tre, er svaret næsten altid en standardløsning.

Mellemvejen: standardsystem med integrationer

Mange bookingsystemer har et API (en åben indgang som andre programmer kan hente og sende data gennem) og webhooks, der giver besked når noget sker, fx når en booking oprettes eller aflyses. Så kan du beholde standardsystemet til selve bookingen og kun få bygget det der mangler:

• en synkronisering af betalinger til dit økonomisystem
• en kundeportal hvor medlemmer ser bookinger, fakturaer og træningshistorik samlet
• en rapport der samler tal fra booking, kasse og medlemsregister
• et lille stykke logik, fx en regel der rykker folk op fra ventelisten på din måde

Det er tit det bedste valg for virksomheder der er ved at vokse ud af standardsystemet, men ikke vil bære prisen for et helt nyt. Udviklingen er mindre, og du slipper for selv at eje kalenderlogik, påmindelser og betaling.

Før du vælger den vej, så tjek tre ting. Kan API'et skrive data og ikke kun læse dem? Er det dokumenteret, og findes det på den plan du betaler for, eller kun på en dyrere? Og kan du trække alle dine data ud, hvis du skifter senere? Husk også at du bliver afhængig af leverandørens API. Ændrer de det eller fjerner funktioner, skal din integration rettes.

Hvornår hver løsning ikke passer

Standardløsningen passer ikke når

• dine vigtigste regler kun kan håndteres med manuelle undtagelser hver uge
• bookingen skal styre noget andet i realtid, fx adgang, udstyr eller et medlemskab, og systemet ikke har et brugbart API
• selve bookingoplevelsen er det der adskiller dig fra dine konkurrenter

Et eget bookingsystem passer ikke når

• du endnu ikke ved om forretningen virker. Test den på et standardsystem først, også selvom det knirker
• du kan ændre dine regler så de passer til et standardsystem, uden at det koster kunder
• der ikke er budget til drift og videreudvikling efter lanceringen, for et bookingsystem der ikke bliver vedligeholdt, bliver en risiko
• du er en enkelt behandler eller træner. Her er et abonnement næsten altid det fornuftige, og du skal ikke bruge penge på en udvikler som mig

Mellemvejen passer ikke når

• standardsystemet mangler et API eller kun tillader at læse data
• problemet ligger i selve bookingreglerne. En integration kan ikke rette et system der regner kapacitet eller priser forkert for dig

Vil du lave samme vurdering for andre dele af din forretning, har jeg samlet de afgørende spørgsmål i skræddersyet software vs standardsoftware.

Næste skridt: find grænsen for din forretning

1. Skriv alle dine bookingregler ned, også dem medarbejderne håndterer i hovedet. Det er det vigtigste dokument i hele beslutningen.
2. Marker de regler der koster tid i dag. Hvor mange timer om ugen går med at rette dobbeltbookinger, flytte folk fra ventelisten eller afstemme betalinger?
3. Test to-tre standardsystemer med dit sværeste rigtige eksempel, ikke med en demobooking. Spørg leverandøren direkte hvilke af dine regler systemet ikke kan.
4. Tjek API og dataeksport på de systemer der kommer tættest på.
5. Regn tre år for hver vej, inklusive drift og din egen tid.

Lander du på at et standardsystem kan klare det, er du færdig, og det er en god nyhed. Lander du på en integration eller et eget system, er næste skridt en afgrænset første version. Jeg starter større projekter med et betalt forprojekt til fast pris, hvor reglerne bliver skrevet ned og første version afgrænset, før der skrives kode. På siden om udvikling af webapps og platforme kan du se hvordan et forløb ser ud. Du ejer koden fra første dag.

Ofte stillede spørgsmål

Kan jeg flytte mine data fra et standardsystem til et eget bookingsystem senere?+

Som regel ja, men eksporten afgør hvor let det bliver. De fleste systemer kan eksportere kunder og fremtidige bookinger som en fil eller via API. Historik, betalinger, klippekort og saldi er ofte sværere at få med. Tjek eksportmulighederne før du vælger system, og tag en fuld eksport med jævne mellemrum, så du ikke står uden data den dag du skifter.

Hvor lang tid tager det at udvikle et bookingsystem?+

En afgrænset første version tager ofte to-fire måneder fra start til lancering med én udvikler, fordi der også skal være tid til test og beslutninger undervejs. Kalender og betaling er sjældent det der tager tid. Det gør kapacitet, ventelister, aflysningsregler og alle undtagelserne. Et forprojekt hvor reglerne skrives ned, giver et langt mere præcist estimat end en funktionsliste.

Skal et eget bookingsystem også have en app?+

Ikke nødvendigvis. En webapp der fungerer godt på mobilen, dækker de fleste behov, og kunderne kan gemme den på hjemmeskærmen. En rigtig app er mest relevant når kunderne booker ofte og forventer push-beskeder. Bygges systemet med et API fra start, kan du tilføje en app senere uden at lave bookinglogikken om.

Hvem har ansvaret for GDPR i et eget bookingsystem?+

Det har du som dataansvarlig, uanset om systemet er købt eller bygget. Med et eget system vælger du også selv hosting, og du skal have databehandleraftaler med hostingleverandøren og den udvikler der har adgang til data. Booker kunderne behandlinger, kan oplysningerne være helbredsdata med skærpede krav. Det er ikke juridisk rådgivning, så spørg en rådgiver hvis du er i tvivl.