Telefoniløsning for Ikomm

Anskaffelse av telefoniløsning for Ikomm AS (konkurranse med forhandling). Behovet dekker mobilabonnementer og telefon-/sentralbord-/kontaktsenterfunksjonalitet (kø- og ruting, vaktordninger, SMS som kanal), med vekt på API-/integrasjonsevne, samhandling med Microsoft 365/Teams og driftsstabilitet/sikkerhet. Det er også en opsjon for videreformidling av tjenester til Ikomms eierkommuner. (Kilde: Konkurransegrunnlag, pkt. 1.2 samt Vedlegg 1 og Vedlegg 2)

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

  Dokumentasjon: Norske selskaper: oppdragsgiver henter dokumentasjon via e-bevis/brønnøysund. Utenlandske: godtgjørelse for registrering i foretaks-/faglig register/handelsregister i etableringsstaten.

  Kilde: Konkurransegrunnlag pkt. 4.1
• Leverandøren skal ha tilstrekkelig økonomisk og finansiell kapasitet til å kunne oppfylle kontrakten.

  Dokumentasjon: Kredittvurdering basert på siste kjente regnskapstall (utført av kredittopplysningsvirksomhet med konsesjon). Oppdragsgiver kan innhente ytterligere økonomisk informasjon (årsregnskap inkl. noter, styrets årsberetning, revisjonsberetning). Alternativt annet egnet dokument dersom saklig grunn til ikke å fremlegge krevd dokumentasjon.

  Kilde: Konkurransegrunnlag pkt. 4.2
• Leverandøren skal ha erfaring fra sammenlignbare oppdrag.

  Dokumentasjon: Beskrivelse av inntil 3 mest relevante oppdrag i løpet av de siste 3 årene, inkl. verdi, tidspunkt og mottaker (navn, telefon, e-post). Leverandøren må dokumentere relevans gjennom beskrivelsen; kan også dokumentere via kompetanse/personell uavhengig av hvor erfaringen er opparbeidet.

  Kilde: Konkurransegrunnlag pkt. 4.3
• Krav om miljøsertifisering eller eget styringssystem for klima og miljø.

  Dokumentasjon: Hvis tredjepartssertifisert (miljøfyrtårn, ISO 14001, EMAS eller tilsvarende): sertifikat vedlegges. Hvis ikke sertifisert: leverandørens egne vedtekter/styringsdokumenter for miljøledelse, og dokumentasjon på at disse er vedtatt av styret/ledelsen.

  Kilde: Konkurransegrunnlag pkt. 4.3
• Leverandøren kan støtte seg på andre virksomheters kapasitet (økonomi/teknisk faglig), og må dokumentere rådighet over ressursene.

  Dokumentasjon: Forpliktelseserklæring/tilsvarende som viser at leverandøren råder over nødvendige ressurser (ved støtte etter forskriften). Egne ESPD-skjemaer for relevante underleverandører.

  Kilde: Konkurransegrunnlag pkt. 4.4

• ESPD-skjema skal fylles ut og leveres sammen med tilbudet som foreløpig dokumentasjon på oppfyllelse av kvalifikasjonskrav og at det ikke foreligger avvisningsgrunner.Kilde: Konkurransegrunnlag pkt. 3.1
• Tilbudet skal leveres via KGV (Artifik).Kilde: Konkurransegrunnlag pkt. 8.1
• Tilbudet må inneholde/ha følgende dokumenter utfylt og lastet opp: Tilbudsbrev, leverandørens standard kontraktsvilkår, beskrivelse av tilbudte tjenester, utfylt prisskjema.Kilde: Konkurransegrunnlag pkt. 8.2
• Prisark skal lastes opp som Excel-fil; øvrig dokumentasjon lastes opp som PDF (dersom ikke annet format er spesifisert).Kilde: Konkurransegrunnlag pkt. 8.2
• Tilbydere må bruke elektronisk signatur ved innlevering (f.eks. BankID) for autentisering.Kilde: Konkurransegrunnlag pkt. 8.3
• Leverandøren skal fylle ut og besvare alle punkter i konkurransedokumentene.Kilde: Konkurransegrunnlag pkt. 8.2

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

30.06.2026

Språk

English, norsk

Elektronisk katalog

Ikke tillatt

