DI pokalbių botas produktų konfiguratoriams: variantų patikra ir pasiūlymų rengimas

B2B produkto konfigūratorius iš daugelio savybių turi sudaryti techniškai tinkamą pasirinkimą. DI pokalbių botas gali užduoti aiškius klausimus, paaiškinti terminiją ir struktūrizuoti reikalavimus. Tačiau jis neturi pats spręsti, kurie komponentai yra suderinami, kokia kaina galioja arba ar variantą galima pristatyti. Būtent toks atskyrimas užtikrina, kad DI pokalbių botas produktų konfiguratoriams veiktų patikimai.

Šis gidas parodo, kaip svetainės savininkai gali sukurti dialogu valdomą konfigūratorių: nuo stabilių produkto duomenų ir deterministinių taisyklių iki kvalifikuoto perdavimo pardavimų komandai. Tikslas nėra laisvai suformuluotas produkto pasiūlymas, o aiškus ir suprantamas kelias nuo reikalavimų iki galiojančio pasirinkimo arba aiškiai pažymėtos atviros patikros.

Produkto konfigūravimas nėra laisvas konsultacinis pokalbis

Kalbos modeliai puikiai supranta natūralią kalbą ir aiškiai pateikia informaciją. Tačiau variantų logika yra visai kita užduotis. Ar profilis tinka prie jungties, ar variklis atlaikys reikiamą apkrovą, ar paviršius pritaikytas naudojimo vietai – visa tai turi remtis patvirtintais duomenimis ir taisyklėmis. Įtikinamai skambančių atsakymų nepakanka.

NIST įtikinamai pateiktą, bet neteisingą generatyvinių sistemų turinį vadina konfabuliacijomis. Teikiant konsultacijas apie produktus, tokios klaidos nėra tik stiliaus trūkumas. Jos gali lemti netinkamas užklausas pasiūlymams, klaidingus lūkesčius arba techniškai neįmanomus derinius. Todėl modelis turėtų valdyti dialogą, o taisyklių rinkinys – nustatyti leistinus rezultatus.

Atskirkite pokalbį, taisyklių rinkinį ir pagrindinius duomenis

Patikima architektūra susideda iš trijų aiškių sluoksnių. Pokalbių sluoksnis atpažįsta užklausą, užduoda kitą tinkamą klausimą ir paaiškina rezultatus. Taisyklių sluoksnis tikrina priklausomybes, išimtis, privalomas savybes ir ribines reikšmes. Duomenų sluoksnis pateikia produktų ID, savybes, dokumentus, kainas ir likučius iš atitinkamų sistemų.

• Pokalbių botas formuluoja klausimus, apibendrina reikalavimus ir paaiškina patikrintą pasirinkimą.
• Taisyklių variklis sprendžia, kurie deriniai yra galiojantys, negaliojantys arba reikalaujantys patikros.
• PIM, ERP arba el. parduotuvės sistema pateikia patvirtintus produkto, kainų ir likučių duomenis.
• CRM arba pasiūlymų procesas perima kvalifikuotą duomenų rinkinį su atsekama kilme.

Šios ribos turėtų būti matomos ir techniškai. Variantų patikros įrankis gauna struktūrizuotas savybes ir grąžina ID, būseną bei priežasčių kodus. Modeliui neturėtų būti perduodama ilga duomenų bazės išraša. Kuo mažesnis sąsajos susiejimas, tuo lengviau kontroliuoti teises, registravimą ir testavimą.

Modeliuokite variantus naudodami stabilius ID

Žmonės kalba apie „plačią antracito spalvos versiją“, o sistemoms reikia stabilių identifikatorių. Todėl produktų šeimoms, variantams, savybėms ir reikšmėms naudokite unikalius ID. Rodomi pavadinimai gali būti verčiami arba redaguojami, nesulaužant taisyklių ryšių.

„Google“ taip pat rekomenduoja produktų variantams naudoti bendrą produkto grupę ir variantą apibrėžiančias savybes. Struktūrizuotuose duomenyse galima naudoti ProductGroup, variesBy, hasVariant ir bendrą productGroupID. Tai nėra pilnas konfigūracijos modelis, tačiau rodo svarbų principą: bendros savybės priklauso grupei, o skiriamosios – konkrečiam variantui.

Papildomai išsaugokite taisyklių rinkinio versiją. Jei derinys vėliau pasikeičia, turi išlikti galimybė atsekti, kurios taisyklės galiojo ankstesnės užklausos metu. Pasiūlymų komanda tuomet galės suprasti, ar konfigūracija vis dar aktuali, ar ją reikia patikrinti iš naujo.

