Klients nospieda “Nosūtīt”. Vai jūs saņēmāt viņa ziņu?

Šis izdomātais piemērs parāda problēmu, kuru nevar atklāt, tikai apskatot sākumlapu. Mājaslapa var atvērties ātri un izskatīties labi, lai gan viena no tās svarīgākajām funkcijām nedarbojas. Klienta ziņa var nenonākt serverī, nesasniegt e-pasta adresātu vai palikt sistēmā, kuru neviens nepārbauda.

Pieteikumu var kļūt mazāk arī tad, ja mainījies pieprasījums pēc jūsu pakalpojuma, pats piedāvājums vai reklāmas auditorija. Tomēr pirms lielākām pārmaiņām pārbaudiet, vai ziņas vispār pienāk. Nosūtiet pārbaudes pieteikumu un noskaidrojiet, vai to saņēmis cilvēks, kuram būtu jāatbild klientam.

Kas notiek pēc pogas nospiešanas

Klientam pēc pogas nospiešanas atliek gaidīt atbildi. Uzņēmuma pusē darbs tajā brīdī tikai sākas. Pārlūkam jānosūta dati, serverim tie jāpārbauda un jāapstrādā, bet tālāk ziņa var nonākt e-pastā, klientu uzskaites sistēmā jeb CRM vai uzdevumu sarakstā.

Katrā posmā iespējama cita kļūme. Tāpēc pārbaudē jānoskaidro, ko katrs apstiprinājums patiesībā nozīmē.

Ne katram uzņēmumam vajadzīga sarežģīta pārdošanas sistēma. Nelielā komandā var pietikt ar vienošanos, kur pieteikumus glabā, kurš tos pārbauda un kas šo cilvēku aizvieto prombūtnes laikā. Pateicības paziņojums klienta ekrānā vēl neapliecina, ka uzņēmumā šī kārtība darbojas.

Izmēģiniet savu formu kā jauns klients

Sāciet ar formu, kuru klienti atver no svarīgākā pakalpojuma lapas vai reklāmas. Atveriet tieši šo lapu telefonā. Pārbaudei izmantojiet pārlūku, kurā neesat pierakstījies vietnē kā administrators. Administratoram var būt cita saskarne un atšķirīgi ierobežojumi nekā parastam apmeklētājam.

Iepriekš pabrīdiniet kolēģi, kurš saņem pieteikumus. Izmantojiet e-pasta adresi, kurai varat piekļūt, un ziņā skaidri norādiet, ka tā ir pārbaude. Neievadiet sveša klienta datus un neizraisiet īstu pasūtījumu vai maksājumu, ja forma ir savienota ar šādiem procesiem.

1. Pierakstiet lapas adresi un pārbaudes laiku. Ja ir vairākas valodas vai formas, atzīmējiet, kuru pārbaudāt. Tas palīdzēs tehniskajai komandai atrast atbilstošo pieprasījumu.
2. Aizpildiet visus nepieciešamos laukus. Pievērsiet uzmanību kļūdu paziņojumiem, faila pievienošanai un pārbaudei pret automatizētu nosūtīšanu, ja tāda ir. Atsevišķā mēģinājumā atstājiet kādu obligāto lauku tukšu. Pārbaudiet, vai no paziņojuma var saprast, kas vēl jāaizpilda, un vai ievadītie dati nav jāraksta no jauna.
3. Saglabājiet ekrānā redzamo rezultātu. Vai forma paziņo par saņemšanu, kļūdu vai turpina bezgalīgi rādīt ielādes simbolu? Vai kļūmes gadījumā paliek veids, kā sazināties?
4. Atrodiet pašu pieteikumu. Pārbaudiet paredzēto pastkasti vai CRM ierakstu. Vajadzības gadījumā apskatiet arī surogātpasta mapi un organizācijas e-pasta karantīnu, kur pakalpojums var aizturēt aizdomīgas vēstules.
5. Pārbaudiet atbildi. Lūdziet atbildīgo kolēģi atbildēt uz pārbaudes ziņu. Pārliecinieties, ka atbilde nonāk pareizajā adresē un ir saprotams, uz kuru pieteikumu tā attiecas.

Viens veiksmīgs mēģinājums apliecina, ka konkrētais pieteikums nonācis līdz adresātam. Tas vēl nepierāda, ka viss darbojas arī citās formās, valodās, pārlūkprogrammās un savienojumos ar uzņēmuma sistēmām. Svarīgākos variantus izvēlieties pēc tā, kā mājaslapu lieto jūsu klienti.

Ko patiesībā nozīmē pateicības paziņojums

Tekstam pēc nosūtīšanas jāatbilst tam, kas sistēmā ir noticis. Ja pieteikums pieņemts un saglabāts uzņēmuma uzskaitē, var paziņot par tā saņemšanu. Ja izdevies tikai sākt nosūtīšanas mēģinājumu, apgalvojums par veiksmīgu saņemšanu būtu maldinošs.

