AI-chatbot til produktkonfiguratorer: Tjek varianter og forbered tilbud

En B2B-produktkonfigurator skal vælge en teknisk passende løsning ud fra mange egenskaber. En AI-chatbot kan i den forbindelse stille spørgsmål på en forståelig måde, forklare fagbegreber og strukturere kravene. Den må dog ikke selv afgøre, hvilke komponenter der er kompatible, hvilken pris der gælder, eller om en variant kan leveres. Præcis denne adskillelse gør en AI-chatbot til produktkonfiguratorer pålidelig.

Denne guide viser, hvordan website-ejere opbygger en dialogstyret konfigurator: fra stabile produktdata og deterministiske regler til en kvalificeret overdragelse til salgsafdelingen. Målet er ikke et frit formuleret produktforslag, men en gennemskuelig vej fra krav til et gyldigt valg eller til et klart markeret åbent tjek.

Produktkonfiguration er ikke en fri rådgivningssamtale

Sprogmodeller er gode til at forstå naturlige formuleringer og gengive informationer på en forståelig måde. Variantlogik er dog en helt anden opgave. Om en profil passer til et samleled, en motor kan klare den nødvendige belastning, eller en overflade er beregnet til anvendelsesstedet, skal fremgå af godkendte data og regler. Svar, der blot lyder sandsynlige, er ikke nok.

NIST betegner overbevisende præsenteret, men forkert indhold fra generative systemer som konfabuleringer. Ved produktrådgivning er sådanne fejl ikke kun redaktionelt uslibede. De kan føre til ubrugelige tilbudsforespørgsler, forkerte forventninger eller teknisk umulige kombinationer. Derfor bør modellen styre dialogen, mens et regelsæt bestemmer de tilladte resultater.

Adskil samtale, regelsæt og stamdata

En robust arkitektur består af tre klare lag. Samtalelaget genkender hensigten, stiller det næste relevante spørgsmål og forklarer resultaterne. Regellaget tjekker afhængigheder, udelukkelser, obligatoriske egenskaber og grænseværdier. Datalaget leverer produkt-ID'er, egenskaber, dokumenter, priser og tilgængelighed fra de henholdsvis ansvarlige systemer.

• Chatbotten formulerer spørgsmål, opsummerer krav og forklarer et godkendt valg.
• Regel-motoren afgør, hvilke kombinationer der er gyldige, ugyldige eller kræver manuel kontrol.
• PIM, ERP eller webshop leverer godkendte produkt-, pris- og lagerdata.
• CRM eller tilbudsprocessen overtager det kvalificerede datasæt med sporbar oprindelse.

Disse grænser bør også være teknisk synlige. Et værktøj til variantkontrol modtager strukturerede egenskaber og returnerer ID'er, status samt begrundelseskoder. Der bør ikke sendes et langt databaseudtræk til modellen. Jo mindre 'kontrakten' er, desto lettere er det at kontrollere rettigheder, logning og tests.

Modelér varianter med stabile ID'er

Mennesker taler om "den brede model i antracit", mens systemer har brug for stabile identifikatorer. Brug derfor entydige ID'er til produktfamilier, varianter, egenskaber og værdier. Viste navne må gerne oversættes eller ændres redaktionelt, uden at regelsammenhængene derved brydes.

Google anbefaler også en fælles produktgruppe og variantdefinerende egenskaber for produktvarianter. I de strukturerede data kan man blandt andet anvende ProductGroup, variesBy, hasVariant og en fælles productGroupID. Det er ikke en komplet konfigurationsmodel, men det viser et vigtigt princip: fælles egenskaber hører til gruppen, mens differentierende egenskaber hører til den konkrete variant.

Gem desuden regelsættets version. Hvis en kombination ændres senere, skal det være muligt at spore, hvilke regler der gjaldt ved en tidligere forespørgsel. Et tilbudsteam kan derefter gennemskue, om en konfiguration stadig er aktuel, eller om den skal tjekkes på ny.