Veskite nuo reikalavimų iki galiojančių parinkčių

Geras dialogas neprasideda nuo viso katalogo. Pirmiausia klausiama apie savybes, kurios atmeta daugelį negaliojančių kelių. Modulinės uždangos sistemos atveju tai galėtų būti naudojimo vieta, vidinis plotis, tvirtinimo tipas, oro sąlygos, pageidaujamas valdymas ir paviršius. Po kiekvieno atsakymo taisyklių sluoksnis patikrina, kurios parinktys dar yra leistinos.

Pokalbių botas gali išversti techninius terminus į kasdienę kalbą: kam reikalingas tvirtinimo tipas? Kokias pasekmes turi montavimas lauke? Kuo skiriasi rankinis ir variklinis valdymas? Paaiškinimai turi būti imami tik iš patvirtintų žinių. Techninės ribinės reikšmės nenespėjamos iš teksto, o tikrinamos kaip struktūrizuotos taisyklės.

Aiškesnis kelių tinkančių rezultatų palyginimas

Jei lieka keli variantai, botas neturėtų savavališkai vadinti vieno iš jų „geriausiu“. Jis gali palyginti patikrintus skirtumus, pavyzdžiui, medžiagą, patvirtintą naudojimo sritį, reikalingus priedus ar dokumentuotą pristatymo formą. Rekomendacijoms reikalingas skaidrus tikslo kriterijus. Be šio kriterijaus neutralus pasirinkimas su patikslinamuoju klausimu yra sąžiningesnis.

Kaina ir likučiai lieka šaltinio duomenimis

Kaina ir pristatymo galimybės keičiasi dažniau nei techniniai aprašymai. Todėl jie nepriklauso bendram žinių skyriui, kurį modelis gali laisvai atkartoti. Prireikus užklauskite abiejų reikšmių iš atsakingo šaltinio ir pateikite rezultatą su valiuta, galiojimo kontekstu bei laiko žyma.

„Google Merchant Center“ specifikacija reikalauja, kad kaina ir likučiai produkto duomenyse sutaptų su tiksliniu puslapiu ir pirkimo procesu. Dialogu valdomam konfigūratoriui iš to kyla praktinė taisyklė: jei šaltinis nepateikia aktualios reikšmės, pokalbių botas nerodo spėjamo pakaitalo. Vietoj to jis nurodo, kad reikšmė bus patikrinta rengiant pasiūlymą.

Taip pat atskirai turi būti laikomos kiekio nuolaidos, klientui pritaikytos sąlygos, montavimas, pristatymas ar nuo projekto priklausantys priedai. Matoma bazinė kaina neturi būti automatiškai vadinama įpareigojančia galutine kaina. Atsakyme turėtų būti tiksliai įvardyta, kurie komponentai yra patvirtinti, o kurie dar atviri.

Neišsamūs duomenys neturi sukurti klaidingo rezultato

Žmonės praleidžia klausimus, naudoja apytikslius matmenis arba nežino techninių sąlygų. Todėl sistemai reikia trijų rezultatų būsenų: galiojanti, negaliojanti ir reikalaujanti patikros. „Reikalaujanti patikros“ nėra klaida, o tvarkingas atsakymas, kai trūksta duomenų arba numatyta specialistų patikra.

Pavyzdys: klientė nurodo apytikslį plotį, bet nežino tvirtinimo pagrindo. Pokalbių botas gali susiaurinti tinkančias produktų šeimas, tačiau negali patvirtinti konkretaus montavimo rinkinio. Jis pažymi atvirą savybę, paaiškina, kodėl ji reikalinga, ir įtraukia ją į pasiūlymo perdavimą. Taip sukuriamas naudingas aprašas be klaidingo techninio saugumo.

Nuo konfigūracijos rezultato iki pasiūlymo užduoties

Pabaigoje turėtų likti ne tik pokalbio protokolas. Sukurkite struktūrizuotą užduotį su produkto grupės ID, patikrintais variantų ID, pasirinktomis savybėmis, atvirais punktais, taisyklių versija ir šaltinių laiko žymomis. Pridėkite tik kontaktinius duomenis, kurių rinkimui yra aiškus tikslas.

Prieš siunčiant parodykite suvestinę. Užklausą teikiantis asmuo gali pataisyti matmenis, naudojimo vietą ir pasirinkimą. Tik po to užklausa perduodama su idempotentiškumo ID, kad pakartotinis iškvietimas nesukurtų dvigubų kontaktų ar užklausų. Pardavimų komanda gauna sprendimui svarbius faktus, o ne nestruktūrizuotą, ilgą pokalbį.