Tehniskajai komandai jānoskaidro, kurā brīdī parādās pateicības paziņojums. Ar klikšķi vai jebkuru servera atbildi nepietiek, jo arī atbildē var būt ziņojums par kļūdu. Dažās sistēmās serveris pieteikumu ievieto uzdevumu rindā, lai apstrādātu vēlāk. Šādā gadījumā saņemšanu drīkst apstiprināt tikai tad, kad uzdevums droši saglabāts. Solījums to saglabāt vēlāk nav saņemšanas apliecinājums.

Kļūdas gadījumā cilvēkam jāzina, ko darīt tālāk. Norādiet, kurā laukā un kas jāizlabo, vai piedāvājiet citu saziņas veidu. Paziņojumam jābūt uztveramam arī ar ekrānlasītāju, kas ekrāna saturu nolasa balsī vai nodod Braila rakstā. Neprasiet cilvēkam minēt, vai viņa ziņa pazudusi vai pienāks vēlāk.

Saprotamus formas rezultāta un kļūdu paziņojumus apraksta W3C piekļūstamības pamācība par lietotāja informēšanu.

Kļūme var rasties vēl pirms e-pasta nosūtīšanas

Neaizpildītu obligāto lauku vai kļūdaini ievadītu e-pasta adresi apmeklētājs bieži var izlabot pats. Pārlūkā veiktā pārbaude palīdz kļūdu pamanīt uzreiz. Tomēr dati jāpārbauda arī serverī, jo pārlūka ierobežojumus iespējams apiet. Pareizs adreses formāts vēl nepierāda, ka pastkaste pastāv.

Šo atšķirību skaidro MDN pamācība par formas datu pārbaudi.

Kļūmi var izraisīt arī JavaScript kods, kas nodrošina lapas darbību, aizsardzība pret surogātpastu, pievienotā faila izmēra ierobežojums vai servera problēma. Ja kļūme parādījusies pēc moduļa atjaunināšanas, vietnes pārcelšanas uz citu serveri vai jaunas formas ieviešanas, vispirms vērts pārbaudīt šīs izmaiņas. Tas palīdz izlemt, ar ko sākt izpēti, bet vēl nepierāda kļūmes cēloni.

Izstrādātājam jāsalīdzina pārlūka nosūtītais pieprasījums ar servera atbildi un ierakstu par pieteikuma apstrādi. Jānoskaidro, ko sistēma vēl paspēja izdarīt pirms kļūmes. Vienas kļūdas ekrānattēls ne vienmēr parāda, vai pieteikums jau paspējis saglabāties.

E-pasta nosūtīšana vēl nav piegādes apliecinājums

PHP valodā veidotās mājaslapās šo atšķirību ir viegli nepamanīt. PHP funkcija mail() var ziņot par sekmīgu darbību, ja vēstule pieņemta nosūtīšanai. PHP dokumentācija skaidri norāda, ka tas nenozīmē vēstules nonākšanu galamērķī.

Rezultāta nozīme ir aprakstīta PHP funkcijas mail dokumentācijā.

Ja forma izmanto ārēju e-pasta pakalpojumu, pārbaudiet konkrētās vēstules statusu un iespējamos kļūdu paziņojumus. Vēstules pieņemšana nosūtīšanas rindā, saņēmēja servera atteikums un veiksmīga piegāde ir atšķirīgi notikumi. Arī saņēmēja servera pieņemta vēstule var nonākt surogātpastā vai karantīnā. Piegādes statuss neapliecina, ka darbinieks ziņu izlasījis.

Šādu statusu piemērus sniedz Amazon SES nosūtīšanas uzraudzības dokumentācija. Nosaukumi un to precīzā nozīme jāskatās izmantotā pakalpojuma dokumentācijā.

Nemainiet nosūtītāja iestatījumus uz labu laimi. Jāpārbauda, kurš pakalpojums vēstuli nosūta, kādu domēnu tas izmanto un vai saņēmēja serveris var pārbaudīt vēstules izcelsmi. SPF norāda, kuriem serveriem atļauts sūtīt e-pastu tehniskās nosūtītāja adreses jeb MAIL FROM domēna vārdā. Tas var atšķirties no domēna, kuru saņēmējs redz laukā From. DKIM pievieno pārbaudāmu digitālu parakstu, kas palīdz noteikt vēstules izcelsmi un to, vai parakstītā daļa nav mainīta.

DMARC pārbaudē vērtē, vai sekmīgas SPF vai DKIM pārbaudes domēns atbilst domēnam, kuru saņēmējs redz nosūtītāja laukā. Pietiek, ja šo nosacījumu izpilda viena no abām pārbaudēm. Domēna DMARC politika norāda arī vēlamo rīcību neatbilstības gadījumā. Šie iestatījumi palīdz pārbaudīt sūtītāju, bet negarantē vēstules nonākšanu iesūtnē.

