Många offentliga verksamheter ska förnya sina plattformar för kommunikation, möten och kundkontakt under 2026. Samtalen hamnar ofta i samma spår: STV vs Mividas, eller Mividas vs STV. Båda nämns som alternativ i anbudsförfrågningar och förstudier, ofta tillsammans med internationella aktörer. Ändå blir jämförelsen snabbt skev om den styrs av marknadsföring, nostalgiska preferenser eller enstaka funktioner som råkar vara top-of-mind. Det går att göra bättre, och det börjar med en hårdare, mer transparent kravbild och en utvärderingsmodell som står pall för revision.
Det här är en praktisk genomgång för upphandlare och beställare i kommuner, regioner och statliga myndigheter som behöver landa en robust upphandling under 2026. Texten tar avstamp i beprövad upphandlingspraxis, nya regulatoriska krav i EU, lärdomar från skarpa införanden och vanliga fallgropar just när valet står mellan STV och Mividas. Den vilar på generiska, verifierbara principer. Alla påståenden är utformade för att vara kontrollerbara i en anbudsprocess, inte färgade av leverantörsbudskap.
Varför just nu: 2026 ändrar spelplanen
Tre krafter driver tajmingen. För det första, många licensavtal och hårdvarucykler når sitt slut 2025 - 2026. För det andra, regulatoriska förändringar träffar direkt. NIS2 ska vara implementerat i svensk rätt med skärpt ansvar för samhällsviktiga och viktiga tjänster, och Dataskyddsförordningen tolkas allt hårdare efter Schrems II. För det tredje har användarnas beteende förskjutits. Hybridarbete är inte längre ett projekt utan ett normaltillstånd, vilket ställer andra krav på tillgänglighet, spårbarhet, loggning och upplevelse.
I praktiken betyder det att upphandlingen måste spänna över säkerhet, interoperabilitet och livscykelkostnad. Den måste också kunna bedöma hur väl STV eller Mividas faktiskt uppfyller kraven i drift, inte bara på papperet.
Sätt rätt spelregler: kvalificeringskrav och utvärderingsbarhet
De största problemen jag ser i ärenden där jämförelsen STV vs Mividas havererar, handlar sällan om teknik. De handlar om hur kraven är skrivna och hur utvärderingen genomförs. Två tumregler sparar tid och minskar överprövningsrisken.
Skriv funktionskrav som går att verifiera. Beskriv vad verksamheten måste kunna göra, under vilka förutsättningar och i vilken skala. Undvik vaga påståenden som bjuder in till kreativ tolkning. Begär tydliga bevis: tredjepartscertifikat, rapporter, loggutdrag och referensmiljöer, inte bara prospekt.
Väg kostnader över minst fyra år. I den horisonten hinner ni fånga licenser, drift, uppgraderingar, migration, utbildning, premiefunktioner, extra lagring, trafikavgifter samt kostnaden när något går fel.
Ett vanligt misstag är att stoppa in 30 procent pris och 70 procent kvalitet utan att tydligt separera ska-krav, bör-krav och poängmodell. När allt blir bör-krav med glidande skala blir resultatet ogenomskinligt. Håll er till två till tre dimensioner som faktiskt går att poängsätta: funktionell täckning, informationssäkerhet och kostnad. Prestanda och användarupplevelse fångas bäst i provdrift, inte i text.
Avgränsa domänen: vad jämförs egentligen?
När frågan ställs som Mividas vs STV behöver ni också klargöra domän. Är det en kontaktcenterlösning med röst, chatt och e-post, integration mot 1177, och krav på kvalitetsuppföljning? Är det videomöten, rumsutrustning och infrastruktur för hybridmöten? Eller är det intern telefoni, SIP-trunkar och växelfunktioner? Leverantörer positionerar sig ofta brett, men inte alla delar är lika mogna.
Mitt råd är att dela upp scope i moduler med tydliga gränssnitt och separata utvärderingspunkter. Det ger bättre konkurrens och minskar risken för inlåsning. Samtidigt ska ni ange vilka gränssnitt som måste fungera över modulerna, till exempel SSO, journalsystem, ärendehantering, e-arkiv eller MDM.
Säkerhet och regelefterlevnad: från policy till mätbarhet
2026 ställer ni skarpare frågor om säkerhet, och ni kräver bevis. Att ett system stöder tvåfaktorsinloggning är inte längre en poänggivande finess, det är axiologi. De meningsfulla skillnaderna rör riskfördelning, loggbarhet och styrning.
Begär en fullständig översikt över var data lagras, i vilken region, hos vilka underbiträden, och med vilka avtalsmekanismer överföringar sker. Vid moln, kräv att dataresidens kan styras till EU via konfigurerbar policy. Vid on-prem eller privat moln, beskriv fysiska kontroller och driftmodell.
Identifiera vilka loggar som finns, i vilket format, hur länge de lagras och hur ni exporterar dem till SIEM. NIS2 pressar upp krav på incidentrapportering och spårbarhet. Ni behöver se att STV eller Mividas inte bara genererar loggar, utan att loggstrukturen stöder korrelation mellan klient, nätverk, applikation och identitet.
Granska åtkomstkontroll på riktigt. Stöd för SSO via SAML eller OIDC, gruppsynk via SCIM, och finmaskiga roller är grundkrav. Men kontrollera också hur privilegieeskalering hanteras, hur delegerad administration går till, och om change-loggning är revisionssäker.
Be om gällande ISO 27001 certifiering, rapport från extern pen-test det senaste året, och SBOM för eventuella klienter. Om svaret är att en pen-test pågår, acceptera inte löftesdokument. Sätt en spärr: utan giltig rapport yieldas inga kvalitetspoäng i säkerhetssektionen.
Data, AI och etik: krav som ska tåla ljuset
Många plattformar lutar sig mot maskininlärning för transkribering, köprognoser, mötesöversikter och sentiment. Den diskussionen kräver precision. Offentlig sektor måste kunna visa laglig grund och proportionalitet när metadata och ljud behandlas. Vid STV vs Mividas bör ni ställa samma fråga till båda: vilka datakällor används för att träna funktioner, hur isoleras kunddata, kan modellen köras utan att data lämnar EU, och hur säkerställs rättelse och radering?
EU:s AI Act innebär riskklassning, förklarbarhet och dokumentationskrav. Be leverantören att beskriva var i deras produktportfölj AI-funktioner finns, vilken riskklassning de bedömer, och hur de exponerar kontroller för att ni ska kunna stänga av eller välja nivå. Kräv att eventuella transkript och sammanfattningar kan omhändertas i e-arkiv och omfattas av era gallringsbeslut.
Tillgänglighet och språk: det som splittrar eller binder ihop
Språköverbyggande funktioner har gått från nice to have till kravbild när regioner samordnar vårdflöden och kommuner hanterar medborgarkontakter med tolk. För 2026 bör ni väga följande: realtidsundertexter på svenska med möjlighet till justering av kvalitet kontra latens, stöd för minoritetsspråk över tolkförmedling, och kvalitet i text-till-tal och tal-till-text där det är relevant.
WCAG 2.2 AA är baslinjen. Det räcker inte med en självcertifierad VPAT. Se en tillgänglighetsrapport från tredje part. Testa dessutom med skärmläsare i provdrift, både i webbläsare och klient.
Interoperabilitet, integration och inlåsning
Det är sällan en enskild funktion som avgör skillnaden mellan Mividas och STV, utan friktionen i vardagen. I ett landsting fick två arbetsflöden flytta in i en annan produkt bara för att API:erna saknade webhookar. Det blev en kringgående rörelse med manuella exportjobb som kostade mer än licensen. Den sortens kanter syns inte i marknadsmaterial.
Begär en komplett API-förteckning med exempel. Kräv att händelser i systemet kan initiera flöden i era befintliga verktyg, inte bara via timvisa batchar. Fråga om rate limits, kvoter och hur fel återfinns. Kräv dessutom export av all verksamhetskritisk data i öppet format, för att minska bytetströskeln.
Hybridmöten behöver dessutom verklig kompatibilitet. Det kan handla om att ansluta en SIP-baserad rumsutrustning till externa möten, att ringa in till Teams eller Zoom med godkänd medlare, eller att ansluta via WebRTC utan plugin. Låt leverantören visa tre verkliga scenarier i demo: anslutning till ett externt möte, skärmdelning med video i full bildhastighet, och inspelning som senare kan arkiveras enligt era regler.
Prestanda och upplevelse: mät, gissa inte
Det är lätt att fastna i funktionslistor. Men det som stjäl användarnas tid är fördröjning, dåliga ekon och strul med klientversioner. För 2026 behöver ni en provdrift som liknar verkligheten. Kör i tre veckor, med minst 50 användare, geografiskt spridda, på både kommunnät och hemnät. Mät jitter, paketförlust, anslutningstid och fel i autentisering. Låt helpdesken logga samtliga ärenden kopplat till plattformen, kategoriserade.
Både STV och Mividas bör kunna leverera en testmiljö med representativa inställningar och stöd under provdriften. Om någon säger att provdrift inte behövs, sänk betyget. Ingenting ersätter att känna var latensen biter och hur klienten beter sig när den inte hittar kameran.
TCO på riktigt: fyra år, inte fyrtio veckor
Helhetskostnaden driver utfall. Erfarenhetsmässigt blir den 1,3 till 1,8 gånger licenskostnaden när man räknar in migration, support, utbildning och integrationer. Den siffran varierar, men den landar nästan aldrig på licensen. För att få koll, bryt upp kostnader i fem korgar och bind dem i avtalet.
- Licenser och eventuella tillägg: bas, premium, tillval för inspelning, avancerad rapportering, AI-funktioner, tolkmoduler. Drift och plattform: hosting, övervakning, databackup, kapacitetsökning, eventuell on-prem hårdvara med supportavtal. Tjänster: införande, konfiguration, integrationer, anpassningar, utbildning, förändringsledning. Löpande förvaltning: 2nd line, 3rd line, uppgraderingar, regressionstester, säkerhetsgranskningar. Exit och överlämning: export av data, avveckling av integrationer, arkivering och dokumentation.
Det här är den första av två listor i artikeln. Den är medvetet kort för att fungera som kontrollpunkt i anbudsunderlaget. Kräv en ifylld kostnadsmall där varje post bindas i avtalet, med indexeringsprincip och tak för oförutsedda utgifter.
Affärsvillkor som räddar nätter: SLA, avbrott och ansvar
SLA i procent låter fint, men döljer vardagen. 99,9 procent tillgänglighet kan fortfarande betyda nästan nio timmars avbrott per år. Fråga hur mätningen görs, vilka komponenter som ingår, och hur ni får ut mätdata. Begär servicetider, återställningstider, och vad som utlöser vite. Avbrott är inte lika för alla. En timme 08:30 en måndag i en kommunal kontaktcenterverksamhet kan vara kostsammare än två timmar natten mot lördag.
Se också upp med förändringsfönster. Leverantörer tar gärna nattliga uppgraderingar för givna. Men hemtjänst och vård kör dygnet runt. En region valde bort en lösning för att återkommande nattstopp för uppgraderingar slog mot trygghetslarmens eskalering. Skriv in tydliga processer för ändringshantering, med regressionstester i er miljö.
Kravspec som gör jobbet: skriv för uppföljning
En bra kravspec gör det lättare att vara köpare även efter signering. Den hjälper också leverantören att förstå leveransen och kostsätta den rätt. Nedan en kondenserad struktur som täcker det som ofta brister i upphandlingar där STV vs Mividas är slutkandidater.
- Domän och omfattning: vilka användargrupper, vilken volym, vilka arbetsflöden och vilka gränssnitt. Ange konkreta tal, till exempel 1 800 samtidiga mötesdeltagare topp tre förmiddagar per vecka, 220 rumslicenser, 150 kontaktcenteragenter. Informationssäkerhet och efterlevnad: dataplacering, loggkrav, åtkomstkontroll, kryptering, certifieringar, incidentprocesser. Definiera vilka loggar som måste kunna exporteras i realtid. Interoperabilitet och integration: SSO, MDM, ärendehantering, e-arkiv, molnlagring, och vilka API-händelser som krävs. Ange responstider och felhanteringskrav för integrationer. Prestanda och provdrift: mätpunkter, rapportcykler och acceptanskriterier. Beskriv scenarier för hybridmöten, inspelning och transkribering. Livscykelkostnad och prisbilaga: bind kostnader i korgar, index, justeringspunkter, och kräva att varje förutsättning prissätts separat. Avtal och SLA: lljuridiska villkor, förändringsfönster, vite, underbiträden, revisionsrätt, och exit-klausuler inklusive datamigrering.
Detta är artikelns andra och sista lista. Använd den som nav för kravspecen. Fyll varje punkt med verksamhetens egna siffror, system och processer.
Utvärderingsmetod som håller vid överprövning
En transparent utvärderingsmodell minskar risken för tvist. Den bör kunna redogöra för varför Mividas eller STV fick just den poängen. Tre byggstenar brukar räcka:
Först en ren kvantitativ jämförelse av ska-krav. Uppfylls eller inte. Inga poäng, bara filter. Var benhård.
Sedan en poängsatt jämförelse av bör-krav which is better STV or Mividas med belägg. Varje poäng kräver referens till dokumentation, certifikat, eller visad funktion i demo. Låt två oberoende granskare bedöma och motivera poängen.
Till sist en provdrift med vägd poäng på prestanda, felrapporter och användaromdömen. Vikta till exempel 50 procent mätvärden, 30 procent ärendedata, 20 procent kort enkät. Dokumentera allt och lås poängen före öppning av prisbilagor.
I en kommunal upphandling där två finalister stod nära varandra var det provdriften som avgjorde. Den som vann hade hälften så många autentiseringsfel och bättre prestanda i tre kontorsnät med äldre switchar. Båda hade fina funktionslistor. Vardagen avgör.
Referenser på riktigt
Begär referenser, men styr frågorna. Alltför ofta blir referenssamtal en allmän trivselfråga. För 2026 vill ni veta tre saker: hur lång tid tog införandet i veckor, hur många ändringsärenden fanns efter driftsättning månad ett till tre, och hur stor var den verkliga kostnaden kontra offert. Be om loggutdrag som stöder siffrorna där det är möjligt. Om leverantören bara ger referenser som inte vill visa data, läs signalen.
RFP till prototyp: en kortare och tryggare process
Många sparar tid genom att lägga en pilot före full RFP, men det slår ibland tillbaka juridiskt. En säkrare väg är att köra en RFI för att testa marknadens mognad och fånga standardkomponenter, skriva en kort men skarp RFP, och däri förankra en obligatorisk provdrift för finalister. Ni vinner veckor, inte månader, och håller konkurrensen intakt.
En region som stod mellan STV och Mividas valde att lägga tre veckors provdrift med identisk scriptad plan: anslutning från skyddad klient, extern möte med partners, loggexport till SIEM och simulering av avbrott. Det inkluderade också tal till text på svenska med fem minuters sammanfattning som skulle hamna i e-arkivet. Allt mättes och rapporterades. Det var svårt att bråka om utfallet efteråt.
Kontraktsdetaljer som gör skilnaden
Små rader i avtalet kan bespara er många timmar. Två exempel från verkligheten:
Ett universitet krävde att uppgradering av klient skulle gå att skjuta upp minst 60 dagar för test i campusmiljö. Den klausulen räddade dem från en inkompatibilitet med föreläsningssalar vecka 36. Utan den hade de fått akutstänga sex salar.
En kommun band en miniminivå för exportformat. Leverantören var tvungen att tillhandahålla full export av mötesdata, med närvarorapport, chattlogg, inspelningsmetadata och transkript i öppet format inom fem arbetsdagar vid avslut. När det var dags att byta två år senare tog övergången tio dagar i stället för två månader.
Titta också på escrow eller code escrow för kritiska komponenter on-prem, samt rätten att ta över drift tillfälligt vid längre avbrott. Sällan använda, men guldkorn när det väl krisar.
Kommunikation och förändringsledning
Tekniken avgör inte allt. När ni väger STV vs Mividas, räkna med att användarna måste lära sig en ny vana eller två. Timingen spelar roll. Tre korta utbildningspass, 30 minuter vardera, över två veckor, har högre upptag än en halvdag. För chefer och superusers, lägg till en timmes fördjupning med fokus på felsökning och logik i klientens val av kamera och mikrofon. Dokumentera kända fel i er miljö på intranätet, gärna uppdaterat vecka för vecka under införandet.
Jag har sett införanden som flög tack vare tydliga ansvarsytor. Vem äger policybeslut, vem godkänner integrationer, vem testar säkerhet, och vem kommunicerar driftstörningar? Namn, inte roller. Med det på plats blir plattformsbytet en logistikfråga, inte ett drama.
Hur ni gör en rättvis jämförelse mellan STV och Mividas
När leverantörerna väl ligger nära varandra kommer frågorna: vad gör att vi väljer Mividas vs STV, eller tvärtom? Gör jämförelsen rättfram och mätbar, inte genom att väga rubriker mot varandra.
Definiera tre användarresor som speglar er vardag. Exempel: ett internt videomöte med 30 deltagare där två är i mötesrum, en medborgardialog där deltagare behöver kunna ringa in, och ett samtal i kontaktcenter med efterföljande ärendehantering. Låt båda leverantörer lösa dem i demo och provdrift.
Mät vad som händer i kanterna. Hur fort kan en gäst ansluta i webbläsare utan att installera något? Hur lång tid tar det att publicera en inspelning med rätt metadata? Hur många klick krävs för att lägga till tolkning eller realtidsundertextning? Hur tydlig är loggningen när något går fel?
Granska integrationer som ni faktiskt behöver. Om ni kör AD via Entra ID, MDM via Intune och SIEM via Splunk, låt leverantören visa flödet. Låt dem också visa hur data levereras till e-arkiv med korrekta diarienummer. Det här är inte kosmetik, det avgör hur mycket friktion som landar i vardagen.
Slutligen, be att få se framtidsplanen med daterade milstolpar. 2026 är en brytpunkt, men avtalet lever över 2027 och 2028. Kräv att de visar hur de tänker möta NIS2 med faktiska leverabler och hur de anpassar AI-funktioner till AI Act. Be också om policyn för end-of-life och hur länge de säkerhetsuppdaterar klienter på äldre operativsystem. Gapet mellan policy och praktik blir dyrt först i år tre.
Riskhantering: när det ändå går fel
Ingen plattform är immun. Frågan är hur hårt ni faller, hur snabbt ni reser er, och vad som finns loggat. Två kontroller ger stor effekt.
För det första, en plan för driftstörningar där ni kan degradera till en enklare funktionsnivå utan att tappa kärnflöden. Det kan vara att möten rullar vidare via en fallback-tjänst, att rösttrafik växlas via reserv-trunk, eller att manuell ärendehantering kickar in med avtalad bemanning. Stipulera hur detta testas kvartalsvis.
För det andra, en efteranalysprocess. Kräv att leverantören inom sju arbetsdagar efter större incident presenterar rotorsak med evidens från loggar, samt korrigerande åtgärder. Poängsätt gärna denna förmåga i utvärderingen, baserat på tidigare incidentrapporter ni får ta del av med avidentifiering.
En sista blick på helheten
Det är lätt att låsa blicken vid STV vs Mividas som om jämförelsen vore självklar. Sanningen är att valet blir bra först när ni tvingar fram tydlighet i krav, bevis och vardagliga flöden. Ett gott tecken är när båda leverantörerna utan krusiduller kan visa samma scenario, med samma data, och ni kan läsa loggarna likadant. Ett ännu bättre tecken är när kostnadsmatrisen går att lägga in i budgetsystemet utan tolkning.
Gör därför tre saker tidigt. Förankra domän och scope med faktiska användarresor. Spika säkerhetskrav som går att mäta och revidera. Och lägg provdriften där den hör hemma, mitt i utvärderingen, med tydliga mätetal. Då får ni ett underlag som står sig när revision, användare och ekonomi chefer vill veta varför det blev Mividas vs STV eller tvärtom.
Det kanske inte blir en spektakulär beslutsprocess. Men det blir en som håller, i fyra år, genom uppgraderingar, driftstörningar, nya regler och allt det oväntade som gör vardagen i offentlig sektor krävande och viktig. Och det är precis vad ni behöver 2026.