Digital kundportal som fungerar för er
Glanser
Portalen är lanserad, integrationen svarar och kunderna har fått sina inloggningar. Ändå skickar säljavdelningen fortfarande prislistor via mejl, kundservice letar orderstatus i affärssystemet och återförsäljare hör av sig med frågor som borde gå att lösa direkt i portalen. Där börjar många portalprojekt på riktigt. Det som såg färdigt ut tekniskt har ännu inte blivit ett arbetssätt som fungerar i vardagen.
Det problemet uppstår ofta när projektet har när projektet har utgått från en funktionslista och lämnat regler, ansvar och data till senare. En kundportal blir värdefull när offert, order, dokument och service går att hantera som självservice utan att användaren fastnar mellan olika interna processer. Det kräver att ni vet vilken information som gäller, vem som får se den och vem som tar ansvar när verkligheten förändras efter lanseringen.
Tänk er en kund som vill lägga en order med sin avtalade rabatt. Samtidigt har prislistan uppdaterats, en leverans delas upp och kontaktpersonen som godkände avtalet har slutat. Om projektgruppen inte har bestämt vilken prisversion som gäller, vem som får godkänna en avvikelse och hur åtkomsten ska flyttas till en ny kontaktperson, uppstår friktion direkt. Portalen visar kanske ett pris vid ett tillfälle och ett annat pris när ordern väl registreras. Då spelar det liten roll att inloggning, design och integrationer ser bra ut på ytan.

