DI tērzēšanas robots produktu konfiguratoriem: variantu pārbaude un piedāvājumu sagatavošana

B2B produktu konfiguratoram no daudzām pazīmēm ir jāizveido tehniski piemērota izvēle. DI tērzēšanas robots šajā procesā var uzdot saprotamus jautājumus, paskaidrot speciālos terminus un strukturēt prasības. Tomēr tas nedrīkst pats izlemt, kuras detaļas ir savietojamas, kāda cena ir spēkā vai vai kāds variants ir pieejams piegādei. Tieši šī nošķiršana padara DI tērzēšanas robotu produktu konfiguratoriem uzticamu.

Šī rokasgrāmata parāda, kā tīmekļa vietņu uzturētāji var izveidot dialoga vadītu konfiguratoru: no stabiliem produktu datiem līdz deterministiskiem noteikumiem un kvalificētai nodošanai pārdošanas komandai. Mērķis nav brīvi formulēts produkta ieteikums, bet gan izsekojams ceļš no prasībām līdz derīgai izvēlei vai skaidri atzīmētai atvērtai pārbaudei.

Produktu konfigurēšana nav brīva konsultāciju saruna

Valodas modeļi labi saprot dabiskus formulējumus un uztverami atspoguļo informāciju. Tomēr variantu loģika ir cits uzdevums. Vai profils der savienotājam, vai motors spēj tikt galā ar nepieciešamo slodzi, vai virsma ir paredzēta izmantošanas vietai – tam jāizriet no apstiprinātiem datiem un noteikumiem. Ticami skanošas atbildes nav pietiekamas.

NIST pārliecinoši noformētu, bet nepareizu ģeneratīvo sistēmu saturu dēvē par konfabulācijām. Produktu konsultācijās šādas kļūdas nav tikai redakcionāla nepilnība. Tās var novest pie nelietojamiem piedāvājumu pieprasījumiem, nepareizām gaidām vai tehniski neiespējamām kombinācijām. Tāpēc modelim vajadzētu vadīt dialogu, kamēr noteikumu kopums nosaka pieļaujamos rezultātus.

Nošķiriet sarunu, noteikumu kopumu un pamatdatus

Izturīga arhitektūra sastāv no trim skaidriem slāņiem. Sarunas slānis atpazīsta vajadzību, uzdod nākamo atbilstošo jautājumu un paskaidro rezultātus. Noteikumu slānis pārbauda atkarības, izņēmumus, obligātās pazīmes un robežvērtības. Datu slānis nodrošina produktu ID, īpašības, dokumentus, cenas un pieejamību no attiecīgi atbildīgajām sistēmām.

• Tērzēšanas robots formulē jautājumus, apkopo prasības un paskaidro pārbaudīto izvēli.
• Noteikumu dzinējs (rule engine) izlemj, kuras kombinācijas ir derīgas, nederīgas vai pakļautas pārbaudei.
• PIM, ERP vai veikala sistēma nodrošina apstiprinātus produktu, cenu un krājumu datus.
• CRM vai piedāvājuma process pārņem kvalificēto datu kopu ar izsekojamu izcelsmi.

Šīm robežām jābūt redzamām arī tehniski. Variantu pārbaudes rīks saņem strukturētas pazīmes un atgriež ID, statusu, kā arī pamatojuma kodus. Modelim nedrīkst padot garu datubāzes izrakstu. Jo šaurāks Līgums (contract), jo vieglāk kontrolēt piekļuves tiesības, žurnalēšanu un testus.

Modelējiet variantus ar stabiliem ID

Cilvēki runā par "platāko izpildījumu antracīta krāsā", bet sistēmām ir nepieciešami stabili identifikatori. Tāpēc produktu saimēm, variantiem, pazīmēm un vērtībām izmantojiet unikalizētus ID. Attēlojamos nosaukumus drīkst tulkot vai redakcionāli mainīt, nesabojājot noteikumu saites.

Arī Google produktu variantiem iesaka kopīgu produktu grupu un variantus definējošas īpašības. Strukturētajos datos cita starpā var izmantot ProductGroup, variesBy, hasVariant un kopīgu productGroupID. Tas nav pilnīgs konfigurācijas modelis, taču parāda svarīgu principu: kopīgās pazīmes pieder grupai, atšķirīgās pazīmes – konkrētajam variantam.

Papildus saglabājiet noteikumu kopuma versiju. Ja kombinācija vēlāk mainās, jāsaglabā iespēja izsekot, kādi noteikumi bija spēkā agrāka pieprasījuma laikā. Piedāvājumu komanda tad var saprast, vai konfigurācija joprojām ir aktuāla vai jāpārbauda no jauna.

