Cenu kalkulators mājaslapā: kad tas palīdz pārdot un kā noteikt aprēķina robežas

Cenu kalkulators mājaslapā ir pamatots, ja būtisku cenas daļu var noteikt pēc klientam saprotamiem datiem un uzņēmums spēj skaidri nosaukt izņēmumus. Tam nav obligāti jāizdod galīgais piedāvājums. Rezultāts var būt orientējoša summa vai pamatots diapazons ar redzamiem pieņēmumiem. Ja ievade neļauj aprēķināt ticamu cenu, kalkulatoram jāapstājas un jāpiedāvā precizēšana. Šādi tas var palīdzēt pircējam saprast budžetu un pārdevējam saņemt sakārtotu uzdevumu. Ietekme uz pārdošanu gan jāpārbauda konkrētajā uzņēmumā, nevis jāpieņem kā garantēts izstrādes rezultāts.

Sāciet ar pārdevēja aprēķinu, nevis formas dizainu

Izvēlieties pakalpojuma veidu, kuram komanda jau sagatavo cenu aplēses pēc līdzīga principa. Palūdziet pārdevējam paskaidrot, kuri ievades dati maina cenu un kuros brīžos viņš pārtrauc aprēķinu, lai uzdotu papildu jautājumu. Šī robeža parasti ir svarīgāka par lauku skaitu ekrānā.

Pierakstiet cenas sastāvdaļas: bāzes darbu, apjoma vienības, izvēles papildinājumus un nosacījumus, kas maina darba sarežģītību. Atsevišķi atzīmējiet, ko klients nevar droši novērtēt pats. Ja aprēķinam vajadzīga tehniska apsekošana, vienkāršs jautājums “Vai objekts ir sarežģīts?” neaizstās šo darbu.

Vērtīgs kandidāts automatizācijai ir modelis, kura ievades un rezultātu var izskaidrot bez slēptiem pieņēmumiem. Ja cena katrā gadījumā rodas no individuālas vienošanās, publisks kalkulators var radīt vairāk skaidrošanas nekā ietaupīt. Tad lietderīgāks sākums ir procesa sakārtošana vai mērķēts pieteikums.

Atšķirībā no klienta pieteikuma formas, kalkulators no atbildēm izveido skaitlisku rezultātu. Nepietiek pārbaudīt, vai jautājumi ir saprotami. Jāpārbauda arī formula, atļautās kombinācijas un tas, kādu solījumu lasītājs saskata gala summā.

Kad cenu kalkulators mājaslapā rāda summu, diapazonu vai neko

Precīzu aplēsi var rādīt, ja ievades ir pietiekamas un cenu nosacījumi ir noteikti. Vārds “precīza” šeit attiecas uz aprēķinu pēc norādītajiem pieņēmumiem, ne automātisku garantiju, ka visi klienta darba apstākļi ir zināmi. Rezultāta nosaukumam jāatspoguļo tā faktiskā loma.

Diapazons ir pamatots, ja ir identificēts nenoteiktības avots un uzņēmums var izskaidrot zemāko un augstāko robežu. Patvaļīgi pievienota rezerve nav labs aizstājējs šim skaidrojumam. Lasītājam jāzina, kurš vēl nezināmais apstāklis mainīs rezultātu un kā to precizēt.

Aprēķins jāpārtrauc, ja būtisks priekšnosacījums nav izpildīts. Piemēram, pakalpojums nav pieejams izvēlētajam objektam vai apjoms pārsniedz uzņēmuma apstiprināto modeli. Šādā gadījumā parādiet iemeslu un konkrētu nākamo soli. Neizvadiet nulles cenu un neizvēlieties lētāko pieņēmumu klusējot.

Pārbaudiet šos formulējumus kopā ar pārdevēju. Ja komanda vēlāk regulāri atbildēs “kalkulators to nebija ņēmis vērā”, trūkstošais nosacījums jāpadara redzams agrāk. Sīkā atruna lapas beigās neatrisina nepareizu iespaidu pie izceltās cenas.

Aprēķina prasību veidlapa pirms izstrādes

Prasību sagatavošanai nav jāsāk ar sarežģītu specifikāciju. Vispirms aizpildiet vienotu aprakstu, kuru saprot gan pakalpojuma īpašnieks, gan izstrādātājs. Neskaidru vietu atzīmējiet kā neatrisinātu lēmumu. Izstrādātājam nevajadzētu minēt uzņēmuma cenu politiku no maketa.

