Klients tiešsaistē izvēlas pakalpojumu un laiku, taču ar kalendāra ieraksta izveidi rezervācijas process vēl nebeidzas. Cilvēkam jāsaņem skaidrs apstiprinājums, jāzina, kā sagatavoties vizītei, un vajadzības gadījumā jāspēj laiku pārcelt vai atcelt. Uzņēmumam savukārt jāredz aktuāls grafiks un jābūt pārliecībai, ka darbinieki saņem pareizo informāciju.
Nepārdomāta plūsma rada manuālu saraksti, neskaidrību un lieku darbu. Automātisks ziņojums pats par sevi problēmu neatrisina, ja tajā nav svarīgās informācijas, tas nonāk nepareizā brīdī vai aizved uz saiti, kurā klientam nav saprotams nākamais solis. Tāpēc rezervāciju atgādinājumi jāplāno kā viena klienta ceļa daļa, nevis kā atsevišķs tehnisks papildinājums.
Šajā ceļvedī soli pa solim izskatīsim, kā uzņēmumam izplānot apstiprinājumus, atgādinājumus, pārcelšanu un atcelšanu. Raksts neparedz vienu universālu rīku visiem uzņēmumiem. Piemērotākais risinājums ir atkarīgs no pakalpojuma, darba laika, darbinieku noslodzes, izmantotā kalendāra un tā, kā klientu dati tiek apstrādāti.
1. Sāciet ar rezervācijas mērķi, nevis ziņojumu rīku
Pirms izvēlēties e-pastu, īsziņu vai citu kanālu, definējiet, ko konkrētā rezervācija nozīmē uzņēmuma darbā. Dažos uzņēmumos klients rezervē noteiktu pakalpojumu pie konkrēta speciālista. Citos gadījumos viņš tikai piesaka vēlamo laiku, kuru darbinieks vēl pārbauda un apstiprina. Šīs plūsmas klientam jāizskaidro atšķirīgi.
Ja sistēma uzreiz parāda vārdu “apstiprināts”, bet uzņēmuma darbiniekam vēl jānovērtē pieejamība, rodas maldīga gaida. Drošāk ir skaidri nošķirt saņemtu pieprasījumu no apstiprinātas rezervācijas. Klientam jāzina, vai vieta jau ir garantēta, vai arī viņš saņems papildu atbildi pēc pārbaudes.
Pierakstiet vienā teikumā rezervācijas rezultātu: kas ir rezervēts, kam, uz kuru laiku un kas notiks tālāk. Šis teikums kļūs par pamatu gan pogas tekstam, gan apstiprinājuma lapai, gan turpmākajiem ziņojumiem. Ja komanda nespēj vienoties par šo rezultātu, automatizēt vēl ir par agru.
2. Uzzīmējiet visu klienta ceļu
Rezervācijas plūsmu ir vērts uzrakstīt kā notikumu secību: pakalpojuma izvēle, brīvā laika izvēle, kontaktinformācijas ievade, noteikumu apstiprināšana, rezervācijas izveide, apstiprinājums, atgādinājums, pakalpojuma saņemšana un pēcapstrāde. Atsevišķi atzīmējiet pārcelšanu, atcelšanu un situāciju, kad uzņēmums nevar piedāvāto laiku nodrošināt.
Pie katra soļa norādiet, ko redz klients, kas tiek saglabāts sistēmā un kuram darbiniekam jāreaģē. Šī vienkāršā karte bieži atklāj nepilnības. Piemēram, klients saņem apstiprinājumu, bet atbildīgā darbinieka kalendārā ieraksts neparādās; vai arī atcelšanas saite darbojas, taču komanda par izmaiņām neuzzina.
Ceļa kartē iekļaujiet arī kļūmju scenārijus. Kas notiek, ja maksājums neizdodas, ja ziņojumu nevar piegādāt vai ja divi cilvēki vienlaikus izvēlas pēdējo brīvo laiku? Nav jāsola, ka kļūmes nekad nebūs. Jāparedz saprotama rīcība, kad tās notiek.
3. Apstiprinājumā iekļaujiet tikai vajadzīgo
Labs rezervācijas apstiprinājums atbild uz svarīgākajiem klienta jautājumiem bez nepieciešamības meklēt informāciju mājaslapā. Tajā parasti jābūt pakalpojuma nosaukumam, datumam, laikam, vietai vai attālinātās tikšanās norādei, izvēlētajam speciālistam, ja tas ir būtiski, un skaidram nākamajam solim.
Ja pakalpojumam nepieciešama sagatavošanās, pievienojiet īsu un konkrētu norādi. Piemēram, ko paņemt līdzi, cik agrāk ierasties vai kādu informāciju sagatavot pirms attālinātas sarunas. Garu noteikumu kopiju labāk aizstāt ar kopsavilkumu un saiti uz aktuālo lapu, lai klientam vienā ziņojumā nav jāizlasa pārmērīgi daudz.
Apstiprinājums nedrīkst radīt iespaidu par apmaksu, ja maksājums nav veikts. Ja rezervācija un maksājums ir atsevišķi soļi, katra statusu nosauciet precīzi. Arī pieteikums nav pirkuma apstiprinājums. Formulējumiem jāatbilst faktiskajam procesam un uzņēmuma noteikumiem.
4. Parādiet rezultātu gan lapā, gan ziņojumā
Pēc rezervācijas iesniegšanas klientam uzreiz jāredz nepārprotams rezultāts pašā mājaslapā. Paļauties tikai uz e-pastu nav pietiekami, jo ziņojums var aizkavēties, nonākt nevēlamā pasta mapē vai netikt piegādāts kļūdaini ievadītas adreses dēļ. Apstiprinājuma lapai jāpasaka, vai darbība izdevās un kas notiks tālāk.
Vienlaikus saglabājiet rezervācijas ierakstu tā, lai uzņēmums var pārbaudīt notikušo neatkarīgi no paziņojuma piegādes. Paziņojums klientam un ieraksts kalendārā nav viens un tas pats. Sistēmai nevajadzētu rādīt veiksmīgu rezultātu, ja rezervācija nav saglabāta.
Pārbaudes laikā izmēģiniet lēnu internetu, atkārtotu pogas nospiešanu un pārlūka aizvēršanu pēc iesniegšanas. Mērķis ir novērst dublikātus un neskaidrus stāvokļus. Ja sistēma nevar droši noteikt rezultātu, klientam jāsaņem godīgs skaidrojums un kontrolēts veids, kā pārbaudīt vai atkārtot darbību.
5. Izvēlieties atgādinājumu laiku pēc pakalpojuma veida
Atgādinājuma laiks jāizvēlas pēc tā, cik daudz sagatavošanās klientam nepieciešams un cik ātri uzņēmums var aizpildīt atbrīvotu laiku. Īsam attālinātam zvanam var pietikt ar atgādinājumu tajā pašā dienā, bet pakalpojumam, kuram jāierodas konkrētā vietā vai jāņem līdzi dokumenti, noder agrāks paziņojums.
Pārāk daudz atgādinājumu var kļūt uzmācīgi. Katram ziņojumam jābūt konkrētam uzdevumam: apstiprināt, sagatavot, atgādināt vai ļaut mainīt laiku. Ja divi paziņojumi atkārto vienu un to pašu bez jaunas vērtības, vienu no tiem var izņemt.
Sāciet ar vienkāršu ritmu un vērojiet reālo procesu. Piemēram, viens paziņojums pietiekami laicīgi, lai klients varētu mainīt plānus, un otrs īss atgādinājums tuvāk vizītei, ja tas ir pamatoti. Precīzais intervāls jāvienojas uzņēmumam, nevis jāņem no nejaušas universālas veidnes.
6. Saskaņojiet kanālus ar klienta izvēli un iespējām
E-pasts ir piemērots detalizētai informācijai un saitēm, savukārt īsāks mobilais paziņojums var būt vieglāk pamanāms. Tomēr kanāla izvēle ietekmē izmaksas, tehnisko pieslēgumu un personas datu apstrādi. Ārējo pakalpojumu maksas un nosacījumi jāizvērtē atsevišķi.
Ja uzņēmums piedāvā vairākus saziņas veidus, klientam skaidri jānorāda, kādam nolūkam viņa kontaktinformācija tiks izmantota. Pakalpojuma atgādinājums nav automātiski tas pats, kas mārketinga ziņojums. Nevajadzētu sajaukt praktisku informāciju par rezervāciju ar reklāmas saturu bez atbilstoša pamata un skaidras izvēles.
Pārbaudiet arī, vai darbinieks redz klienta izvēlēto kanālu un vai sistēma spēj fiksēt nepiegādātu ziņojumu. Ja automātisks paziņojums nav sasniedzis adresātu, uzņēmumam jāzina, vai konkrētajā situācijā nepieciešama cita rīcība.
7. Atgādinājums var palīdzēt klientam sagatavoties
Noderīgs atgādinājums nav tikai datuma atkārtojums. Tas palīdz klientam izdarīt to, kas vajadzīgs veiksmīgai vizītei. Frizētavai tā var būt īsa norāde par izvēlēto pakalpojumu; konsultācijai — saite uz attālināto tikšanos un jautājumi, kurus vērts sagatavot; remontdarbnīcai — informācija par automašīnas nodošanas vietu.
Tekstam jābūt īsam, taču pietiekamam. Svarīgāko novietojiet sākumā: laiks, vieta un darbība, ko klients var veikt. Ja ir īpaši nosacījumi, norādiet tos saprotamā valodā. Neslēpiet būtisku atcelšanas vai ierašanās informāciju neskaidrā saitē.
Vienmēr pārbaudiet ziņojumu telefonā. Garš temats, pārāk plaša tabula vai saite bez paskaidrojuma var padarīt saturu grūti lietojamu. Tekstam jābūt saprotamam arī bez attēliem, un saites nosaukumam jāpasaka, ko klients atvērs.
8. Atcelšanas noteikumiem jābūt redzamiem pirms rezervācijas
Klients nevar pieņemt informētu lēmumu, ja atcelšanas nosacījumi parādās tikai pēc rezervācijas. Pirms iesniegšanas skaidri norādiet, līdz kuram brīdim laiku var mainīt vai atcelt, kā tas izdarāms un vai pastāv citi saskaņoti nosacījumi. Tekstam jāatbilst uzņēmuma faktiskajai kārtībai.
Ja noteikumi atšķiras pēc pakalpojuma, sistēmai jāparāda pareizā versija. Nav lietderīgi vienā garā dokumentā likt klientam meklēt, kura rindkopa attiecas uz viņa izvēli. Kopsavilkums rezervācijas solī un saite uz pilno aktuālo informāciju parasti ir saprotamāks risinājums.
Atcelšanas nosacījumus nepārvērtiet par juridisku solījumu bez pārbaudes. Uzņēmumam jāapstiprina gala formulējums un vajadzības gadījumā jākonsultējas ar atbilstošu speciālistu. Tehniskā sistēma tikai īsteno saskaņoto kārtību; tā pati nenosaka uzņēmuma juridiskos pienākumus.
9. Pārcelšanu veidojiet kā kontrolētu plūsmu
Ērta pārcelšana ļauj klientam izvēlēties citu pieejamu laiku, neizveidojot otru neatkarīgu rezervāciju. Sistēmai jāzina, kuru sākotnējo ierakstu mainīt, un jānovērš situācija, kurā abi laiki paliek aizņemti. Pēc izmaiņas klientam un uzņēmumam jāredz vienāds aktuālais rezultāts.
Pirms apstiprināšanas parādiet veco un jauno laiku, lai cilvēks var pārbaudīt izvēli. Pēc apstiprināšanas nosūtiet atjaunotu informāciju un skaidri norādiet, ka iepriekšējais laiks vairs nav spēkā. Ja pārcelšana vairs nav atļauta tiešsaistē, piedāvājiet konkrētu saziņas ceļu, nevis tukšu kļūdas lapu.
Jāpārbauda arī vienlaicīgas darbības. Kamēr klients izvēlas jaunu laiku, to var mēģināt rezervēt cits cilvēks. Pieejamība jāapstiprina serverī izmaiņas brīdī, nevis tikai tad, kad kalendārs sākotnēji tika atvērts.
10. Kalendāram jāatspoguļo reālā kapacitāte
Brīvs laiks kalendārā nav tikai tukša rūtiņa. Pieejamību var ietekmēt darbinieka grafiks, telpa, aprīkojums, pakalpojuma ilgums un nepieciešamais laiks starp klientiem. Ja sistēma pārbauda tikai vienu no šiem resursiem, tā var pieņemt rezervāciju, kuru uzņēmums faktiski nevar izpildīt.
Pirms tehniskās izstrādes uzskaitiet visus ierobežojumus. Vai dažādi pakalpojumi aizņem atšķirīgu laiku? Vai vienam speciālistam vajadzīga konkrēta telpa? Vai pēc vizītes jāparedz sagatavošanās intervāls? Šie noteikumi jāformulē saprotami, lai tos var pārbaudīt arī uzņēmuma darbinieki.
Kalendāra sinhronizācija jātestē abos virzienos, ja tā paredzēta. Pārbaudiet, cik ātri aizņemts laiks pazūd no publiskās izvēles un kā tiek apstrādātas manuālas izmaiņas. Sinhronizācija nav jāuzskata par veiksmīgu tikai tāpēc, ka savienojums tehniski izveidots.
11. Definējiet darbinieku rīcību pēc katra notikuma
Automatizācija ir vērtīga tikai tad, ja tā iederas komandas darbā. Nosakiet, kurš pārskata jaunas rezervācijas, kurš reaģē uz atcelšanu un kurš risina kļūmes. Darbiniekam jāredz rezervācijas statuss un nākamā darbība, nevis jāmeklē informācija vairākās nesaistītās vēstulēs.
Vienojieties par statusiem, piemēram: saņemts pieprasījums, apstiprināts, pārcelts, atcelts, izpildīts. Statusu nosaukumiem jābūt saprotamiem visai komandai. Ja katrs darbinieks tos interpretē atšķirīgi, atskaites un automatizētie ziņojumi kļūs neuzticami.
Noteiktos gadījumos nepieciešama manuāla pārbaude. Piemēram, nestandarta pakalpojums, īpašs pieejamības pieprasījums vai kļūdains maksājuma statuss var prasīt darbinieka iesaisti. Šādi izņēmumi jāizceļ, nevis jāpaslēpj kopējā sarakstā.
12. Integrācijas plānojiet pēc datu avota
Rezervāciju sistēma var būt saistīta ar mājaslapu, darbinieku kalendāru, klientu profilu, e-pasta piegādi, maksājumu risinājumu vai uzņēmuma iekšējo sistēmu. Pirms savienošanas nosakiet, kura sistēma ir galvenais avots katram datam. Pretējā gadījumā dažādās vietās var parādīties atšķirīgs laiks vai statuss.
Pierakstiet, kādi dati pārvietojas, kurā virzienā un pēc kāda notikuma. Piemēram, mājaslapā izveidota rezervācija var nosūtīt ierakstu uz kalendāru, bet kalendārā veikta atcelšana — atjaunot klienta profilu. Katram savienojumam vajadzīgs kļūdu žurnāls un veids, kā atkārtot neizdevušos darbību bez dublikāta.
Individuālas integrācijas jāizvērtē atsevišķi. Nav droši pieņemt, ka divi rīki būs savietojami tikai tāpēc, ka abi piedāvā kalendāru. Jāpārbauda pieejamās saskarnes, atļaujas, datu lauki un ārējo pakalpojumu nosacījumi.
13. Savāciet tikai vajadzīgos datus un ierobežojiet piekļuvi
Rezervācijai parasti nepieciešama kontaktinformācija un dati par izvēlēto pakalpojumu, taču katrs papildu lauks jāspēj pamatot ar konkrētu darba vajadzību. Jutīgu informāciju nevajadzētu prasīt tikai tāpēc, ka veidne piedāvā šādu lauku. Daļu informācijas var drošāk precizēt vēlāk.
Piekļuves tiesībām jāatbilst darbinieku pienākumiem. Speciālistam var būt vajadzīgs dienas grafiks un klienta sagatavošanās piezīme, bet ne visa klientu datubāze vai sistēmas iestatījumi. Administratoram savukārt vajadzīgas tehniskas tiesības, taču arī tās jāpiešķir apzināti.
Uzņēmumam jāvienojas par glabāšanas, labošanas un dzēšanas kārtību. Sīkdatņu un analītikas iestatījumiem jāatbilst izvēlētajai piekrišanas pieejai. Šis raksts neaizstāj juridisku izvērtējumu; gala procesus un dokumentus apstiprina uzņēmums.
14. Testējiet pilnu ceļu, nevis tikai pogu
Pirms palaišanas izveidojiet testa rezervācijas dažādiem pakalpojumiem, darbiniekiem, laikiem un ierīcēm. Pārbaudiet gan klienta redzamo pusi, gan ierakstu sistēmā. Katram testam fiksējiet gaidīto rezultātu, faktisko rezultātu un atbildīgo par labojumu.
Noteikti pārbaudiet nepareizu e-pastu, aizņemtu laiku, atkārtotu iesniegšanu, atcelšanu, pārcelšanu, nepiegādātu ziņojumu un manuālu kalendāra izmaiņu. Ja plūsmā ir maksājums, atsevišķi izmēģiniet veiksmīgu, neveiksmīgu un pārtrauktu maksājuma procesu. Nevienā gadījumā nedrīkst rādīt maldinošu statusu.
Testēšanā iesaistiet arī cilvēku, kurš sistēmu iepriekš nav redzējis. Lūdziet viņam skaļi izskaidrot, ko viņš sagaida pēc katras darbības. Šāds tests bieži atklāj neskaidrus formulējumus, kurus izstrādes komanda vairs nepamana.
15. Pēc palaišanas vērojiet procesam noderīgus signālus
Pēc palaišanas regulāri pārbaudiet, vai rezervācijas tiek saglabātas, paziņojumi tiek nosūtīti un darbinieki laikus redz izmaiņas. Nevajag vākt visu iespējamo. Izvēlieties dažus rādītājus, kas palīdz pieņemt lēmumu, piemēram, nepabeigtu rezervāciju gadījumus, atcelšanas brīdi vai nepiegādātu ziņojumu skaitu.
Skaitļus interpretējiet kopā ar kontekstu. Bieža pārcelšana var nozīmēt, ka klientiem mainās plāni, bet tā var arī norādīt uz neērtu laiku izvēli vai neskaidru pakalpojuma aprakstu. Pirms veikt izmaiņas, izskatiet konkrēto klienta ceļu un darbinieku novērojumus.
Analītiku pieslēdziet atbilstoši piekrišanas iestatījumiem un neiekļaujiet notikumu nosaukumos nevajadzīgus personas datus. Mērķis ir uzlabot procesu, nevis izveidot plašāku datu krājumu bez skaidras vajadzības.
16. Ieviesiet pa posmiem un saglabājiet manuālu atkopšanu
Sarežģītu rezervāciju plūsmu nav obligāti jāievieš vienā reizē. Pirmajā posmā var sakārtot pakalpojumus, pieejamību un skaidru apstiprinājumu. Nākamajā pievienot atgādinājumus, pēc tam pārcelšanu un vajadzīgās integrācijas. Katrs posms jāpārbauda pirms nākamā.
Posmu pieeja samazina risku automatizēt nesakārtotu procesu. Tā ļauj komandai novērtēt, vai ziņojumi ir saprotami un vai kalendāra noteikumi atbilst ikdienas darbam. Izmaiņas balstās uz pārbaudītu pieredzi, nevis pieņēmumu, ka vairāk funkciju vienmēr nozīmē labāku rezultātu.
Saglabājiet dokumentētu manuālu rīcību gadījumiem, kad kāda sistēma nav pieejama. Darbiniekiem jāzina, kā pārbaudīt rezervāciju, sazināties ar klientu un atjaunot statusu pēc kļūmes. Atkopšanas plāns ir tikpat svarīgs kā automātiskais scenārijs.
17. Piemērs: neliela pakalpojumu uzņēmuma plūsma
Pieņemsim, ka neliels labsajūtas pakalpojumu uzņēmums piedāvā trīs procedūras ar atšķirīgu ilgumu un diviem speciālistiem. Klients mājaslapā izvēlas pakalpojumu, redz tikai tos laikus, kuros pieejams gan attiecīgais speciālists, gan telpa, un ievada vārdu, e-pastu un tālruņa numuru. Pirms iesniegšanas viņš redz īsu atcelšanas nosacījumu kopsavilkumu un saprot, ka poga izveidos rezervāciju, nevis tikai nosūtīs vispārīgu jautājumu.
Pēc iesniegšanas serveris vēlreiz pārbauda laika pieejamību. Ja laiks joprojām brīvs, rezervācija tiek saglabāta ar unikālu identifikatoru, klients redz apstiprinājuma lapu, bet speciālista kalendārā parādās ieraksts. E-pastā ir procedūras nosaukums, datums, laiks, adrese, īsa sagatavošanās norāde un saite izmaiņām. Ja ierakstu neizdodas saglabāt, sistēma nerāda viltus apstiprinājumu un saglabā ievadīto informāciju, lai klientam nebūtu jāsāk no jauna.
Atgādinājums tiek nosūtīts uzņēmuma izvēlētajā laikā. Klients tajā redz būtiskāko un var atvērt kontrolētu pārcelšanas lapu. Pārcelšanas laikā sistēma piedāvā tikai tai pašai procedūrai piemērotos laikus, atkārtoti pārbauda jauno izvēli un aizstāj sākotnējo ierakstu. Vecais laiks atbrīvojas tikai pēc sekmīgas izmaiņas, un abas puses saņem atjaunotu informāciju.
Ja klients atceļ rezervāciju, statuss mainās esošajā ierakstā, nevis tiek izveidots tukšs vai dublēts ieraksts. Atbildīgais darbinieks redz izmaiņu, un atbrīvotais laiks atkal kļūst pieejams atbilstoši uzņēmuma noteikumiem. Ja termiņš tiešsaistes atcelšanai ir beidzies, lapa izskaidro situāciju un piedāvā konkrētu saziņas veidu, nevis ļauj klientam domāt, ka atcelšana notikusi.
Darba dienas sākumā speciālists redz aktuālu grafiku, nevis atsevišķus ziņojumus no vairākiem kanāliem. Vadītājs var pārbaudīt nepiegādātus paziņojumus un kļūdu ierakstus, bet viņam nav manuāli jāapstiprina katra standarta rezervācija. Izņēmumi tiek izcelti atsevišķi. Šādi automatizācija samazina atkārtotu darbu, vienlaikus saglabājot cilvēka iesaisti tur, kur vajadzīgs lēmums.
Šis piemērs nav gatava funkciju pakete, kas vienādi der visiem. Citam uzņēmumam var būt vajadzīgs priekšapmaksas solis, vairāki resursi, grupu nodarbības vai tikai pieprasījuma apstiprināšana pēc darbinieka pārbaudes. Tāpēc sākuma uzdevums ir aprakstīt reālo procesu un robežsituācijas. Tikai pēc tam izvēlas kalendāru, ziņojumu kanālus un integrācijas.
Praktiskajā pārbaudē uzņēmums iziet cauri šim scenārijam ar testa kontaktinformāciju un salīdzina visus rezultātus. Klients redz vienu statusu, publiskais kalendārs vairs nepiedāvā aizņemto laiku, speciālista kalendārs rāda pareizo ilgumu, un paziņojumā nav pretrunīgas informācijas. Pēc pārcelšanas atkārto to pašu pārbaudi, lai pārliecinātos, ka vecais laiks tiešām ir atbrīvots un jaunais nav rezervējams citam klientam.
Komanda arī nosaka, kur glabājas atbildība par saturu. Ja mainās adrese, sagatavošanās norāde vai atcelšanas kārtība, jābūt skaidram, kurš atjaunina tekstu un kuras ziņojumu versijas jāpārbauda. Pretējā gadījumā mājaslapā var būt viena informācija, bet automātiskajā e-pastā — veca versija. Vienots pārskatīšanas saraksts palīdz saglabāt saskaņotu klienta pieredzi arī pēc sistēmas palaišanas.
Visbeidzot, uzņēmums fiksē atkopšanas soļus saprotamā instrukcijā. Tajā norāda, kur pārbaudīt rezervācijas ierakstu, kā atpazīt dublikātu, kā rīkoties ar nepiegādātu paziņojumu un kuram darbiniekam eskalēt tehnisku kļūmi. Šāda instrukcija palīdz turpināt darbu arī tad, ja atbildīgais kolēģis nav pieejams.
Pirms gala palaišanas ieplānojiet arī īsu darbinieku izmēģinājumu ar reālistisku dienas grafiku. Lai viens cilvēks izveido rezervāciju kā klients, otrs to apstrādā kā speciālists, bet trešais pārbauda atcelšanu un kļūdas ierakstu. Šāda lomu pārbaude palīdz pamanīt ne tikai tehniskas problēmas, bet arī neskaidru atbildības sadalījumu, nepilnīgas instrukcijas un situācijas, kurās informācija pienāk par vēlu.
18. Praktiska pārbaudes lapa pirms ieviešanas
Pārbaudiet, vai ir skaidri atbildēti šādi jautājumi: ko klients rezervē; vai rezervācija tiek apstiprināta uzreiz; kādi resursi nosaka pieejamību; kādu informāciju klients saņem; kad tiek sūtīti atgādinājumi; kā notiek pārcelšana un atcelšana; kas uzņēmumā saņem paziņojumu; un kā rīkoties kļūmes gadījumā.
Pārskatiet visus tekstus vienā komplektā — pogu, apstiprinājuma lapu, e-pastu, mobilo paziņojumu, atcelšanas lapu un kļūdas ziņojumu. Terminoloģijai jābūt vienādai. Ja vienā vietā rakstīts “pieteikums”, citā “rezervācija”, bet trešajā “pasūtījums”, klientam var būt grūti saprast faktisko statusu.
CANIMAPS DIGITAL palīdz plānot mājaslapas, rezervāciju kalendārus un saskaņotus sistēmu savienojumus atbilstoši konkrētam biznesa procesam. Vispirms izvērtējam vajadzību un tikai pēc tam piemērotu tehnisko risinājumu. Izlasiet arī, ko izdomāt pirms rezervāciju palaišanas, un kā sagatavoties sistēmu savienošanas sarunai. Ja vēlaties pārrunāt savu plūsmu, aprakstiet uzņēmuma vajadzību pieteikumā.