Vadiet no prasībām līdz derīgām opcijām

Laba saruna nesākas ar visu katalogu. Vispirms tiek jautāts par pazīmēm, kas izslēdz daudzus nederīgus zarus. Modulāras noēnošanas sistēmas gadījumā tās varētu būt izmantošanas vieta, gaismas platums, stiprinājuma veids, laikapstākļu iedarbība, vēlamā vadība un virsma. Pēc katras atbildes noteikumu slānis pārbauda, kuras opcijas vēl ir pieļaujamas.

Tērzēšanas robots var pārtulkot speciālos terminus ikdienišķā valodā: Kāpēc nepieciešams stiprinājuma veids? Kādas sekas ir montāžai ārpusē? Ar ko atšķiras manuālā un motorizētā vadība? Paskaidrojums drīkst nākt tikai no apstiprinātajām zināšanām. Tehniskās robežvērtības netiek minētas no brīva teksta, bet tiek pārbaudītas kā strukturēti noteikumi.

Saprotami salīdziniet vairākus atbilstošus rezultātus

Ja pāri paliek vairāki varianti, botam nevajadzētu patvaļīgi nosaukt kādu no tiem par "labāko". Tas var pretstatīt pārbaudītās atšķirības, piemēram, materiālu, apstiprināto izmantošanas zonu, nepieciešamos piederumus vai dokumentēto piegādes veidu. Ieteikumiem ir nepieciešams caurspīdīgs mērķa kritērijs. Bez šī kritērija neitrāla izvēle ar precizējošu jautājumu ir godīgāka.

Cena un pieejamība paliek avota dati

Cena un pieejamība piegādei mainās biežāk nekā tehniskie apraksti. Tāpēc tie nepieder pie vispārīgās zināšanu sadaļas, ko modelis brīvi atstāsta. Pēc nepieciešamības pieprasiet abas vērtības no atbildīgā avota un pievienojiet rezultātam valūtu, derīguma kontekstu un laika spiedogu.

Google Merchant Center specifikācija pieprasa, lai cena un pieejamība produktu datos sakristu ar mērķa lapu un pirkuma procesu. Dialoga vadītam konfiguratoram no tā izriet praktisks noteikums: ja avots nesniedz aktuālu vērtību, tērzēšanas robots nerāda aptuvenu aizstājēju. Tā vietā tas paziņo, ka vērtība tiks pārbaudīta piedāvājumā.

Tāpat atsevišķi jāsaglabā apjoma atlaides, klientam specifiski nosacījumi, montāža, piegāde vai no projekta atkarīgās piemaksas. Redzamu bāzes cenu nedrīkst automātiski nosaukt par saistošu kopējo cenu. Atbildē precīzi jānorāda, kuras sastāvdaļas ir apstiprinātas un kuras vēl ir atvērtas.

Nepilnīgi dati nedrīkst radīt šķietamu rezultātu

Cilvēki izlaiž jautājumus, izmanto aptuvenus izmērus vai nezina tehniskos pamatnosacījumus. Tāpēc sistēmai ir nepieciešami trīs rezultāta stāvokļi: derīgs, nederīgs un pārbaudāms. "Pārbaudāms" nav kļūda, bet gan tīra atbilde, ja trūkst datu vai ir paredzēta speciālista pārbaude.

Piemērs: kliente nosauc aptuveno platumu, bet nezina stiprinājuma pamatni. Tērzēšanas robots var sašaurināt atbilstošās produktu saimes, taču nedrīkst apstiprināt konkrētu montāžas komplektu. Tas atzīmē atvērto pazīmi, paskaidro, kāpēc tā ir nepieciešama, un iekļauj to piedāvājuma nodošanā. Tādējādi rodas lietojams uzdevuma apraksts bez viltus tehniskās drošības.

No konfigurācijas rezultāta līdz piedāvājuma uzdevumam

Nobeigumā vajadzētu būt kam vairākam par sarunas protokolu. Izveidojiet strukturētu uzdevumu ar produkta grupas ID, pārbaudītiem variantu ID, izvēlētajām pazīmēm, atvērtajiem punktiem, noteikumu kopuma versiju un avota laika spiedogiem. Pievienojiet tikai tos kontaktpārtas datus, kuru ievākšanai ir skaidrs mērķis.

Pirms nosūtīšanas parādiet kopsavilkumu. Pieprasītājs var labot izmērus, izmantošanas vietu un izvēli. Tikai pēc tam pieprasījums tiek nodots ar idempotences ID, lai atkārtots izsaukums neradītu dubultus pieteikumus vai piedāvājumu gadījumus. Pārdošanas komanda saņem lēmumu pieņemšanai svarīgos faktus, nevis nestrukturētu, garu sarunu.

