Billettsystem til DNS

Den Nationale Scene (DNS) skal anskaffe et billettsystem (skybasert/SaaS eller tilsvarende) via konkurranse med forhandling etter forutgående kunngjøring. Formålet er å etablere et fremtidsrettet billettsystem som støtter billett- og kundehåndtering, moderne netthandel med krav til GDPR og universell utforming, fleksible pris-/rabattstrukturer, integrasjon mot relevante systemer og systemlandskap (bl.a. dns.no) samt høy datasikkerhet og stabil drift. Kontrakten skal benytte SSA-lille sky 2026-rammevilkår, med estimerte kontraktsverdi 3,6 MNOK eks. mva og oppstart snarlig etter signering.

• Leverandør skal være registrert i foretaksregister, faglig register eller handelsregister i staten leverandøren er etablert.

  Dokumentasjon: Firmaattest (norske selskaper) / godtgjørelse på registrering (utenlandske selskaper).

  Kilde: Pkt. 8.3 Krav til registrering, autorisasjon m.m.
• Leverandør skal ha tilstrekkelig økonomisk og finansiell kapasitet til å oppfylle avtalen.

  Dokumentasjon: Kredittvurdering fra et anerkjent kredittvurderingsselskap basert på siste regnskapstall (nøkkeltall og betalingserfaring). Eventuelt annet egnet dokumentasjon ved saklig grunn til ikke å fremlegge krevd dokumentasjon.

  Kilde: Pkt. 8.4 Krav til økonomisk og finansiell stilling
• Leverandør skal ha god erfaring fra leveranse av sammenlignbare billettsystemer.

  Dokumentasjon: Beskrivelse av 3 siste års mest relevante oppdrag (prosjektnavn, oppdragsgiver, totalkostnad og lengde, leverandørens rolle, omfang i timer, tidspunkt og leveranse i prosjektet). Referanseskjema (Del I vedlegg 5) utfylles per referanse. Leverandøren har ansvar for å dokumentere relevans; erfaring kan dokumenteres via kompetanse til personell selv om erfaringen er opparbeidet i annen leverandør.

  Kilde: Pkt. 8.5 Krav til tekniske og faglige kvalifikasjoner
• Leverandør skal ha gode rutiner for kvalitetsstyring.

  Dokumentasjon: Enten rutinebeskrivelse for kvalitetsstyring (kvalitetssikring, ressursstyring, leders ansvar og kontinuerlig analyse/forbedring) eller ISO 9001 (eller tilsvarende) dokumentert ved sertifikat.

  Kilde: Pkt. 8.6 Krav til kvalitetsstyringssystem
• Ved støtte på underleverandører/samarbeidspartnere for å oppfylle kvalifikasjonskrav knyttet til økonomi/finansiell stilling og/eller tekniske/faglige kvalifikasjoner: skal det leveres nødvendig dokumentasjon for underleverandøren.

  Dokumentasjon: Forpliktelseserklæring/samarbeidsavtale (signert) om rådighet over nødvendige ressurser (FOA § 16-10 (2)); dokumentasjon fra underleverandør på relevante kvalifikasjonskrav; ESPD for underleverandører (oppsett i KGV).

  Kilde: Pkt. 8.7 Bruk av underleverandører/samarbeidspartnere

• Forespørsel om deltakelse skal leveres i KGV innen frist angitt i fremdriftsplan (pkt. 4.3).Kilde: Pkt. 7 Innlevering av forespørsel om deltakelse
• Forespørsel skal bestå av: Forespørselsbrev med forpliktende signatur (Del I vedlegg 0). Dokumentasjon på oppfyllelse av kvalifikasjonskrav (inkl. sjekkliste i forespørselsbrev). Forpliktelseserklæring (Del I vedlegg 2) ved støtte på underleverandører. Dokumentasjon for underleverandører hvis aktuelt. ESPD for hovedleverandør (i KGV) og ESPD for underleverandører (i KGV). Egenerklæring taushetsplikt (Del I vedlegg 3).Kilde: Pkt. 7 Innlevering av forespørsel om deltakelse
• Tilbud (fase 2) skal leveres elektronisk i KGV innen tilbudsfrist (pkt. 4.3). Ved for sent innkomne tilbud: avvisning. Vedlegg skal lastes opp som separate dokumenter; det er ikke nødvendig med elektronisk signatur, men verifikasjon at tilbyder har signert/skannet og lastet opp mal for tilbudsbrev.Kilde: Pkt. 10.1 Innlevering av tilbud
• Tilbud skal som minimum inneholde: Tilbudsbrev med forpliktende signatur (Del I vedlegg 1). Egenerklæring taushetsplikt (Del I vedlegg 3). Avvik (Del I vedlegg 4) dersom avvik. Kravspesifikasjon: leverandørens besvarelse av Del II bilag 1 (oppdragsgivers kravspesifikasjon) og øvrige vedlegg. Utfylt prismatrise (Del II bilag 7a). Øvrige tildelingskriterier: Del II bilag 1 med egne vedlegg. Utfylt Bilag 2 (Del II bilag 2). Utfylt bilag 11 eller egen databehandleravtale (Del II bilag 11).Kilde: Pkt. 10.2 Innhold og struktur

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

