B2B kundeportal

Hvad er en B2B kundeportal?

En B2B kundeportal er et sted, hvor jeres kunder kan logge ind og klare det selv: se deres ordrer, hente en faktura, bestille igen og finde de oplysninger, de ellers ville have ringet eller skrevet efter.

Forskellen på en portal og en webshop er, hvem der kigger. En webshop skal sælge til nogen, der ikke kender jer. En portal skal gøre hverdagen nemmere for nogen, der allerede handler hos jer – og som har deres egne priser, deres eget sortiment og deres egne aftaler.

Derfor er en portal sjældent noget, man køber færdigt. Den skal kende jeres kunder, og de oplysninger ligger i jeres ERP.

Kundeportal eller B2B-webshop?

De to ord bruges i flæng, men de løser ikke det samme.

En B2B-webshop skal sælge til nogen, der ikke nødvendigvis kender jer. Den skal kunne findes i Google, vise et katalog uden login, have kampagner og tage imod betaling.

En kundeportal er lukket. Kunden logger ind og ser sit eget: sine priser, sit sortiment, sine ordrer og sine fakturaer. Der er ingen kampagneside og ofte ingen betalingskort – der faktureres som altid, på de vilkår der står i ERP’et.

Forskellen betyder noget for, hvad der skal bygges. En webshop har brug for produkttekster, billeder og søgemaskineoptimering. En portal har brug for, at adgangsstyring, prislogik og ordrehistorik er rigtige – for kunden opdager med det samme, hvis en pris er forkert.

Mange ender med begge dele: samme data bagved, to forskellige indgange foran.

Start med det, der fylder mest

De fleste virksomheder, vi taler med, har den samme oplevelse: kundeservice bruger meget tid på at svare på noget, der allerede står i systemet.

• “Hvornår kommer min ordre?”
• “Kan jeg få fakturaen for marts igen?”
• “Hvad var det nu, vi betalte for den vare?”
• “Kan I sende de samme varer som sidst?”

Det er dét, den første udgave af portalen løser. Kunden logger ind, ser sine egne ordrer med status og leveringsdato, og henter selv de fakturaer, der skal bruges. Det kræver ingen ny webshop og ingen ændring i, hvordan I arbejder – kun at data flyder fra jeres ERP og ud til kunden.

Den udgave koster fra 500 kr./md. oven i en Connectify-integration.

Fakturaer og kontoudtog, uden at nogen skal lede

Det lyder som den enkleste funktion på listen, og teknisk set er den det også. Men der er nogle beslutninger, I skal tage, før den virker som den skal.

Hvor ligger fakturaen? I Business Central kan den bogførte salgsfaktura dannes som PDF direkte, eller hentes fra det dokumentarkiv, I allerede bruger. Ligger de gamle fakturaer i et tidligere ERP, skal vi beslutte, om de skal med – og hvor langt tilbage.

Kun det bogførte. Kladder og ikke-bogførte fakturaer må ikke dukke op hos kunden. Det er en af de fejl, der koster mest tillid, hvis den slipper igennem.

Kreditnotaer hører med. Ser kunden kun fakturaer, ser regnskabet forkert ud hos dem. Kreditnotaer vises derfor i samme liste, med beløbet som negativt.

Saldo og forfaldne poster kommer fra debitorposterne, ikke fra fakturalisten. Det er dem, der gør, at kunden kan se, hvad der faktisk udestår – og jeres bogholderi slipper for at sende rykkere, som kunden allerede har betalt.

Byg på, når I ved hvad der virker

Når selvbetjeningen kører, kan I se i tallene, hvad kunderne bruger. Det er et meget bedre grundlag for at beslutte det næste trin end et kravspecifikationsmøde.

Typisk er næste skridt bestilling: kunden kan lægge en ordre direkte i portalen, med sine egne priser og sit eget sortiment. Derefter kommer det, der er særligt for jer – roller, godkendelser, budgetter eller konfiguration af varer.

Fordi hvert modul kobles på jeres systemer gennem den samme integration, bliver det ikke dyrere at tilføje noget senere. Grundlaget er der allerede.

Kundens egne priser – og hvorfor det er den svære del

Prisen er dét, kunden tjekker først. Derfor er prislogikken sjældent det, der tager længst tid at bygge, men næsten altid det, der tager længst tid at blive enige om.