Domēnu atbilstību sīkāk skaidro Amazon SES dokumentācija par DMARC.

Kontaktformas vēstuli parasti sūta, izmantojot uzņēmuma pārvaldītu domēnu ar pareiziem e-pasta nosūtīšanas iestatījumiem. Pēc ievadīto datu pārbaudes apmeklētāja adresi var norādīt laukā Reply-To, kas nosaka atbildes adresi. Apmeklētāja adreses ievietošana nosūtītāja laukā From var radīt iespaidu, ka mājaslapa sūta vēstuli cita domēna vārdā, un izraisīt kļūmi sūtītāja pārbaudē.

Šādu nosūtītāja un atbildes adreses nodalīšanu savam spraudnim iesaka arī Contact Form 7 konfigurācijas dokumentācija.

Autentifikācijas prasības un atšķirību starp sūtītāju kategorijām skaidro Google norādījumi e-pasta sūtītājiem. Tie attiecas uz sūtīšanu uz personīgajiem Gmail kontiem. Citu saņēmēju prasības jāpārbauda pie attiecīgā pakalpojuma sniedzēja.

Saglabājiet pieteikumus, lai tos var atrast arī kļūmes gadījumā

Ja pieteikums glabājas tikai vēstulē, kuru sistēma mēģina nosūtīt, ir grūtāk noskaidrot kļūmes cēloni un to, kas noticis ar pieteikumu. Atbilstoši uzņēmuma vajadzībām pieteikumu var vispirms saglabāt aizsargātā uzskaites sistēmā un e-pastu izmantot kā paziņojumu par jaunu ierakstu.

Tā var būt esošā CRM sistēma vai vietnes pārvaldības sadaļa ar ierobežotām piekļuves tiesībām. Jānosaka, cik ilgi pieteikumus glabā un kuri cilvēki drīkst tos apskatīt. Publiski pieejams fails ar visu pieteikumu saturu tam nav piemērots risinājums.

Katram pieteikumam var piešķirt identifikatoru jeb unikālu numuru vai kodu. Tas palīdz atrast gan ierakstus par formas apstrādi, gan nosūtīto paziņojumu un pieteikumu uzņēmuma sistēmā. Tehnisko notikumu žurnālā bieži pietiek norādīt šo kodu, laiku, apstrādes posmu un rezultātu. Klienta ziņa nav jākopē katrā tehniskajā ierakstā.

Jāparedz rīcība arī tad, ja nav zināms, vai pieteikums saņemts. Savienojums var pārtrūkt pēc datu saglabāšanas. Šādā gadījumā atkārtota pogas nospiešana nedrīkst bez pārbaudes izveidot vēl vienu pasūtījumu. Savienotajām sistēmām jāspēj atpazīt atkārtotu pieprasījumu. Ja nevar droši noteikt iepriekšējā mēģinājuma iznākumu, tas jānoskaidro pārbaudē, nevis nepārtraukti jāatkārto darbība.

Analītika un saņemto pieteikumu uzskaite rāda dažādas lietas

Google Analytics paplašinātā mērīšana var reģistrēt formas aizpildīšanas sākumu un nosūtīšanu ar notikumiem form_start un form_submit. Tie raksturo apmeklētāja darbības formā. No šāda notikuma vien nevar secināt, ka CRM izveidots ieraksts vai atbildīgais darbinieks saņēmis vēstuli.

Notikumu nozīmi apraksta Google Analytics paplašinātās mērīšanas dokumentācija. Formas nosūtīšana un pieteikuma saņemšana uzņēmuma sistēmā ir atšķirīgi procesa posmi.

Uzņēmuma pārskatā atsevišķi skaitiet saņemtos pieteikumus, jūsu piedāvājumam atbilstošos pieprasījumus un noslēgtos darījumus. Google piedāvā arī notikumus šo posmu uzskaitei, piemēram, qualify_lead un close_convert_lead. Tie jāievieš atbilstoši reālajam procesam. Šādu notikumu drīkst izmantot attiecīgā posma uzskaitei tikai tad, ja uzņēmums tiešām izvērtējis pieprasījumu vai noslēdzis darījumu.

Atsevišķos pieteikuma apstrādes posmus definē Google Analytics ieteikto notikumu saraksts.

Ja skaitļi nesakrīt, tas ir iemesls sākt pārbaudi. Salīdziniet datus par vienu un to pašu periodu un formām, izmantojot vienādu laika joslu. Ņemiet vērā testus, atkārtotus mēģinājumus, surogātpastu un mērīšanas ierobežojumus. Starpību starp divām atskaitēm nedrīkst automātiski nosaukt par pazaudētiem klientiem vai zaudētu apgrozījumu.

