Produktkonfigurator i B2B: vad ni bör veta före valet

En inköpare ska beställa en produkt med flera varianter. Motor, material och anslutning måste passa ihop. Utan en produktkonfigurator blir det mejl fram och tillbaka, och säljaren kontrollerar varje kombination för hand.

Det som oftast brister är priset och artikelnumret. En snygg valyta hjälper inte om rabatten kommer från fel lista eller om ordern inte kan skapas. Konfiguratorn är lika korrekt som reglerna, priserna och artikelnumren bakom den.

Därför är den en transaktionsdel i köpet. Den ska avgöra vilka val som är giltiga, vilket pris som gäller och vilket underlag som går vidare till offert eller order.

Vad en produktkonfigurator gör för ert köp

Tänk er en beställningsblankett med inbyggd kontroll. Den som fyller i ett fält som inte hör ihop med de andra stoppas innan blanketten skickas. En produktkonfigurator gör samma sak digitalt. Kunden väljer egenskaper, varianter och tillval. Systemet släpper bara igenom kombinationer som går att tillverka och leverera.

I föreskriften SCB-FS 2024:27 ingår företagens möjlighet att låta besökare anpassa eller designa varor eller tjänster på en webbplats i mätningen av digital försäljning. Avgränsningen är tydlig. En produktkonfigurator samlar kundens val kring en vara eller tjänst. Den är mer än en bildvisning.

Samma föreskrift skiljer webbförsäljning från EDI-försäljning. I webbförsäljning beställer kunden via webbplats eller app. EDI bygger på beställningsmeddelanden från kundens affärssystem. Konfiguratorn kan vara steget före offert, order eller det flödet. Den sitter mellan produktdata och affärstransaktionen.

En konfigurator som bara byter bild flyttar inget manuellt moment. Säljaren får ändå tolka valet, räkna priset och skapa artikeln. Felet upptäcks sent, ofta när ordern redan är lovad.

Skriv ner de tre beslut som konfiguratorn ska fatta hos er: vilka val som är giltiga, vilket pris som gäller och vilket artikelnummer som skapas. De tre raderna styr typ, data och förvaltning längre fram.

Fyra typer av produktkonfigurator och när vilken passar

Typen styrs av vilket beslut kunden måste fatta. Utseendet i en demo är en svag grund för valet.

En regelbaserad konfigurator passar när komponenterna har hårda beroenden. En motor i en viss storlek går bara ihop med vissa växellådor. Regeln döljer eller stoppar det ogiltiga valet. Fallgropen är ägarskapet. Om ingen namngiven person godkänner ändringar glider reglerna isär efter nästa produktlansering.

Guided selling passar när köparen saknar den tekniska kartan. En fråga i taget leder fram till en produkt eller ett paket. Det avlastar säljaren i enkla ärenden. Risken är att frågeflödet lovar en lösning som produktion eller lager inte kan leverera. Frågorna måste därför peka på samma regler som den tekniska modellen.

En visuell konfigurator passar när utseendet styr köpet, till exempel färg, form eller placering. Kunden väljer i bild eller i en förhandsvisning. Bilden måste följa reglerna. Annars kan kunden spara en kombination som ritningen ser bra ut i och som verkstaden sedan avvisar.

En CPQ-liknande konfigurator gör valet till en offert. Pris, villkor och leveransdatum följer med. Den passar projekt och affärer med kundspecifika priser. Fallgropen är en prisregel som inte är avstämd mot affärssystemet innan offerten går iväg.

Rena typer är ovanliga. Säg att en pumptillverkare har tekniska beroenden mellan pumphus, motor och anslutning. Återförsäljaren behöver frågor som leder rätt. Då bär reglerna de tekniska spärrarna, och guided selling bär dialogen. Välj typ efter beslutet hos kunden.

Så sätts priset när konfigurationen blir offert

Priset är det lager som oftast spricker. Varje val kan ändra priset. Vissa val ändrar också rabatt, fraktvillkor och ledtid. Tre lager behöver hållas isär.

Listpriset är grundpriset för varianten. Det kundspecifika priset gäller en viss kund eller ett visst avtal. Rabatten gäller ett avtal eller en period och läggs ovanpå rätt grund. Om lagren blandas kan konfiguratorn visa ett belopp som ekonomin inte kan fakturera.

