Sådan bygger du en booking-app: tider, ledighed, påmindelser og depositum

For at bygge en booking-app skal fire ting fungere sammen: en liste over, hvad der kan bookes (ydelser, lokaler, medarbejdere), regler for hvornår hver enkelt er ledig, et bookingforløb, der kun tilbyder reelt ledige tidsslots, og en privat visning, hvor virksomheden håndterer det, der kommer ind. En AI-app-builder kan lave en fungerende første version ud fra en kort beskrivelse på få minutter; det egentlige arbejde er at beslutte reglerne — slotlængde, buffere, afbestillinger, tidszoner — og at teste, at dobbeltbookinger er umulige.

Start med at beslutte, hvad „en booking“ betyder for dig

Booking-apps ligner hinanden på overfladen, men er meget forskellige under overfladen. Besvar disse først:

• Hvad bookes? En ydelse (en klipning), en person (en lærer), en ressource (et mødelokale, en bane, en varevogn) eller en plads ved en session (en yogatime med 12 pladser).
• Hvor lang tid tager det? Fast pr. ydelse, eller valgt af kunden?
• Hvem leverer det? Én person, flere medarbejdere med egne arbejdstider, eller ingen (et lokale)?
• Hvad sker der efter booking? Øjeblikkelig bekræftelse, eller en anmodning, som ejeren godkender?
• Er der penge involveret? Gratis, betaling på dagen, depositum på forhånd eller fuld forudbetaling?

„Anmod om et tidspunkt, ejeren bekræfter via e-mail“ er langt enklere at bygge end „øjeblikkelig booking mod tre medarbejderkalendere med depositum“. Begge er gyldige — vælg den, du faktisk har brug for i version et.

Hvad appen har brug for

Data

Det gør overlapstjek meget enklere at gemme sluttidspunktet på hver booking, ikke kun starttidspunktet.

Sider

• Offentlig: ydelsesliste, tidsslot-vælger, bookingformular, bekræftelsesside og et link til annullering eller ombooking.
• Privat (ejer eller medarbejder): dagens skema, kommende bookinger, mulighed for at blokere tid og indstillinger for ydelser og arbejdstider.

Tilladelser

Kunder må kun se ledige eller optagede tidsslots — aldrig andre kunders navne. Medarbejdere kan måske kun se deres eget skema; ejeren ser alt. Skriv det ned, for det afgør, om du har brug for logins og roller. Vores guide til at tilføje login til din app dækker mulighederne.

De svære dele, og hvordan du håndterer dem

Dobbeltbookinger

Den klassiske fejl: to personer indlæser siden, begge ser kl. 10:00 som ledig, og begge booker den. Løsningen er at tjekke igen på serveren, når bookingen gemmes, og afvise den, hvis noget nu overlapper. Bed om det eksplicit:

Når en booking gemmes, skal du tjekke på serveren, at ingen bekræftet eller afventende booking for den samme medarbejder overlapper det ønskede tidspunkt (inklusive bufferen). Hvis en gør, så afvis bookingen og vis „Det tidspunkt er lige blevet taget — vælg venligst et andet.“

Test derefter med to browservinduer.

Tidszoner

Gem hvert tidspunkt i UTC og konverter til visning. Beslut, hvilken tidszone bookingsiden viser — typisk virksomhedens for fysiske ydelser og kundens for online-møder — og angiv det på siden. Test en booking over en sommertids-skifte.

Buffere, varsel og grænser

Almindelige regler, det er værd at beslutte på forhånd: en buffer mellem aftaler, minimumsvarsel („ingen bookinger mindre end 2 timer før“), hvor langt frem folk kan booke, og et dagligt loft. Hver er én sætning i en prompt; udelader du dem, vælger AI'en standardindstillinger for dig.

Afbestillinger og udeblivelser

Giv hver bekræftelse et annulleringslink med et unikt token, så kunder ikke behøver en konto. Beslut dit afbestillingsvindue, og om depositum kan refunderes, og vis politikken før betaling.

Påmindelser

Påmindelses-e-mails eller sms'er kræver noget, der kører efter en plan („hvert 15. minut, send påmindelser for bookinger, der starter om 24 timer“). Tjek, hvordan din builder og hosting håndterer planlagte job. Hvis de ikke gør det, så brug en ekstern planlægger, der kalder et endpoint i din app, eller send bekræftelses-e-mailen med en kalenderinvitation vedhæftet, så kundens egen kalender minder dem om det. Se sådan sender du e-mails fra din app for udbyder-delen.

Depositum og betalinger

Det almindelige mønster med Stripe:

1. Kunden vælger et tidsslot; appen opretter en afventende booking, der holder tidsslottet i kort tid (fx 15 minutter).
2. Appen sender dem til Stripe Checkout for depositummet.
3. Stripe giver din app besked via et webhook, når betalingen lykkes; bookingen bliver bekræftet.
4. Hvis betalingen ikke sker i tide, udløber den afventende booking, og tidsslottet frigives.