• Leverandøren skal legge ved sine standard kontraktsvilkår som del av tilbudet.Kilde: Konkurransegrunnlag pkt. 8.2 samt pkt. 6
• Leverandøren skal dokumentere oppfyllelse av absolutte sikkerhetskrav (jf. behovsbeskrivelse pkt. 10).Kilde: Konkurransegrunnlag pkt. 5
• Løsningen skal ha moderne API-er og leverandørene skal beskrive hvordan integrasjoner benyttes; eventuelle begrensninger skal tydeliggjøres.Kilde: Vedlegg 2 Punkt 4
• Tilbudet må ikke inneholde bindingstider; hvis oppsigelsestid er lengre enn tre måneder skal dette fremkomme og kan gi trekk.Kilde: Konkurransegrunnlag pkt. 5

• Konkurransegrunnlaget inneholder ikke i utdraget konkrete lister over de «absolutte sikkerhetskrav» i behovsbeskrivelsens punkt 10 (kun at de finnes og kan medføre avvisning).
• Selve kontraktens SLA/reaksjonstider og konkrete leveranse-/driftsforpliktelser fremgår ikke av utdraget (kun at driftsstabilitet/robusthet og sikkerhet er et behov).
• Kvantifiserte krav til funksjoner (f.eks. eksakte ruting-/køregler, EI/tilgjengelighet, API-omfang) er i stor grad formulert som behov/ønsker i Vedlegg 1/2, ikke som entydige «skal»-krav i teksten som er gitt.

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 behovsbeskrivelsen punkt 10 vises det til at Vedlegg/beskrivelse «absolutte sikkerhetskrav» i behovsbeskrivelsens punkt 10 kan medføre avvisning, men utdraget sier ikke hvilke konkrete krav som gjelder. Kan dere oppgi full liste over de absolutte sikkerhetskravene som medfører avvisning, samt dokumentasjonsformatet dere forventer for å dokumentere oppfyllelse?

   Hvorfor det er verdt å spørre: Leverandøren må kunne kontrollere avvisningsrisiko og utarbeide korrekt dokumentasjon før tilbud.

   Kilde: Behovsbeskrivelse punkt 10 (Absolutte sikkerhetskrav / avvisning) / Konkurransegrunnlag pkt. 5

2. Hvilke konkrete SLA-, responstid- og/eller driftsforpliktelser (reaksjon/istandsetting) er knyttet til «Drift, robusthet og sikkerhet» i denne avtalen, og hvor i konkurransedokumentene er de spesifisert (evt. i kontraktsutkast eller andre vedlegg)?

   Hvorfor det er verdt å spørre: Uten konkrete SLA-er er det vanskelig å prise operasjonell risiko og leveranseomfang riktig.

   Kilde: Behovsbeskrivelse punkt 10 / Kontraktsvilkår (pkt. 1.3), samt omtale av SLA ikke synlig i utdraget

3. I konkurransegrunnlaget pkt. 6.2/6 fremgår at «Kontraktsvilkår» evalueres med trekk ved ubalanserte vilkår/høy risiko, men konkrete risikopunkter i kontrakten fremgår ikke av utdraget. Kan dere dele/peke på hvilke kontraktsvilkår som typisk gir trekk i evalueringen (f.eks. oppsigelsestid/binding, ansvarsbegrensning, mislighold, erstatning, endringsadgang, sikkerhet/pålegg, databehandling, datalagring)?

   Hvorfor det er verdt å spørre: Leverandøren må forstå evalueringslogikken og hvilke vilkår som bør forhandles/tilpasses for å unngå trekk.

   Kilde: Konkurransegrunnlag pkt. 6 (Tildelingskriterier), særlig «Kontraktsvilkår»

4. Behovsbeskrivelsen punkt 5, og konkurransegrunnlaget pkt. 5, sier at avtalen ikke skal inneholde bindingstider og at oppsigelsestid > 3 måneder kan gi trekk. Kan dere bekrefte hva som gjelder for oppsigelsestid/avtalens varighet i kontraktsutkastet (måneders oppsigelse), og om eventuelle minimumsperioder/”lojalitetsplikt” omfattes som bindingstid?

   Hvorfor det er verdt å spørre: Dette påvirker både kontraktsrisiko og evaluering av «Kontraktsbetingelser».

   Kilde: Konkurransegrunnlag pkt. 5 (Absolutte krav / bindingstider og oppsigelsestid)

