Rezervācija sākas pirms kalendāra
Tiešsaistes rezervācija uzņēmumam dod iespēju saņemt pieteikumus arī tad, kad darbinieks nevar atbildēt uz zvanu. Tomēr kalendāra ievietošana mājaslapā pati par sevi nesakārto pakalpojuma sniegšanu. Klientam jāsaprot, ko viņš izvēlas, cik ilgi tas notiks, kur jāierodas un kas notiek pēc pogas nospiešanas. Savukārt uzņēmumam jāspēj solīto laiku patiešām nodrošināt. Labs rezervācijas risinājums savieno abas puses vienā saprotamā procesā.
Šajā rakstā aplūkojam sagatavošanos neliela pakalpojumu uzņēmuma rezervāciju sistēmai. Piemēri ir ilustratīvi: konsultācija, darbnīcas apmeklējums vai individuāla nodarbība. Tie nav apgalvojumi par konkrētu klientu rezultātiem. Mērķis ir palīdzēt jums pieņemt lēmumus pirms izstrādes un vēlāk pārbaudīt, vai uzbūvētā sistēma strādā tā, kā uzņēmumam nepieciešams.
Sāciet ar vienu reālu pakalpojumu un aprakstiet ceļu no intereses līdz notikušai vizītei. Pierakstiet arī situācijas, kurās cilvēks neatnāk, maina laiku vai izvēlas nepareizu pakalpojumu. Šīs situācijas nav reti tehniski izņēmumi. Tās ir ikdienas darba daļa, kurai nepieciešamas skaidras atbildes, atbildīgais darbinieks un vienkāršs rīcības veids.
Izlemiet, vai klients rezervē vai piesaka interesi
Svarīgākais sākuma jautājums ir apstiprinājuma nozīme. Vienā uzņēmumā brīva laika izvēle uzreiz nozīmē apstiprinātu rezervāciju. Citā tā ir tikai vēlme, kuru darbinieks pārbauda un apstiprina vēlāk. Abas pieejas var būt piemērotas, taču mājaslapā tās nedrīkst sajaukt. Ja uzņēmumam nepieciešams pārbaudīt darba apjomu, izbraukuma attālumu vai speciālista pieejamību, automātisks solījums var radīt problēmu.
Iedomāsimies remonta konsultāciju, kurai ir nemainīgs ilgums un noteikta vieta. To var piedāvāt kā konkrētu laiku. Savukārt sarežģīta objekta apsekošana var prasīt iepriekšēju sarunu. Šajā gadījumā klientam loģiskāk iesniegt pieteikumu ar vēlamo periodu. Galvenās pogas tekstam, apstiprinājuma lapai un e-pastam jālieto viena un tā pati nozīme.
Praktiski pierakstiet trīs statusus: saņemts pieteikums, apstiprināta rezervācija un atcelta rezervācija. Nosakiet, kurš drīkst tos mainīt un kā klients par izmaiņu uzzina. Ja apstiprinājums ir manuāls, norādiet paredzamo atbildes kārtību, neizdomājot termiņu, kuru komanda nespēs ievērot. Sistēmas teksts nedrīkst solīt tūlītēju vizīti, ja darbības process vēl prasa darbinieka lēmumu.
Sagatavojiet saprotamu pakalpojumu sarakstu
Rezervācijas izvēlnei nevajadzētu būt uzņēmuma iekšējā cenrāža kopijai. Klients var nezināt profesionālos saīsinājumus vai atšķirību starp vairākām līdzīgām procedūrām. Katram rezervējamam pakalpojumam sagatavojiet nosaukumu, īsu skaidrojumu, ilgumu, vietu un informāciju par cenu. Ja cena atkarīga no situācijas, paskaidrojiet, kad un kā to precizēs.
Piemēram, nosaukums “Sākotnējā konsultācija” ir noderīgs tikai tad, ja cilvēks saprot, ko tajā saņems. Var norādīt, ka tikšanās laikā apspriedīs vajadzību, izvērtēs pieejamo informāciju un vienosies par nākamo soli. Nevajag radīt iespaidu, ka konsultācijas rezervēšana jau ietver visu turpmāko darbu. Līdzīgi nodarbībai jānorāda līmenis, priekšnosacījumi un nepieciešamais inventārs, ja tāds tiešām vajadzīgs.
Pārbaudiet sarakstu ar cilvēku, kurš nepārzina jūsu nozari. Palūdziet viņam izvēlēties pakalpojumu konkrētā situācijā un paskaidrot savu izvēli. Ja nepieciešams mutisks papildskaidrojums, iespējams, tas jāiekļauj lapā. Vienkāršāks saraksts bieži ir noderīgāks par lielu izvēļu skaitu, kurā klientam pašam jāmin pareizā atbilde.