Šo veidlapu var pievienot mājaslapas tehniskajam uzdevumam. Tad izstrādes piedāvājumus iespējams salīdzināt pēc vienas funkcijas faktiskā apjoma. Kalkulators, kas tikai parāda skaitli, nav tas pats risinājums, kas saglabā aprēķina versiju un nodod pārbaudītu kopsavilkumu pārdošanas sistēmai.

Demonstrācijas aprēķins ar skaidrām robežām

Iedomāsimies standartizētu pakalpojumu ar bāzes maksu un cenu par darba vienību. Tālāk minētās summas ir izdomātas tikai formulas demonstrācijai. Tās nav konkrēta uzņēmuma cenas, tirgus cenu aplēse vai nodokļu aprēķina paraugs.

Demonstrācijas bāzes maksa ir 120 EUR, cena par darba vienību ir 30 EUR, un klients izvēlas 4 vienības. Papildpakalpojums šajā piemērā nav izvēlēts.

Aplēse = 120 EUR + 4 × 30 EUR = 240 EUR

Pie rezultāta jābūt redzamam, ka tas attiecas uz norādīto standarta darba apjomu. Nodokļu un citu maksājumu attēlošanas kārtība jānosaka reālajā cenu modelī; demonstrācija to nenosaka. Ja atklājas, ka darbam vajadzīgs ārpus standarta apjoma esošs risinājums, sistēmai jānovirza pieteikums precizēšanai, nevis jāturpina lietot šo pašu tarifu.

Lai pārbaudītu ievades robežu, pieņemsim, ka demonstrācijas modelis atļauj veselus apjomus no 1 līdz 10 vienībām. Nulle, negatīva vērtība un daļēja vienība nav atļauta. Ja klients ievada 11, pareizais rezultāts ir paziņojums par individuālu izvērtēšanu, nevis turpināts automātisks aprēķins.

Šīs robežas ir izdomātā modeļa prasības, ne ieteikums visiem pakalpojumiem. Reālā uzņēmumā tās jāpamato ar darba organizāciju. Pieņēmums “jo vairāk vienību, jo cena vienmēr pieaug lineāri” jāpārbauda, jo var mainīties sagatavošanas darbs, izpildes metode vai piegādes nosacījumi.

Papildiniet demonstrāciju ar pārdevēja sagaidāmo atbildi. Viņam jāsaņem izvēlētais apjoms, standarta pakalpojuma pazīme, izmantotie tarifi un rezultāts. Tikai summa “240 EUR” neatklāj, ko klients ir izvēlējies. Bez šīs informācijas kalkulators var kļūt par vēl vienu neskaidru sākumpunktu sarunai.

Robežvērtības pārbaudiet pirms dizaina apstiprināšanas

Katram ievades laukam vajag testu ar atļautu, neatļautu un trūkstošu vērtību. Skaitļa laukā pārbaudiet arī daļu atdalītājus un to, kas notiek, ja cilvēks ielīmē tekstu. Neskaidru ievadi nevajag pārvērst par citu vērtību bez saprotama skaidrojuma lietotājam.

Ar atsevišķu lauku pārbaudēm nepietiek. Derīgas izvēles var veidot nederīgu kombināciju: papildpakalpojums nav pieejams izvēlētajam darba veidam vai termiņam. OWASP ievades validācijas vadlīnijas nošķir sintaktisko un semantisko derīgumu. Kalkulatorā tas nozīmē pārbaudīt gan datu formātu, gan atbilstību uzņēmuma noteikumiem.

Demonstrācijas modelim pārbaudiet zemāko un augstāko atļauto apjomu, kā arī ievadi ārpus tiem. Atsevišķi pārbaudiet darbību pēc izvēles maiņas: vai iepriekš parādītā summa vairs netiek pasniegta kā aktuāla? Ja rezultāts tiek pārrēķināts, paziņojiet par izmaiņu tā, lai lietotājs saprastu tās cēloni.

Izveidojiet apstiprinātu testu piemēru kopu ar sagaidāmo rezultātu. To sagatavo cenas modeļa īpašnieks kopā ar izstrādātāju. Ja kods un tests atkārto vienu nepareizu pieņēmumu, sekmīgs tehniskais tests vēl nepierāda cenas pareizību. Nepieciešama neatkarīga aprēķina pārbaude.