Laba nodošana nosauc arī statusu: "tehniski pārbaudīts", "pagaidu sašaurināts" vai "nepieciešama speciālista pārbaude". Tā nesola ne piedāvājumu, ne piegādes termiņu, pirms atbildīgais process nav apstiprinājis šo paziņojumu.

Datu aizsardzība un tiesības ierobežo kontekstu

Publiskai produktu konsultēšanai visbiežāk nav nepieciešama identitāte. Kontaktdata kļūst lietderīgi tikai tad, kad kāds vēlas saglabāt konfigurāciju vai pieprasīt piedāvājumu. Ievāciet tikai nepieciešamos laukus un paskaidrojiet mērķi vietā, kur dati tiek pieprasīti.

Klientam specifiskas cenas, iepriekšējie projekti vai līguma produkti pieder autentificētai zonai. Lietotne pārbauda piekļuves tiesības; modelis par tām nelemj. Raksts par autentificētu DI tērzēšanas robotu klientu portālā sīkāk apraksta šo robežu.

Daudzvalodu variantiem nepieciešami kopīgi identifikatori

Tulkojiet attēlojamos nosaukumus, paskaidrojumus un jautājumus, bet netulkojiet iekšējos ID. "Pulverbeschichtet", "powder-coated" un "revêtu par poudre" jānorāda uz vienu un to pašu pazīmes vērtību. Tādējādi noteikumu pārbaude paliek neatkarīga no valodas, un daudzvalodu piedāvājumu komanda strādā ar tiem pašiem objektiem.

Testējiet skaitļu formātus, komatus un punktus, mērvienības un iztulkotos sinonīmus. Lietotājs var nosaukt "2,5 metri", "250 cm" vai noapaļotu skaitli. Normalizācijai skaidri jāsaglabā vienība un precizitāte. Rokasgrāmata par daudzvalodu pieteikumu kvalificēšanu parāda, kā apvienot valodas maiņu un strukturētu nodošanu.

Testējiet noteikumus, valodu un nodošanu kopā

Plūstošs dialogs nav pietiekams tests. Izveidojiet matricu no derīgām kombinācijām, aizliegtajiem pāriem, robežvērtībām, trūkstošajiem datiem, novecojušām cenām, nepieejamiem krājumiem un sistēmas kļūmēm. Katram gadījumam pārbaudiet parādīto paskaidrojumu, rīka izsaukumu, noteikuma rezultātu un nodotos datus.

• Vai lietotāja instrukcija var apiet noteikumus vai piekļuves tiesības?
• Vai bots paliek godīgs, ja trūkst cenas vai krājumu?
• Vai nederīgas kombinācijas tiek paskaidrotas saprotami?
• Vai katra valoda saņem tos pašus ID un noteikumu rezultātus?
• Vai atkārtots mēģinājums (retry) nerada otro piedāvājuma gadījumu?
• Vai nodošana darbojas arī pie nezināmām prasībām?

Testējiet arī tipiskas formu ievades, drukas kļūdas un labojumus. Raksts par DI tērzēšanas robotiem kā formu palīgiem parāda, kā mijiedarbojas lauku palīdzība un servera puses validācija.

Pārbaudes lapa ražošanas darbināšanai

1. Pilotprojektam izvēlieties skaidri ierobežotu produktu saimi.
2. Definējiet stabilus ID un atbildīgos par katru datu lauku.
3. Pārnesiet savietojamību un robežvērtības testējamos noteikumos.
4. Nošķiriet paskaidrojumus no cenu, krājumu un piedāvājumu pieprasījumiem.
5. Atzīmējiet derīgus, nederīgus un pārbaudāmus rezultātus.
6. Veiciet noteikumu, datu avotu un nodošanas formāta versijvadību.
7. Samaziniet līdz minimumam personas un klientam specifiskos datus.
8. Pārbaudiet visas valodas ar tiem pašiem atsauces gadījumiem.
9. Mēriet derīgos noslēgumus, labojumus un speciālistu nodošanas.

Sāciet ar vienu produktu saimi, ierobežotu jautājumu ceļu un skaidru nodošanu. Ja noteikumi, avoti un atbildības ir tīri nošķirtas, DI tērzēšanas robots var padarīt sarežģītu izvēli uztveramu, netēlojot saistošas saistības. Tādējādi konfigurators kļūst par noderīgu ievadu uzticamā piedāvājumā, nevis par jaunu kļūdu avotu.

Avoti un standarti

• 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