Slik bygger du en bookingapp: tidsluker, tilgjengelighet, påminnelser og forskudd

For å bygge en bookingapp trenger du fire ting som fungerer sammen: en liste over det som kan bookes (tjenester, rom, ansatte), regler for når hver av dem er tilgjengelig, en bookingflyt som bare tilbyr reelt ledige tidsluker, og en privat visning der bedriften håndterer innkomne bookinger. En AI-appbygger kan lage en fungerende første versjon ut fra en kort beskrivelse på minutter. Det virkelige arbeidet er å bestemme reglene (lengde på tidsluken, buffere, avbestillinger, tidssoner) og å teste at dobbeltbookinger er umulige.

Start med å bestemme hva «en booking» betyr for deg

Bookingapper ser like ut på overflaten, men er ulike under panseret. Svar på disse spørsmålene først:

• Hva bookes? En tjeneste (en hårklipp), en person (en lærer), en ressurs (et møterom, en bane, en bil), eller en plass på en økt (en yogatime med 12 plasser).
• Hvor lang tid tar det? Fast per tjeneste, eller valgt av kunden?
• Hvem utfører det? Én person, flere ansatte med egne arbeidstider, eller ingen (et rom)?
• Hva skjer etter bookingen? Umiddelbar bekreftelse, eller en forespørsel som eieren godkjenner?
• Er det penger involvert? Gratis, betaling på dagen, forskudd på forhånd, eller full forhåndsbetaling?

«Be om et tidspunkt, eieren bekrefter på e-post» er mye enklere å bygge enn «umiddelbar booking mot tre ansattkalendere med forskudd». Begge er gyldige. Velg den du faktisk trenger i første versjon.

Hva appen trenger

Data

Å lagre sluttidspunktet på hver booking, ikke bare starttidspunktet, gjør overlappsjekker mye enklere.

Sider

• Offentlig: tjenesteliste, velger for tidsluker, bookingskjema, bekreftelsesside og en lenke for avbestilling eller endring av tidspunkt.
• Privat (eier eller ansatte): dagens timeplan, kommende bookinger, en måte å blokkere fritid på, og innstillinger for tjenester og arbeidstider.

Tilganger

Kunder bør bare se ledige eller opptatte tidsluker, aldri andre kunders navn. Ansatte kan kanskje bare se sin egen timeplan, mens eieren ser alt. Skriv dette ned, for det avgjør om du trenger innlogging og roller. Vår guide om å legge til innlogging i appen din dekker alternativene.

De vanskelige delene, og hvordan du håndterer dem

Dobbeltbookinger

Den klassiske feilen: to personer laster siden, begge ser at klokken 10:00 er ledig, og begge booker den. Løsningen er å sjekke på nytt på serveren når bookingen lagres, og avvise den hvis noe nå overlapper. Be eksplisitt om dette:

Når en booking lagres, må du sjekke på nytt på serveren at ingen bekreftet eller ventende booking for samme ansatte overlapper det ønskede tidspunktet (inkludert bufferen). Hvis en gjør det, avvis bookingen og vis «Det tidspunktet ble nettopp tatt. Velg et annet.»

Test deretter med to nettleservinduer.

Tidssoner

Lagre alle tidspunkter i UTC og konverter dem for visning. Bestem hvilken tidssone bookingsiden viser. Vanligvis er det bedriftens for tjenester på stedet, og kundens for nettbaserte samtaler. Merk det på siden. Test en booking over en overgang til sommertid.

Buffere, varsel og grenser

Vanlige regler som er verdt å bestemme på forhånd: en buffer mellom avtaler, minste varsel («ingen bookinger mindre enn 2 timer frem i tid»), hvor langt frem folk kan booke, og et daglig tak. Hver av dem er én setning i en prompt. Hvis du utelater dem, velger AI-en standarder for deg.

Avbestillinger og uteblivelser

Gi hver bekreftelse en avbestillingslenke med et unikt token, slik at kunder ikke trenger konto. Bestem avbestillingsfristen og om forskudd er refunderbare, og vis retningslinjen før betaling.

Påminnelser

Påminnelser på e-post eller SMS krever noe som kjører etter en plan («hvert 15. minutt, send påminnelser for bookinger som starter om 24 timer»). Sjekk hvordan appbyggeren og hostingen din håndterer planlagte jobber. Hvis de ikke gjør det, bruk en ekstern planlegger som kaller et endepunkt i appen din, eller send bekreftelsen på e-post med en kalenderinvitasjon vedlagt, slik at kundens egen kalender minner dem på timen. Se hvordan du sender e-post fra appen din for leverandørdelen.

Forskudd og betalinger

Vanlig mønster med Stripe:

1. Kunden velger en tidsluke. Appen oppretter en ventende booking som holder tidsluken en kort stund (for eksempel 15 minutter).
2. Appen sender kunden til Stripe Checkout for forskuddet.
3. Stripe varsler appen din med en webhook når betalingen er gjennomført, og bookingen blir bekreftet.
4. Hvis betalingen uteblir i tide, utløper den ventende bookingen og tidsluken blir ledig igjen.

