Problemet det løser: Manuell booking (en delt kalender, en whiteboard, en gruppechat) fører uunngåelig til dobbeltbookinger og panikk i siste liten.

Hvordan det hjelper:

• Rom og bookbare ressurser modelleres på samme måte som andre bookbare enheter — med tilgjengelighet, kapasitet og planleggingsregler som håndheves automatisk.
• Bestillinger knyttes direkte til Arrangementer og Ordrer-systemet, slik at en rombestilling kan være en enkel reservasjon eller en betalt booking (f.eks. leie av en hall) ved bruk av samme underliggende motor.
• Konflikter sjekkes automatisk ved bookingstidspunktet, noe som forhindrer at samme lokale blir dobbeltbooket.
• Bookingaktivitet kan utløse Automatisering-regler — påminnelser, bekreftelser og oppfølginger — uten at ansatte må følge opp hver reservasjon manuelt.

Den gode arbeidsdagen: Bestill et rom på sekunder, stol på at systemet allerede har sjekket for konflikter, og oppdag aldri en dobbeltbooking på arrangementsdagen.

Hvorfor dette betyr noe for organisasjonen din

En dedikert bookingmotor fjerner byrden med manuell konfliktsjekking fra ansatte, og fordi den er koblet til automatisering, skjer påminnelser og bekreftelser uten at noen trenger å huske å sende dem.

Tekniske detaljer

Bookingsfunksjonalitet er implementert i BookingService (ExireNexus.Services/Services/BookingService.cs), og fungerer sammen med Event-modellen (ExireNexus.Shared/Models/Event.cs) — plattformens kalender-entitet, som dekker rombestillinger, offentlige arrangementer, avtaler og gjentakende arrangementer under én type.

Viktige implementeringspunkter:

• Bookbare ressurser (rom, utstyr) representeres som Event-knyttede enheter med kapasitets- og tidsromsbegrensninger, slik at den samme bookingslogikken kan brukes både for enkel intern romreservasjon og for en offentlig betalt booking.
• BookingAutomationProcessor (ExireNexus.Services/Services/Automation/BookingAutomationProcessor.cs) kobles til den delte AutomationBackgroundService, så bookingbekreftelser, påminnelser og oppfølginger håndteres av den samme automatiseringsmotoren som brukes i resten av plattformen — ingen egen planleggingskode for bookinger.
• Når en booking innebærer betaling (f.eks. leie av en hall), går den gjennom ShopOrder/ShopOrderItem, som kan kobles til et Event for den bookede tidsluken — gjenbruk av handelssystemet i stedet for å bygge en parallell betalingsvei for bookinger.
• Konfliktdeteksjon håndheves på tjenestelaget før en booking vedvarees, og sikrer at dobbeltbookinger konsekvent avvises uavhengig av hvilken UI (Backstage eller offentlig nettsted) som initierte forespørselen.

Dette gjenbruker plattformens eksisterende Arrangement (kalender) og Ordre (transaksjon)-enheter i stedet for å introdusere en separat booking-spesifikk datamodell, i tråd med plattformens kjerneprinsipp om flerbruksenheter.