Produktstudie · Plattformarkitektur
Én bestillingsmotor for time- og dagsbaserte tjenester samt tjenester med variabel varighet
Anolla er bygget rundt ressurser, tilgjengelighet og regler, ikke etter en mal for én bestemt bransje. Derfor kan den samme kjernemotoren håndtere avtaler, gruppetjenester, lokaler og utleietjenester uten at det må utvikles et eget programvareprodukt for hver tjenestemodell.
Denne tekniske oversikten beskriver hvordan Anolla modellerer ulike planleggingsmetoder gjennom en felles logikk for ressurser og tilgjengelighet.
Grunnleggende planleggingsmodeller: timebasert, dagsbasert og variabel varighet.
KonfigurasjonsomfangRessurstyper som støttes i den nåværende konfigurasjonsmodellen.
Verifisert plattformkapasitetEn felles motor for validering av tilgjengelighet og konflikter.
ArkitekturprinsippHvilket problem løser en felles bestillingsmotor?
Mange planleggingssystemer tar utgangspunkt i en kalender med avtaler med fast varighet, som det senere legges til unntak i. Anolla bygger på det motsatte prinsippet: Det defineres separat hva som bestilles, hvor lenge det trengs, og hvilke vilkår som må være oppfylt. Slik oppstår et gjenbrukbart, felles fundament for ulike typer tjenestebedrifter.
Utfordringen
En avtale kan kreve én spesialist i 45 minutter, en utleietjeneste kan reservere et objekt i flere dager, mens en gruppetjeneste kan tillate flere deltakere på samme tidspunkt.
Designbeslutningen
Ressurser, tid og begrensninger modelleres separat, slik at tilgjengeligheten kan beregnes ved hjelp av gjenbrukbare komponenter.
Plattformresultatet
Én kjernemotor støtter ulike bestillingsscenarioer gjennom en felles administrasjonsmodell, samtidig som kundeopplevelsen forblir enhetlig.
Hvorfor er ikke en kalender alene en bookingmotor?
En enkel kalender kan vise ledige og opptatte tider. Et bookingsystem i produksjon må avgjøre hva som kan bestilles, hvilke ressurser som kreves, hvordan varigheten fastsettes, om det fortsatt er ledig kapasitet, og om en annen bestilling har endret situasjonen før bekreftelse.
Disse beslutningene blir kompliserte når plattformen betjener mer enn én forretningsmodell. Å lage en egen kalender for hver kategori ville duplisere logikken, fragmentere brukeropplevelsen og gjøre fremtidige endringer vanskeligere å administrere.
Avtaler
Krever en spesialist, en tjenestevarighet og buffertid mellom kundene.
Gruppetjenester
Krever administrasjon av antall plasser i stedet for enerett til et tidsrom.
Lokaler og baner
Kan reserveres i faste intervaller og være avhengige av åpningstider og tilgangsregler.
Utleieobjekter
Kan bruke dagsbaserte perioder, overleveringsvinduer og tilgjengelighet over flere dager.
Tjenestekategorien bør beskrive virksomhetens kontekst, ikke definere grensene for planleggingsmotoren.
Hvilke prinsipper gjør det mulig å bruke én motor for ulike tjenestemodeller?
Anollas bookingmodell består av uavhengige lag. Hvert lag svarer på én type spørsmål og kan gjenbrukes når en ny bransje eller et nytt bestillingsscenario legges til.
01 · Ressursorientert struktur
Alt som begrenser tilgjengeligheten, kan behandles som en ressurs: en spesialist, et lokale, en bane, en enhet, et bord, et kjøretøy, et tjenestested eller et annet objekt som kan bestilles.
02 · Bransjeuavhengig planleggingsmodell
En tjeneste kan bruke et timebasert tidsrom, en dagsbasert periode eller variabel varighet uten en separat produktarkitektur for hver kategori.
03 · Sentralisert vurdering av begrensninger
Tidsplaner, kapasitet, buffertider, bestillingsvinduer og overlappende bestillinger vurderes samlet før et tidspunkt tilbys, og på nytt før bekreftelse.
04 · Én modell for kunde- og administrasjonsflyter
Den offentlige bestillingssiden og administrasjonsverktøyene bruker den samme tilgjengelighetslogikken, noe som reduserer risikoen for motstridende valg.
Hvordan flyter konfigurasjonen inn i tilgjengelighetsmotoren?
Motoren tar ikke utgangspunkt i navnet på bransjen, men i ressursene, tidsplanleggingsmodellen og begrensningene som kreves for bookingen som skal vurderes. Den samme beslutningslogikken brukes både for offentlige bookinger og bookinger som opprettes i administrasjonen.
Konfigurasjonsdata
Tilgjengelighetsmotor
Beregn · sammenlign · valider
En felles motor kombinerer konfigurasjonen, kontrollerer tilgjengeligheten og anvender bestillingsreglene før resultatet returneres.
Motorens utdata
Det konseptuelle diagrammet beskriver beslutningsflyten for tilgjengelighet, ikke den fullstendige tekniske arkitekturen til Anollas interne systemer.
Hvordan bruker den samme motoren ulike tjenestescenarioer?
Konfigurasjonen varierer fra scenario til scenario, men kjernemotoren besvarer alltid de samme spørsmålene: Hvilke ressurser kreves, hvor lenge, basert på hvilke begrensninger, og hvor mye bookingkapasitet er igjen?
| Scenario | Tidsplanleggingsmodell | Hva motoren vurderer | Gjenbrukbar plattformlogikk |
|---|---|---|---|
| Konsultasjon hos en spesialist | Variabel varighet | Tjenestens varighet, spesialistens timeplan, forberedelses- eller oppryddingstid og eksisterende bookinger. | Ressurstilgjengelighet, beregning av varighet, forhåndsvarsel og konfliktkontroll. |
| Gruppetime | Fast varighet | Timeplanen, instruktøren, lokalet, maksimalt antall deltakere og antall ledige plasser. | Kontroll av flere ressurser, sporing av antall plasser, bookingvinduer og bekreftelsesregler. |
| Bane eller lokale | Timebasert | Åpningstider, bookingintervall, ressursens belegg, forberedelsestid og valgfrie tillegg. | Generering av bestillbare tidspunkter, utelukkelse av overlappende bookinger og visning av tilgjengelighet. |
| Utleieobjekt | Dagsbasert | Start- og sluttdato, overleveringsvinduer, objektets tilgjengelighet og overlappende leieperioder. | Validering av perioden, ressursstatus, bookingregler og endelig kontroll av tilgjengeligheten. |
Hvordan støtter den samme motoren kombinasjoner av flere tjenester?
Én bestilling trenger ikke alltid å bety én tjeneste. Kunden kan ønske flere relaterte tjenester etter hverandre, og tjenesteleverandøren kan angi hvilke tjenester som kan bestilles separat, og hvilke som bare kan bestilles sammen med en annen tjeneste.
Bestillingsmotoren behandler de valgte tjenestene som én helhet: Varigheten, pausene, prisene og de nødvendige ressursene utgjør en kombinasjon som brukes til å finne passende tidspunkter og opprette én bestilling.
Én bestilling, flere tjenester
Kunden kan velge flere kompatible tjenester i én booking uten å opprette separate bookinger.
Kontrollerbare kombinasjoner
Tjenesteleverandøren kan angi hvilke tjenester som kan bestilles separat, og hvilke som inngår i en kombinasjon.
Felles beregning av tilgjengelighet
Tilgjengeligheten beregnes ut fra hele kombinasjonens varighet, pauser og nødvendige ressurser.
Kombinering av tjenester krever ikke en egen bestillingsmotor. Den samme logikken for ressurser, varighet og tilgjengelighet kan vurdere om både én enkelt tjeneste og en bestilling som består av flere tjenester, passer.
Hvordan fører konfigurasjonen frem til en bekreftet bestilling?
Bestillingsflyten følger den samme rekkefølgen selv om tjenesten som vises til brukeren, og planleggingsmodellen er forskjellige.
Definer hva som kan bestilles
Tjenesteleverandøren angir hovedressursen og alle tilleggsressursene som kreves for å levere tjenesten.
Angi planleggingsmodellen
Tjenesten bruker et timebasert tidsintervall, en dagsbasert periode eller en varighet som avhenger av tjenesten og tilleggsvalgene.
Bruk tidsplaner og begrensninger
Arbeidstider, antall plasser, buffertider, varslingsfrister, bestillingsvinduer og andre regler begrenser den teoretiske tilgjengeligheten.
Finn alternativene som skal vises til kunden
Motoren returnerer bare tidspunktene eller periodene som samsvarer med konfigurasjonen som er aktiv på tidspunktet for forespørselen.
Kontroller tilgjengeligheten på nytt før bekreftelse
En ny kontroll beskytter mot overlappende endringer som har oppstått under valgprosessen.
Hvilke egenskaper følger av en felles bookingmotor?
Resultatet er ikke at alle virksomheter bruker en identisk konfigurasjon. Ulike konfigurasjoner kan bygge på den samme testede beslutningsmotoren og felles administrasjonsprinsipper.
Felles administrasjonsmodell
Brukerne administrerer ressurser, tjenester, tidsplaner og regler gjennom felles begreper.
Gjenbrukbare valideringsregler
Konfliktkontroller og begrensninger administreres sentralt, slik at flere tjenestemodeller kan dra nytte av forbedringene.
Enhetlig kundereise
Avtaler, rom og utleietjenester kan følge et velkjent bestillingsmønster selv når tilgjengelighetsreglene er forskjellige.
Skalerbart plattformfundament
Nye ressurskategorier og tjenestekombinasjoner kan legges til ved å utvide konfigurasjonen og reglene.
Hva betyr påstandene i denne casestudien helt konkret?
Dette er en produktcasestudie, ikke en kundehistorie. Den beskriver Anollas nåværende bookingmodell, støttede ressurskonfigurasjon og funksjonelle beslutningsflyt. Omfangsindikatorene beskriver plattformens kapasitet og er ikke et resultat som loves til en bestemt virksomhet.
Grunnlag for funksjonalitet
Plattformens nåværende konfigurasjon, systemet for støttede ressurstyper og eksisterende planleggingsmodeller.
Funksjonell dokumentasjon
Bookingscenarioer som vurderes gjennom den samme kontrollen av tilgjengelighet og konflikter.
Bruk av data
Casestudien bruker ikke data fra navngitte eller identifiserbare kunder eller individuelle resultatindikatorer fra noen virksomhet.
Tolkning
Siden viser plattformens omfang og arkitekturens gjenbrukbarhet, ikke garanterte kunderesultater.
Begrensninger. En fleksibel kjerne gjør ikke arbeidsflytene i alle bransjer identiske. Bransjespesifikke krav, skreddersydde integrasjoner, fysiske adgangssystemer eller uvanlige prisregler kan kreve ytterligere konfigurasjon eller utvikling. Nøyaktigheten i tilgjengeligheten avhenger av kvaliteten på tidsplanene, ressursene og reglene som tjenesteleverandøren legger inn.