Billettsystem til DNS

Den Nationale Scene (DNS) skal anskaffe et billettsystem som dekker netthandel, billett-/kundeadministrasjon, integrasjon mot dns.no og andre systemer, migrering av data, og løpende drift/vedlikehold/support. Anskaffelsen gjennomføres som konkurranse med forhandling etter forutgående kunngjøring (FOA del I og III) med kvalifiseringsfase og tilbudsfase via EU-Supply KGV. Kontraktsvilkår: SSA-lille sky 2026 (skytjeneste/hosting) med bilag, inkl. databehandleravtale, kravspesifikasjon og pris-/prismatrise.

• Leverandøren skal være registrert i foretaksregister/faglig register/handelsregister i staten den er etablert.

  Dokumentasjon: Firmaattest (norske selskaper) / dokumentasjon for registrering (utenlandske selskaper).

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

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

  Kilde: Konkurransegrunnlag, pkt. 8.4 Krav til økonomisk og finansiell stilling
• Leverandøren skal ha god erfaring fra leveranse av sammenlignbare billettsystemer (de 3 siste årene).

  Dokumentasjon: Beskrivelse av relevante oppdrag (prosjektnavn, oppdragsgiver, totalkostnad og lengde, leverandørens rolle, omfang i timer, tidspunkt for leveransen og leveranseomfang), dokumentert pr. referanse i Del I vedlegg 5 Referanseskjema. Relevans skal dokumenteres.

  Kilde: Konkurransegrunnlag, pkt. 8.5 Krav til tekniske og faglige kvalifikasjoner
• Leverandøren skal ha gode rutiner for kvalitetsstyring.

  Dokumentasjon: Enten rutinebeskrivelse for kvalitetssikring/ressursstyring/leders ansvar/forbedring, eller ISO 9001-sertifikat eller tilsvarende.

  Kilde: Konkurransegrunnlag, pkt. 8.6 Krav til kvalitetsstyringssystem
• Dersom tilbyder støtter seg på underleverandører/samarbeidspartnere for kvalifikasjonskrav (økonomi/finans og/eller teknisk/faglig), skal nødvendig dokumentasjon for disse leveres.

  Dokumentasjon: Forpliktelseserklæring/samarbeidsavtale signert, dokumentasjon fra underleverandør for de kvalifikasjonskrav det støttes på (inkl. ESPD for underleverandører). ESPD leveres i KGV.

  Kilde: Konkurransegrunnlag, pkt. 8.7 Bruk av underleverandører/samarbeidspartnere
• ESPD som foreløpig dokumentasjon på oppfyllelse av kvalifikasjonskrav og fravær av avvisningsgrunner (inkl. nasjonale avvisningsgrunner iht. anskaffelsesforskriften § 24-2).

  Dokumentasjon: Utfylt ESPD i KGV (hovedleverandør og evt. underleverandører).

  Kilde: Konkurransegrunnlag, pkt. 8.2 Det europeiske egenerklæringsskjemaet (ESPD)

• Forespørsel om deltakelse skal leveres i KGV innen fristen. Forespørselen skal bestå av: Forespørselsbrev med forpliktende signatur; dokumentasjon på oppfyllelse av kvalifikasjonskrav; forpliktelseserklæring ved støtte til underleverandører; dokumentasjon for underleverandører der relevant; ESPD for hovedleverandør og evt. underleverandører; egenerklæring om taushetsplikt.Kilde: Konkurransegrunnlag, pkt. 7 Innlevering av forespørsel om deltakelse
• Tilbud i fase 2 skal leveres elektronisk i KGV innen tilbudsfrist (absolutt frist). For sent innkomne tilbud avvises. Det er ikke krav om elektronisk signatur; verifikasjon ved signering/skanning/last opp av tilbudsbrev.Kilde: Konkurransegrunnlag, pkt. 10.1 Innlevering av tilbud
• Tilbudet skal minst inneholde: Tilbudsbrev med forpliktende signatur (Del I vedlegg 1); Egenerklæring taushetsplikt (Del I vedlegg 3); Tilbyders avvik (Del I vedlegg 4) ved avvik; Kravspesifikasjon besvart (Del II bilag 1); Prismatrise (Del II bilag 7a); Utfylt Bilag 2 (leverandørens beskrivelse av Skytjenestene og Tilleggstjenester); Utfylt bilag 11 databehandleravtale eller egen databehandleravtale (Del II bilag 11).Kilde: Konkurransegrunnlag, 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

