Bookingkalenderen: for innbyggere, bygget for saksbehandlere

En kommunal bookingkalender har to brukere som aldri møter hverandre, men deler samme datakilde: innbyggeren som booker en kantine to ganger i året, og saksbehandleren som administrerer 1 200 bookinger i måneden. De har motsatte behov. Det vanlige feilgrepet er å designe for én av dem og håpe den andre overlever. Digilist designet for begge — fra første dag.

Innbyggerens kalender: så enkel at den ikke føles som et system

En innbygger som åpner Digilist for å booke en idrettshall til datterens bursdagsfest 2. lørdag i mars 2026 har én oppgave: finn ledig tid, og book den. Tre prinsipper styrer designet:

1. Stedet først, ikke datoen. De fleste innbyggere vet hva de vil booke (Vestby Storsal), ikke nødvendigvis når. Søkefeltet starter med anlegget, datoen er en filter etterpå.
2. Ledig er grønt, opptatt er grått. Ikke fem farger, ikke statuser. Innbyggeren skal kunne lese kalenderen på fem sekunder med solskinn på skjermen.
3. Bekreftelse uten konto. Innbyggeren logger inn via ID-porten når hun bekrefter, ikke før. Å bla i kalenderen krever ikke pålogging.

Bookingflyten er fire skjermbilder: velg anlegg → velg tid → fyll inn (navn, e-post, formål, antall personer) → bekreft og betal med Vipps eller kort. Ingen step er valgfritt, men hver step er kort. Mediant tid fra åpning til bekreftet booking i Digilist er under 90 sekunder.

Saksbehandlerens kalender: bygget for arbeidsdagens virkelighet

Saksbehandleren har en helt annen oppgave. Hun jobber gjennom en sak-kø, prioriterer søknader, behandler unntak, og må ha overblikk over 12 anlegg samtidig. Designet er forskjellig:

• Listevisning er primær, kalendervisning er sekundær. Søknader behandles raskere som rader i en tabell enn som blokker i en kalender. Filtrering på anlegg, status, søker, dato.
• Tastatursnarveier på alt. J/K for opp/ned, Enter for åpne, A for godkjenn, R for avvis, ? for hjelp. Saksbehandlere som behandler 80 søknader om dagen kan ikke klikke seg gjennom hver.
• Bulkhandlinger. Velg ti søknader → «godkjenn alle med standard avtale». Saksbehandlere bruker 90 % av tiden på de 10 % av søknadene som er kompliserte; resten skal kunne ekspederes raskt.
• Konfliktdeteksjon i klar tekst. Ikke bare «kollisjon» — men «Vestby Idrettslag har søkt om samme slot, og har høyere prioritet etter kommunens fordelingsregler».

Sak-køen oppdateres reaktivt (se Sanntidskalender). Når saksbehandlerens kollega godkjenner en søknad, forsvinner den fra kollegaens kø samme sekund — uten refresh.

Det vanskelige: én sannhet, to grensesnitt

Begge brukere ser samme underliggende data. Når innbyggeren booker tirsdag 14:00–16:00, vises bookingen i saksbehandlerens kø som «godkjent automatisk (verifisert bruker, regelinnenfor)» — uten at saksbehandleren trenger å gjøre noe. Når en søknad fra et idrettslag krever manuell vurdering, dukker den opp i saksbehandlerens kø samtidig som søkeren får meldingen «Behandles av kommunen».

Det betyr at:

• Innbyggeren får statusen «behandles» eller «bekreftet» i sanntid. Ikke en e-post tre dager senere.
• Saksbehandleren ser hvem som har søkt, hvilke regler som gjelder, og hva systemet ville gjort automatisk. Hun kan akseptere forslaget eller justere.
• Begge ser samme historikk. Hvis innbyggeren ringer servicetorget, ser saksbehandleren akkurat det innbyggeren ser — pluss interne notater.

Tilgjengelighet er et felles krav

Saksbehandlerne har ofte de samme tilgjengelighetsbehovene som innbyggerne, bare i en annen kontekst. En saksbehandler med musearmsmerte trenger tastatursnarveier. En saksbehandler med redusert syn trenger samme kontrastsuverenitet som en innbygger. Det er ikke separate løsninger — det er samme WCAG 2.1 AA-implementering, bare brukt forskjellig.

Hva som ofte går galt

De fleste kommunale bookingsystemer feiler på én av to måter:

• De er enkle for innbyggeren, men umulige for saksbehandleren. Et flott bestillingsskjema, men saksbehandleren må eksportere til Excel for å gjøre noe nyttig.
• De er kraftige for saksbehandleren, men avskrekkende for innbyggeren. Tjue felter, krav om kontooppretting før man kan se ledige tider, terminologi som «ressursallokering».

Den vanskeligste designdisiplinen i kommunal SaaS er å gjøre begge samtidig — uten å gå på akkord med noen av dem. Det er ikke en pen idé. Det er forskjellen mellom en plattform en kommune er stolt av, og en plattform en kommune unnskylder.