I et ERP som Business Central kan prisen på en linje komme fra flere steder på én gang: en salgspris på varen, en kampagnepris med gyldighedsdato, en pris på kundens prisgruppe, en linjerabat på varegruppen og en mængderabat, der først slår til ved et bestemt antal. Rækkefølgen er ikke altid indlysende.

Der er grundlæggende to måder at gøre det på:

• Spørg ERP’et hver gang. Portalen beder om prisen, når kunden lægger i kurven. Den er altid rigtig, men kræver at ERP’et kan svare hurtigt nok.
• Spejl prislogikken i portalen. Hurtigere for kunden, men I har nu to steder, hvor prisreglerne lever – og de skal holdes ens.

Vi anbefaler som regel det første, og lader ERP’et beregne ordren igen, når den oprettes. Så kan kunden aldrig komme til at bestille til en pris, I ikke kan honorere.

Hertil kommer moms, valuta og eksport. En kunde i Tyskland skal se priser uden dansk moms, i euro, og med de leveringsbetingelser der gælder for dem. Det er ikke svært, men det skal besluttes, inden der bygges.

Hvem må bestille hvad – og for hvor meget?

Hos en lille kunde bestiller den samme person hver gang. Hos en stor kunde er der en indkøber, en afdelingsleder, en økonomichef og fem lagre, der hver har deres eget forbrug.

Portalen kan håndtere begge dele, men det kræver, at tre ting er på plads:

Roller. Hvem må se priser, hvem må bestille, hvem skal godkende, og hvem må oprette nye brugere hos kunden. Den sidste er værd at tænke over: kan kunden selv oprette sine kolleger, slipper I for at gøre det.

Regler for godkendelse. Typisk et beløb – ordrer over 25.000 kr. skal forbi økonomichefen – men det kan også være en varegruppe, en afdeling eller et projekt. Reglen skal også tage stilling til, hvad der sker, hvis godkenderen er på ferie.

Budgetter. Nogle kunder vil have et loft pr. afdeling, projekt eller periode. Budgettet kan ligge i portalen, eller det kan hentes fra dimensionerne i jeres ERP, hvis det allerede styres der. Når en ordre overskrider det, kan den enten blokeres, sendes til godkendelse eller gå igennem med en note – det er kundens valg, ikke jeres.

Det lyder administrativt, men det er ofte dét, der afgør, om de store kunder flytter deres indkøb over i portalen. Jo mere kontrol de selv har, jo mindre skal de ringe til jer.

Det, standardsystemerne ikke kan

Nogle arbejdsgange findes der ikke et plugin til. Et par eksempler på noget, vi har bygget:

Budgetter i stedet for priser. En virksomhed, hvis kunder bestiller arbejdstøj til deres medarbejdere, ville ikke have kroner i portalen. Hver medarbejder fik i stedet en pointpulje, som kundens egen administrator kunne tildele, flytte mellem kollegaer og udvide. Når en medarbejder manglede point, kunne de med ét klik spørge den ansvarlige, som fik en mail med indholdet af kurven.

Varer, der sendes som sæt. Den samme portal skulle sende tre varelinjer til ERP’et, når medarbejderen valgte én vare: beklædningen plus to logotryk i forskellige størrelser. Kunden ser én vare, ERP’et får det, produktionen har brug for.

Lager på noget, der ikke er en vare. Kundespecifikke logoer blev holdt på lager pr. størrelse, og når beholdningen blev lav, gik der automatisk besked til kunden om at bestille nye – ellers kunne tøjet ikke bestilles.

Bestilling på vegne af andre. Den ansvarlige hos kunden kunne lægge ordrer for sine medarbejdere, og det blev noteret på ordren, hvem der havde bestilt til hvem.

Ingen af delene er standard. Alle sammen er bygget, fordi det var sådan, forretningen fungerede.

Integration med jeres eksisterende systemer

En kundeportal er ikke en ø. Den skal spille sammen med de systemer, der allerede ejer data – ellers bliver den endnu et sted, nogen skal vedligeholde i hånden.

Systemer, der typisk kobles på:

• ERP – fx Dynamics 365 Business Central, Infor M3 eller TRIMIT
• PIM – fx Struct PIM eller Plytix
• WMS til lagerlokationer og plukstatus
• Fragt – fx Shipmondo eller Webshipper