Breakit. Ett felräknat pris skadar förtroendet för hela leverantören, även när produkten i sig är rätt.

Automatisering kräver tre svar innan bygget startar. Finns det en prislista per variant? Hur hanteras ett tillval som saknar eget pris, till exempel genom ett påslag eller en fast avgift? Vem godkänner en avvikelse när kunden vill ha ett pris utanför listan?

Ett offertverktyg som ska ta emot konfigurationen behöver samma prislogik. Annars räknar offerten om beloppet och kunden ser två siffror.

Kartlägg de tre prislagren innan någon bygger. Markera varje val som saknar pris. De tomma raderna är det arbete som återstår.

Vem som äger vilken data i PIM och ERP

Konfiguratorn läser från två håll. Varje rad behöver en master. Annars får samma produkt två beskrivningar, och kunden får ett pris som inte går att fakturera.

PIM är master för texter, attribut, bilder och dokument. De berikas en gång och går sedan ut till webb, portal och återförsäljare. Affärssystemet är master för artikelnummer och grunddata, eftersom ekonomi, lager och order behöver samma källa. Där ligger också kundspecifika priser och prislogik, så att priset i konfigurationen är samma pris som faktureras. Lagersaldo och ledtid hämtas från samma håll, så att konfiguratorn inte lovar mer än produktionen kan leverera. Konfigurationsreglerna hör hemma i en versionerad regelfil med en namngiven ägare, så att ingen regel kan ändras i tysthet.

Så här ser felet ut när ägarskapet är oklart. Ett mått uppdateras i PIM men samma fält ligger kvar i affärssystemets artikelregister. Webben visar det nya värdet, offertunderlaget läser det gamla och ordern tar en tredje siffra från en äldre export. Artikelnummer och priser bör därför ligga i affärssystemet, till exempel Business Central eller Monitor, och den fördelningen måste vara beslutad innan integrationen byggs.

Varje val i konfiguratorn ska gå att koppla till artikelnummer, komponenter, prisvillkor, lagerlogik och underlaget för offert eller order. Då glider webbens produktlogik inte isär från orderhanteringen.

Attributen behöver stabila id. En gemensam modell för hanteringen av produktinformation gör att texter och attribut kan återanvändas i webb, offert och produktion.

Testa fördelningen på en riktig variant. Välj en produkt och följ varje fält från visning till faktura. Ett fält som kan ändras på två ställen saknar master, och en rad utan namngiven ägare är ett beslut ni ännu inte har tagit.

Vad upplägget kräver av er och när det inte passar

Konfiguratorn blir inte bättre än den data den läser. Ni behöver äga tre saker innan en leverantör börjar bygga: en utsedd regelägare, en produktmodell med rena attribut och en beslutad väg för avvikelser, så att ett undantag inte blir en tyst regel.

Regelägaren godkänner nya kombinationer och sparar versionen. Produktmodellen talar om vilka attribut som finns, vilka som är obligatoriska och vilka som utesluter varandra. Avvikelseprocessen säger vem som får släppa igenom ett val som reglerna stoppar, och hur det valet dokumenteras.

Digg pekar ut WCAG 2.1 som den centrala referensen för digital tillgänglighet. I en konfigurator betyder det tangentbordsstyrning, begripliga felmeddelanden kopplade till rätt val och en chans att granska resultatet innan offert eller order. Om användaren inte förstår varför ett val avvisas ökar belastningen på säljare och support. Tillgängligheten blir då också en kontroll av affärslogiken.

Ett annat arbetssätt passar bättre i tre lägen. Produkten har få varianter, och en enkel prislista räcker. Regelverket ändras varje vecka, så att en regelfil hinner bli inaktuell. Affärssystemet kan inte lämna lagerdata i tid, och konfiguratorn skulle lova saldo den inte har. Då kan ett enklare offertformulär eller ett säljsamtal ge samma resultat till lägre kostnad.

Skriv ner namnet på regelägaren, listan över attribut och vägen för avvikelser. Saknas någon av dem är det för tidigt att bygga.

Förvaltningen efter go-live avgör den verkliga kostnaden

Kostnaden slutar inte vid go-live. Regler, priser och integrationer ändras när sortiment, affärssystem och webbplattform uppdateras. Någon måste äga det arbetet varje månad.

