B2B produktu katalogs bez interneta veikala: kad pietiek ar cenu pieprasījumu

B2B produktu katalogs ar cenu pieprasījuma grozu ir piemērots, ja klients var izvēlēties produktu un daudzumu, bet cenu, piegādes nosacījumus vai komplektāciju vēl jāapstiprina pārdevējam. Mājaslapas uzdevums tad ir savākt saprotamu pieprasījumu, kuru iespējams apstrādāt bez atkārtotas produktu minēšanas e-pastā. Pilns interneta veikals kļūst pamatots, kad uzņēmums spēj tiešsaistē droši apstiprināt arī darījuma nosacījumus. Izvēli nosaka pārdošanas process, nevis vēlme katalogam pievienot apmaksas pogu.

Ražotājam vai vairumtirgotājam šī robeža bieži atklājas vienkāršā jautājumā: ko darbinieks pārbauda pirms piedāvājuma nosūtīšanas? Ja viņam jāprecizē materiāls, savietojamība, izgatavošanas iespēja vai piegādes vieta, mājaslapai vispirms jāpalīdz savākt šos datus. Maksājuma pieņemšana neatrisina trūkstošu specifikāciju.

Kad pietiek ar B2B produktu katalogu

Cenu pieprasījums ir noderīgs darījumos, kuros publiska produkta lapa apraksta izvēles iespējas, bet vēl nenosaka visu pasūtījumu. Piemēram, vienam produktam var būt dažādi izmēri, iepakojumi vai apstrādes varianti. Pircējs spēj norādīt vajadzīgo, taču pārdevējam jāpārbauda, vai šo kombināciju var piegādāt kopā ar pārējām pozīcijām. Šādā gadījumā pieprasījuma grozs dod abām pusēm kopīgu sarunas sākumu.

Tas ir mazāk piemērots, ja klienti regulāri iegādājas standartizētas preces ar skaidru cenu un piegādi, bet pārdevējs katru pieprasījumu tikai pārkopē pasūtījumā. Tad manuāla saskaņošana var kļūt par nevajadzīgu šķērsli. Pirms izlemt, izsekojiet tipiskam pirkumam: kur darbinieks patiešām pieņem lēmumu un kur vienkārši pārvieto informāciju?

Iespējams arī jaukts modelis. Standarta sortimentam var paredzēt pasūtīšanu, bet individuālai komplektācijai saglabāt pieprasījumu. Abiem ceļiem jābūt skaidri nosauktiem. Klients nedrīkst tikai pēc formas nosūtīšanas uzzināt, ka redzamā summa nebija apstiprināta cena vai norādītais datums vēl nenozīmēja piegādes solījumu.

Platformu piemēri palīdz saprast iespējas, bet neizvēlas procesu uzņēmuma vietā. Shopify B2B katalogu dokumentācija apraksta sortimenta un cenu pieejamības noteikšanu klientiem. Tas parāda, ka katalogs var ietvert komerciālus noteikumus. No tā neizriet, ka katram katalogam vajadzīga tūlītēja apmaksa vai ka tādas pašas funkcijas ir jebkurā CMS.

Nosakiet, ko nozīmē nosūtīts pieprasījums

Pirms projektēt grozu, vienojieties par rezultātu. Vai uzņēmums saņem tikai jautājumu par cenu, tehniskās saderības pārbaudes uzdevumu vai pietiekamu informāciju piedāvājuma sagatavošanai? Šīs ir atšķirīgas darbības ar atšķirīgiem obligātajiem laukiem. Poga “Pieprasīt piedāvājumu” ir saprotama tikai tad, ja aiz tās ir noteikts turpmākais process.

Pieprasījuma apstiprinājumā pasakiet, kas ir saņemts un kas notiks tālāk. Ja piegāde un cena vēl jāsaskaņo, to norādiet pie iesniegšanas, nepaslēpjot būtisko tikai automātiskā e-pasta beigās. Atbildes termiņu soliet vienīgi tad, ja komandai ir iespēja to ievērot. Pirmajā versijā drošāk ir aprakstīt nākamo darbību un atbildīgo, nevis publicēt nepamatotu ātruma solījumu.