Vi aftaler i afklaringen, hvilket system der ejer hvilke oplysninger. Det lyder teknisk, men er den beslutning, der afgør, om portalen bliver let eller besværlig at leve med: når ét system ejer prisen, kan de andre ikke komme til at overskrive den.

Sådan forløber et portalprojekt

Afklaring (gratis). Vi gennemgår jeres systemer, jeres kunder og de arbejdsgange, der fylder mest. Resultatet er en liste over moduler i den rækkefølge, der giver mening – og en pris.

Datagrundlag. Før noget kan vises, skal vi vide, hvad der findes. Er debitorerne vedligeholdt? Har varerne billeder og tekster, eller skal de komme fra et PIM? Findes der e-mailadresser på de personer, der skal logge ind? Det er her, de fleste projekter bliver forsinket – ikke i udviklingen.

Første modul i drift. Vi bygger det ene modul færdigt og sætter det i luften, i stedet for at vente på at det hele er klart.

Pilot med nogle få kunder. Fem til ti kunder, gerne dem der ringer mest. De finder på en uge det, der ellers ville tage os en måned at teste os frem til.

Udrulning og næste modul. Resten af kunderne får adgang, og I beslutter ud fra det, I nu kan se i tallene, hvad der skal bygges derefter.

Den enkle selvbetjeningsportal kan være i drift på få uger, fordi den bygger på data, vi i forvejen flytter. Bestilling med priser og roller tager typisk nogle måneder.

Det bør I have afklaret, inden I går i gang

Spørgsmålene herunder er dem, vi altid stiller. I kan lige så godt tage dem på forhånd – de fleste af dem er forretningsbeslutninger, ikke tekniske.

• Hvem er brugeren? Én person pr. debitor, eller flere personer med hver sin rolle?
• Hvordan kommer de ind? Inviteres de af jer, kan de oprette sig selv, eller skal de logge ind med deres eget firmalogin?
• Hvilken pris gælder? Og hvilket system ejer den, når der er uenighed?
• Hvor langt tilbage skal historikken gå? To år? Alt? Også det der ligger i det gamle ERP?
• Hvad sker der, når en vare er udsolgt? Må kunden bestille alligevel, se en forventet dato, eller ingen af delene?
• Må nogen bestille på vegne af andre? Både hos kunden og hos jer.
• Hvad sker der, hvis ordren ikke kan oprettes i ERP’et? Hvem får besked, og hvad ser kunden?
• Hvem vedligeholder indholdet – produktteksterne, kategorierne, forsiden?

Kan I svare på de otte spørgsmål, har I reelt specificeret portalen.

Hvad afgør prisen?

Den enkle selvbetjeningsportal – login, ordrehistorik og fakturaer – koster fra 500 kr./md. oven i en Connectify-integration. Derfra afhænger prisen af fem ting:

1. Hvor mange moduler I vælger. Hvert modul er en selvstændig pris, så I kan starte småt.
2. Om prislogikken kan hentes fra ERP’et. Kan den det, er det hurtigt. Skal den bygges om eller spejles, tager det længere.
3. Hvor mange roller og regler der skal være. En portal med én brugertype er noget andet end en med indkøbere, godkendere og budgetter pr. afdeling.
4. Om produktdata findes. Har I et PIM med tekster og billeder, er sagen klar. Skal data samles fra regneark, er det en opgave i sig selv.
5. Om vi skal bygge noget, der ikke findes i forvejen. Det gør vi gerne – men det prissættes særskilt.

I får prisen på det hele, før vi går i gang, og afklaringen koster ikke noget.

Hvad I får ud af det

Færre henvendelser. Det, der i dag kommer ind som mails, bliver noget kunden selv finder.

Flere ordrer. Når det er nemt at genbestille, og priserne er de rigtige, bliver der bestilt oftere – også uden for jeres åbningstid.

Færre fejl. Ordren kommer ind som den er lagt, i stedet for at blive tastet om fra en mail.

Et bedre udgangspunkt for at sælge. I kan se, hvad kunderne kigger på, og hvad de ikke finder.

Sådan kommer I i gang

Vi starter med en gratis afklaring, hvor vi gennemgår jeres systemer, jeres kunder og de arbejdsgange, der fylder mest. Derefter foreslår vi et første modul, der kan stå alene og give værdi med det samme – og lægger en plan for, hvad der kan følge efter.

I får prisen på det hele, før vi går i gang.