Så väljer ni e-handelsbyrå som tar ansvar efter go-live

Ni har flera offerter på bordet. Alla beskriver en ny e-handel, bättre produktdata och en kundportal kopplad till affärssystemet. Priserna skiljer sig, men det är svårt att se om ni jämför samma åtagande.

När ni väljer e-handelsbyrå behöver ni få klart vem som bär osäkerheten efter go-live. Det gäller vem som rättar en order som fastnar, vem som håller kopplingen fungerande efter en uppgradering och vad leverantören får fakturera när omfattningen förändras.

Svaren ligger i prislogiken, integrationerna och avtalen. Där behöver ni börja, innan ni bedömer butiksvyn.

Sex frågor som avgör om e-handelsbyrån passar er

Be varje leverantör besvara samma frågor skriftligt. Då kan ekonomichefen jämföra kostnader samtidigt som IT-chefen granskar beroenden. E-handelsansvarig kan kontrollera att det dagliga arbetet faktiskt ryms i leveransen.

Under 2024 bedrev 36,7 procent av svenska företag med minst tio anställda e-handelsförsäljning via webb eller EDI, enligt SCB:s statistik om företagens it-användning. Statistiken omfattar både webbaserad försäljning och automatiserade affärstransaktioner mellan system. För er bedömning behöver därför hela ordervägen vara synlig i offerten.

Varje svar ska kunna styrkas med en demonstration, en avtalstext eller en relevant kundreferens.

Vilka affärssystem finns färdiga integrationer mot, och vem äger kopplingen? Be om dokumentation för integrationer mot Business Central, Monitor eller Jeeves samt besked om ansvaret efter go-live. Svaret visar om order, pris och lager omfattas av ett definierat produktansvar.

Hur fungerar fast pris eller löpande räkning? Be om en skriftlig omfattning, regler för ändringar och besked om när priset blir bindande. Svaret visar om ni riskerar att samma arbete prissätts två gånger.

Vem ansvarar för förvaltningen efter lansering? Be om avtal för buggar, säkerhet och drift samt besked om när en ny offert krävs. Svaret visar om leverantörens ansvar fortsätter efter lanseringsdagen.

Vad ingår vid uppgraderingar? Be om besked om nya versioner av plattform och affärssystem omfattas av avtalet. Svaret visar om varje uppgradering kan medföra ett nytt projekt.

Hur hanteras plattform och PIM? Be om namngivna ägare för berikning och godkännande av produktdata till samtliga kanaler. Svaret visar om kanalerna kan visa konsekventa uppgifter.

Vilka referenser liknar er verksamhet? Be om företagskunder med samma affärssystem och kundunika priser. Svaret visar om leverantörens erfarenhet omfattar era affärsregler.

Ett tydligt nej är användbart. Då kan ni prissätta det som saknas eller välja bort en funktion. Ett allmänt besked om att allt går att lösa lämnar fler beslut öppna.

Jämför offerternas undantag innan ni jämför slutsummorna. Markera vad ni själva måste leverera, vilka antaganden priset bygger på och vem som godkänner resultatet. Två liknande totalsummor kan innehålla helt olika risker för er.

Begär också att demonstrationerna följer ett eget affärsfall. Använd en verklig kundtyp, en representativ artikel och en avtalad prisregel. Då får ni ett underlag som går att bedöma tillsammans med försäljning och ekonomi.

Affärssystemet visar vem som äger integrationen

En beställning kan se korrekt ut i kundportalen och ändå kräva manuell rättning i affärssystemet. Kunden kanske har rätt rabatt men fel leveransadress. Ordern kan också sakna en referens som er ekonomiavdelning behöver för faktureringen.

Börja därför med ert nuvarande affärssystem. Be leverantören namnge färdiga kopplingar mot exempelvis Business Central, Monitor och Jeeves. Fortsätt sedan med det system och den version ni faktiskt använder.

Färdig integration behöver betyda något kontrollerbart. Omfattning, förutsättningar och pris ska vara beskrivna. Dokumentationen ska ange vilka uppgifter som överförs, i vilken riktning och vad som händer när mottagaren avvisar dem.

Era undantag behöver synas i provkörningen

Låt leverantören visa produkter, kundunika priser, lagersaldo och order genom hela flödet. Alla uppgifter behöver inte gå åt båda håll. Varje uppgift behöver däremot en bestämd källa och en dokumenterad väg till mottagaren.

Pröva stafflade rabatter, spärrade kunder, restnoterade artiklar och avvikande leveransadresser. Kontrollera också hur systemet hanterar ett avbrott efter att kunden skickat beställningen. Återförsök ska kunna ske utan att samma order registreras igen.

När ni granskar färdiga integrationer behöver ni se exakt vilka sådana regler som omfattas. Resonemanget om e-handel och affärssystem hjälper er att hålla fokus på hela affärsflödet. Följ en order från inloggad kund till registrerad order i affärssystemet, och lägg in ett avsiktligt fel på vägen.

Ni behöver bidra med testmiljö, åtkomst och en person som kan prislogiken. Någon hos er måste också avgöra vilka undantag som ska behållas. Annars får utvecklaren fatta affärsbeslut genom tekniska antaganden.