Nosakiet laika ilgumu un sagatavošanās rezervi
Klientam redzamais pakalpojuma ilgums un kalendārā aizņemtais laiks ne vienmēr ir vienādi. Pēc vizītes var būt jāsakārto telpa, jāaizpilda dokumentācija vai jāsagatavojas nākamajam klientam. Ja šos darbus neiekļauj pieejamības noteikumos, kalendārs izskatās pilns, bet reālais darbs sāk kavēties. Tāpēc jānosaka arī pārtraukumi pirms vai pēc pakalpojuma.
Pieņemsim, ka konsultācija ilgst četrdesmit piecas minūtes, bet piecpadsmit minūtes vajadzīgas pierakstu pabeigšanai. Šādā ilustratīvā piemērā viena rezervācija aizņem stundu no darbinieka pieejamības. Ja klients redz tikai konsultācijas ilgumu, tas ir pieņemami, tomēr sistēmai jābloķē viss darba periods. Šo noteikumu vajag pārbaudīt arī dienas pēdējam laikam.
Izlemiet, cik drīz pirms sākuma drīkst rezervēt un cik tālu nākotnē kalendārs ir atvērts. Darbiniekam var nebūt iespējams sagatavoties pieteikumam, kas saņemts dažas minūtes pirms vizītes. Savukārt pārāk tāla pieejamība rada risku, ka vēlāk mainīsies darba grafiks. Šie parametri jānosaka pēc uzņēmuma faktiskā darba ritma.
Savienojiet darbiniekus, telpas un aprīkojumu
Pakalpojumam var būt vajadzīgs vairāk nekā viens resurss. Pieejams darbinieks vēl nenozīmē, ka pieejama telpa, konkrēta iekārta vai transportlīdzeklis. Pirms sistēmas izstrādes uzzīmējiet vienkāršu tabulu: pakalpojums, nepieciešamais speciālists, nepieciešamā vieta un nepieciešamais aprīkojums. Tad kļūst redzams, kur dažādas rezervācijas var konfliktēt.
Ja divi darbinieki izmanto vienu kabinetu, kalendāram jāņem vērā kopīgā telpa. Ja katram ir savs kabinets un neatkarīgs inventārs, noteikumi var būt vienkāršāki. Grupas nodarbībām savukārt svarīga ir ietilpība: viena rezervācija samazina brīvo vietu skaitu, bet neaizņem visu nodarbību. Tie ir atšķirīgi darbības modeļi, kurus nevajag sajaukt vienā neskaidrā iestatījumā.
Sākumā iekļaujiet tikai tos resursus, kuri reāli ietekmē iespēju izpildīt solījumu klientam. Pārmērīgi detalizēta konfigurācija rada papildu uzturēšanas darbu. Taču neizlaidiet būtisku koplietojamu resursu tikai tāpēc, lai pirmā versija izskatītos vienkārša. Labs minimums ir mazākais modelis, kas novērš faktiskās dubultās rezervācijas un ir saprotams administratoram.
Uzbūvējiet īsu un saprotamu klienta ceļu
Klienta darbību secībai jāatbilst tam, kā viņš izvēlas pakalpojumu. Bieži loģiski sākt ar pakalpojumu, pēc tam piedāvāt pieejamo laiku un tikai beigās prasīt kontaktinformāciju. Ja vieta vai speciālists ir svarīgāks par laiku, secība var atšķirties. Svarīgi, lai katrs nākamais solis izmantotu jau izdarīto izvēli un neliktu visu ievadīt atkārtoti.
Pirms iesniegšanas parādiet īsu kopsavilkumu: izvēlētais pakalpojums, datums, laiks, vieta un cena vai cenas precizēšanas nosacījums. Klientam jāspēj atgriezties un labot izvēli, nezaudējot pārējos laukus. Mobilajā ierīcē pogām un kalendāram jābūt lietojamiem bez precīzas trāpīšanas sīkos elementos. Kļūdas paziņojumam jāpasaka, kurš lauks jāizlabo.
Nevajag prasīt konta izveidi tikai tāpēc, ka sistēma to tehniski atbalsta. Ja vienreizējai konsultācijai pietiek ar vārdu un saziņas informāciju, papildu parole var radīt lieku šķērsli. Konts kļūst pamatots tad, ja klientam vajadzīga rezervāciju vēsture, atkārtota pārvaldība vai cita skaidra funkcija. Katram papildu solim jābūt saprotamam ieguvumam.

