E-handelsplattform för er portal och affärssystem

Portalens första version är lanserad. Kunderna kan logga in, se produkter och lägga order. Ändå fortsätter säljarna att mejla prislistor, bekräfta avtal och svara på frågor om orderstatus som redan borde gå att se i portalen. Kundservice hanterar returer vid sidan av systemet, och varje avvikelse i offertflödet leder tillbaka till manuell handpåläggning. Då ligger problemet sällan i gränssnittet. Det ligger i hur affären är modellerad, hur information rör sig mellan systemen och hur portalen speglar verksamhetens verkliga regler.

Många jämförelser av e-handelsplattformar börjar i fel ände. De väger mallar, lanseringstakt och visuella funktioner tyngst, trots att de mest avgörande frågorna ofta handlar om prislogik, åtkomst, produktinformation, affärssystem och ansvar över tid. För er som ska välja plattform för en portal eller handelslösning blir därför det viktigaste beslutsunderlaget sällan en demo. Det är hur väl lösningen klarar verkliga arbetssätt när flera bolag, kundavtal, sortiment och orderflöden ska fungera tillsammans.

När priset finns i flera versioner samtidigt

Ett vanligt tecken på att portalen inte bär affären fullt ut är att priset lever sitt eget liv utanför systemet. En kund ser ett pris i portalen, säljaren har ett annat i sin fil och affärssystemet innehåller en tredje version som gäller från ett visst datum eller för en viss kontaktperson. Sådana skillnader uppstår när priset behandlas som ett innehållsproblem i webbskiktet, trots att det i praktiken är en affärsregel med flera beroenden.

Samma sak gäller vem hos kunden som får göra vad. I många verksamheter finns en kontaktperson som får beställa fritt, en annan som får se sortimentet men måste skicka förfrågan, och en tredje som får godkänna order över en viss nivå. Om portalen saknar stöd för den typen av roller hamnar arbetet snabbt i mejltrådar och manuella rutiner. Då blir själva portalen ett extra lager ovanpå verksamheten i stället för ett arbetsverktyg som bär den.

Det är därför valet av plattform måste börja med frågor om versioner, relationer och ansvar. Kan samma kund ha olika prislogik beroende på bolag, avtal, tidpunkt eller kontaktperson? Kan lösningen visa rätt innehåll och rätt handlingsutrymme beroende på vem som är inloggad? Kan ändringar slå igenom utan att någon först exporterar, justerar och skickar nya underlag manuellt? Om svaret blir oklart i utvärderingen brukar det vara ett tidigt tecken på att plattformen kommer skapa friktion längre fram.

Tre integrationsområden som avgör om portalen fungerar

När en portal ska fungera i vardagen behöver tre integrationsområden hålla ihop. Det första är kopplingen till affärssystemet, där priser, lager, kunder, order och villkor ofta har sin källa. Det andra är produktinformationen, där attribut, dokument, relationer och publicering behöver vara konsekventa mellan kanaler. Det tredje är användar- och åtkomstmodellen, där företag, enheter, roller och behörigheter styr vad varje person får se och göra.

Om en av dessa delar blir svag påverkas resten direkt. En portal med bra produktpresentation men svag koppling till affärssystemet skapar osäkerhet kring pris, tillgänglighet och orderstatus. En stark koppling till affärssystemet men svag struktur för produktinformation leder ofta till dubbla datakällor, olika benämningar och tung administration. En lösning med god data men förenklad åtkomstmodell gör att kunderna ändå behöver ringa för att få hjälp med sådant som borde gå att lösa själva.

För svenska företag som säljer digitalt är det här en praktisk fråga snarare än en teknisk ambition. Enligt SCB bedrev 36,7 procent av svenska företag med minst 10 anställda e-handelsförsäljning under 2024, och andelen var betydligt högre bland större företag. SCB:s statistik om e-handel i företag 2025 Ju större verksamheten är, desto fler beroenden finns mellan handel, kunddata, produktdata och orderhantering. Därför blir integrationsförmågan ett mer användbart mått än hur snabbt en första version går att visa upp.

Ett affärssystem kan bära stora delar av sanningen om pris, lager och order, men portalen måste göra den sanningen användbar för kunden. Det kräver genomtänkt modellering, tydliga ansvar och en struktur som håller när verksamheten förändras. I praktiken är det ofta här skillnaden märks mellan en lösning som ser bra ut i demonstration och en lösning som fortsätter fungera efter lansering.

Offertflöden behöver klara undantag utan att tappa fart

Många affärer följer ett huvudflöde, men nästan alla verksamheter lever också med undantag. En kund kan behöva begära offert på ett sortiment som delvis saknar pris i portalen. En order kan behöva delas upp på olika leveransdatum. Ett avtal kan kräva särskilda villkor för frakt, godkännande eller märkning. Om plattformen bara fungerar när allt följer standardflödet kommer undantagen tillbaka till säljarna och kundservice.