• Kontrakten inneholder krav til lønns- og arbeidsvilkår.Kilde: Konkurransegrunnlag, pkt. 5 Særlige kontraktsvilkår (5.1) og Bilag 6 pkt. 5.5
• Avtaleperiode: løpende tjenesteavtale til oppsigelse; 1 år fra undertegning, deretter automatisk fornyelse 1 år om gangen; oppsigelsestid 3 mnd (Kunden) og 6 mnd (Leverandøren) før fornyelse.Kilde: Konkurransegrunnlag, pkt. 3.3 Avtaleperiode
• Skatteattest: valgt leverandør skal på forespørsel levere skatteattest for merverdiavgift og skatt (kun for norske leverandører), ikke eldre enn 6 måneder fra tilbudsfrist.Kilde: Konkurransegrunnlag, pkt. 4.14 Skatteattest
• Kunden skal integrere/benytte løsningen på dns.no; leverandøren er ansvarlig for å tilgjengeliggjøre skytjenester fra avtalt tidspunkt og bistå med Kundens godkjenningsprøve (integrasjon og funksjon).Kilde: SSA-lille sky 2026 (generell avtaletekst), punkt om Tilgjengeliggjøring av Skytjenestene og Kundens Godkjenningsprøve (bl.a. 2.2 og 2.4 i avtalens TOC)
• Databehandleravtale: databehandleravtale skal inngås før behandling av personopplysninger starter, og databehandleravtale(r) skal fremgå av bilag 11.Kilde: SSA-lille sky 2026 (generell avtaletekst), punkt 7.2 og bilag 11 / Konkurransegrunnlag pkt. 10.2.2 (databehandleravtale som del av tilbud)
• Tjenester/kontraktsvilkår: SSA-lille sky 2026 med bilag, inkludert standardvilkår for skytjenester (bilag 10).Kilde: Konkurransegrunnlag, pkt. 3.2 Kontraktstype og omfang

• Kravspesifikasjonen i Del 2/Bilag 1 er delvis gjengitt i teksten; ikke alle kravpunkter (1.6 og utover, samt videre i tabellen) er tilgjengelige her.
• Tildelingskriterienes referanser til konkrete C-krav (f.eks. «15%» i Implementering-delen) er gjengitt uten tydelig mapping til eksakte kravnummer i utdraget; fullstendig kravtabell er ikke med.
• Prismodell-valg for evaluering (lineær/hybrid/hybrids knekkpunkt) er delvis angitt i teksten, men kun én modell ser ut til å være valgt; detaljer kan kreve resten av dokumentet.

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. I Bilag 1 krav 1.6 (billettkontroll ved innslipp) bes vi beskrive tekniske løsninger «per i dag» samt utviklingsmuligheter. Kan dere spesifisere dagens innløsnings-/scanningsløsning(er) og hvilke innslippskanaler DNS bruker (f.eks. fast vakt, mobil scanning, spesifikke enheter/leverandører), slik at vi kan beskrive korrekt utviklingsvei og kompatibilitet?

   Hvorfor det er verdt å spørre: Kravet gjelder både nåsituasjon og fremtidige muligheter. Uten tydelig referanse til dagens løsning blir det vanskelig å gi et presist tilbud som også tåler evaluering og senere avtalespesifikasjon.

   Kilde: Del 2 / Bilag 1, krav 1.6 Innslipp og billettkontroll