Stripes standardpriser er en procentdel plus et fast gebyr pr. vellykket kortbetaling, uden månedligt gebyr (pr. september 2026); satserne varierer efter land, så tjek Stripes prisside for dit. Brug testtilstand og testkort, indtil alt virker. Vores guide til at tilføje betalinger gennemgår det trin for trin.

En første prompt, der virker

Byg en booking-app til Northside Barbers. Ydelser: Klipning (30 min, $25), Skægtrimning (15 min, $12), Klipning + skæg (45 min, $32). To frisører, Sam og Ali, som arbejder tirsdag–lørdag kl. 9:00–18:00. Kunder vælger en ydelse, derefter en frisør eller „enhver frisør“, og ser derefter kun ledige starttidspunkter med 15 minutters mellemrum for de næste 14 dage, og indtaster navn, telefon og e-mail. Gem bookinger i en database, med en buffer på 10 minutter efter hver aftale, og tjek ledigheden igen, når bookingen gemmes, for at forhindre dobbeltbookinger. Vis en bekræftelsesside med et annulleringslink. Ejeren har en privat side med dagens og de kommende bookinger, kan annullere en booking og kan blokere tid. Tider er i butikkens lokale tidszone. Rent, mobilfirst-design.

Den navngiver ydelserne, medarbejderne, arbejdstiderne, reglerne og ejerens visning — alt det, AI'en ellers ville gætte.

Byggetrin

1. Kerneflowet først. Ydelser → tidsslot → formular → gemt booking → bekræftelse. Intet andet, før dette virker på en telefon.
2. Ejerens visning. Dagens liste, kommende liste, annullering, blokering af tid.
3. Beskyt ejersiderne. Tilføj login, før rigtige data kommer ind.
4. Regler. Buffere, varselsperiode, bookingsvindue, helligdage.
5. E-mail. Bekræftelse med kalenderinvitation og annulleringslink.
6. Depositum, hvis du har brug for det, først i Stripes testtilstand.
7. Test kantsituationerne. To vinduer, der booker det samme tidsslot, en booking over midnat, en dato med sommertid, en annulleret booking, der frigiver sit tidsslot.
8. Udgiv, og foretag derefter selv en rigtig booking, før du deler linket.

Almindelige fejl

• At tjekke ledigheden kun i browseren. Det ser rigtigt ud og dobbeltbooker alligevel.
• At gemme lokale tider uden tidszone. Det virker, indtil uret skifter.
• At vise kundenavne i den offentlige kalender. Vis kun ledig eller optaget.
• At bygge medarbejderplanlægning, loyalitetspoint og sms på dag ét. Lancér kerneflowet, og tilføj derefter det, kunderne faktisk beder om.
• Ingen måde for ejeren at blokere tid på. Den første sygedag vil skabe udeblivelser.

Hvornår Calendly (eller lignende) er det bedre valg

Hvis du er én person, der deler sin tilgængelighed til opkald, er et planlægningsværktøj svært at slå. Pr. september 2026 dækker Calendlys gratisplan én begivenhedstype, én kalenderforbindelse og en-til-en-planlægning med en tilpasselig bookingside, og betalte planer tilføjer flere begivenhedstyper og teamfunktioner. Sådanne værktøjer forbinder til din eksisterende kalender ud af boksen, hvilket en selvbygget app skal bygges for at kunne.

Byg din egen, når du har brug for regler, som disse værktøjer ikke understøtter, flere ressourcer der kan bookes, din egen branding igennem hele forløbet, bookinger forbundet med andre data (kunder, ordrer, medlemskaber), eller du bygger et bookingprodukt, du vil sælge til andre.

At bygge det med Mythex

På Mythex beskriver du booking-appen i chatten, den bygger den i en live-forhåndsvisning, og den tilføjer en Postgres-database, når bookinger skal gemmes. Booking-sidens use case i dokumentationen foreslår at starte med en anmodningsformular og en admin-liste og derefter tilføje resten. Vær klar over, hvad der er indbygget, og hvad du selv forbinder: Mythex har ingen indbygget kalendersynkronisering, sms-påmindelser eller depositumprodukt. E-mail går via din egen udbyder, depositum via dine egne Stripe-nøgler gemt som projekthemmeligheder (Stripe-opskriften), og regler mod dobbeltbookinger og tidszoner er ting, du specificerer og tester, som ovenfor.

Kommandoen /test får agenten til at klikke sig igennem bookingforløbet i forhåndsvisningen og rapportere, hvad der går i stykker. Til en startprompt kan du prøve skabelonerne for barbershop-bookingwebsite eller mødebooker, eller se alle app-skabeloner.

Spørgsmål