05.08.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Kontraktstype/vilkår: SSA-lille sky 2026 med bilag (inkl. bilag 10 Standardvilkår for Skytjenestene og bilag 11 Databehandleravtale).Kilde: Pkt. 3.2 Kontraktstype og omfang + Del II bilagsoversikt
• Avtaleperiode/fornyelse: 1 år fra undertegning, automatisk fornyelse 1 år om gangen; Kunden kan si opp med 3 måneders varsel, Leverandøren med 6 måneder før fornyelsestidspunkt.Kilde: Pkt. 3.3 Avtaleperiode
• Lønns- og arbeidsvilkår skal inn i kontrakten.Kilde: Pkt. 5 Særlige kontraktsvilkår (5.1) + Bilag 6 pkt. 5.5
• Skatteattest: valgt leverandør skal på forespørsel levere skatteattest for merverdiavgift og skatt (kun norsk leverandør), ikke eldre enn 6 måneder regnet fra tilbudsfrist.Kilde: Pkt. 4.14 Skatteattest
• Krav om databehandleravtale ved behandling av personopplysninger: databehandleravtale må være inngått før behandling påbegynnes (bilag 11).Kilde: SSA-lille sky generelle avtaletekst pkt. 7.2 + Bilag 11 beskrivelse
• Kundens godkjenningsprøve: skal gjennomføres (bilag 4; varighet 21 dager i kravspesifikasjon). Systemet anses ikke godkjent før integrasjon mot nettsted fungerer i sanntid og kundedata/historikk er overført. Avvik kan gi mangler og rett til prisavslag/heving ved vesentlige forhold.Kilde: Bilag 4 Kundens Godkjenningsprøve (i vedlagt bilag 4) + SSA-lille sky pkt. om godkjenningsprøve
• Informasjonssikkerhet: leverandøren skal iverksette forholdsmessige tiltak; krav til sikring av kundedata, konfidensialitet, tilgjengelighet og tiltak mot angrep/skadevare. Plikter knyttet til skytjenestene i bilag 1/2.Kilde: SSA-lille sky generelle avtaletekst pkt. 7.1

• Dokumentteksten er delvis: kravtabellen i Bilag 1 (krav 6 og videre) er avkortet, så full liste over kvalifiserende/ evalueringsrelevante C-krav og tekniske krav utover de som vises i utdraget er ikke komplett.
• Kontrakts-/utførelseskrav utover godkjenningsprøve, varighet, oppsigelsestid og generelle SSA-bestemmelser er ikke uttømmende trukket ut, da SSA-tekst er meget lang og innholdet er ikke spesifikt oppsummert i del I-dokumentet.
• Det fremgår ikke i utdraget konkrete nivåer/satser for dagbøter i bilag 7 (kun at 0,15% er oppgitt i bilagutdrag).
• Funksjonelle C-krav som inngår i tildelingsvekter (referanser som 7.2, 13.1, 15, osv.) er kun listet i tildelingsmatrisen; selve kravtekstene for disse er ikke med 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. Krav 1.1 (salgs-/billettkontor- og kundeadministrasjon): Kan dere presisere hva dere mener med «publikumsrettete billettkontorer og spillesteder» i praksis (antall lokasjoner/roller), og hvordan dere forventer at løsningens backoffice skal håndtere henvendelser fra fysik, chat, e-post og telefon (f.eks. én felles innboks vs. integrasjon til kanalverktøy)?

   Hvorfor det er verdt å spørre: Opplysningene påvirker både løsningsbeskrivelsen og hvilke integrasjoner/arbeidsomfang som skal prise.

   Kilde: Bilag 1, krav 1.1

2. Krav 1.2 (maskinlesbart format for forestillinger/arrangement): Hvilken frekvens forventer dere for eksport via «eksportfil eller API» (batchfiler med X minutters intervall vs. sanntidsoppslag), og hvilke format-/skjemavarianter ønsker dere dokumentert i tilbudet (XML/JSON, versjonering, autentiseringsmetode)?

   Hvorfor det er verdt å spørre: Frekvens, format og autentisering er avgjørende for å kunne prise riktig integrasjons- og driftsarbeid.

   Kilde: Bilag 1, krav 1.2