Iestatot analītiku, pārbaudiet, kādus datus tā saņem. Google Analytics nedrīkst nosūtīt e-pasta adresi, tālruņa numuru vai klienta brīvi rakstīto ziņu. Pārbaudiet arī lapu adreses un to parametrus, jo personas dati var nonākt analītikā arī kā daļa no lapas adreses.

Ierobežojumus un biežākos noplūdes ceļus skaidro Google norādījumi par personu identificējošas informācijas nenosūtīšanu Analytics.

Pēc labojuma vēlreiz pārbaudiet, vai pieteikums pienāk

Uzraudzība, kas pārbauda tikai sākumlapas pieejamību, neatklāj visas formas kļūmes. Atbilstoši mājaslapas nozīmei ieplānojiet pārbaudi, kurā pieteikumam izseko no nosūtīšanas līdz saņemšanai. To var veikt cilvēks vai automatizēt, iepriekš nosakot pārbaudes robežas.

Automātiskajam testam jābūt atpazīstamam. Tas nedrīkst kļūt par īstu pārdošanas uzdevumu vai sagrozīt kampaņas rezultātu uzskaiti. Izmantojiet pārbaudei paredzētu e-pasta adresi un atzīmi, pēc kuras atpazīt testa pieteikumu. Vienojieties, kā pēc pārbaudes izdzēsīsiet nevajadzīgos testa datus. Pārbaudiet arī to, vai paziņojums par kļūmi nonāk pie atbildīgā.

Ja nedarbojas e-pasta nosūtīšanas pakalpojums, arī brīdinājums par kļūmi var nepienākt, ja to sūta ar to pašu pakalpojumu. Tāpēc jāparedz arī cits piemērots paziņošanas veids. Vienlaikus jābūt skaidram, kurš reaģē un kā rīkoties ārpus parastā darba laika.

Pārbaudes biežums atkarīgs no tā, cik būtiski pieteikumi ir uzņēmuma darbam un kā izveidota to apstrāde. Papildu pārbaude ir vajadzīga pēc būtiskām izmaiņām formā, vietnes mitināšanā, e-pasta iestatījumos vai savienojumā ar citu sistēmu. Ar vienreizēju pārbaudi vietnes palaišanas dienā nepietiek visam tās darbības laikam.

Ko nedarīt, kad pieteikumi pazuduši

Nesāciet ar visu aizsardzības līdzekļu izslēgšanu. Ja tiek noraidīti derīgi pieteikumi, noskaidrojiet konkrēto iemeslu un pielāgojiet pieteikumu pārbaudes noteikumus. Noņemot visus ierobežojumus, var pieaugt surogātpasta apjoms, kurā īstās ziņas pamanīt kļūst vēl grūtāk.

Nesūtiet failu ar visu klientu pieteikumiem publiskā tērzētavā vai nepārbaudītam atbalsta pakalpojuma sniedzējam. Problēmas sākotnējai izpētei bieži pietiek ar pārbaudes pieteikumu, laiku, pieteikuma identifikatoru un kļūdas aprakstu. Ja izpētei vajadzīgi īsto klientu dati, jāvienojas, kam tiem būs piekļuve un kā tos droši nodot.

Nesteidzieties pasūtīt pilnīgi jaunu mājaslapu tikai tāpēc, ka nedarbojas forma. Vispirms noskaidrojiet cēloni un ietekmi. Atsevišķu konfigurācijas kļūdu var būt iespējams novērst esošajā vietnē. Plašāka pārbūve jāvērtē pēc tehniskā stāvokļa un uzņēmuma vajadzībām.

Uzturēšanā pārbaudām arī pieteikumu saņemšanu

CreateIT pārņem, uztur un apkalpo mājaslapas, arī citu izstrādātāju veidotas vietnes. Strādājam ar WordPress, WooCommerce, Drupal un individuāliem risinājumiem. Pārbaudām, vai darbojas formas un integrācijas un vai pēc izmaiņām nav radušās jaunas kļūdas. Vispirms novēršam to, kas traucē klientiem un jūsu komandai.

Pirmajā ziņā atsūtiet lapas adresi, īsi aprakstiet problēmu un norādiet, kur pieteikumam būtu jānonāk. Noderēs arī pārbaudes laiks un informācija par nesenām izmaiņām. Paroles un reālu klientu pieteikumus sākotnējā ziņā nesūtiet.

Varam pārbaudīt, kā mājaslapa apstrādā konkrētu pieteikumu un kur tas nonāk. Tad būs skaidrāk, kas jālabo uzreiz un kuriem jautājumiem jāpievēršas turpmākajā uzturēšanā.

Vairāk par darbu pēc mājaslapas palaišanas lasiet mājaslapu apkalpošanas un uzturēšanas pakalpojuma aprakstā.