Det är därför offertflöden måste bedömas utifrån hur de hanterar variation. Kan en kund skapa en förfrågan som innehåller både vanliga produkter och artiklar som kräver manuell prövning? Kan svaret bli ett nytt underlag som går vidare till beställning utan att information tappas bort? Kan lösningen visa vad som väntar på svar, vad som ändrats och vad som redan godkänts? När dessa steg blir otydliga uppstår lätt dubbla versioner av samma affär, och varje undantag kostar mer än det borde.

För er handlar det därför om att välja en plattform som klarar avvikelser med ordning. Ett fungerande offertflöde behöver kunna bära både struktur och flexibilitet. Kunden ska förstå vad som händer, säljaren ska kunna ingripa där det krävs och affärssystemet ska få rätt underlag vidare. När det fungerar väl minskar mängden sidoprocesser utan att verksamheten tappar kontroll.

Kundens vy av orderstatus, returer och självservice

En portal blir värdefull när den minskar behovet av att fråga någon annan. Det gäller särskilt efter köpet. Om kunden saknar en tydlig bild av vad som har beställts, vad som levererats, vad som restnoterats och vad som går att returnera kommer frågor om orderstatus fortsätta belasta organisationen även efter att portalen är live.

Orderstatus behöver därför byggas från kundens perspektiv. Det räcker sällan att visa ett internt statusfält från affärssystemet. Kunden behöver förstå vad statusen betyder i praktiken, vilka rader som påverkas, vilka leveranser som är på väg och vilka dokument som hör till ordern. För verksamheter med delleveranser, återkommande beställningar eller flera mottagare blir detta extra viktigt, eftersom samma order kan ha flera förlopp samtidigt.

Returer är en lika central del av självservicen. Om kunden måste ringa eller mejla för att förstå vilka artiklar som går att returnera, hur ärendet registreras och vad som händer sedan saknas en viktig del av portalens nytta. Ett bra upplägg binder ihop returorsak, godkännande, transport och uppdaterad orderbild så att kunden ser sammanhanget och medarbetarna slipper jaga information i flera system.

Svensk Handels E-handelsindikator visar att den svenska e-handelns omsättning uppskattades till 166 miljarder kronor under 2025. Svensk Handels E-handelsindikator 2025 När mer handel går genom digitala kanaler blir också efterköpsupplevelsen viktigare. För portaler och självservice innebär det att orderhistorik, leveransinformation, reklamationer och returer behöver vara begripliga, spårbara och nära kopplade till affärens faktiska data.

Åtkomstmodellen avgör vad portalen verkligen kan bära

Många projekt underskattar åtkomstmodellen. Det är ett vanligt förbiseende, eftersom den ofta framstår som en detalj i början och sedan visar sig vara avgörande för nästan varje viktig funktion. Om ni har kunder med flera bolag, flera användare, olika roller och lokala inköpsregler behöver portalen kunna spegla det på ett stabilt sätt.

Kärnan i åtkomstmodellen är relationen mellan företag, användare, roller och rättigheter. Vem får se priser? Vem får lägga order? Vem får begära offert? Vem får följa leveranser, hantera returer eller bjuda in fler användare? När svaren på dessa frågor saknar tydlig modell tvingas verksamheten ofta kompensera med manuella rutiner, vilket gör portalen svårare att lita på.

Här blir det också tydligt hur nära affär och teknik hänger ihop. En kontaktperson kan vara köpare i ett bolag och godkännare i ett annat. Ett huvudkontor kan vilja se hela inköpsbilden medan en lokal enhet bara får se sina egna beställningar. En återförsäljare kan ha tillgång till annat sortiment än en slutkund. Om plattformen saknar stöd för denna typ av relationer påverkas både användarupplevelse, förvaltning och intern administration.

Förvaltningen blir dessutom enklare när åtkomstmodellen är genomarbetad från början. Då går det att lägga till nya bolag, marknader eller användartyper utan att bygga om grundstrukturen varje gång. Det är en viktig egenskap för er som vill att portalen ska utvecklas stegvis och samtidigt hålla ihop över tid.

Tre leveransmodeller och deras praktiska följder

När ni har ringat in behovet återstår frågan om hur lösningen ska levereras. I praktiken återkommer tre modeller. Den första är en standardiserad molnplattform med snabb väg till lansering. Den andra är en mer kodtung lösning med större frihet i genomförandet. Den tredje är en produktiserad modell där återanvändbara byggblock, integrationsmönster och förvaltningssätt redan är definierade.

En standardiserad molnplattform passar ofta när processerna är relativt enkla och organisationen vill komma igång fort. Fördelen är ett tydligt ramverk och lägre tröskel i början. Nackdelen visar sig ofta när prislogik, roller, bolagsstruktur och undantag i flöden blir fler. Då växer behovet av tillägg, anpassningar och sidolösningar, vilket kan göra helheten svårare att styra över tid.

En kodtung lösning ger större frihet att forma funktioner och arbetsflöden efter verksamheten. Den kan vara rätt väg när ni har stark intern styrning, hög teknisk mognad och beredskap för test, uppgraderingar och kontinuerlig prioritering. Samtidigt innebär den modellen ofta att förändringar blir mer projektberoende. Varje ny regel, vy eller integration behöver planeras, byggas och kvalitetssäkras, vilket påverkar både ledtid och ägandekostnad.