3. Krav 1.3 (DNS skal eie alle kundedata): Kan dere bekrefte at dere forventer full datakontroll og -portabilitet i tråd med SSA-lille sky (særlig tilgang/eksport ved avslutning), og i den forbindelse be oss om å beskrive hvilke «tilgjengelige data/metadata» som faktisk kan eksporteres (feltkartlegging) i Bilag 7a eller i bilag 2?

   Hvorfor det er verdt å spørre: Leverandøren må forstå hva DNS faktisk får kontroll over, og hvor dette skal dokumenteres i tilbudet for evaluering.

   Kilde: Bilag 1, krav 1.3

4. Krav 1.6 (billettkontroll ved innslipp – «bør»): Hvilke enheter/teknologier bruker dere i dag til scanning/kontroll (f.eks. mobilapp, dedicated skannere, nettleserbasert kontroll), og er det krav om offline-funksjon ved nettutfall (og i så fall hvor lenge)?

   Hvorfor det er verdt å spørre: Dette påvirker designet av kontroll-løsningen og eventuelle tiltak/risiko som må inn i kostnads-/leveransegrunnlaget.

   Kilde: Bilag 1, krav 1.6

5. Krav 2.1 (integrasjon mot dns.no uavhengig av CMS, via API/iframe/iframe el. annen dokumentert metode): Hvilken integrasjonsmetode ønsker dere primært å bruke for «DNS sin nettbutikk» (API vs. iframe vs. annen), og hvilke praktiske føringer har dere (f.eks. eksisterende nettstedsløsning, krav til domener/hosting, CSP/tilgang til checkout)?

   Hvorfor det er verdt å spørre: Valg av integrasjonsmetode påvirker teknisk løsning, testomfang og kostnad; det er også sentralt for forståelsen av løsningen i evalueringen.

   Kilde: Bilag 1, krav 2.1

6. Krav 2.4 (betalingsflyt og avbrutte betalinger): Kan dere presisere ønsket betalingsflyt «direkte mellom billettsystem og DNS» – betyr dette at DNS ikke ønsker redirect via tredjeparts betalingsside i det hele tatt (eller at vi skal minimere tredjepart), og hvilke betalingsaggregatorer/leverandører benytter dere i dag (om kjent) som systemet må støtte?

   Hvorfor det er verdt å spørre: Betalingsflyt og avbrutte betalinger bestemmer integrasjonsarbeid og eventuelle kostnader til betalingsgateway/operasjonelle rutiner.

   Kilde: Bilag 1, krav 2.4

7. Krav 3.2 (salkart og prising for flere spillesteder): Kan dere gi et estimat eller konkret eksempel på typiske salkartsituasjoner (antall spillesteder, antall salkart per spillested, antall priskategorier/prissoner, og forventet variasjon per forestilling), slik at vi kan prise fleksibiliteten som etterspørres?

   Hvorfor det er verdt å spørre: Selv om kravene er funksjonelle, trenger leverandøren volum-/kompleksitetsgrunnlag for å gi korrekt pris og riktig ressursplan.

   Kilde: Bilag 1, krav 3.2

8. Krav 4.1 og 4.2 (reservasjoner/allokasjoner og gruppesalg): Hvilke faktiske scenarier har dere behov for (f.eks. gruppesalg med individuelle uttak vs. samlet uttak, endring etter at frist er passert, og fakturering av billetter i hvilke tilfeller), og hvilke «regler» må kunne settes opp i backoffice?

   Hvorfor det er verdt å spørre: Konkrete reservasjon-/allokeringsregler påvirker både konfigurasjon og løsningens kompleksitet samt testopplegg i godkjenningsprøve.

   Kilde: Bilag 1, krav 4.1-4.2

9. Krav 7.2 (fleksibel uttrekk/segmentering/rapportering): Hvilke datakilder forventer dere at uttrekk skal dekke (inkl. samtykkestatus og medlemskap/abonnement), og hvordan forventer dere at uttrekk distribueres (manuelt eksport, planlagt rapportutsendelse, filformat/SQL/API)?

   Hvorfor det er verdt å spørre: Uttrekksmuligheter og distribusjonsformater påvirker både teknisk løsning og ressursbruk for rapportering og drift.

   Kilde: Bilag 1, krav 7.2

10. Bilag 4 / Godkjenningsprøve: Dere har angitt at «Godkjenningskriterier» inkluderer sanntidsintegrasjon mot dns.no og at overføring av kundedata/historikk skal være gjennomført. Kan dere spesifisere hva dere regner som «sanntid» (maks avvik/forsinkelse i minutter) og hvordan dere vil verifisere at «kundedata og historikk» er riktig (inkl. testomfang, datakvalitetssjekker og akseptansekriterier)?

    Hvorfor det er verdt å spørre: Godkjenningsprøve og kriterier påvirker både leveranseplan, risiko og hva som skal testes før aksept.

    Kilde: Bilag 4, «Kundens Godkjenningsprøve»