Stripes standardpriser er en prosentandel pluss et fast gebyr per vellykket kortbetaling, uten månedsavgift (per september 2026). Satsene varierer etter land, så sjekk Stripes prisside for ditt land. Bruk testmodus og testkort til alt fungerer. Vår guide til å legge til betalinger gjennomgår det steg for steg.

En første prompt som fungerer

Bygg en bookingapp for Northside Barbers. Tjenester: Hårklipp (30 min, $25), Skjeggtrimming (15 min, $12), Hårklipp + skjegg (45 min, $32). To frisører, Sam og Ali, som jobber tirsdag til lørdag kl. 9:00 til 18:00. Kunder velger en tjeneste, deretter en frisør eller «hvilken som helst frisør», og ser så bare ledige starttidspunkter på 15 minutter for de neste 14 dagene. De skriver inn navn, telefon og e-post. Lagre bookinger i en database, med en buffer på 10 minutter etter hver avtale, og sjekk tilgjengeligheten på nytt ved lagring for å hindre dobbeltbooking. Vis en bekreftelsesside med en avbestillingslenke. Eieren har en privat side som viser dagens og kommende bookinger, kan avbestille en booking og kan blokkere tid. Tidspunktene er i barbershopens lokale tidssone. Ren, mobilfokusert design.

Den nevner tjenestene, de ansatte, arbeidstidene, reglene og eierens visning. Alt dette ville AI-en ellers gjettet.

Byggetrinn

1. Kjernebookingflyten først. Tjenester, tidsluke, skjema, lagret booking, bekreftelse. Ingenting annet før dette fungerer på en telefon.
2. Eiervisning. Dagens liste, kommende liste, avbestilling, blokkering av tid.
3. Beskytt eiersidene. Legg til innlogging før ekte data legges inn.
4. Regler. Buffere, varselperiode, bookingshorisont, helligdager.
5. E-post. Bekreftelse med kalenderinvitasjon og avbestillingslenke.
6. Forskudd, hvis du trenger dem, først i Stripes testmodus.
7. Test kanttilfellene. To vinduer som booker samme tidsluke, en booking over midnatt, en dato for sommertid, og en avbestilt booking som frigjør tidsluken.
8. Publiser, og gjør deretter en ekte booking selv før du deler lenken.

Vanlige feil

• Å sjekke tilgjengelighet bare i nettleseren. Det ser riktig ut, men dobbeltbooker likevel.
• Å lagre lokale tidspunkter uten tidssone. Det fungerer til klokkene skifter.
• Å vise kundenavn i den offentlige kalenderen. Vis bare ledig eller opptatt.
• Å bygge ansattplanlegging, lojalitetspoeng og SMS på første dag. Lansér kjerneflyten, og legg deretter til det kundene faktisk spør etter.
• Ingen måte for eieren å blokkere tid på. Den første sykedagen vil skape uteblivelser.

Når Calendly (eller lignende) er det bedre valget

Hvis du er én person som deler tilgjengeligheten din for samtaler, er et planleggingsverktøy vanskelig å slå. Per september 2026 dekker Calendlys gratisplan én type hendelse, én kalendertilkobling og én-til-én-planlegging med en tilpassbar bookingside. Betalte planer legger til flere typer hendelser og teamfunksjoner. Slike verktøy kobler seg til din eksisterende kalender rett ut av boksen, noe en egenlaget app må bygges for å gjøre.

Bygg din egen når du trenger regler som disse verktøyene ikke støtter, flere ressurser som kan bookes, din egen profil gjennomgående, bookinger koblet til andre data (kunder, bestillinger, medlemskap), eller du bygger et bookingprodukt som skal selges til andre.

Bygge det med Mythex

På Mythex beskriver du bookingappen i chatten. Den bygges i en live-forhåndsvisning, og den legger til en Postgres-database når bookinger må lagres. Brukstilfellet for bookingside i dokumentasjonen foreslår å starte med et forespørselsskjema og en adminliste, og legge til resten etterpå. Vær klar over hva som er innebygd, og hva du kobler til selv. Mythex har ingen innebygd kalendersynkronisering, SMS-påminnelser eller forskuddsprodukt. E-post går gjennom din egen leverandør, og forskudd går gjennom dine egne Stripe-nøkler, lagret som hemmeligheter i prosjektet (Stripe-oppskriften). Regler mot dobbeltbooking og tidssoner er ting du spesifiserer og tester, som beskrevet over.

Kommandoen /test får agenten til å klikke seg gjennom bookingflyten i forhåndsvisningen og rapportere hva som feiler. Som utgangspunkt for en prompt kan du prøve malen for frisørbooking eller møtebookeren, eller bla gjennom alle app-malene.

Spørsmål