En produktiserad leveransmodell försöker förena struktur med utvecklingsutrymme. Tanken är att återkommande behov, som inloggning, rollhantering, prisvisning, integrationer och självservice, ska vila på byggblock som redan är prövade. Då går det lättare att hålla ihop kvalitet, ansvar och förvaltning mellan olika bolag, varumärken eller marknader. För den som vill förstå hur ett sådant upplägg kan se ut i praktiken finns en genomgång av funktionsbiblioteket och hur återanvändbara komponenter kan korta ledtid och ge bättre kontroll över vidareutvecklingen.

Valet mellan modellerna handlar därför mindre om vilken plattform som ser mest tilltalande ut i ett tidigt skede och mer om vilket arbetssätt som passar er verklighet. Om ni redan vet att lösningen kommer behöva leva länge, kopplas tätt till affärssystemet och utvecklas stegvis med flera intressenter, blir leveransmodellen en central del av beslutsunderlaget. Förvaltning, ansvar och vidareutveckling behöver vara tydliga från början, vilket också är skälet till att många organisationer tittar närmare på upplägg för löpande utveckling som Glanser Care.

Förvaltning efter lansering formar den verkliga kostnaden

Det som händer efter lansering avgör ofta om satsningen blir hållbar. Många lösningar fungerar väl i projektform men tappar fart när de ska förvaltas, prioriteras och förbättras i vardagen. Då märks det snabbt om grundstrukturen är robust eller om varje förändring kräver ny tolkning, ny utveckling och nya beroenden.

För er som utvärderar plattform och partner är det därför klokt att se förvaltning som en del av själva lösningen. Om prisregler förändras, nya bolag tillkommer eller kundernas arbetssätt utvecklas behöver portalen kunna följa med utan att varje justering blir ett större projekt. Det gäller också när produktinformationen ska utökas, när nya roller ska läggas till eller när nya steg i självservicen ska införas.

Det finns också krav utanför den rena handeln som påverkar hur en portal bör byggas och förvaltas. Under 2025 började nya tillgänglighetskrav få större praktisk betydelse för webbaserade tjänster, och PTS:s tillsyn gör frågan mer konkret för många verksamheter. Maqs om tillgänglighet och cybersäkerhet 2025 För portaler betyder det att struktur, navigering och användbarhet behöver tas på allvar tidigt, eftersom förbättringar blir dyrare när de skjuts upp till senare skeden.

Förvaltning handlar också om rytm. Hur fångas förbättringar upp, hur prioriteras de och hur skiljer ni löpande utveckling från större initiativ? Den typen av frågor påverkar kostnaden mer än många först tror. En portal som går att justera stegvis med tydligt ansvar ger bättre förutsättningar för långsiktig effekt än en lösning där varje förändring kräver att man börjar om från början.

Frågor till leverantören innan ni väljer väg

När ni jämför alternativ är det klokt att föra samtalet bort från generella produktlöften och in i den vardag som portalen faktiskt ska bära. Be leverantören beskriva hur prisversioner, kontaktpersoner, roller och bolagsstrukturer modelleras i praktiken. Be också om en konkret bild av hur offertflöden med avvikelser hanteras, hur orderstatus presenteras ur kundens perspektiv och hur returer hålls ihop med övrig självservice.

En annan viktig fråga gäller ansvar över tid. Vad ingår i löpande förbättringar och vad blir ett nytt projekt? Svaret säger mycket om hur leverantören ser på förvaltning, samarbete och prioritering efter lansering. Det är också värdefullt att fråga hur de arbetar när nya behov uppstår i gränslandet mellan affärssystem, produktinformation och åtkomstmodell, eftersom det ofta är där verkliga förändringar landar.

Be slutligen om exempel på hur lösningen har utvecklats efter att den första versionen satts i drift. Då blir det lättare att se om modellen verkligen stödjer stegvis utveckling eller om varje förbättring riskerar att bli ett eget initiativ med ny kostnad, ny ledtid och ny osäkerhet. För fler resonemang om portaler, handel och strukturerad utveckling kan ni också läsa relaterade artiklar i bloggen.

Välj plattform utifrån hur affären faktiskt fungerar

När ni väljer e-handelsplattform för portal och självservice blir den avgörande frågan därför hur väl lösningen bär era regler, relationer och arbetssätt. Om säljarna fortfarande skickar prislistor efter lansering, om offertflöden bryts vid undantag och om kunderna saknar en tydlig bild av orderstatus och returer, då saknas något i arkitekturen eller leveransmodellen. En hållbar lösning bygger på att pris, produktinformation, affärssystem och åtkomst hänger ihop på ett sätt som fungerar i vardagen.

För er som vill fördjupa er i hur en kundportal kan byggas upp, vilka funktioner som brukar ge störst effekt och hur självservice kan kopplas närmare affärsprocesserna finns en konkret genomgång på kundportal och självservice.