5. I behovsbeskrivelsen punkt 5 «Personlige abonnementer» oppgis ca. 160 abonnementer, samt ønske om at samme identitet/nummer kan benyttes ved samtaler fra PC/Teams-lignende klient. Kan dere spesifisere hva dere mener med «samtaler fra PC» i denne konkurransen (f.eks. Teams Direct Routing/tilsvarende vs. egen softphone), og hvilke funksjoner som er nødvendige for å anses som oppfylt?

   Hvorfor det er verdt å spørre: Leverandøren må vite riktig integrasjons- og løsningsmodell for å kunne beskrive og prise funksjonaliteten.

   Kilde: Behovsbeskrivelse punkt 5

6. Behovsbeskrivelsen punkt 6 beskriver kø-/rutingfunksjon med ønske om KI/talegjenkjenning og kompetansebasert ruting, samt at multitenant er ønsket. Kan dere avklare hvilke elementer som er «må» vs. «ønskelig» for evalueringen innen «Oppfyllelse av behovsbeskrivelse» (f.eks. skill-based ruting, køoppsett, historikk på tvers av kanaler, ledelsens innsyn)?

   Hvorfor det er verdt å spørre: Dokumentet er prosaorientert og dermed uklart for hvordan behov vektes; leverandøren trenger avklaring for å prioritere løsning og beskrivelse.

   Kilde: Behovsbeskrivelse punkt 6 (Kø- og rutingfunksjon, multitenant, innsyn og historikk) / Konkurransegrunnlag pkt. 6

7. I behovsbeskrivelsen punkt 7 om vakttelefoner og SMS står det at «Behov fra sikkerhet: beholde dagens vaktnummer» og «mulighet til å melde seg inn i vakt-kø fra personlig mobil» samt «krav om alltid en som står påkoblet» og «samtaler ut må vises med vaktnummer». Kan dere oppgi hvilke konkrete vaktnumre som må videreføres (antall og format) og beskrive hva som er akseptert løsning dersom videreføring ikke er mulig teknisk (f.eks. alternativ nummerplan)?

   Hvorfor det er verdt å spørre: Antall/format på numre og akseptable alternativer avgjør både løsning og kostnadsdrivere.

   Kilde: Behovsbeskrivelse punkt 7 (Vakttelefoner / Sikkerhetskrav om vaktnummer og vakt-kø)

8. I behovsbeskrivelsen punkt 7 og 8 beskrives SMS-håndtering (volum 1 000–2 000/mnd) og profesjonell avsenderidentitet ved utgående samtaler (61-nummer/selskapsnummer). Kan dere bekrefte hvilke «fellesnummer/tjenestenummer/alias» vi skal kunne sende SMS fra, og om dere har faste nummer/identiteter som må beholdes?

   Hvorfor det er verdt å spørre: Uten kjennskap til eksisterende nummer-/aliaskrav kan leverandøren få avvik som påvirker oppfyllelse og pris.

   Kilde: Behovsbeskrivelse punkt 7 (SMS) og punkt 8 (avsenderidentitet / Ikomms nummer)

9. Behovsbeskrivelsen punkt 9 sier at åpne API-er er viktig og at API-er dokumenteres i behovsbeskrivelsens punkt 9, men utdraget sier ikke hva som er minimumskrav til API-omfang. Kan dere utdype hvilke API-kategorier dere forventer levert (f.eks. samtalehendelser, køstatus/køhistorikk, SMS-send/receive, brukermanagement, integrasjon mot Microsoft Teams/graph), og hva som er «baseline» dere vurderer opp mot når dere scorer tildelingskriteriet «API, KI og fremtidsrettet løsning»?

   Hvorfor det er verdt å spørre: Konkurransen scorer API/åpenhet; leverandøren trenger konkret minimumsnivå og evalueringsreferanse for å prise og beskrive riktig.

   Kilde: Behovsbeskrivelse punkt 9 (Integrasjoner og samhandling / åpne API-er) og Konkurransegrunnlag pkt. 6 (API, KI og fremtidsrettet løsning)

10. I vedlegg 2 punkt 3 beskrives kontaktsenter- og købehov med skill-based ruting, ca. 50–70 innkommende samtaler daglig og 30–40 ansatte tilknyttet kontaktsenteret (10–15 aktive samtidig). Kan dere bekrefte forventet samtidighet i topp- og høytider (f.eks. maksimum samtidige agenter) og om antall samtaler daglig bør brukes som dimensjonerende grunnlag for kapasitet i tilbudet?

    Hvorfor det er verdt å spørre: Kapasitet påvirker kost og løsning (særlig kø-/ruting og integrasjoner) og må være riktig dimensjonert før tilbudsprising.

    Kilde: Vedlegg 2 punkt 3 (Bakgrunn og nåsituasjon, dimensjonering/antall samtaler og samtidighet)