Avsluta genomgången med att namnge integrationsägaren efter go-live. Avtalet behöver ange vem som felsöker när plattformen och affärssystemet visar olika uppgifter. En demonstration av webbflödet lämnar den frågan obesvarad.

Fast pris håller när scopet är känt före starten

Priset sätts ofta medan delar av arbetet fortfarande är okända. Osäkerheten finns då kvar i leveransen. Kunden eller leverantören kommer att bära den, beroende på vad avtalet säger.

Ett lågt ingångspris kan följas av en ny offert när prisregler, datamigrering eller behörigheter undersöks närmare. Därför behöver ni skilja mellan en kostnad för kartläggning och ett bindande pris för genomförandet.

Be leverantören beskriva vad som ingår, vad som räknas som ändring och vem som får beställa tillägg. Ändringen ska godkännas innan arbetet påbörjas. Samma regel behöver gälla när någon hos er lämnar ett önskemål direkt till utvecklaren.

Omfattningen behöver gå att godkänna

En formulering som kundunika priser räcker sällan som acceptanskriterium. Beskriv var priset beräknas, vilka rabatter som kombineras och vad användaren ser när pris saknas. Då går funktionen att testa före godkännandet.

Vi använder färdigutvecklade, testade och kompatibla funktioner genom Funktionsbiblioteket. Standard har fast omfattning och fast pris. Anpassad utgår från samma grund med avtalade ändringar, medan Kundunik isoleras så att resten kan uppgraderas utan att påverkas.

Avtalet behöver innehålla en leveransbeskrivning som anger vilket beteende ni ska godkänna, förutsättningar som anger vilka uppgifter och beslut ni måste lämna, en ändringsregel som anger vem som godkänner kostnad och påverkan på tidsplanen, och undantag som anger vilket arbete som ligger utanför priset.

Fast pris kräver att ni visar nuvarande webb, portal och affärssystem före prissättningen. Ni behöver också välja vilka önskemål som hör till första leveransen. Ett oavgjort önskemål går sällan att prissätta ansvarsfullt.

Löpande räkning passar när ni medvetet utforskar ett arbetssätt eller en funktion. Då behöver ni kunna prioritera arbetet fortlöpande och acceptera att slutkostnaden är öppen. Begär tät redovisning av återstående osäkerheter, så att budgetbeslut följer det ni faktiskt vet.

Förvaltningen avgör kostnaden efter go-live

Efter lanseringen fortsätter plattformen och affärssystemet att förändras. Er kundportal följer bådas tekniska förutsättningar. Microsoft släpper till exempel större uppdateringar av Business Central två gånger per år. Därför behöver någon läsa release notes, bedöma påverkan och prova att pris- och orderflöden fortfarande fungerar.

Dela upp ansvaret för buggar, säkerhetsrättningar och drift. De kräver olika åtgärder och kan ligga hos olika parter. En allmän rad om support ger er för lite besked när en beställning stannar.

Buggrättning gäller fel i det ni redan har köpt. Säkerhetsarbete gäller bland annat sårbarheter och uppdaterade beroenden. Drift omfattar miljön där lösningen körs samt bevakning och hantering av avbrott.

Avtalet behöver skilja mellan att ta emot ett ärende och att ansvara för att felet blir löst.

Uppgraderingar behöver ett eget åtagande

Begär att avtalet beskriver versionsuppföljning och kompatibilitet genom uppgraderingar av både plattform och affärssystem. Det behöver också framgå vem som bokar testmiljön, genomför testerna och godkänner produktionssättningen.

En uppgradering kan kräva mer än att installera en ny version. Behörigheter, prisberäkningar och orderöverföring behöver provas med relevanta affärsfall. Dokumentera dessutom hur ni återgår om produktionssättningen misslyckas.

Avtalet behöver namnge vem som rättar buggar och hur ärenden prioriteras, vem som bedömer och genomför säkerhetsrättningar, vem som bevakar driften och agerar vid avbrott, och vem som säkerställer kompatibilitet och godkänner testresultatet vid uppgraderingar.

En schablon baserad på byggets pris säger lite om dessa åtaganden. I er TCO-kalkyl behöver ni kunna följa både avtalad månadskostnad och arbete som kan tillkomma. Beskrivningen av förvaltning och uppgraderingsansvar är relevant när ni granskar gränsen mellan löpande ansvar och vidareutveckling.

Hos er krävs en namngiven mottagare och tid för att godkänna produktionssättningar. Egna kodändringar behöver hanteras enligt samma överenskomna arbetssätt. Avtalet ska till sist namnge ansvarig part, omfattade system och villkoren för arbete som kräver ny offert.

PIM avgör om era kanaler visar samma produkt

En tekniskt fungerande koppling kan publicera fel produktuppgifter. Om ingen äger attributen kan webb, kundportal och återförsäljarkanal visa olika benämningar. Varje kanal kan dessutom ha egna manuella rättningar som försvinner vid nästa överföring.