Arī pārdevēja pusē jāatšķir saņemts pieprasījums no sagatavota piedāvājuma. Atzīme “nosūtīts” pati par sevi nepasaka, vai kāds ir pārbaudījis pielikumu un sapratis klienta vajadzību. Vienojieties, kur darbinieks atzīmē, ka vajag precizējumu, un kur redzams, ka klients to jau sniedzis. Tas ļauj izmantot katalogu kā darba sākumpunktu, nevis vēl vienu neuzraudzītu pastkasti.

Produkta variantam jānonāk līdz pārdevējam

Produkta lapā svarīgi atšķirt saimes aprakstu no konkrētas izvēles. Ja pārdošanai būtisks garums, materiāls un savienojuma tips, ar produkta nosaukumu nepietiek. Grozā un pārdevēja skatā jānonāk gan produkta identifikatoram, gan izvēlētajiem atribūtiem. Katras pozīcijas daudzumam nepieciešama mērvienība: gabali, metri un iepakojumi nav savstarpēji aizstājami.

No klienta prasiet tikai to, kas vajadzīgs nākamajam lēmumam. Ja pārdevējs cenu var sagatavot pēc varianta, daudzuma un piegādes reģiona, nevajag jau pirmajā solī pieprasīt visu uzņēmuma iepirkumu procedūru. Papildu komentāra lauks palīdz neparedzētās situācijās, taču tas nedrīkst aizstāt strukturētus atribūtus, kas vajadzīgi katram pieprasījumam.

Klientam jāvar norādīt arī to, ko viņš vēl nezina. Ja klients nezina nepieciešamo materiālu, izvēle “vajadzīga konsultācija” var būt labāka par piespiedu minējumu. Pārdevējam tā jāredz kā neatrisināts jautājums, nevis apstiprināta specifikācija. Zināmi nesavietojamas kombinācijas jāizskaidro vēl produkta izvēlē, lai lietotājs netērētu laiku pieprasījumam, kuru nevar apstrādāt.

Pielikumu izmantojiet tur, kur rasējums vai specifikācija tiešām palīdz. Nosakiet pieņemamos formātus un apjomu, kā arī to, kurš failiem piekļūst. Projektā jāparedz ievades pārbaude un aizsargāta glabāšana; fails nedrīkst kļūt publiski pieejams tikai tāpēc, ka tas pievienots katalogā. Lietotājam arī jāredz, vai augšupielāde izdevās un kuru failu viņš nosūta.

Vairākas preces vienā cenu pieprasījuma grozā

Pieprasījuma groza vērtība parādās tad, kad klients veido komplektu. Viņam jāvar pāriet starp produktu lapām, nezaudēt iepriekšējo izvēli un pirms nosūtīšanas pārskatīt visas pozīcijas. Viena kopīga piezīme var attiekties uz piegādes vietu, bet konkrētas pozīcijas piezīme uz tās pielietojumu. Šīs piezīmes nevajag sapludināt vienā grūti interpretējamā tekstā.

Līdzīgi jānodala pozīcijas dzēšana no daudzuma maiņas. Ja vienam produktam ir divi dažādi varianti, grozs nedrīkst tos apvienot tikai vienāda nosaukuma dēļ. Iesniegtais pieprasījums pārdevējam jāattēlo tieši tā, kā klients to pārbaudījis, ar saglabātām mērvienībām un pielikumu piesaisti. Kopējais produktu skaits bez specifikācijas vēl nav lietojams darba uzdevums.

Pirms nosūtīšanas nepieciešams pārskatāms kopsavilkums. Klientam jāvar atgriezties un izlabot izvēli, nezaudējot kontaktinformāciju. Pēc veiksmīgas nosūtīšanas viņam noder pieprasījuma identifikators un tā kopija. Ja rodas tehniska kļūda, interfeisam skaidri jāpasaka, vai pieteikums ir saņemts; citādi atkārtota pogas nospiešana var radīt vairākus neskaidrus ierakstus.

Pirmās versijas funkciju minimuma matrica

Apjomu nosakiet pēc pilna pieprasījuma ceļa. Šī matrica ir darba veidne, ko pielāgot uzņēmuma sortimentam. Tā neparedz obligātu konkrētu platformu vai gatava moduļa iegādi.