Geras perdavimas taip pat nurodo būseną: „techniškai patikrinta“, „preliminariai susiaurinta“ arba „reikalinga specialistų patikra“. Jis nežada nei pasiūlymo, nei pristatymo datos, kol atsakingas procesas nepatvirtina šio teiginio.

Duomenų apsauga ir teisės riboja kontekstą

Viešoms konsultacijoms apie produktus dažniausiai nereikia tapatybės. Kontaktai tampa prasmingi tik tada, kai kas nors nori išsaugoti konfigūraciją arba paprašyti pasiūlymo. Rinkite tik būtinus laukus ir paaiškinkite tikslą toje vietoje, kur duomenys yra reikalingi.

Klientui pritaikytos kainos, ankstesni projektai ar sutartiniai produktai priklauso autentifikuotai sričiai. Programėlė tikrina teises; modelis priima sprendimų dėl jų. Straipsnyje apie autentifikuotą DI pokalbių botą klientų portale ši riba aprašyta išsamiau.

Daugiakalbiam variantų valdymui reikalingi bendri identifikatoriai

Išverskite rodomus pavadinimus, paaiškinimus ir klausimus, bet ne vidinius ID. „Pulverbeschichtet“, „powder-coated“ ir „revêtu par poudre“ turi rodyti į tą pačią savybės reikšmę. Taip taisyklių patikra išlieka nepriklausoma nuo kalbos, o daugiakalbė pasiūlymų komanda dirba su tais pačiais objektais.

Testuokite skaičių formatus, dešimtainius skirtukus, matavimo vienetus ir išverstus sinonimus. Naudotojas gali nurodyti „2,5 metro“, „250 cm“ arba suapvalintą reikšmę. Normalizavimas turi aiškiai išsaugoti vienetą ir tikslumą. Vadovas apie daugiakalbį kontaktų kvalifikavimą parodo, kaip sujungti kalbos keitimą ir struktūrizuotą perdavimą.

Testuokite taisykles, kalbą ir perdavimą kartu

Sklandus dialogas nėra pakankamas testas. Sukurkite matricą iš galiojančių derinių, draudžiamų porų, ribinių reikšmių, trūkstamų duomenų, pasenusių kainų, nesamų likučių ir sistemos sutrikimų. Kiekvienu atveju patikrinkite rodomą paaiškinimą, įrankio iškvietimą, taisyklės rezultatą ir perduotus duomenis.

• Ar naudotojo nurodymas gali apeiti taisykles ar teises?
• Ar botas išlieka sąžiningas, kai trūksta kainos ar likučių?
• Ar negaliojantys deriniai paaiškinami suprantamai?
• Ar kiekviena kalba gauna tuos pačius ID ir taisyklių rezultatus?
• Ar pakartotinis bandymas (retry) nesukuria antro pasiūlymo atvejo?
• Ar perdavimas veikia ir esant nežinomiems reikalavimams?

Papildomai testuokite tipines formų įvestis, spausdinimo klaidas ir pataisymus. Straipsnis apie DI pokalbių botus kaip pagalbininkus formose parodo, kaip sąveikauja laukų pagalba ir serverio pusės validacija.

Kontrolinis sąrašas gamybiniam naudojimui

1. Pilotiniam projektui pasirinkite aiškiai apribotą produktų šeimą.
2. Apibrėžkite stabilius ID ir atsakingus asmenis kiekvienam duomenų laukui.
3. Paverskite suderinamumą ir ribines reikšmes testuojamomis taisyklėmis.
4. Atskirkite paaiškinimus nuo kainų, likučių ir pasiūlymų užklausų.
5. Pažymėkite galiojančius, negaliojančius ir patikros reikalaujančius rezultatus.
6. Versijuokite taisykles, duomenų šaltinius ir perdavimo formatą.
7. Sumažinkite asmens ir klientui specifinių duomenų kiekį.
8. Patikrinkite visas kalbas naudodami tuos pačius pavyzdinius atvejus.
9. Matuokite galiojančius užbaigimus, pataisymus ir perdavimus specialistams.

Pradėkite nuo vienos produktų šeimos, apriboto klausimų kelio ir aiškaus perdavimo. Kai taisyklės, šaltiniai ir atsakomybės yra švariai atskirti, DI pokalbių botas gali paversti sudėtingą pasirinkimą suprantamu, nesukuriadamas klaidingo įsipareigojimo. Taip konfigūratorius tampa naudinga pradžia patikimam pasiūlymui gauti, o ne nauju klaidų šaltiniu.

Šaltiniai ir standartai

• 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