Billettsystem - Asker og Bærum Kulturhus

Anskaffelse av billettsystem som skal være 100% sky-/nettleserbasert (SaaS) for Bærum kommune og Asker kommune/kulturhus, inkl. billettkjøp, box office (salg og rapportering), integrasjoner, opplæring, rapportering, scanning og støtte for gavekort/produkter/abonnement. Leverandør skal etablere system og sette krav innen oppstart (krav 1-27), samt oppfylle omfattende sikkerhets- og personvernkrav (GDPR/ISMS) og gi databehandler-/forpliktelsesdokumentasjon ved underleveranser. Varighet 4 år fra leveringsdag (med opsjon for forlengelse).

• Underleverandør/leverandør må etterleve relevante krav og kontraktsvilkår, samt ha oppfylt skatte- og avgiftsforpliktelser og overholde HMS-krav.

  Dokumentasjon: Forpliktelseserklæring for underleverandør signert av underleverandør (inkl. bekreftelse på skatte-/avgiftsforhold og HMS).

  Kilde: Bilag 5 - Forpliktelseserklæring.docx, pkt. 4 og signatur

• Leverandøren må kunne bekrefte oppfyllelse av absolutte ytelseskrav 1-27 (Ja/Nei og evt. kommentarer) samt beskrive løsning for evaluerings-/kvalitetskrav der dette fremgår.Kilde: Bilag 1: Kravspesifikasjon.xlsx (Krav.spek løsningen: «Fylles ut av leverandør» og skjema for Ja/Nei/kommentarer)
• Leverandøren skal levere/utfylle plan og beskrivelser knyttet til implementering (rolle-/ansvarsfordeling og ressurser) og overføring av data (kundedata/arrangementer/historikk), samt redegjørelser for eksisterende funksjonalitet og white label ved oppstart.Kilde: Bilag 1: Kravspesifikasjon.xlsx (Krav 98-103)
• Leverandør skal svare ut informasjonssikkerhetskrav (ISMS m.m.) i skjema med Ja/Nei/Delvis/IR og beskrivelser/vedlegg ved behov.Kilde: Ark: Informasjonssikkerhetskrav i Bilag 1 (Kravbank) – «Fylles ut av leverandør» og relevante punkt (1.1.1-2.1.8)
• Leverandøren skal svare ut prisskjema med priser/betingelser i NOK eks. mva for billetter, fribilletter, gavekort/produkter, andre avgifter (SMS/e-post), lisenser/programvare, implementering, support, integrasjoner, printere/skannere og andre kostnader (skal ligge til grunn for evaluering; uspesifiserte kostnader kan ikke faktureres).Kilde: Bilag 3 - Prisskjema.xlsx, «Prisskjema»
• Databehandleravtale signeres mellom partene; ved avtalens innhold gjelder databehandleravtale med bilag (A-D) som skal suppleres/brukes i leveransen for personopplysninger.Kilde: Bilag 6a Databehandleravtale.docx (signatur/innhold)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

07.08.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• Systemet skal være 100% sky-/nettbasert og operere via nettleser uten krav til lokal maskinvare (krav 2).Kilde: Bilag 1: Kundens kravspesifikasjon.xlsx, krav 2
• API/integrasjon: levere veldokumentert åpen API (f.eks. REST/SOAP/XML/JSON) og etablere feed mellom billettsystem og oppdragsgivers integrasjoner før oppstart/live (krav 3-4).Kilde: Bilag 1: Kundens kravspesifikasjon.xlsx, krav 3-4
• Betalingshåndtering: billett- og produktkjøp skal håndteres via ekstern sertifisert betalingsleverandør; billettsystemet skal ikke lagre/behandle sensitiv kortinformasjon (krav 10-12).Kilde: Bilag 1: Kundens kravspesifikasjon.xlsx, krav 10-12
• Refusjon: ved avlysninger skal kjøpte billetter bulkrefunderes til betalingskort benyttet ved kjøp, også for Vipps (krav 19).Kilde: Bilag 1: Kundens kravspesifikasjon.xlsx, krav 19
• Kryptering og sikkerhet: all kommunikasjon kryptert (f.eks. HTTPS/SSL-TLS 1.2 og sRTP), og ev. passordkryptert (krav 25-26).Kilde: Bilag 1: Kundens kravspesifikasjon.xlsx, krav 25-26
• Support og drift: krav til oppetid (min. 99,9% pr mnd), support tilgjengelig alle virkedager (spesifiseres i skjema) og rutiner for feilretting ved høy pågang (krav 104-105).Kilde: Bilag 1: Kundens kravspesifikasjon.xlsx, krav 104-105
• Implementering/leveringsprosess i SSA-L: leverandøren skal ha plan i etableringsfase, sende leveransemelding når tjenesten kan tas i bruk, og Kunden har 10 virkedager godkjenningsprøve (avtalemal SSA-L punkt 3.3).Kilde: Kontrakt - Billettsystem SSA-L Generell avtaleteks.docx, pkt. 3.1-3.3
• Dokumentasjon og opplæring: dokumentasjon på norsk, leveres senest når godkjenningsprøve starter (med mindre annet avtales) og opplæring iht. bilag; pris for evt opplæring i bilag 3 (SSA-L punkt 3.4).Kilde: Kontrakt - Billettsystem SSA-L Generell avtaleteks.docx, pkt. 3.4
• Personopplysninger og sikkerhet: SSA-L stiller krav til informasjonssikkerhet og at leverandør skal behandle personopplysninger i tråd med databehandleravtale/bilag (SSA-L kap. 6).Kilde: Kontrakt - Billettsystem SSA-L Generell avtaleteks.docx, pkt. 6.1-6.2
• Databehandlerforpliktelser: underleverandører kun med samtykke, varsling ved brudd uten ugrunnet opphold, og sletting/tilbakelevering ved opphør (databehandleravtale punkt 8, 9, 12).Kilde: Bilag 6a Databehandleravtale.docx, punkter 8-9-12
• Databehandlers plikt ved oppstart/leveranseovergang: leverandør skal kunne tilrettelegge for at kommunenes data kan overføres ved avslutning og at leverandør ikke skal kunne tilbakeholde kundens data (SSA-L avslutning/oppfølging og databehandleravtale).Kilde: Kontrakt - Billettsystem SSA-L Generell avtaleteks.docx (pkt. 5.3 Avslutning av avtalen) og Bilag 6a (Sletting og tilbakelevering)

