Produktcase · Platformarkitektur
Én bookingmotor til time- og dagsbaserede tjenester samt tjenester med variabel varighed
Anolla er bygget op omkring ressourcer, tilgængelighed og regler frem for en branchespecifik skabelon. Derfor kan den samme kernemotor håndtere aftaler, gruppetjenester, lokaler og udlejningstjenester, uden at der skal udvikles et særskilt softwareprodukt til hver tjenestemodel.
Denne tekniske oversigt beskriver, hvordan Anolla modellerer forskellige planlægningsmetoder gennem en fælles logik for ressourcer og tilgængelighed.
Primære planlægningsmodeller: timebaseret, dagsbaseret og variabel varighed.
KonfigurationsomfangUnderstøttede ressourcetyper i den nuværende konfigurationsmodel.
Dokumenteret platformskapacitetEn fælles motor til validering af tilgængelighed og konflikter.
ArkitekturprincipHvilket problem løser en samlet bookingmotor?
Mange planlægningssystemer tager udgangspunkt i en kalender med aftaler af fast varighed, hvortil der senere føjes undtagelser. Anolla følger det modsatte princip: Det defineres separat, hvad der bookes, hvor længe det er nødvendigt, og hvilke betingelser der skal være opfyldt. På den måde skabes et fælles, genanvendeligt fundament for forskellige typer servicevirksomheder.
Udfordringen
En aftale kan kræve én specialist i 45 minutter, en udlejningstjeneste kan reservere et objekt i flere dage, og en gruppetjeneste kan tillade flere deltagere på samme tidspunkt.
Designbeslutning
Ressourcer, tid og begrænsninger modelleres separat, så tilgængeligheden kan beregnes ud fra genanvendelige komponenter.
Platformens resultat
Én kernemotor understøtter forskellige bookingscenarier gennem en fælles administrationsmodel, mens kundeoplevelsen forbliver ensartet.
Hvorfor er en kalender alene endnu ikke en bookingmotor?
En simpel kalender kan vise ledige og optagede tider. Et bookingsystem i et produktionsmiljø skal afgøre, hvad der kan bookes, hvilke ressourcer der er nødvendige, hvordan varigheden fastsættes, om der stadig er ledig kapacitet, og om en anden booking har ændret situationen inden bekræftelsen.
Disse beslutninger bliver komplekse, når platformen betjener mere end én forretningsmodel. Hvis man oprettede en separat kalender for hver kategori, ville det medføre dobbelt logik, en fragmenteret brugeroplevelse og gøre fremtidige ændringer vanskeligere at administrere.
Aftaler
Kræver en specialist, en tjenestevarighed og buffertid mellem kunder.
Gruppetjenester
Kræver styring af antallet af pladser frem for eneret til et bestemt tidsrum.
Lokaler og baner
Kan bookes i faste intervaller og afhænge af åbnings- og adgangsregler.
Udlejningsobjekter
Kan anvende dagsbaserede perioder, afleveringsvinduer og tilgængelighed over flere dage.
Tjenestekategorien bør beskrive virksomhedens forretningsmæssige kontekst, ikke fastlægge planlægningsmotorens begrænsninger.
Hvilke principper gør det muligt at anvende én motor til forskellige tjenestemodeller?
Anollas bookingmodel består af uafhængige lag. Hvert lag besvarer én type spørgsmål og kan genbruges, når der tilføjes et nyt domæne eller bookingscenarie.
01 · Ressourcecentreret struktur
Alt, hvad der begrænser tilgængeligheden, kan behandles som en ressource: en specialist, et lokale, en bane, en enhed, et bord, et køretøj, et betjeningssted eller et andet objekt, der kan bookes.
02 · Domæneuafhængig planlægningsmodel
En tjeneste kan anvende et timebaseret tidsrum, en dagsbaseret periode eller en variabel varighed uden en separat produktarkitektur for hver kategori.
03 · Centraliseret vurdering af begrænsninger
Tidsplaner, kapacitet, buffertider, bookingvinduer og overlappende bookinger vurderes samlet, før et tidspunkt tilbydes, og igen inden bekræftelsen.
04 · Én model til kunde- og administrationsforløb
Den offentlige bookingside og administrationsværktøjerne anvender den samme tilgængelighedslogik, hvilket reducerer risikoen for modstridende valg.
Hvordan overføres konfigurationen til tilgængelighedsmotoren?
Motoren tager ikke udgangspunkt i branchebetegnelsen, men i de ressourcer, den tidsplanlægningsmodel og de begrænsninger, der er nødvendige for den booking, som skal vurderes. Den samme beslutningslogik anvendes både på offentlige bookinger og på bookinger, der oprettes via administrationen.
Konfigurationsinput
Tilgængelighedsmotor
Beregn · sammenlign · valider
En fælles motor kombinerer konfigurationen, kontrollerer tilgængeligheden og anvender bookingreglerne, inden resultatet returneres.
Motorens output
Det konceptuelle diagram beskriver beslutningsprocessen for tilgængelighed, ikke den fulde tekniske arkitektur i Anollas interne systemer.
Hvordan anvender den samme motor forskellige servicescenarier?
Konfigurationen varierer fra scenarie til scenarie, men kernemotoren besvarer altid de samme spørgsmål: Hvilke ressourcer er nødvendige, hvor længe, under hvilke begrænsninger, og hvor meget bookingkapacitet er der tilbage?
| Scenarie | Tidsplanlægningsmodel | Hvad motoren vurderer | Genanvendelig platformslogik |
|---|---|---|---|
| Konsultation hos en specialist | Variabel varighed | Ydelsens varighed, specialistens kalender, forberedelses- eller rengøringstid samt eksisterende bookinger. | Ressourcetilgængelighed, beregning af varighed, varslingsfrist og kontrol af konflikter. |
| Holdtime | Fast varighed | Holdets tidsplan, instruktøren, lokalet, deltagergrænsen og antallet af ledige pladser. | Kontrol af flere ressourcer, registrering af antal pladser, bookingvinduer og bekræftelsesregler. |
| Bane eller lokale | Timebaseret | Åbningstider, bookinginterval, ressourcebelægning, forberedelsestid og valgfrie tilkøb. | Generering af tider, der kan bookes, udelukkelse af overlappende bookinger og visning af tilgængelighed. |
| Udlejningsobjekt | Dagsbaseret | Start- og slutdato, udleveringsvinduer, objektets tilgængelighed samt overlappende lejeperioder. | Validering af perioden, ressourcestatus, bookingregler og endelig kontrol af tilgængeligheden. |
Hvordan understøtter den samme motor kombinationer af flere ydelser?
Én booking behøver ikke altid at omfatte én ydelse. Kunden kan ønske flere relaterede ydelser efter hinanden, og udbyderen kan angive, hvilke ydelser der kan bookes selvstændigt, og hvilke der kun kan bookes sammen med en anden ydelse.
Bookingmotoren behandler de valgte ydelser som én samlet helhed: Deres varigheder, pauser, priser og nødvendige ressourcer udgør en kombination, som bruges til at finde passende tidspunkter og oprette én booking.
Én booking, flere ydelser
Kunden kan vælge flere kompatible ydelser i én booking uden at oprette separate bookinger.
Kontrollerbare kombinationer
Udbyderen kan angive, hvilke ydelser der kan bookes selvstændigt, og hvilke der indgår i en kombination.
Fælles beregning af tilgængelighed
Tilgængeligheden beregnes ud fra hele kombinationens varighed, pauser og nødvendige ressourcer.
Kombinationen af ydelser kræver ikke en separat bookingmotor. Den samme logik for ressourcer, varighed og tilgængelighed kan vurdere egnetheden af både en enkelt ydelse og en booking, der består af flere ydelser.
Hvordan fører konfigurationen frem til en bekræftet booking?
Bookingforløbet følger den samme rækkefølge, selv når den ydelse, der vises for brugeren, og planlægningsmodellen er forskellige.
Definér, hvad der kan bookes
Udbyderen angiver den primære ressource og alle de ekstra ressourcer, der er nødvendige for at levere ydelsen.
Vælg planlægningsmodel
Ydelsen bruger et timebaseret tidsinterval, en dagsbaseret periode eller en varighed, der afhænger af ydelsen og tilvalgene.
Anvend tidsplaner og begrænsninger
Arbejdstider, antal pladser, buffertider, varsler, bookingvinduer og andre regler begrænser den teoretiske tilgængelighed.
Find de valgmuligheder, der skal vises for kunden
Motoren returnerer kun de tidspunkter eller perioder, der stemmer overens med den konfiguration, som er aktiv på forespørgselstidspunktet.
Kontrollér tilgængeligheden igen før bekræftelse
En ny kontrol beskytter mod overlappende ændringer, der er opstået under valget.
Hvilke egenskaber følger af en fælles bookingmotor?
Resultatet er ikke, at alle virksomheder anvender en identisk konfiguration. Forskellige konfigurationer kan bygge på den samme gennemtestede beslutningsmotor og fælles administrationsprincipper.
Fælles administrationsmodel
Brugerne administrerer ressourcer, ydelser, tidsplaner og regler ved hjælp af fælles begreber.
Genanvendelige valideringsregler
Konfliktkontrol og begrænsninger administreres centralt, så flere ydelsesmodeller kan drage fordel af forbedringerne.
Ensartet kunderejse
Aftaler, lokaler og udlejningsydelser kan følge et velkendt bookingmønster, selv når reglerne for tilgængelighed er forskellige.
Skalerbart platformsfundament
Nye ressourcekategorier og kombinationer af ydelser kan tilføjes ved at udvide konfigurationen og reglerne.
Hvad betyder påstandene i dette casestudie helt præcist?
Dette er et produktcasestudie, ikke en kundehistorie. Det beskriver Anollas nuværende bookingmodel, understøttede ressourcekonfiguration og funktionelle beslutningsflow. Omfangsindikatorerne beskriver platformens kapacitet og er ikke et resultat, der loves en bestemt virksomhed.
Kapacitetsgrundlag
Platformens nuværende konfiguration, systemet af understøttede ressourcetyper og de eksisterende planlægningsmodeller.
Funktionel dokumentation
Bookingscenarier, der vurderes ved hjælp af den samme kontrol af tilgængelighed og konflikter.
Anvendelse af data
Casestudiet anvender ikke data fra identificerbare kunder eller individuelle resultatmålinger fra nogen virksomhed.
Fortolkning
Siden viser platformens omfang og arkitekturens genanvendelighed, ikke garanterede kunderesultater.
Begrænsninger. En fleksibel kerne gør ikke arbejdsgangene ens på tværs af alle brancher. Branchespecifikke krav, specialudviklede integrationer, fysiske adgangssystemer eller usædvanlige prisregler kan kræve yderligere konfiguration eller udvikling. Tilgængelighedens nøjagtighed afhænger af kvaliteten af de tidsplaner, ressourcer og regler, som tjenesteudbyderen indtaster.