Før brugeren fra krav til gyldige muligheder

En god dialog starter ikke med hele kataloget. Den spørger først om egenskaber, der udelukker mange ugyldige veje. Ved et modulært solafskærmningssystem kunne det være anvendelsessted, lysåbningsbredde, monteringstype, vejrforhold, ønsket betjening og overflade. Efter hvert svar tjekker regellaget, hvilke muligheder der stadig er tilladt.

Chatbotten kan i den forbindelse oversætte fagbegreber til hverdagssprog: Hvorfor er monteringstypen nødvendig? Hvilke konsekvenser har en udvendig montering? Hvad adskiller manuel og motoriseret betjening? Forklaringen må kun stamme fra godkendt viden. Tekniske grænseværdier gættes ikke ud fra en fritekst, men tjekkes som strukturerede regler.

Sammenlign flere passende resultater på en forståelig måde

Hvis der er flere varianter tilbage, bør botten ikke tilfældigt betegne én af dem som "den bedste". Den kan opstille kontrollerede forskelle over for hinanden, såsom materiale, godkendt anvendelsesområde, nødvendigt tilbehør eller dokumenteret leveringsform. Anbefalinger kræver et gennemskueligt målkriterium. Uden dette kriterium er et neutralt valg med et opfølgende spørgsmål mere ærligt.

Pris og tilgængelighed forbliver kildedata

Pris og leveringsevne ændrer sig oftere end tekniske beskrivelser. De hører derfor ikke hjemme i et generelt vidensafsnit, som modellen frit gengiver. Hent begge værdier efter behov fra den ansvarlige kilde, og forsyn resultatet med valuta, gyldighedskontekst og tidsstempel.

Google Merchant Center-specifikationen kræver, at pris og tilgængelighed i produktdata stemmer overens med landingssiden og købsprocessen. For en dialogstyret konfigurator giver det en praktisk regel: Hvis kilden ikke leverer en aktuel værdi, viser chatbotten ikke en skønnet erstatning. Den siger i stedet, at værdien bliver tjekket i tilbuddet.

Mængderabatter, kundespecifikke vilkår, montering, fragt eller projektafhængige tillæg skal også holdes adskilt. En synlig basispris må ikke automatisk betegnes som en bindende totalpris. Svaret bør angive præcist, hvilke elementer der er bekræftet, og hvilke der stadig er åbne.

Ufuldstændige oplysninger må ikke skabe et tilsyneladende resultat

Mennesker springer spørgsmål over, bruger omtrentlige mål eller kender ikke de tekniske rammebetingelser. Systemet har derfor brug for tre resultattilstande: gyldig, ugyldig og kræver kontrol. "Kræver kontrol" er ikke en fejl, men et ordentligt svar, når der mangler oplysninger, eller der er planlagt en faglig kontrol.

Eksempel: En kunde opgiver den omtrentlige bredde, men kender ikke monteringsunderlaget. Chatbotten kan indsnævre de passende produktfamilier, men må ikke bekræfte et konkret monteringssæt. Den markerer den åbne egenskab, forklarer hvorfor den er nødvendig, og tager den med i overdragelsen af tilbuddet. På den måde opstår der en brugbar briefing uden falsk teknisk tryghed.

Fra konfigurationsresultat til tilbudsbriefing

Til sidst bør der ikke blot stå en samtalelog. Generér en struktureret briefing med produktgruppe-ID, kontrollerede variant-ID'er, valgte egenskaber, åbne punkter, regelsætversion og kildetidsstempler. Tilføj kun kontaktoplysninger, hvor der er et klart formål med indsamlingen.

Vis opsummeringen inden afsendelse. Personen, der forespørger, kan rette mål, anvendelsessted og valg. Først derefter overdrages forespørgslen med et idempotens-ID, så et gentaget kald ikke skaber dobbelte leads eller tilbudssager. Salgsteamet modtager de beslutningsrelevante fakta i stedet for en ustruktureret, lang samtale.