• Kvalifikasjonskrav utover forpliktelseserklæring er ikke eksplisitt identifisert i mottatt tekst (ingen egen «kvalifikasjonskrav»-del er tydelig avgrenset).
• Tildelings-/evalueringsmatrise for alle punkter er ikke fullstendig synlig i teksten (det fremgår noen vekter og rubrikker, men ikke komplett for hele konkurransen).
• SSA-L-delen er kun delvis gjengitt; konkrete kontrakts-/tjenestenivåbestemmelser (SLA, bøter/dagbot) er nevnt i TOC, men ikke detaljert i utdraget.
• Databehandleravtalens bilag A/B/C/D er presentert som maltekst/struktur, men innholdet for behandlingsbeskrivelse og sikkerhetsnivåvalg (høy/ikke høy) er ikke utfylt i utdraget.

Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.

1. Kravspesifikasjonen punkt 1 og 4–12 beskriver at vi må gå live med kjøp av billetter, opplæring, oppsett av rapporter samt overføring av eksisterende kunder/arrangementer. Kan dere bekrefte hvilke konkrete datagrunnlag som skal overføres (kunder/historikk/arrangementer), og i hvilke filformater/uttrekksmetoder dere forventer at vi tar imot data (evt. eksisterende system Tixly) og gjennomfører validering før første dag?

   Hvorfor det er verdt å spørre: Leverandøren må vite omfang, format og valideringskrav for datamigrering for å prise riktig og unngå risiko knyttet til “første dag”-operativitet.

   Kilde: Bilag 1 – Krav.spek løsningen, krav 1 (inkl. pkt. 2–12), krav 4 og krav 13; samt evalueringskrav 99 (overføring av kundedata/arrangementer/historikk fra Tixly).

2. I kravspesifikasjonen krav 19 står det at ved avlysninger skal alle kjøpte billetter bulkrefunderes til betalingskortet som ble benyttet ved kjøp, og at det samme gjelder de som har betalt med Vipps. Kan dere utdype forventet refusjonsflyt (inkl. hvilke status-/refusjonshendelser som skal logges, og hvordan vi håndterer billetter som er delvis brukt/overført/bytett i mellomtiden)?

   Hvorfor det er verdt å spørre: Refusjonslogikk og håndtering av ulike billett-/betalingsstatuser påvirker både integrasjoner og beregning av kost/risiko.

   Kilde: Bilag 1 – Krav.spek løsningen, krav 19.

3. Kravspesifikasjonen krav 2–4 sier at løsningen skal være 100% sky-/nettbasert, og at feed mellom billettsystem og oppdragsgivers integrasjoner skal etableres før går live (med «vedlagte systemskisse»). Kan dere dele systemskissen og spesifisere hvilke integrasjoner/tenester som inngår i “feed” (hvilke endepunkter, event-typer, frekvenser og forventet datavolum) samt hvilke tester/akseptansekriterier dere bruker for å bekrefte at integrasjonene virker før første dag?

   Hvorfor det er verdt å spørre: Integrasjonsomfang, testregime og akseptkriterier er avgjørende for gjennomføringsevne og kostnadsestimat.

   Kilde: Bilag 1 – Krav.spek løsningen, krav 2 og krav 4 (feed før igangsettelse/går live).

