Bokningssystem brukar inte fallera i en demo. De fallerar en lördagskväll när tre personer klickar på samma tidslucka, en tidszon skiftar och en betalning ”lyckas” två gånger. Plötsligt har du dubbelbokningar, arga kunder och supportärenden du inte kan stänga eftersom du inte ens kan förklara vad som hände.
Den här blueprinten för en bokningsplattform är byggd för produktutvecklare som behöver ett bokningssystem som klarar verklig trafik, tech leads som måste standardisera tillståndsändringar och återställningsvägar, och grundare som vill lansera bokningar utan att lära sig de här läxorna den hårda vägen. Resultatet är en produktionsmogen byggplan för en React + TypeScript-app med en realtidsbackend, inklusive en tillståndsmaskin, datamodell, mappstruktur, pseudokod/TypeScript-snippets samt en checklista för testning + drift.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Vad du får |
|---|---|---|
|
|
|
Hela AI-prompten: blueprint för bokningsplattform (produktionsklass)
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[BOKNINGSSYFTE] |
Ange vad bokningssystemet ska användas för att boka, inklusive vilken typ av tjänst eller resurs som reserveras. Till exempel: "Privata mötesrum i ett coworking-utrymme, där varje rum är utrustat med whiteboard och projektor."
|
|
[TIDSALTERNATIV] |
Lista godkända bokningslängder eller tidsluckor, inklusive eventuella regler eller intervall. Till exempel: "Tidsluckor på 30 minuter, 1 timme och 2 timmar, utan möjlighet till kortare delintervall."
|
|
[OPPETTIDER] |
Ange vilka dagar, tider och vilken tidszon verksamheten har öppet och bokningar kan göras. Till exempel: "Måndag till fredag kl. 09:00–18:00, tidszon UTC+2."
|
|
[AVBOKNINGSPOLICY] |
Beskriv regler för avbokning och ombokning, inklusive tidsfrister, avgifter eller villkor för återbetalning. Till exempel: "Avbokning tillåts fram till 24 timmar före bokningsstart med full återbetalning; ingen återbetalning vid avbokning samma dag."
|
|
[BETALNINGSKRAV] |
Definiera betalningsupplägg för bokningar, inklusive krav på handpenning, förskottsbetalning eller kostnadsfria bokningar samt eventuella begränsningar. Till exempel: "En handpenning på 50 % krävs vid bokning, och resterande belopp ska betalas senast 1 timme före bokningsstart."
|
|
[PLATTFORM] |
Ange avsedd plattform eller kanal för bokningssystemet, till exempel webb, mobilwebb eller ett internt verktyg. Till exempel: "Webbplattform som kan nås via webbläsare på dator och mobil."
|
|
[KONTEXT] |
Lägg till relevant bakgrund eller specifika krav som påverkar utformningen av bokningssystemet. Till exempel: "Systemet är avsett för en plats med hög efterfrågan där det är avgörande att förhindra dubbelbokningar och ha uppdateringar i realtid."
|
Proffstips för bättre resultat från AI-prompten
- Beskriv regeln ”en tidslucka” som ett kontrakt. Säg inte ”användare bokar tider”. Säg ”varje utförare kan bara ha en bekräftad bokning per 30-minuterslucka, men kan acceptera flera väntande reservationer i upp till 2 minuter.” Efter första outputen, fråga: ”Lista de exakta invariants som förhindrar överlappande bekräftade bokningar och hur de upprätthålls.”
- Tvinga fram tidszonsbeslut tidigt. Ge ett exempel i platsens tid och ett i användarens tid, inklusive DST-edge cases. Följ sedan upp med: ”Visa din strategi för kanoniska tidsstämplar och hur UI:t visar lokal tid utan att korrumpera lagringen.”
- Ta med berättelser om betalningsfel, inte bara ”Stripe-integration”. Ge två realistiska fel (webhook försenad, kund stänger checkout, kort auktoriseras men capture misslyckas). En bra följdfråga är: ”Designa idempotency keys och retry-regler för varje Stripe-event så att vi aldrig skapar dubbla bokningar eller dubbla återbetalningar.”
- Iterera på tillståndsmaskinen före kod. Om den första tillståndsmaskinen känns för enkel, pressa den. Prova: ”Lägg nu till ombokning, avbokning från utförare och policy för uteblivet besök; håll det granskbart och undvik tvetydiga tillstånd.”
- Be om scenarier för ”hur det fallerar” som acceptanskriterier. Den här prompten är som starkast när den får vara paranoid. När du fått arkitekturen, fråga: ”Ge mig 12 tester för felmoder (samtidighet, tidszon, webhooks, retries) med förväntade utfall och vilka loggar/mätvärden vi borde se.”
Vanliga frågor
Seniora fullstackutvecklare använder den för att stresstesta samtidighet, idempotens och realtidskonsistens i data innan de låser sig vid en backend-inriktning. Engineering managers får en avgränsningsartefakt som gör ”vi behöver bokningar” till tydliga moduler, risker och testkrav. CTO:er på startups förlitar sig på den för att undvika dyra omskrivningar genom att göra återhämtning vid betalningsfel och spårbarhet till förstaklasskrav. Lösningsarkitekter använder den när de måste dokumentera avvägningar (Firebase vs Supabase, lås vs reservationer, synkrona flöden vs webhook-drivna flöden) för intressenter.
Hälso- och sjukvård samt kliniker använder den för att förhindra dubbelbokning av utförare, upprätthålla besökslängder och hantera avbokningar med tydliga revisionsspår. Hotell, hospitality och upplevelser använder den för lager med hög samtidighet (turer, klasser, tidsstyrt inträde) där reservationer och utgångstider är avgörande, särskilt i mobilflöden. Skönhet, träning och lokala tjänster vinner på tidszons- och ombokningsdisciplinen eftersom kunder bokar sent på kvällen, under resor och runt DST-omställningar. B2B-plattformar för schemaläggning använder den för att designa observerbarhet och retries i enterprise-klass, där missade webhooks eller duplicerade event kan påverka många konton samtidigt.
En typisk prompt som ”Write me a booking app architecture” misslyckas eftersom den: saknar en explicit tillståndsmaskin för bokning och betalningar, ger inga konkreta invariants som stoppar dubbelbokningar under samtidighet, ignorerar tidszonskorrekthet och DST-edge cases, producerar generiska CRUD-diagram i stället för idempotenta flöden som är säkra vid retries, och missar driftkrav som granskningsbara tillståndsändringar och observerbarhet. Du får en snygg plan som havererar första gången webhooks kommer i fel ordning. Ärligt talat är det den vanligaste felmoden.
Ja. Prompten ber dig beskriva ett verkligt bokningsscenario, och kvaliteten blir bättre när du specificerar regler för lucklängd, vem/vad som reserveras och dina policies för avbokning + återbetalning. Du kan också styra designen genom att ange en preferens för Firebase eller Supabase samt eventuella krav på compliance eller revision/spårbarhet. Efter första körningen kan du följa upp med något som: ”Skriv om blueprinten för en tvåsidig marknadsplats (utförare + kund), lägg till begränsningar för ombokning och visa den exakta eventsekvensen för betalningsauktorisering, bekräftelse och avbokning.”
Det största misstaget är att lämna bokningsscenariot för otydligt — i stället för ”folk bokar tider”, använd något som ”kunder bokar 60-minutersbesök med en enskild utförare; en lucka kan reserveras i 2 minuter; bekräftade bokningar får inte överlappa; drop-in är inte tillåtet.” Ett annat vanligt fel är att hoppa över felcase; säg inte ”integrera Stripe”, säg ”Stripe-webhooks kan komma sent eller två gånger, och vi måste kunna reconcilea utan dubbletter.” Många glömmer också att definiera avbokningsregler (dåligt: ”återbetalning vid avbokning”, bättre: ”full återbetalning upp till 24 timmar, därefter 50 %, ingen återbetalning inom 2 timmar”). Till sist missar många tidszonskrav; bra indata inkluderar var schemat är förankrat (platslokalt) och hur bokningar för resenärer visas (användarlokalt).
Den här prompten är inte optimal för små prototyper där du bara behöver ett enkelt kalender-UI och du inte tar betalt än. Den är också overkill om du inte tänker iterera på outputen, eftersom värdet kommer av att förfina tillståndsmaskinen och felhanteringen. Och om du behöver en helt copy-pastebar app där varje komponent är implementerad end-to-end kommer det här kännas för ”arkitektur först”. I de fallen, börja med en lättviktig mall och kom tillbaka när riktiga bokningar och riktiga betalningar står på spel.
Bokningar med hög samtidighet är oförlåtande, men de är inte mystiska om du designar för fel redan från början. Klistra in den här prompten i ditt AI-verktyg, beskriv ditt verkliga scenario och få en blueprint som teamet faktiskt kan bygga utifrån.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.