2. I Bilag 1 krav 2.1 (integrasjon av kjøpsflyt mot dns.no) ber dere om at vi bekrefter hvilke integrasjonsmetoder som tilbys (API, integrert kjøpsflyt, iframe eller annen dokumentert metode). Hvilke av disse integrasjonsmetodene er teknisk akseptert/foretrukket for dns.no i DNS’ nåværende oppsett (WordPress), og er det begrensninger vi må ta hensyn til (f.eks. krav til API-autentisering, cookie/consent, eller teknisk ramme for checkout)?

   Hvorfor det er verdt å spørre: Integrasjonsmåten påvirker både løsning, kost og risiko (GDPR/cookies, drift, endringer). Leverandør må forstå DNS’ faktiske forutsetninger for å prise riktig og unngå avvik.

   Kilde: Del 2 / Bilag 1, krav 2.1 Netthandel og kjøpsprosess

3. I Bilag 1 krav 2.4 ber dere beskrive ønsket betalingsflyt «direkte mellom billettsystem og Den Nationale Scene, uten bruk av tredjepart». Hva mener dere konkret med «uten tredjepart» her: (a) ingen betalings-/innløserleverandører, (b) ingen tredjepart for selve ordre-/oppgjørshåndteringen, eller (c) at dere ikke ønsker en bestemt type mellomledd? Kan dere beskrive hvilke betalings-/innløsningstjenester som uansett må benyttes (f.eks. Vipps/acquirer) og hvilke deler som kan være direkte?

   Hvorfor det er verdt å spørre: Uklart tolkingsrom for betalingsflyt kan gi stor pris- og risikoforskjell. Leverandør må vite hva som faktisk er forventet for å levere korrekt løsning og unngå å tilby noe som evalueres som avvik.

   Kilde: Del 2 / Bilag 1, krav 2.4 Betalingsløsninger (beskrivelse og betalingsflyt)

4. I Bilag 1 krav 3.1 og 3.2 (backoffice-administrasjon av forestillinger, priser/rabatter og salkart/prissoner) ber dere at dette ikke krever særskilt utvikling, og samtidig beskriver vi fleksibilitet for flere samtidige spillesteder. Hvor mange spillesteder skal systemet støtte «samtidig», og finnes det forventede størrelser på salkart (antall sone-/priskombinasjoner og typisk antall seter) som vi bør bruke som grunnlag i løsningen vår og i ressurs-/implementeringsestimat?

   Hvorfor det er verdt å spørre: Tildelings- og prissettingsevne avhenger av kompleksiteten. Manglende volum-/kompleksitetsindikator kan føre til feilprising av konfigurering/tilpasning som kravene indikerer skal håndteres «uten særskilt utvikling».

   Kilde: Del 2 / Bilag 1, krav 3.1 og 3.2 Billettstruktur, salkart og backoffice

5. I Bilag 1 krav 4.1–4.2 (reservasjoner/allokasjoner og gruppesalg) ber dere at DNS kan opprette, endre og avslutte reservasjoner/allokasjoner i backoffice, inkludert frister, prisgrupper og samlet/individuelt uttak. Hvilke konkrete regler må støttes for «allokasjoner» (f.eks. automatisk frigivelse ved deadline, maks antall billetter per kunde/gruppe, venteliste/overbooking, og om endringer kan skje etter at uttak er gjort)? Kan dere gi 1–2 typiske scenarier dere forventer at leverandøren løser?

   Hvorfor det er verdt å spørre: Dette er et funksjonskrav som påvirker både design og implementeringsarbeid. Ved å få konkrete scenarier kan leverandør beskrive riktig funksjonalitet og begrense risiko for uforutsette avvik ved godkjenningsprøven.

   Kilde: Del 2 / Bilag 1, krav 4.1 og 4.2 Reservasjoner, allokasjoner og gruppesalg

6. I Bilag 1 krav 7.1 (uttak/segmenter/rapporter) og krav 7.2 (fleksibel rapportering, automatiske utsendelser, eksportformater og integrasjoner) står det at listen ikke er uttømmende og at nye variasjoner må kunne settes opp. Hvilke 5–10 rapporter/segmenter anser dere som mest kritiske å få riktig fra oppstart (inkludert forventet hyppighet: dag/uke/måned, samt om dette må kunne gjøres selvbetjent av ansatte i backoffice)?

   Hvorfor det er verdt å spørre: Evalueringen vektlegger C-krav og leverandørens beskrivelse av fleksibilitet. Å avklare hvilke rapporter som er mest verdifulle gir bedre dokumentasjon i tilbudet og sikrere implementeringsplan.

   Kilde: Del 2 / Bilag 1, krav 7.1 Segmentering, uttrekk, rapportering og analyse og krav 7.2 Leverandør bes beskrive