Prasiet tikai darbam vajadzīgos datus
Anketas laukus izvēlieties pēc darbības vajadzības. Ja darbiniekam jānosūta apstiprinājums, nepieciešama uzticama kontaktadrese. Ja jāorganizē izbraukums, vajadzīga pakalpojuma vieta. Taču uzņēmuma reģistrācijas dati vai plašs problēmas apraksts var nebūt nepieciešams sākotnējai laika izvēlei. Obligāts lauks ir pamatots tad, ja bez tā rezervāciju nevar korekti apstrādāt.
Atsevišķi izvērtējiet brīvā teksta laukus. Cilvēks tajos var ierakstīt arī informāciju, kas rezervācijas organizēšanai nav vajadzīga. Norādiet, kādu informāciju gaidāt, un nelūdziet sensitīvus dokumentus vispārīgā pieteikuma formā. Ja konkrētam pakalpojumam nepieciešama īpaša informācijas apmaiņa, tai jāparedz atbilstošs process, piekļuves un skaidrojums.
Datu apstrādes tekstam jāatbilst faktiskajai sistēmai un uzņēmuma situācijai. Nepārkopējiet cita uzņēmuma politiku, nemainot saņēmējus, glabāšanas kārtību un kontaktus. Izstrādes uzdevumā jānorāda, kuri darbinieki redz pieteikumus un kur tie glabājas. Šis raksts nenosaka universālu juridisku risinājumu; tas palīdz pamanīt jautājumus, kas jāprecizē pirms palaišanas.
Atšķiriet saglabātu rezervāciju no nosūtīta e-pasta
Pēc pogas nospiešanas svarīgākais ir droši saglabāts pieteikums. E-pasta nosūtīšana ir nākamā darbība, kurai var būt savas kļūmes. Ja vēstule uzreiz nepienāk, tas automātiski nenozīmē, ka rezervācija nav izveidota. Klienta ekrānā vajag skaidru rezultātu un atsauci, kuru darbinieks var atrast sistēmā.
Uzņēmuma pusē jābūt iespējai atšķirt saņemtu rezervāciju no neizdevušās paziņojuma piegādes. Pretējā gadījumā klients var atkārtoti aizpildīt formu, bet darbinieks saņem divus ierakstus vienam laikam. Atkārtotai pogas nospiešanai vai pārlūka atsvaidzināšanai nevajadzētu radīt jaunu rezervāciju, ja tas joprojām ir tas pats iesniegšanas mēģinājums.
Pārbaudes laikā apzināti simulējiet lēnu atbildi un paziņojuma kļūdu. Skatieties, vai pieteikums saglabājas, vai lietotājs saņem saprotamu informāciju un vai darbinieks redz, kas jādara. Ziņojums “radās kļūda” bez turpmākā soļa nav pietiekams. Arī vispārīgs “viss veiksmīgi” nav korekts, ja sistēma patiesībā nevar apstiprināt rezultātu.
Izlemiet, vai vajadzīga priekšapmaksa
Maksājums nav obligāta katras rezervācijas daļa. Ja cenu vai darba apjomu vispirms precizē sarunā, tūlītēja apmaksa var radīt nepareizas gaidas. Fiksētam pakalpojumam var būt piemērota pilna maksa vai avanss, bet izvēle jāsaista ar uzņēmuma reālo procesu. Mājaslapā skaidri jāparāda, ko maksājums apstiprina un kas vēl jāsaskaņo.
Ja rezervācija tiek turēta maksājuma veikšanas laikā, jānosaka turēšanas ilgums un rīcība pēc tā beigām. Neveiksmīgs vai pārtraukts maksājums nedrīkst bezgalīgi aizņemt laiku kalendārā. Savukārt saņemtu maksājumu nedrīkst ignorēt tikai tāpēc, ka klients aizvēris pārlūku pirms atgriešanās mājaslapā. Sistēmai nepieciešama droša saikne starp rezervācijas un maksājuma stāvokli.
Pirms šīs funkcijas ieviešanas aprakstiet arī atcelšanu, pārcelšanu un atmaksas izskatīšanu. Konkrētie noteikumi jāsaskaņo atbilstoši pakalpojumam un piemērojamajām prasībām. Tehniskā sistēma izpilda noteikumus, bet tā pati nevar izdomāt uzņēmuma komerciālos nosacījumus. Ja tie vēl nav pieņemti, vienkāršāka pieteikuma plūsma var būt labāks sākuma risinājums.