Fyra poster återkommer. Regelunderhållet omfattar ändrade regler, nya varianter och kontroll av ogiltiga kombinationer, och ägs av er regelägare med stöd från leverantören. Prisuppdateringarna håller prislistor, kundspecifika priser och rabatter i takt med affärssystemet och kräver en fast rutin på er sida. Integrationerna mot PIM och affärssystemet måste fungera efter varje ändring och ligger hos leverantören enligt avtal. Uppgraderingarna handlar om kompatibilitet när plattformen eller konfiguratorn får en ny version, och ligger hos leverantören när det finns ett förvaltningsavtal.

En kalkyl med bara byggkostnad blir fel. Underhållet syns först när en ny version bryter en regel, eller när en prisändring inte når konfiguratorn. Samma risk finns i en integration mot affärssystemet. Anropet kan fungera på lanseringsdagen och falla vid nästa release.

Lägg förvaltningen som en återkommande post i budgeten, vid sidan av byggkostnaden.

Glanser Care är ett avtalat ansvar till fast månadskostnad som omfattar versionsuppföljning, kompatibilitet vid uppgraderingar, underhåll av integrationerna mot affärssystemet och buggrättning. Om förvaltningen redan ligger hos er egen IT kan det upplägget vara onödigt. Räkna fram årskostnaden för de fyra posterna innan avtalet skrivs.

Så rullar ni ut en konfigurator i etapper

Nyttan växer när konfiguratorn följer hela värdekedjan, från kundens val till produktionsunderlaget. När underlaget skapas direkt från giltiga val behövs färre manuella omtolkningar längre fram.

Börja med en produktfamilj eller en marknad som pilot, eftersom felen göms i ett helt sortiment. Definiera sedan attributmodellen för filtrering, varianter och dimensioner. Konfiguratorn kan bara välja på attribut som finns.

Koppla därefter PIM för innehållet och affärssystemet för artikelnummer, priser och lager, och testa tre konfigurationer mot ett riktigt offertfall. Bygg sedan regelflödet och låt produktion eller teknik granska alla ogiltiga kombinationer innan kunderna ser dem.

Lansera först för en begränsad grupp, till exempel återförsäljare, och mät hur många offerter som behöver rättas för hand. Utöka sortiment och funktioner när pilotens fel är under kontroll.

Varje steg kommer före nästa eftersom felet annars sprids. Attributen måste finnas innan kopplingen. Kopplingen måste stämma innan reglerna granskas. Reglerna måste hålla innan en större grupp använder dem.

Lista de produktfamiljer som ger flest ogiltiga kombinationer. Den listan är er pilot.

Svaren från leverantören visar vem som förvaltar reglerna

Be om tre svar i skrift, och jämför dem med er fördelning av master.

Första frågan gäller regelägarskap. Vem godkänner en ny regel, och hur sparas versionen när en regel ändras efter en produktlansering? Ett tydligt svar visar att leverantören räknar med förvaltning. Ett svagt svar, till exempel att reglerna ligger i konfiguratorn utan version, visar att underhållet hamnar hos er.

Andra frågan gäller prislogik. Hur får en konfiguration fram ett pris som stämmer mot affärssystemet när ett tillval saknar eget pris, och vad händer med en offert som skapades före en prisändring? Svaret visar om gamla offerter skyddas eller räknas om i tysthet.

Tredje frågan gäller driftfel. Vilket beteende får konfiguratorn när affärssystemet inte svarar, till exempel en reserv för lagerdata och en tydlig signal till kunden? Svaret visar om ni riskerar att lova saldo ni inte har.

Lägg svaren bredvid det ni har bestämt om konfigurationsregler och pris. Om ägare, version och källa saknas i svaret är upplägget inte redo att byggas.

Kontrollera er nuvarande lösning innan ni väljer

Många företag har redan en offertprocess, ett PIM eller en portal. Kartlägg vilka artikelnummer och prisregler som ligger i affärssystemet, var det berikade innehållet finns och vilka integrationer som bär flödet i dag. Ta med den som ansvarar för affärssystemet och den som ansvarar för prissättningen, eftersom båda behövs för att besvara frågorna om regler, pris och driftfel.

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. Glanser