Börja med att ange var varje uppgift hör hemma. Produktbeskrivningar och tekniska attribut kan hanteras i PIM. Pris och lager kan hämtas från affärssystemet. Bestäm också vilket system som får skriva över ett befintligt värde.

Godkännandet behöver en ägare

Be leverantören visa vilka fält som måste vara kompletta före migrering och publicering. Ange vem hos er som godkänner tekniska specifikationer, översättningar och lokala avvikelser. Vid koncerngemensamma sortiment behöver även beslutsrätten mellan bolagen framgå.

Ett användbart arbetssätt är att berika uppgiften där den ägs och sedan publicera den till berörda kanaler. Manuell berikning passar texter som kräver produktkunskap. Automatik passar uppgifter som redan finns i en tillförlitlig källa. En artikel som saknar obligatoriska attribut ska få en tydlig ägare och ett synligt felmeddelande.

Anta att en reservdel får fel benämning men korrekt artikelnummer. Kunden väljer efter benämningen och beställer fel del. Orderöverföringen fungerar, men ni får ändå hantera retur och supportärende.

Låt därför genomgången av PIM och datakvalitet omfatta både publiceringsregler och ansvar för rättning. Följ upp saknade obligatoriska fält, avvisade artiklar och manuella korrigeringar. Då kan ni prioritera de fel som påverkar beställningarna.

PIM-arbetet kräver tid från era produktansvariga under införandet. Ett mindre sortiment med få kanaler kan klara sig med enklare produktadministration. Välj omfattning efter vem som ska underhålla uppgifterna och hur ofta de ändras.

Tre frågor avslöjar om referensen liknar er

Referenser blir användbara när ni känner till vad som faktiskt levererades. En välgjord butik visar hur gränssnittet fungerar. För ert beslut behöver ni också förstå prisreglerna, systemkopplingen och vad kunden själv fortfarande gör manuellt.

Vilka två företagskunder kan ni namnge som använder samma affärssystem som vi, och hur hanteras deras kundunika priser och order? Svaret visar hur nära leverantörens erfarenhet ligger er egen affär.

Vad var färdig funktion, anpassat respektive kundunikt, och hur hanterades den kundunika delen vid uppgradering? Svaret visar om lösningen går att bygga vidare på med bibehållen grund.

Be om att få veta vilken omfattning som levererades och vad kunden faktiskt använder, vilka moment kunden fortfarande utför manuellt, hur förändringar efter lansering beställdes och betalades, och vilken part som hanterar fel i dag.

Vem ringer kunden när en order stannar efter go-live, och omfattas den hjälpen av avtalet? Svaret visar om referensen fortfarande har ett fungerande förvaltningsåtagande.

Be att få tala med kunden och låt samtalet handla om vardagen. Ta reda på hur fel rapporteras, vem som samordnar felsökningen och hur ändringar godkänns. Kunden behöver få beskriva både det som fungerar och det som kräver egen tid.

Ett publicerat kundcase räcker sällan för att bedöma vem som bär ansvaret när systemen visar olika uppgifter.

Respektera att vissa detaljer omfattas av sekretess. Leverantören bör ändå kunna beskriva system, levererad omfattning och ansvarsfördelning på en relevant nivå. Om systemet aldrig kan namnges har ni begränsat stöd för att bedöma erfarenheten.

Låt någon från er verksamhet delta i referenssamtalet tillsammans med IT. Försäljningen hör om prislogiken fungerar i vardagen. IT kan bedöma om kunden fortfarande samordnar leverantörer på egen hand.

Avsätt två timmar innan ni skriver på

Innan ni skriver på behöver ni kunna visa hur lösningen fungerar i dag och vad som måste förändras. Ta med webb eller portal, ett representativt sortiment och exempel på prisundantag. Samla även befintliga avtal, så att ansvar för drift, integration och utveckling går att bedöma.

Er nuvarande lösning hjälper er att avgöra vad som kan behållas och vad som behöver ändras. Pris- och orderundantag visar vilka funktioner som måste ingå från början. Befintliga avtal visar vilket ansvar som behöver flyttas eller kompletteras.

Använd underlaget för att skilja mellan funktioner som kan återanvändas och sådant som kräver utveckling. Då blir det tydligare om en färdig integration täcker era regler, eller om omfattningen behöver anpassas. Ni kan också bedöma om en produktwebb räcker som första steg och senare kan byggas ut till en portal.

Ett fast upplägg passar när ni kan beskriva omfattningen och ge leverantören möjlighet att undersöka beroendena före ett bindande åtagande. Om ni saknar ett affärssystem att koppla mot kan integrationsfrågorna väga lättare. En tillfällig kampanjsida kan också kräva ett enklare åtagande. Vill ni ändra kod ofta utan avtalad omfattning, kan löpande räkning bättre spegla osäkerheten.

För Litium och Business Central finns en färdig koppling i Funktionsbiblioteket, men omfattningen behöver fortfarande stämmas av mot era prisregler och undantag. I en 72-timmarsanalys avsätter ni två timmar och får inom 72 timmar en inventering av funktioner och integrationer, en funktionsspecifikation, en prototyp och en komplett kostnadsbild med tidsplan, kostnadsfritt.