Padariet pārcelšanu un atcelšanu pārvaldāmu
Klienta plāni var mainīties, un rezervācijas sistēmai tas jāņem vērā. Nosakiet, vai cilvēks var pats atcelt vai pārcelt laiku, līdz kuram brīdim to drīkst darīt un kas notiek vēlāk. Ja vajadzīga saziņa ar darbinieku, norādiet konkrētu kanālu. Šai informācijai jābūt pieejamai gan pirms rezervācijas, gan apstiprinājumā.
Pašapkalpošanās saitei jāattiecas tikai uz konkrēto rezervāciju. Tā nedrīkst atklāt citus klientus vai ļaut brīvi pārlūkot visu kalendāru ar personu datiem. Pārcelšanas laikā iepriekšējais un jaunais laiks jāapstrādā vienoti: klientam jāzina, kurš no tiem ir spēkā. Pēc izmaiņas nosūtāmajā informācijā jābūt jaunajam datumam, nevis tikai paziņojumam, ka kaut kas ir mainīts.
Izdomājiet arī uzņēmuma iniciētu atcelšanu. Ja darbinieks saslimst vai telpa nav pieejama, nepieciešams atrast skartās rezervācijas un sazināties ar klientiem. Vienkārša pieejamības noņemšana kalendārā neatrisina jau apstiprinātos pieteikumus. Atbildīgajam jāredz, kuri klienti informēti un kuriem vēl vajadzīgs individuāls risinājums.
Pārbaudiet kalendāru neērtos scenārijos
Sistēmas pārbaude nav tikai viena veiksmīga rezervācija. Pamēģiniet vienlaikus izvēlēties pēdējo brīvo laiku divos pārlūkos. Gala rezultātā sistēmai jāievēro pieejamības noteikumi, nevis jāpieņem abi pieteikumi tāpēc, ka abiem sākumā bija redzams brīvs laiks. Klientam, kurš laiku vairs nevar rezervēt, jāsaņem iespēja izvēlēties citu.
Pārbaudiet nedēļas nogales, brīvdienas, darbinieka prombūtni un pakalpojumu, kas beidzas pie darba laika robežas. Ja klienti ir dažādās valstīs, laikam jābūt saprotamam attiecīgajā laika joslā. Arī pāreja starp vasaras un ziemas laiku var radīt divdomīgus laikus. Tieši testos ir vieta noskaidrot, kā sistēma tos attēlo un saglabā.
Izmantojiet arī telefonu ar mazāku ekrānu un lēnāku savienojumu. Aizpildiet formu ar kļūdainu e-pastu, atgriezieties iepriekšējā solī un mēģiniet atkārtoti. Pārbaudiet, vai personas dati neparādās publiskā adresē vai citu klientu skatā. Katram pārbaudes scenārijam pierakstiet sagaidāmo un faktisko rezultātu; ar iespaidu, ka viss izskatās labi, nepietiek.
Sagatavojiet darbiniekam ikdienas darba kārtību
Pat labi izveidota klienta saskarne nepalīdz, ja uzņēmuma pusē nav skaidrs, kas apstrādā rezervācijas. Norādiet atbildīgo personu un aizvietotāju. Vienojieties, cik bieži pārskata jaunus pieteikumus, kā atzīmē notikušas vizītes un kur pieraksta nepieciešamās izmaiņas. Šim procesam jābūt izpildāmam arī noslogotā dienā.
Darbiniekam vajadzētu vienā vietā redzēt tuvākās rezervācijas, to statusu un darbam nepieciešamo informāciju. Piekļuve nav jāpiešķir plašāka, nekā vajadzīgs pienākumu veikšanai. Ja cilvēks tikai pārvalda kalendāru, viņam nav automātiski vajadzīgas vietnes koda vai visu sistēmas iestatījumu maiņas iespējas. Tas palīdz samazināt nejaušu izmaiņu risku.
Sagatavojiet īsu instrukciju ar reāliem ekrānattēliem: kur atrast rezervāciju, kā mainīt laiku, kā redzēt paziņojuma stāvokli un kam ziņot par kļūmi. Instrukcijai jāatbilst uzstādītajai versijai. Garš vispārīgs apraksts, kas neparāda konkrētās darbības, ikdienā būs mazāk noderīgs nekā daži precīzi soļi un piemērs.