En god overdragelse angiver desuden status: "teknisk godkendt", "midlertidigt indsnævret" eller "faglig kontrol påkrævet". Den lover hverken et tilbud eller en leveringsdato, før den ansvarlige proces har bekræftet denne udtalelse.

Databeskyttelse og rettigheder begrænser konteksten

En offentlig produktrådgivning kræver som regel ingen identitet. Kontaktoplysninger giver først mening, når nogen ønsker at gemme en konfiguration eller anmode om et tilbud. Indsaml kun de nødvendige felter, og forklar formålet på det sted, hvor dataene skal bruges.

Kundespecifikke priser, tidligere projekter eller aftaleprodukter hører til i et godkendt område. Applikationen tjekker rettighederne; modellen afgør dem ikke. Indlægget om godkendt AI-chatbot i kundeportalen beskriver denne grænse mere detaljeret.

Flersprogede varianter kræver fælles identifikatorer

Oversæt viste navne, forklaringer og spørgsmål, men ikke de interne ID'er. "Pulverbeschichtet", "powder-coated" og "revêtu par poudre" skal pege på den samme egenskabsværdi. På den måde forbliver regelkontrollen uafhængig af sproget, og et flersproget salgsteam arbejder med de samme objekter.

Test talformater, decimaltegn, måleenheder og oversatte synonymer. En bruger kan skrive "2,5 meter", "250 cm" eller en afrundet angivelse. Normaliseringen skal udtrykkeligt gemme enhed og præcision. Guiden til flersproget lead-kvalificering viser, hvordan sprogskift og struktureret overdragelse kan kombineres.

Test regler, sprog og overdragelse samlet

En flydende dialog er ikke en tilstrækkelig test. Opbyg en matrix af gyldige kombinationer, forbudte parringer, grænseværdier, manglende oplysninger, forældede priser, manglende lager og systemfejl. Tjek for hvert tilfælde den viste forklaring, værktøjskaldet, regelresultatet og de overdragede data.

• Kan en brugerinstruks omgå regler eller rettigheder?
• Forbliver botten ærlig ved manglende pris eller lager?
• Bliver ugyldige kombinationer forklaret på en forståelig måde?
• Modtager hvert sprog de samme ID'er og regelresultater?
• Genererer et nyt forsøg (retry) ikke en ekstra tilbudssag?
• Fungerer overdragelsen også ved ukendte krav?

Test desuden typiske formularindtastninger, tastefejl og rettelser. Indlægget om AI-chatbots som formularhjælp viser, hvordan felthjælp og validering på serversiden samspiller.

Tjekliste til produktionsdrift

1. Vælg en klart afgrænset produktfamilie til pilotprojektet.
2. Definér stabile ID'er og ansvarlige for hvert datafelt.
3. Overfør kompatibilitet og grænseværdier til testbare regler.
4. Adskil forklaringer fra pris-, lager- og tilbudsforespørgsler.
5. Markér gyldige, ugyldige og kontrolkrævende resultater.
6. Versionsstyr regler, datakilder og overdragelsesformat.
7. Minimér personhenførbare og kundespecifikke data.
8. Tjek alle sprog med de samme referencesager.
9. Mål gyldige afslutninger, rettelser og faglige overdragelser.

Start med én produktfamilie, en afgrænset spørgesti og en klar overdragelse. Når regler, kilder og ansvarsområder er adskilt korrekt, kan en AI-chatbot gøre komplekse valg forståelige uden at foregive bindende tilsagn. Derved bliver konfiguratoren til en hjælpsom indgang til et solidt tilbud i stedet for en ny fejlkilde.

Kilder og standarder

• Google Search Central: Structured data for product variants
• Google Search Central: Product structured data
• Google Merchant Center: Product data specification
• NIST AI 600-1: Generative Artificial Intelligence Profile