7. I Bilag 1 krav 8.1 (sanntid/«kontinuerlig» eksport eller ved behov) og krav 8.3 (API-er, datastruktur, synkronisering, oppdateringsfrekvens, feilhåndtering og duplikater) ber dere om sanntids-/kontinuerlig eksport. Kan dere angi forventet oppdateringsfrekvens for de viktigste datasettene (f.eks. beholdning/ledige plasser, salgsstatus, priskategorier/priser, kundedata og kjøpsstatus) og hvilke integrasjoner som må være «i sanntid» vs «batch ved behov»?

   Hvorfor det er verdt å spørre: Oppdateringsfrekvens og feilhåndtering påvirker arkitektur, kost og SLA. Leverandør må vite hva som faktisk skal kalles sanntid for å gi korrekt løsning og pris.

   Kilde: Del 2 / Bilag 1, krav 8.1 og 8.3 Integrasjoner og dataflyt

8. I Bilag 1 krav 9.2 (økonomisk håndtering, dagsoppgjør/ukeoppgjør og integrasjon mot Visma NXT) ber dere om beskrivelse av løsning. Hvilken integrasjonsmetode forventer dere mot Visma NXT (f.eks. filimport CSV/XML, API, elektronisk dokumentflyt), og hvilke konkrete dataobjekter må integreres (ordrelinjer, betalinger, refusjoner/avbrutt kjøp, kampanjekoder, merverdiavgift pr. art)?

   Hvorfor det er verdt å spørre: Økonomi-integrasjoner kan variere betydelig og gir ulik risiko for korrekt oppgjørslogikk og rapportering. Klargjøring sikrer at tilbudet dekker forventet dybde og ikke undervurderer integrasjonsarbeidet.

   Kilde: Del 2 / Bilag 1, krav 9.2 Økonomi

9. I Bilag 1 krav 11.1 (migrering og implementering) ber dere om beskrivelse av hvordan data migreres og hvordan implementering gjennomføres, samt mulighet for testmiljø før live. Kan dere spesifisere hvilke datasett som inngår i migreringen (f.eks. kundedata/kundekort, historikk for kjøp, samtykker, billetttyper/priser/konfig, salkart-kapasitet, gavekort/tilgodelapper historikk) og ca. volum (antall kunder/kjøp/ordrelinjer, størrelse på historikk dere ønsker med)?

   Hvorfor det er verdt å spørre: Migrering er en av de største risikopostene. Volum og datatyper avgjør innsats, testoppsett og tidsplan for godkjenningsprøven, og dermed også pris og leveranseplan.

   Kilde: Del 2 / Bilag 1, krav 11.1 Migrering og implementering

10. I Bilag 1 krav 12.2 (supportordning og evt. telefonsupport i 6 uker i sommerferien) står det at det er positiv uttelling dersom dette tilbys innenfor normal arbeidstid og estimert antall solgte billetter er 50 i perioden. Bekrefter dere at evalueringen legger vekt på direkte «tillegg for support i sommerferien» kun dersom dere tilbyr telefoni og salg over telefon som en del av supportordningen? Og kan dere opplyse om forventet varighet per henvendelse og kanalprioritet (telefon vs e-post/SMS) for å gjøre det mulig å prise bemanning riktig?

    Hvorfor det er verdt å spørre: Tilleggstjenester kan bli priset ulikt uten tydelig definisjon av tjenestenivå/bruksmønster. Avklaring reduserer risiko for misforståelser og gjør det enklere å gi konkurransedyktig og riktig tilbud.

    Kilde: Del 2 / Bilag 1, krav 12.2 Drift, support og utvikling (sommerferiestøtte)