Mēriet rezultātu pēc klienta ceļa
Rezervāciju skaits ir noderīgs, taču tas viens pats nepasaka, kur rodas problēmas. Aplūkojiet ceļu pa posmiem: pakalpojuma apskate, laika izvēle, formas sākšana, iesniegšana un faktiskā vizīte. Ja cilvēki bieži pārtrauc darbību pirms laika izvēles, iemesls var būt neskaidrs piedāvājums. Ja viņi apstājas formā, iespējams, tā prasa pārāk daudz informācijas.
Nesāciet ar desmitiem mērījumu, kuriem neviens neseko. Izvēlieties dažus jautājumus, uz kuriem tiešām vēlaties atbildēt. Piemēram, vai klienti atrod piemērotu laiku, cik pieteikumu jāprecizē manuāli un cik rezervāciju tiek pārceltas. Mērījumu tehnisko ieviešanu un datu apstrādi pieskaņojiet faktiskajai vietnes konfigurācijai un nepieciešamajām izvēlēm.
Vērtējiet arī darbinieka laiku. Ja tiešsaistes forma rada vairāk precizējošu zvanu nekā iepriekšējā kārtība, iespējams, pakalpojumu skaidrojums nav pietiekams. Automatizācijas ieguvums nav tikai lielāks iesniegumu skaits. Tas var būt arī mazāk pārpratumu, vienkāršāka grafika pārvaldība un skaidrāka saziņa ar cilvēkiem, kuri jau izlēmuši pieteikties.
Sāciet ar kontrolētu palaišanu
Pirms saites plašas izplatīšanas izpildiet pilnu rezervācijas ceļu ar saskaņotiem testa datiem. Pārbaudiet gan klienta apstiprinājumu, gan uzņēmuma ierakstu, gan darbinieka paziņojumu. Ja tiek izmantota apmaksa, tai nepieciešams atsevišķs pārbaudīts testa scenārijs. Testa rezultātu nedrīkst sajaukt ar reālu klienta rezervāciju vai patiesi iekasētu maksājumu.
Pirmajās darbības dienās īpaši sekojiet kļūdām, neskaidriem jautājumiem un neatbilstošām izvēlēm. Saglabājiet iespēju sazināties arī citā veidā, piemēram, ar uzņēmuma norādīto e-pastu. Tas nenozīmē, ka jāveido divas neatkarīgas uzskaites sistēmas. Manuāli saņemtais pieteikums jāiekļauj tajā pašā kalendāra kārtībā, lai novērstu konfliktus.
Pēc sākotnējās pārbaudes izvērtējiet vienu uzlabojumu reizē. Vispirms novērsiet kļūdas, kas liedz rezervēt vai rada nepareizus solījumus. Pēc tam uzlabojiet tekstus un darbību secību. Papildu funkcijas pievienojiet tad, kad saprotams, kādu problēmu tās atrisinās. Tādējādi sistēma attīstās pēc uzņēmuma vajadzībām, nevis pēc pieejamo pogu skaita.
Ko sagatavot sarunai par rezervāciju ieviešanu
Pirms sarunas apkopojiet pakalpojumu sarakstu, to ilgumu, darba laikus un nepieciešamos resursus. Pievienojiet piemēru, kā pašlaik saņemat un apstiprināt pieteikumu. Norādiet, kuri soļi rada visvairāk pārpratumu vai aizņem darbinieka laiku. Ja ir esošs kalendārs, aprakstiet tā lomu, nesūtot paroles vai klientu datus parastā ziņojumā.
Atzīmējiet arī neatbildētos jautājumus. Jums nav pašiem jāizdomā visas tehniskās detaļas. Taču ir vērtīgi zināt, vai vajadzīgs tūlītējs apstiprinājums, manuāla pārbaude, vairāki darbinieki, vairākas vietas vai maksājums. No šīm izvēlēm izriet risinājuma apjoms un pārbaudes. Vienkāršs pieraksts vienam pakalpojumam atšķiras no vairāku resursu plānošanas sistēmas.
CANIMAPS DIGITAL pieteikumā aprakstiet savu pakalpojumu un vēlamo klienta ceļu. Pieteikums palīdz sākt sarunu par piemērotu risinājumu; tas pats par sevi nav pasūtījums vai apmaksas apstiprinājums. Sākuma mērķis ir vienoties par saprotamu procesu, kuru iespējams izveidot, pārbaudīt un pēc palaišanas uzturēt. Labs rezervācijas risinājums klientam dod skaidru nākamo soli un uzņēmumam uzticamu darba kārtību.
Ko darīt, ja internetā un telefonā pieejami atšķirīgi laiki
Ja uzņēmums pieņem rezervācijas vairākos kanālos, jābūt vienam noteiktam patiesās pieejamības avotam. Pretējā gadījumā darbinieks telefonā apsola laiku, kuru tajā pašā brīdī izvēlas mājaslapas apmeklētājs. Svarīgi nav tas, vai sākumā izmantojat sarežģītu programmu vai vienkāršu administrācijas skatu. Svarīgi, lai apstiprinājums notiktu pēc vieniem noteikumiem un katrs aizņemtais laiks būtu redzams visiem atbildīgajiem.
Sarunā ar izstrādātāju nosauciet visus pieteikumu kanālus: telefonu, e-pastu, klātieni, sociālos tīklus un esošās platformas. Katram aprakstiet, kurā brīdī pieteikums kļūst par rezervāciju. Ja klients tikai uzdod jautājumu sociālajā tīklā, tas vēl nav obligāti jābloķē kalendārā. Ja darbinieks laiku jau apstiprinājis, ieraksts jāsaglabā uzreiz. Šī atšķirība palīdz izvairīties gan no dubultas aizņemšanas, gan no nepamatoti tukša kalendāra.
Pārbaudiet arī situāciju, kad darbinieks rezervāciju labo klienta vietā. Labojumam jābūt saprotamam pārējiem kolēģiem, un klientam jāsaņem aktuālā informācija. Iekšēja piezīme nav tas pats, kas paziņojums klientam. Ja paziņojumu sūta manuāli, jābūt skaidram, kurš to izdara. Ja automātiski, darbiniekam jāredz, vai darbība ir notikusi vai vajadzīga atkārtota pārbaude.
Vienkāršs pieņemšanas pārbaudes piemērs
Sagatavojiet testa klientu ar uzņēmumam pieejamu testa e-pastu. Izvēlieties pakalpojumu, kuram zināms ilgums un pieejamais darbinieks. Pirms iesniegšanas pierakstiet sagaidāmo sākuma un beigu laiku. Pēc iesniegšanas salīdziniet klienta ekrānu, administrācijas ierakstu un saņemto paziņojumu. Visās trīs vietās jābūt vienādai informācijai par to pašu rezervāciju.
Pēc tam pārceliet šo rezervāciju uz citu pieejamu laiku. Pārbaudiet, ka iepriekšējais periods ir atbrīvots atbilstoši noteikumiem, jaunais periods aizņemts un vecā apstiprinājuma saite neļauj nejauši veikt nesaprotamu darbību. Atceliet rezervāciju un pārbaudiet gala statusu. Šī secība parāda vairāk nekā vienreizēja formas aizpildīšana, jo pārbauda arī izmaiņu dzīves ciklu.
Visbeidzot palūdziet kolēģim atkārtot to pašu bez jūsu mutiskiem norādījumiem. Pierakstiet vietas, kur viņš apstājas vai jautā, ko nozīmē poga. Ne katra neskaidrība prasa jaunu funkciju. Dažreiz pietiek ar precīzāku tekstu, redzamāku kopsavilkumu vai loģiskāku lauku secību. Pieņemšanas mērķis ir pierādīt, ka process ir saprotams un izpildāms cilvēkam, kurš nepiedalījās tā veidošanā.
Pārbaudes pierakstā norādiet datumu, vietnes versiju, izmantoto pārlūku un novēroto rezultātu. Ja atrodat problēmu, saglabājiet īsu reproducēšanas aprakstu, nevis tikai ekrānattēlu. Piemēram, norādiet izvēlēto pakalpojumu, sākotnējo laiku un darbību, pēc kuras parādījās nepareizais statuss. Tas ļauj uzturētājam pārbaudīt konkrēto gadījumu, neiztērējot laiku minējumiem. Testa datos neizmantojiet reāla klienta sensitīvu informāciju, ja pārbaudei pietiek ar izdomātu piemēru.
Pirms darba nodošanas vienojieties arī par kontaktpersonu, kura saņems uzturēšanas jautājumus un apstiprinās turpmākās procesa izmaiņas.