Varför kundportaler fastnar före eller efter lansering
Många satsningar börjar med en välbekant lista: inloggning, orderhistorik, dokument, lagerstatus och offertförfrågningar. Den listan beskriver vad portalen ska visa, men den säger väldigt lite om vilka regler som styr innehållet. Det är också där många projekt tappar fart. Frågor om prisversioner, avtal, kontaktpersoner, behörigheter och manuella undantag kommer sent, trots att de påverkar både utveckling, test och drift.
Det som avgör om portalen fungerar över tid är datakvalitet, beslutsregler och förvaltning. Om produktinformation saknar ägare, om prislogik lever i flera system samtidigt eller om ansvaret upphör vid go-live, börjar människor snabbt lösa uppgifterna vid sidan av portalen igen.
Därför behöver ni tidigt avgränsa vilket första flöde som ska bli riktigt bra. En tidig nulägesbild hjälper er att se vilka datakällor som faktiskt styr kundupplevelsen, vilka undantag som återkommer och vilket team som ska äga förbättringarna efter lanseringen. När den bilden saknas blir portalen ofta ett projekt med ett slutdatum. När den finns blir portalen en tjänst som går att utveckla och hålla relevant.
Tre integrationsområden som avgör kvaliteten
En portal kan vara tekniskt stabil och ändå skapa merarbete. Det händer när informationsmodellen och arbetsflödena inte hänger ihop. För att undvika det behöver ni tänka i tre integrationsområden: produktinformation, affärssystem och kundflöden. Varje område behöver en tydlig källa, en ansvarig och en regel för hur förändringar slår igenom i portalen.
Produktinformationen avgör ofta det första intrycket. Affärssystemet kan ha artikelnummer, interna benämningar och prisdata, men kunden behöver ett sammanhang som går att förstå och agera på. Det handlar om namn, tekniska egenskaper, bilder, dokument, enheter och relationer mellan produkter. Därför behöver ni definiera hur informationen struktureras, vem som godkänner den och hur gamla dokument eller ersättningsprodukter hanteras när sortimentet förändras. Om ni arbetar med PIM och strukturerad produktinformation bör den modellen kopplas direkt till kundresan, så att informationen stödjer rätt uppgift vid rätt tillfälle. Det gäller också hur publicering per kanal ska fungera för olika målgrupper.
Det andra området är affärssystemet, där priser, lager, order, fakturor och kundvillkor vanligtvis hämtas. Här räcker det inte att säga att produkter och order ska integreras. Ni behöver beskriva hur varje dataflöde rör sig mellan systemen, hur ofta det uppdateras, vad som händer när ett värde blir fel och vem som ansvarar för korrigeringen. Det blir särskilt viktigt när prislistor byts ut, avtal går in i en ny period eller leveranser delas upp. Krav på affärssystemsintegrationer för produkter, priser, lager och order behöver därför vara detaljerade redan innan utvecklingen startar. Annars blir det svårt att testa sådant som kunderna märker direkt, som pris, lagersaldo och status.
Det tredje området är kundflödena, alltså hur användaren upplever helheten. Kunden bryr sig inte om ifall informationen kommer från ett PIM, ett affärssystem eller något annat internt system. Det som spelar roll är om portalen visar vad som gäller, vad som väntar på besked och vilket nästa steg som finns. Därför behöver ni definiera roller, ansvar och felvägar innan gränssnittet byggs. En inköpare, en attestant och en ekonom behöver se olika delar av samma relation, och deras gemensamma kundkonto behöver fungera utan att information blandas ihop.
Offert, order och retur kräver olika logik
Självservice fungerar när portalen hjälper användaren genom konkreta situationer som annars skulle ha hamnat i inkorgen eller hos kundservice. Offert, order och retur ser ofta ut som närliggande funktioner i en kravlista, men de bygger på olika regler och bör beskrivas som egna flöden.
I offertflödet behöver portalen förstå när ett standardpris räcker och när en säljare måste kopplas in. Kunden ska kunna välja produkter, ange kvantitet och lämna rätt uppgifter om sitt behov, men det måste också finnas regler för vilka prislistor, rabattgrupper och avtalsnivåer som gäller. När en offert kräver godkännande behöver det vara tydligt vem som fattar beslutet och hur offerten sedan går vidare till order utan dubbelarbete. Ett vanligt förbiseende uppstår när priset som visas när offerten skapas inte är samma pris som används när ordern senare registreras i affärssystemet. Om den skillnaden inte förklaras i flödet tappar användaren snabbt förtroendet för portalen.
Orderflödet behöver i sin tur utgå från kundens frågor. Kunden vill veta om ordern är mottagen, om den är godkänd, om varorna finns tillgängliga, om leveransen har skickats och om det finns avvikelser eller dokument att agera på. Om en leverans delas upp, om en vara restnoteras eller om en ändring begärs efter att ordern har skickats, behöver det framgå tydligt vad som går att göra i portalen och vad som kräver manuell handläggning. En klar statusbild skapar trygghet, medan otydliga mellanlägen leder till samtal och mejl.
Returflödet visar ofta hur mogen självservicen verkligen är. Här behöver kunden kunna koppla sitt ärende till rätt order, rätt produkt och rätt anledning. I vissa fall krävs bilder, batchnummer eller serienummer. Reklamation, transportskada, felbeställning och behov av reservdelar följer olika processer, och portalen behöver guida användaren till rätt väg från början. Det gör handläggningen snabbare och förbättrar kvaliteten i underlaget som kommer in till er organisation.
Behörighet och säkerhet måste följa kundrelationen
Säkerhet i en kundportal omfattar inloggning, åtkomst, uppföljning och styrning av information. Det centrala är att rätt person får tillgång till rätt information vid rätt tillfälle, och att åtkomsten förändras när roller, kontaktpersoner eller organisationsstrukturer förändras. En användare kan vara korrekt inloggad och ändå få fel uppgifter om behörighetskontrollen sker i gränssnittet och inte på serversidan. Samma problem uppstår när ett anrop mot affärssystemet saknar en verifierad koppling till rätt kundkonto.
Ni behöver därför bygga en åtkomstmodell som utgår från både individer och kundorganisationer. Den bör beskriva vilka data som varje roll får se, ändra och exportera, hur behörigheter skapas och stängs, och hur ni hanterar ett byte av kontaktperson när ett avtal fortfarande gäller. Administratörer och känsliga flöden bör skyddas med flerfaktorsautentisering, gärna med en nätfiskeskyddad metod där det är möjligt. Loggning behöver täcka sådant som inloggning, export, prisvisning och ändringar i order eller behörigheter, så att avvikelser går att följa upp i efterhand.
Hotbilden är konkret. I Företagarnas rapport om IT-säkerhet uppgav 55 procent att de hade tagit emot nätfiskemejl under det senaste året. För en portalmiljö är den siffran relevant eftersom användarkonton, prisinformation och dokument skapar ett tydligt mål för angripare. Därför behöver säkerhetsarbetet fortsätta efter lanseringen, med rutiner för test av återställning, rollbyten och integrationsfel.
Tillgänglighet och användbarhet påverkar om portalen används
En kundportal kan ha korrekt data och stabil drift men ändå skapa friktion om den är svår att använda. Det gäller särskilt i återkommande arbetsuppgifter där kunder behöver söka produkter, läsa dokument, följa status eller hantera formulär under tidspress. Om fält saknar tydliga felmeddelanden, om statusinformation kräver mus eller om dokument inte går att läsa på olika enheter uppstår snabbt ett beroende av manuell hjälp.
Tillgänglighet behöver därför vara en del av kravställning, test och förvaltning. Det omfattar tangentbordsnavigering, kontraster, zoom, formulärhantering och hur dokument publiceras och uppdateras. För portalprojekt är det klokt att utgå från de flöden som används mest och testa dem med verkliga användarscenarier. I PTS:s mätning av svenska webbplatsers tillgänglighet nådde 57 procent av privata webbplatser nivån få eller begränsade brister. Den siffran räcker för att visa att kvaliteten varierar, även i etablerade miljöer, och att tillgänglighet behöver följas upp löpande när innehåll, dokument och komponenter förändras.
cybersäkerhetsmognadsrapporten 2025
Välj leveransmodell utifrån ansvar över tid
Valet mellan en produktdriven leverans, en förutvecklad plattform och en egenutvecklad lösning bör styras av vilket ansvar ni vill bära över tid. Skillnaden mellan modellerna ligger sällan i om det går att bygga en viss funktion. Den ligger i hur lösningen förvaltas, uppgraderas, testas och dokumenteras när behoven förändras.
En produktdriven leverans passar ofta när ni vill ha en tydlig omfattning och en förutsägbar kostnadsbild. Då blir det lättare att komma överens om vad som ingår och vilka acceptanskriterier som gäller. En förutvecklad plattform kan ge en snabbare väg till en lösning där vanliga mönster redan är genomarbetade, till exempel för produkter, priser, lager och order. Om ni utvärderar moduler eller återanvändbara delar kan ett funktionsbibliotek ge en bättre bild av vad som redan finns färdigt och var anpassningar faktiskt behövs.
En egenutvecklad lösning kan vara rätt när era processer skiljer sig så mycket att affärsvärdet ligger i det unika arbetsflödet. Då behöver ni samtidigt vara medvetna om att varje särskild anpassning också blir ett framtida ansvar för test, uppgradering och dokumentation. Många företag underskattar den delen och fokuserar för mycket på friheten i byggfasen. I praktiken blir det långsiktiga ägandet ofta den viktigaste kostnaden.
Det är också klokt att tänka på hur förvaltningen ska fungera när portalen väl är i drift. Om leverantören erbjuder en tydlig modell för löpande arbete, till exempel genom Glanser Care, blir det lättare att se hur felrättningar, uppgraderingar och vidareutveckling hanteras i praktiken. För den som vill fördjupa sig ytterligare i hur digital självservice förändrar kundrelationer finns även relaterade resonemang i Glanser blogg.
Frågor som visar vad leverantören faktiskt tar ansvar för
När ni jämför leverantörer är det värt att ställa frågor som blottlägger hur ansvaret ser ut efter go-live. Fråga till exempel: Vad ingår i löpande förbättringar och vad blir ett nytt projekt? Svaret visar om leverantören ser portalen som en levande tjänst eller som en leverans som avslutas när funktionerna är publicerade.
Fråga också vem som felsöker när affärssystem och portal visar olika orderstatus. Svaret visar om leverantören tar ansvar för helheten mellan system, eller om ni själva förväntas samordna analysen när ett fel uppstår i gränslandet mellan data, integration och gränssnitt.
Funka Nus lägesanalys i förhållande till WCAG
En tredje fråga är vem som testar integrationen före en plattformsuppgradering eller en förändring i affärssystemet. Svaret visar hur moget arbetet med risk, regressionstest och kontinuitet är, och hur stor del av det ansvaret som kommer att landa hos er egen organisation.
Från planering till en portal som håller i vardagen
På sidan om kundportal och självservice hittar ni hur en sådan lösning kan byggas upp, vilka flöden som brukar ingå och hur kopplingen till affärssystem och löpande förvaltning kan se ut.

Om Glanser
Glanser writes for Glanser on ERP integration, PIM infrastructure, and B2B commerce architecture.

Så får ni Business Central och Magento att hålla ihop i drift
Bygg en stabil business central magento integration. Lär er hantera dataflöden, systemägarskap och B2B-logik utan onödiga fel i produktion.
Glanser
Produktdata som går att spåra, styra och lita på
Ett product data management system centraliserar er produktdata. Läs om datamodellering, governance och hur ni styr informationen mot webb och ERP.
Glanser
Infor M3-integration som ni kan lita på i drift
Praktisk guide om Infor M3 integration mot webb, PIM och portaler. Mönster, fältsynk, prestanda och fallgropar ni bör känna till.
Glanser