Tinklaraštis
Paleidimas yra perdavimas: agentūroms skirtas klientui paruoštas kontrolinis sąrašas
Prieš perdavimą skirtas agentūrų kontrolinis sąrašas, kuris kiekvieną kliento paleidimą paverčia pakartojamu kokybės vartais.
Santrauka
Dauguma paleidimo patarimų į svetainę žiūri kaip į vienkartinį įvykį. Agentūrai kiekvienas paleidimas yra perdavimas, o pakartojamumas svarbiau nei tobula paleidimo diena. Šiame straipsnyje pateikiame prieš perdavimą skirtą kontrolinį sąrašą, sukurtą valdyti kelis klientų projektus. Jis apima griežtos perdavimo datos nustatymą, ankstyvą turinio užfiksavimą, testavimą iš kliento perspektyvos, patikrų apimties pagal svetainės tipą ir saugos, SEO bei runbook vartų vykdymą. Paskutinis žingsnis – 48 valandų tęsinys, kuris perkelia pamokas į kitą projektą. Naudokite tai kaip gyvą sąrašą, o ne kopijuokite ir įklijuokite.
Dauguma paleidimo patarimų parašyti vienai svetainei, todėl jie neveikia agentūroje. Jie daro prielaidą, kad turite neribotai laiko ištestuoti kiekvieną puslapį. Neturite. Turite kelis vykdomus projektus, klientą, kuris du kartus pakeitė telefono numerį, ir suinteresuotąjį asmenį, kuris nuolat rašo dėl vienos smulkmenos. Veikiantys patarimai į paleidimą žiūri kaip į perdavimą, o ne į įvykį. Jūsų tikrasis produktas yra pakartojamas procesas, kuris sukuria svetainę, kurioje klientas gali gyventi neskambindamas jums panikoje. Šis sąrašas – tas procesas, sukurtas agentūroms, kurios turi vykdyti tą patį kokybės vartą skirtingiems klientams, biudžetams ir svetainių tipams. Naudokite jį kaip stuburą, o ne universalų kopijuotiną sąrašą.
Pirmiausia nustatykite perdavimo datą
Perdavimo datą įrašykite į kalendorių prieš pasirinkdami šabloną. Pavadinkite ją „klientui paruošta“ vietoj „paleidimas“. Tada dirbkite atgal: turinio terminas, dizaino peržiūra, testavimo langas ir tikras rezervas, nes klientas vėluos bent dvi dienas. Užrašykite datą ten, kur visi ją matytų.
Jei datos nėra, apimties plėtimasis neturi inkaras. Kai klientas prašo dar vieno puslapio, galite pasakyti, kad tai nukelia perdavimo datą. Jei data jau egzistuoja, kompromisas matomas; jei ne, kiekvienas smulkus prašymas yra nemokamas, o kiekvienas terminas – fikcija. Agentūra, kuri negali įvardyti perdavimo datos, negali apsaugoti savo maržų. Kai pradedate nuo neaiškios užduoties, pakartojamas agentūros procesas kiekviename projekte išlaiko tą patį pokalbį.
Užfiksuokite turinį, kurio negalima improvizuoti
Turinys yra vieta, kur klientų svetainės žlunga, o ne kodas. Kūrėjas gali sukurti puslapį; jis negali sugalvoti tikrojo kliento adreso, kainų ar komandos biografijų. Nustatykite griežtą turinio terminą prieš dizaino patvirtinimą ir padarykite jį tokį pat griežtą kaip perdavimo data.
Kiekvienam projektui naudokite vieną standartinę informacijos rinkimo formą. Paprašykite telefono, el. pašto, fizinio adreso, darbo valandų ir trijų paslaugų, kurias klientas nori parduoti. Vienas klientas duos telefono numerį, kuris perjungiamas į faksą; kitas paduos logotipą, išsaugotą kaip „Word“ dokumentą. Pastebėti tai turinio rinkimo metu yra pigiau nei pastebėti gyvos svetainės apačioje.
Jei termino metu ko nors trūksta, paskelbkite su aiškiai pažymėtu vietos rezervavimu, o ne sustabdykite projektą. Vietos rezervavimas su terminu yra geriau nei sustabdytas kūrimas. Dažna klaida – traktuoti turinį kaip tai, ką galima pridėti vėliau, todėl paleidžiate svetainę su netinkamu žemėlapiu arba paslauga, kurią klientas nebeteikia nuo šešių mėnesių. Planavimas ir informacijos architektūra egzistuoja, kad šie sprendimai būtų priimti prieš kūrimą.
Testuokite kaip klientas blogą dieną
Jūs žiūrėjote į svetainę savaites, todėl matote tai, ko tikitės. Klientas mato tai, kas iš tikrųjų yra ekrane. Atidarykite svetainę inkognito lange su nauja sesija ir peržiūrėkite ją šviežiomis akimis.
Spustelėkite kiekvieną matomą nuorodą, ne tik tas, kurias prisimenate. Pateikite kiekvieną formą ir ištestuokite gedimų būsenas, ne tik sėkmės kelią. Įkelkite svetainę telefone, lėtu ryšiu ir atidarytu meniu. Patikrinkite, ar telefono numeris antraštėje atitinka tą, kuris yra kontaktų puslapyje.
Čia nedideli vėlavimai tampa istorijomis. Herojaus vaizdas, kuris kraunasi lėtai, mygtukas, kuris niekur neveda, lipni antraštė, kuri mobiliajame įrenginyje uždengia telefono numerį – bet kuris iš šių dalykų sudaro pirmąjį kliento įspūdį. Jums nereikia šimto patikrų; jums reikia tų kelių, kurių nebūtų galima paaiškinti. Rašybos klaida tinklaraščio įraše yra ištaisoma; sugedęs atsiskaitymas – ne. Jei tą patį testą atliekate kiekvienam klientui, nustojate pirmą savaitę po paleidimo skirti atsakymams į el. laiškus „mygtukas neveikia“.
Pritaikykite vartus svetainei
Prieš vykdydami bet kurį kontrolinį sąrašą, atlikite apimties nustatymą kiekvienam projektui. Keturių puslapių brošiūros svetainė ir parduotuvės katalogas nėra tas pats projektas. Vienodus patikrinimus taikyti abiem – arba per daug inžinerijos, arba per mažai testavimo. Prieš vykdydami sąrašą, nuspręskite, kurie patikrinimai svarbūs šiam klientui.
| Svetainės tipas | Privalomi patikrinimai |
|---|---|
| Brošiūros svetainė | Kliento perspektyvos patikra, kontaktiniai duomenys, SSL, pagrindinis SEO |
| Nukreipimo puslapis | Įkėlimo laikas, formos pateikimas, padėkos puslapis, analitika |
| El. prekyba | Atsiskaitymo kelias, mokėjimo testas, produktų nuotraukos, atsarginės kopijos |
Išlaikykite bendrus vartus – perdavimo datą, saugą, runbook, tęsinį – ir pridėkite patikras, kurios apsaugo šį konkretų klientą. Praleiskite apimties nustatymo žingsnį ir penktadienį praleisite testuodami paslaugų puslapį, o kliento tikrasis rūpestis – neveikiantis atsiskaitymas. Arba paleisite el. prekybos svetainę neištestavę mokėjimo srauto, ir klientas sužinos tik tada, kai dingsta užsakymas.
Sukurkite saugos vartus vieną kartą, vykdykite juos kiekvieną kartą
Sauga yra sritis, kurioje agentūros nukrypsta. El. prekybos klientui atliekate išsamų auditą, o tada praleidžiate brošiūros svetainę, nes jie nerenka duomenų. Tai klaidinga nuostata. UpGuard svetainių saugos gairės tos pačios praktikos reikalauja kiekvienoje svetainėje: nuolat atnaujinkite platformą, reikalaukite stipraus autentifikavimo, apribokite vartotojų teises, reguliariai kurkite atsargines kopijas ir viską teikite per SSL/TLS. Brošiūros svetainė vis tiek gali būti pažeista; kliento domenas vis tiek gali būti naudojamas šiukšlių laiškams siųsti.
Sukurkite vieną bendrą saugos kontrolinį sąrašą ir vykdykite jį kiekviename projekte. Daugiafaktorinis autentifikavimas įjungtas kiekvienam prisijungimui. Programinė įranga ir papildiniai atnaujinti. Atsarginė kopija, kuri buvo realiai ištestuota, o ne tik suplanuota. SSL/TLS sertifikatas įdiegtas ir veikiantis. Vartotojų teisės apribotos iki to, ko kiekvienam reikia.
Padarykite saugą taip/ne vartais. Jei nors vienas atsakymas yra „dar ne“, svetainė nėra paruošta klientui. Vykdykite vartus testavimo aplinkoje prieš paleidimo savaitę, nes sertifikato gedimai paleidimo naktį yra avarijos, už kurias negalite išrašyti sąskaitos. Laikykite sąrašą pakankamai mažą, kad kiekvienas punktas reikštų ką nors. Jei punktas visada praeina, automatizuokite jį arba įtraukite į kūrimo įrankius. Praleidimo kaina nėra abstrakti – tai vidurnakčio žinutė iš kliento, kurio svetainė buvo sugadinta.
Padarykite SEO patikra, o ne viltimi
Štai paleidimas, kurį jau matėte: svetainė tampa gyva, dizainas atrodo švarus, o po mėnesio klientas klausia, kodėl jo nėra „Google“. Mažos svetainės SEO atrodo kaip ateities problema, todėl ji praleidžiama. „Digital Marketing Institute“ pradedančiųjų SEO vadovas techninį nustatymą laiko pagrindų dalimi, o ne rinkodaros plepalais: HTTPS, XML svetainės schema ir robots.txt failas, kuris įsileidžia paieškos sistemas.
Pridėkite SEO skyrių prie savo perdavimo kontrolinio sąrašo ir padarykite jį konkretų. Patvirtinkite pavadinimo žymą ir meta aprašymą kiekvienam svarbiam puslapiui. Įsitikinkite, kad kiekvienas puslapis turi bent vieną realaus teksto turinį, o ne tik paveikslėlius. Sukurkite XML svetainės schemą ir pateikite ją. Patikrinkite, ar robots.txt neblokuoja puslapių, kuriuos norite indeksuoti.
Niekas iš to nėra brangu. Visa tai nuobodu, todėl praleidžiama. Kaina nematoma kelias savaites, tada sulaukiate skambučio: kodėl mano verslo nėra „Google“? Negalite atsakyti į tai perdavimo patikra; galite atsakyti tik įrodymu, kad pagrindai buvo vietoje prieš svetainei pradedant veikti. Norėdami visos sąrankos, paleiskite „no-code“ svetainę, kuri reitinguojasi nuo pirmos dienos. Bent jau padarykite SEO vartus taip/ne sąrašu, kad „SEO padarysime vėliau“ negalėtų įsliūkinti į projektą.
Perduokite raktus su runbook
Perdavimas nebaigtas, kai svetainė tampa gyva. Jis baigtas, kai klientas gali prisijungti neskambindamas jums. Nuoroda ir slaptažodis nėra perdavimas; tai pirmoji namų užduotis. Klientas ras nustatymų puslapį, eksperimentuos ir arba ką nors sugadins, arba paskambins su klausimu, į kurį būtumėte galėję atsakyti viename puslapyje.
Parašykite runbook. Kaip prisijungti ir pakeisti pagrindinio puslapio tekstą. Kaip pakeisti paveikslėlį. Kur yra domenas ir hostingas. Kada atnaujinamas domenas ir kas už jį atsakingas. ICANN domeno registracijos procesas reikalauja veikiančios kontaktinės informacijos, susietos su savininku. Jei klientas yra domeno savininkas, jis turi žinoti, kur yra paskyra ir kas atsitiks, jei ji pasibaigs. Įrašykite atnaujinimo datą į runbook; nenorite, kad pirmasis pokalbis po paleidimo būtų „mūsų svetainė dingo, nes niekas neatnaujino domeno“.
Runbook gali būti vieno puslapio. Jam nereikia būti vadovu. Bet jis turi egzistuoti, ir klientas turi jį atidaryti, kol dar esate pokalbio metu.
Susisiekite po 48 valandų
Klientas po paleidimo savaitę tyli. Jūs manote, kad jis patenkintas. Tada ateina sąskaitos el. laiškas ir suprantate, kad jis šešias dienas nežinojo, kaip atnaujinti savo kainas. Naudingiausias testas įvyksta po perdavimo, o ne prieš jį.
Praėjus 48 valandoms po svetainės paleidimo, išsiųskite trumpą žinutę. Užduokite vieną konkretų klausimą, o ne „ar viskas gerai?“. Konkretūs klausimai atskleidžia tikrus atsakymus. Ar bandėte prisijungti? Ar kontaktinė forma matoma jūsų gautuosiuose? Ar adresas apačioje teisingas? Užfiksuokite, ką klientas atsako, ir pridėkite tai prie kito projekto kontrolinio sąrašo.
Tai momentas, kai pagauate tai, ko nebūtumėte galėję pagauti: tikrąjį kliento telefono numerį, tikrus produkto paveikslėlius, integraciją, kuri veikia tik su jo duomenimis. Kiekvieną kartą, kai klientas atskleidžia spragą, pridėkite ją prie kito perdavimo vartų. Taip sąrašas išlieka gyvas, o ne tampa dokumentu, kurio niekas neskaito. Jei ieškote didesnės sistemos, kliento svetainės priežiūros brandos modelis prasideda ten, kur baigiasi šis tęsinys.
Vartai, o ne trofėjus
Tikslas – ne turėti išsamiausią kontrolinį sąrašą pramonėje. Tikslas – turėti vartus, kurie pagautų problemas, kurias realiai matote tarp savo klientų. Tai reiškia genėjimą. Jei patikra per paskutinius kelis paleidimus nesugavo nė vienos problemos, arba ją automatizavote, arba ji yra triukšmas. Sąrašas, pilnas visada praeinančių punktų, suteikia klaidingą užbaigtumo jausmą. Svarbios yra tos patikros, kurios kartais nepavyksta, nes būtent jos apsaugo nuo gėdingų skambučių.
Nepridėkite patikrų, kad jaustumėtės turtingi procesais. Pridėkite jas tik tada, kai jos užsitarnauja savo vietą. Geriausias paleidimo kontrolinis sąrašas agentūrai yra trumpesnis, nei manote: nustatyta perdavimo data, užfiksuotas turinys, išlaikytas kliento perspektyvos testas, žali saugos ir SEO vartai, perduotas runbook, suplanuotas 48 valandų tęsinys. Kai tie vartai egzistuoja, paleidimas nustoja būti baimės akimirka ir tampa formalumu. Tai skirtumas tarp agentūros, kuri kuria svetaines, ir agentūros, kuri jas pristato.