Pārlūka parādītā cena nav uzticams servera ievades avots

Pārlūka pārbaudes palīdz lietotājam kļūdu izlabot uzreiz. Taču nosūtītos datus var mainīt ārpus paredzētās saskarnes. MDN formu validācijas apraksts tāpēc uzsver arī servera puses pārbaudi. Kalkulatora rezultātu, kas ietekmē pieteikumu vai piedāvājumu, nevajag uzticami pieņemt tikai tāpēc, ka tas atnācis no paša mājaslapas formas.

Ieteicams nosūtīt izvēlētās ievades un serverī pārbaudīt tās pret atļauto modeli. Ja serveris saglabā cenu, tam jāizmanto uzticami tarifi un noteikumi, ne klienta iesūtīta patvaļīga summa. Kļūmes gadījumā parādiet, ka aprēķinu neizdevās apstiprināt. Nedrīkst saglabāt veco rezultātu kā jaunu tikai tāpēc, lai lietotājs neredzētu tehnisku problēmu.

Pārbaudiet, kas notiek, ja klienta atvērtajā lapā palikusi iepriekšējā tarifu versija. Serveris var prasīt pārrēķinu un parādīt mainīto rezultātu pirms iesniegšanas. Šim procesam jābūt saprotamam: lietotājs nedrīkst nospiest pogu pie vienas summas un saņemt apstiprinājumu ar citu, nepamanot izmaiņu.

Validācija viena pati nav visa drošība. Piekļuves tiesības cenu pārvaldībai, droša datu apstrāde un citi aizsardzības pasākumi jāprojektē atbilstoši konkrētajai sistēmai. Šis raksts koncentrējas uz aprēķina uzticamību, ne pilnu mājaslapas drošības auditu.

Cenu atjaunināšana ir daļa no funkcijas

Nosakiet, kurš maina tarifus un kurš apstiprina to publicēšanu. Saglabājiet modeļa versiju un spēkā stāšanās brīdi. Ja vēlāk pārdevējs saņem agrāk sagatavotu aprēķinu, viņam jāvar redzēt, pēc kādiem noteikumiem tas radīts. Vēsturisku pieteikumu nevajag pārrēķināt klusējot ar jaunākajām cenām.

Pirms tarifu maiņas palaidiet iepriekš apstiprinātos piemērus un izvērtējiet sagaidāmās atšķirības. Ja mainās pati formula, testējiet arī tās robežas. Jauns papildpakalpojums var ietekmēt agrāk korektas izvēļu kombinācijas, tāpēc nav droši pārbaudīt tikai vienu skaisti aizpildītu piemēru.

Atjaunošanas plānā paredziet rīcību, ja publicēts kļūdains tarifs. Var būt jāaptur jauni aprēķini, jāsaglabā skartie pieteikumi un jānodod tie pārdevēja pārbaudei. Automātiska atgriešanās pie iepriekšējās versijas pati par sevi neatrisina klientiem jau parādītās cenas. Tam vajadzīga uzņēmuma saskaņota saziņas kārtība.

Arī kalkulatora apraksta tekstam jāsaskan ar modeli. Ja rezultāts vairs neietver agrāku pakalpojuma daļu, nepietiek mainīt tarifu tabulu. Pārskatiet pieņēmumus ekrānā, e-pasta kopsavilkumā un pārdevēja skatā. Pretējā gadījumā skaitlis var būt matemātiski pareizs, bet tā skaidrojums nepareizs.

Ko nodot pārdevējam un kā vērtēt ieguvumu

Saglabājiet skaidru rezultātu arī pēc pārtraukuma

Lietotājs var atgriezties pie aprēķina vēlāk vai pārsūtīt to kolēģim. Nosakiet, vai tiek saglabāts fiksēts kopsavilkums vai tikai saite, kas atver ievades jaunam aprēķinam. Šie varianti nav savstarpēji aizstājami. Ja saite aprēķina visu no jauna, lietotājam jāredz, ka tiek izmantots aktuālais modelis, ne agrāk apskatītais rezultāts.