Klienta konts nav automātiska pirmās versijas prasība. Tas var būt vajadzīgs atkārtotiem pieprasījumiem vai ierobežotai informācijai, bet publisku katalogu var sākt arī bez obligātas reģistrācijas. Izlemiet pēc konkrētā lietotāja uzdevuma. Konts rada papildu pienākumus piekļuves pārvaldībā, tāpēc tam jārisina reāla vajadzība.

Līdzīgi integrācija ar pārdošanas sistēmu jāvērtē pēc darba apjoma un kļūdu riska. Pirmajā posmā var pietikt ar saglabātu ierakstu un paziņojumu atbildīgajam, ja ir skaidra apstrādes kārtība. Tomēr paziņojumam nevajadzētu būt vienīgajai pieprasījuma kopijai. Integrācijas traucējums nedrīkst padarīt nosūtīto specifikāciju neatgūstamu.

Demonstrācija no produkta līdz piedāvājumam

Iedomāsimies vairumtirgotāju, kura klients meklē stiprinājumus un saderīgus montāžas elementus. Vienā pieprasījumā viņš izvēlas vairākas pozīcijas, norāda vajadzīgo iepakojumu un pievieno rasējumu. Piegādes vieta ir kopīga visam pieprasījumam, bet vienai pozīcijai nepieciešama tehniska pārbaude. Šādu hipotētisku scenāriju var izmantot piegādātāja demonstrācijā ar testa datiem.

Sāciet produkta lapā un palūdziet pievienot izvēlēto variantu grozam. Pēc tam atveriet citu produktu, pievienojiet to un atgriezieties pie iepriekšējās izvēles. Pārbaudiet, vai atribūti un daudzums palikuši saprotami. Rasējumam jābūt piesaistītam īstajai pozīcijai vai skaidri norādītam kā kopīgam dokumentam. Visbeidzot mainiet vienu izvēli kopsavilkumā un iesniedziet pieprasījumu.

Ar klienta ekrānu demonstrācija nebeidzas. Atveriet saņemto ierakstu pārdevēja pusē un pārbaudiet, vai darbinieks var sagatavot piedāvājumu bez minējumiem. Lai viņš atzīmē trūkstošo precizējumu un nodod darbu kolēģim. Ja otrs cilvēks nesaprot, par kuru variantu bija saruna, jālabo datu attēlojums vai vēsture, nevis jāpievieno vēl viena poga sākumlapā.

Demonstrējiet arī kļūdu: trūkstošu obligāto lauku, nepareizu faila formātu vai neveiksmīgu nosūtīšanu. Pēc kļūdas pārbaudiet, vai ievadītā specifikācija saglabājusies un vai redzamais paziņojums atbilst faktiskajam rezultātam. Šāds tests palīdz pamanīt problēmas, kuras veiksmīga prezentācija ar iepriekš sagatavotu grozu var neatklāt.

Lai demonstrācijas rezultāts būtu izmantojams lēmumam, pie katra novērojuma pierakstiet sagaidīto un faktisko darbību. Piemēram, divi vienādi nosaukumi ar atšķirīgu iepakojumu jāsaglabā kā atšķirīgas izvēles. Ja pārdevējs redz tikai kopēju daudzumu, prasība nav izpildīta pat tad, ja nosūtīšanas poga strādā. Nevienojieties, ka darbinieks šo atšķirību turpmāk vienmēr atcerēsies no klienta zvana.

Darba nodošanas pārbaudē otram darbiniekam parādiet tikai sistēmā saglabāto informāciju. Viņam jāspēj noteikt, kurš precizējums vēl vajadzīgs un kam jautāt. Ja demonstrētājs katru reizi papildina ekrānā redzamo ar mutisku skaidrojumu, fiksējiet trūkstošo lauku vai darbības piezīmi. Tā kļūst par konkrētu labojumu specifikācijā, nevis neskaidru prasību padarīt administrācijas paneli ērtāku.

Arī neveiksmīgas iesniegšanas gadījumā lēmumam jābalstās uz to, ko redz abas puses. Pārdevējam pieejams ieraksts un klientam redzama kļūda ir cita situācija nekā nesaglabāts pieprasījums. Pieņemšanas testā šīs situācijas jānošķir. Pretējā gadījumā nevar droši pateikt, vai klientam jāmēģina iesniegt vēlreiz vai jāsazinās par jau saņemto pieprasījumu.