4. I evalueringen punkt 104 stilles krav om oppetid minimum 99,9% per måned, samt rutiner for varsling, feilmeldinger, responstid og feilretting ved høy pågang. I SSA-L går det frem at tjenestenivå/kompensasjon følger av avtalt tjenestenivå og bilag 1/3, men SLA-detaljer er ikke synlige her. Kan dere presisere hvilket SLA-nivå som gjelder (definisjon av måleperiode/tilgjengelighet, hva som regnes som nedetid, og hvilke standardiserte satser/kompensasjon som gjelder ved brudd)?

   Hvorfor det er verdt å spørre: Uten definert SLA-måling og kompensasjonsrammer kan leverandøren verken dimensjonere drift/beredskap eller prise korrekt risiko.

   Kilde: Kontrakt SSA-L (dagbot/brudd på tjenestenivå omtales i pkt. 9.2.3–9.2.4), samt Bilag 1 evalueringskrav 104.

5. SSA-L punkt 3.4 og 3.3 omtaler godkjenningsprøve på 10 virkedager fra første virkedag etter leveransemelding. Kan dere bekrefte hvordan ‘A-, B- og C-feil’ skal håndteres i godkjenningsprøven i praksis (hva skjer med leveringsdag og tidsplan dersom det er A/B-feil, og hvem beslutter hva som er vesentlig/non-vesentlig for kundens bruk)?

   Hvorfor det er verdt å spørre: Leverandøren trenger å forstå beslutningsprosess og konsekvenser for leveringsdag/tidsplan for å planlegge bemanning og marginer.

   Kilde: Kontrakt SSA-L, avsnitt «godkjenningsprøve og Leveringsdag» og feildefinisjoner A/B/C.

6. Kravspesifikasjonen krav 23 og 25 sier at løsning (inkl. printere/skannere) skal støtte siste versjon av moderne nettlesere, og at kommunikasjon skal være kryptert med sikre protokoller (f.eks. HTTPS og TLS 1.2 og sRTP), samt at kravet gjelder både skyløsning og lokal server. Skal vi legge til grunn at det også inngår en lokal komponent (server) for scanning/printer (eller kun skannere/printere uten lokal server)? Kan dere beskrive forventet arkitektur for scanning/innslipp (hvilke komponenter er lokale vs. i sky)?

   Hvorfor det er verdt å spørre: Arkitekturvalg påvirker implementering, sikkerhetsarbeid og kost, samt hvilke test- og sertifiseringsforutsetninger som gjelder.

   Kilde: Bilag 1 – Krav.spek løsningen, krav 23 og krav 25; samt krav 85–88 under «Scanning».

7. Kravspesifikasjonen krav 24–25 omtaler eventuell mobilapplikasjon, og krav 110–119 omtaler autentisering/autorisasjon, SSO og MFA (samt reverse proxy og URL-omskriving). Kan dere bekrefte hvilke identitets-/tilgangsstandarder dere forventer (f.eks. SAML2 vs OIDC) for Single Sign-On, og om dere har en bestemt IdP dere bruker (og eventuelle tekniske metadata/tilkoblingskrav)?

   Hvorfor det er verdt å spørre: Riktig SSO-standard og IdP-tilkobling er avgjørende for plan/risiko og for å kunne levere innen oppstart.

   Kilde: Bilag 1 – Krav.spek løsningen, «Provisjonering, autentisering og autorisering» (krav 115–116 og 119) og «Øvrige viktige løsningskrav»/krav 24.

8. I informasjons-/personvernfane står det at noen sikkerhetskrav er avkrysset som «Nei/Delvis/IR» i leverandørskjema (f.eks. 1.6 Kryptografi = Nei, 1.8.1 Driftssikkerhet = IR, 1.7.1 = Delvis). Kan dere gi veiledning på hvordan dere forventer at vi svarer på disse feltene for denne konkurransen (hvilke dokumentasjonsvedlegg/utfylling dere ser etter), og om det er ‘må-krav’ der vi uansett må levere bestemte sikkerhetskontroller på et bestemt nivå for å bli vurdert?

   Hvorfor det er verdt å spørre: Leverandøren trenger klarhet i hva som faktisk forventes i utfylling og hvilke evalueringseffekter avvik/IR har.

   Kilde: Ark «Informasjonssikkerhetskrav» samt Ark «Ark2» (oppsummering av Ja/Nei/Delvis/IR).

9. Kravspesifikasjonen krav 74 sier at leverandøren bør ha løsning/samarbeidspartner som tilbyr videresalg av kjøpte billetter. Kan dere bekrefte om dette er et ‘bør’-krav som skal tilbys innenfor eksisterende standard, eller om dere forventer at videresalg skal være en integrert funksjon i billettsystemet (inkl. regler for pris/avgifter, og hvordan vi håndterer kontroll/gyldighet ved scanning)?

   Hvorfor det er verdt å spørre: Utydelig forventning til funksjon og integrasjon for videresalg påvirker leveringsrisiko og kost.

   Kilde: Bilag 1 – Krav.spek løsningen, krav 74.