Kopsavilkumā izceliet arī to, kas nav iekļauts. Sarakstam jābūt saistītam ar izvēlēto pakalpojumu, ne garai universālai atrunai. Ja trūkst informācijas, nosauciet konkrēto jautājumu, kuru risinās pārdevējs. Tad aprēķinu var izmantot sarunas turpināšanai, nepārvēršot katru rezultātu par šķietami pilnīgu piedāvājumu.

Pieteikuma nosūtīšanas pārtraukumam vajag atsevišķu paziņojumu. Aprēķina sekmīga izveide vēl nenozīmē, ka pārdevējs to saņēmis. Saskarnē nodaliet rezultāta parādīšanu no pieteikuma pieņemšanas un saglabājiet iespēju pārbaudīt nosūtīšanas iznākumu. Neaiciniet cilvēku akli atkārtoti iesniegt visu informāciju, ja sistēma nezina, vai iepriekšējais pieteikums jau izveidots.

Izmēģiniet arī cenu skaidrojumu bez vizuālā akcenta uz gala skaitli. Palūdziet kolēģim no kopsavilkuma pateikt, kāds darbs ir iekļauts un kāds nosacījums vēl jāpārbauda. Ja viņš var atkārtot summu, bet nevar nosaukt tās robežas, jāmaina rezultāta izklāsts. Šāda pārbaude palīdz izvērtēt, vai kalkulators tiešām atvieglo nākamo sarunu.

Dodiet pārdevējam aprēķina pamatojumu

Pieteikumā saglabājiet klienta ievades, aprēķina rezultātu, valūtu, modeļa versiju un redzamos pieņēmumus. Pievienojiet neatbildētos jautājumus un apturēšanas iemeslu, ja automātiska cena nav dota. Pārdevējam vajag saprast, ko cilvēks redzēja un kāpēc viņš pieteicās.

Kontaktinformācijas pieprasīšanai jābūt pamatotai ar nākamo darbību. Ja lietotājs tikai iepazīstas ar budžeta robežām, pārdomājiet, vai visu aprēķinu nepieciešams slēpt aiz datu iesniegšanas. Ja viņš vēlas individuālu precizējumu, paskaidrojiet, kā iesniegtā informācija palīdzēs sagatavot atbildi. Datu apjomu un glabāšanu nosakiet atbilstoši faktiskajam procesam.

Kalkulatora vērtību mēriet pēc tā uzdevuma. Vai pārdevējs saņem pietiekamus datus? Kāpēc klientam vēlāk jāpaskaidro cita summa? Kuri nosacījumi visbiežāk nav saprasti? Aprēķinu skaits viens pats neparāda labāku pārdošanu. Noderīgāks ir pārbaudāms skaidrojums, kuri pieteikumi kļuvuši precīzāki un kuri joprojām prasa papildu darbu.

Pēc palaišanas regulāri salīdziniet kalkulatora aplēses ar sagatavotajiem piedāvājumiem. Atšķirības sadaliet pēc iemesla: klients precizēja apjomu, modelis neaptvēra izņēmumu vai tika atrasta kļūda. Ne katra atšķirība ir defekts, taču atkārtota neskaidrība var norādīt uz sliktu ievades jautājumu vai pārāk plašu aprēķina solījumu.

Vērtējiet arī atteiktos aprēķinus. Ja cilvēki regulāri nonāk pie individuālas izvērtēšanas, noskaidrojiet, vai tas atbilst uzņēmuma mērķauditorijai. Iespējams, modelis apzināti paredzēts tikai standarta darbam un darbojas pareizi. Iespējams, būtiska klientu grupa ir palikusi ārpus tā. Atbildi nedod atteikumu skaits vien; vajag saprast šo pieprasījumu saturu, pirms paplašināt formulu.

Pirms pasūtīšanas sagatavojiet robežas un piemērus

Izstrādes sarunai paņemiet cenu veidojošo faktoru sarakstu, apstiprinātus aprēķinu piemērus un gadījumus, kuros automātisku cenu nedrīkst dot. Ar šo informāciju var vērtēt, vai pietiek ar vienkāršu modeli vai vajadzīga plašāka integrācija un versiju pārvaldība.

Mājaslapas izstrādes apjomu kalkulatoram ir vieglāk noteikt pēc šīm prasībām nekā pēc vēlamā lauku dizaina. Sāciet ar skaidru solījumu lietotājam: ko viņš pēc aprēķina zinās un ko vēl pārbaudīs cilvēks. Pārējai funkcijai jāatbalsta šī robeža.