Pirmās versijas apjomu var uzskatīt par saprotamu, kad šo ceļu iespējams iziet bez neparedzētas pārrakstīšanas e-pastā. Papildu ērtības drīkst atlikt, bet produkta izvēles nozīmi, atbildīgo un saņemšanas rezultātu atlikt nedrīkst. Tie nosaka, vai katalogs vispār palīdz sagatavot piedāvājumu. Šādi formulēta robeža palīdz arī salīdzināt izstrādātāju piedāvājumus: vērtējiet vienu un to pašu klienta darbību, nevis atšķirīgi nosauktu moduļu sarakstus.

Kad var pievienot pasūtīšanu un apmaksu

Pārejai uz pasūtīšanu vajadzīgi pārbaudāmi komerciālie noteikumi. Uzņēmumam jāzina, kuru cenu klients drīkst izmantot, kā tiek noteikta piegāde un kad izvēlētais daudzums patiešām ir pieejams. Ja šie jautājumi joprojām katrā darījumā prasa individuālu lēmumu, apmaksas pievienošana tikai pārcels neskaidrību uz vēlāku posmu.

Attīstību var sākt ar ierobežotu sortimenta daļu, kur noteikumi ir stabili. Pārējiem produktiem saglabājas cenu pieprasījuma ceļš. Esošajā katalogā tādēļ ir vērts uzturēt konsekventus produktu identifikatorus un atribūtus, nevis visu aprakstīt vienā brīvā teksta laukā. Tas atvieglo turpmāku sasaisti, taču negarantē pāreju bez papildu izstrādes.

Svarīga ir arī atšķirība starp piedāvājuma pieņemšanu un jauna pasūtījuma veidošanu. Ja klients apstiprina jau saskaņotu piedāvājumu, sistēmai jāsaprot, uz kuru tā versiju viņš atsaucas. Cenas vai specifikācijas izmaiņas nevar klusi attiecināt uz iepriekš nosūtītu dokumentu. Šo prasību nosakiet, pirms automatizējat darījuma apstiprināšanu.

Individuālo cenu prioritātes un konfidencialitāte ir atsevišķs projektēšanas jautājums. Publiska kataloga pirmās versijas apjomu nevajag pārslogot ar visu iespējamo atlaižu dzinēju, ja faktiskā vajadzība ir saņemt strukturētu pieprasījumu. Toties jau sākumā jāzina, kuri dati ir publiski un kurus pārdevējs drīkst izpaust tikai konkrētam klientam.

Kā izvēlēties apjomu kopā ar izstrādātāju

Uz pirmo sarunu paņemiet esošo kataloga paraugu un anonimizētu tipiska pieprasījuma piemēru. Atzīmējiet vietas, kur pārdevējam parasti jāpārjautā produkta variants vai daudzums. No tām veidojas obligātie lauki un pārbaudes. Ja vienai produktu grupai vajag pavisam citu informāciju, parādiet arī šo izņēmumu, nevis mēģiniet visu ietilpināt vienā formā.

Izstrādes piedāvājumā lūdziet atsevišķi nosaukt kataloga satura sagatavošanu, groza funkcijas, pieteikumu apstrādi un integrācijas. Produktu dati nerodas līdz ar dizainu. Komandai jāzina, kurš sakārtos atribūtus, pielikumus un aprakstus un kurš pēc palaišanas uzturēs to aktualitāti. Pretējā gadījumā darbojošs interfeiss var palikt piepildīts ar nepilnīgu informāciju.

Plašākai platformas izvēlei izmantojiet mājaslapu un CMS izstrādes ceļvedi, bet saskaņotās prasības noformējiet mājaslapas tehniskajā uzdevumā. Kataloga lēmuma centrā paliek tas, vai klients spēj patstāvīgi sagatavot kvalitatīvu pieprasījumu un uzņēmums spēj to pārņemt darbā.

Ja vajadzīga mājaslapu izstrāde uzņēmumam Latvijā, atsūtiet kataloga paraugu un tipisku klienta pieprasījumu, lai noteiktu mājaslapas pirmās versijas apjomu. Sākumam vajadzīgs skaidrs ceļš no produkta izvēles līdz pārdevēja lēmumam. Apmaksu pievienojiet tad, kad tai gatavi arī darījuma noteikumi.