Blog

Az indítás egy átadás: Ügyfélkész ellenőrzőlista ügynökségeknek

Egy átadás előtti ellenőrzőlista ügynökségeknek, amely minden ügyfélindítást ismételhető minőségi kapuvá alakít.

Summary

A legtöbb indítási tanács egy webhelyet egyszeri eseményként kezel. Egy ügynökség számára minden indítás egy átadás, és az ismételhetőség fontosabb, mint egy tökéletes indulási nap. Ez a cikk egy átadás előtti ellenőrzőlistát ad, amelyet több ügyfélprojekt kezelésére terveztek. Lefedi az átadási dátum rögzítését, a tartalom korai befagyasztását, az ügyfél szemszögéből történő tesztelést, az ellenőrzések webhelytípus szerinti méretezését, valamint a biztonsági, SEO és runbook kapuk futtatását. Az utolsó lépés egy 48 órás utókövetés, amely visszacsatolja a tanulságokat a következő projektbe. Használd ezt élő ellenőrzőlistaként, nem pedig másolás-beillesztés listaként.

A legtöbb indítási tanács egyetlen webhelyre íródott, ezért nem működik egy ügynökségen belül. Feltételezi, hogy korlátlan időd van minden oldal tesztelésére. Nincs. Több projekt van folyamatban, egy ügyfél, aki kétszer is megváltoztatta a telefonszámát, és egy érdekelt fél, aki folyamatosan emailt ír egy apróságról. A működő tanács az indítást átadásként kezeli, nem eseményként. A valódi terméked egy ismételhető folyamat, amely egy olyan webhelyet eredményez, ahol az ügyfél élhet anélkül, hogy pánikban hívna. Ez az ellenőrzőlista az a folyamat, olyan ügynökségeknek készült, amelyeknek ugyanazt a minőségi kaput kell futtatniuk különböző ügyfelek, költségvetések és webhelytípusok között. Használd gerincként, nem pedig egy mindenki számára egyforma, másolandó listaként.

Először rögzítsd az átadási dátumot

Tedd az átadási dátumot a naptárba, mielőtt sablont választanál. Nevezd el ügyfélkésznek az indítás helyett. Azután haladj visszafelé: tartalom határideje, dizájn felülvizsgálat, tesztelési ablak, és egy valódi tartalékidő, mert az ügyfél legalább két napot csúszni fog. Írd le a dátumot, ahol mindenki látja.

Ha nincs dátum, a követelményterjedésnek nincs horgonya. Amikor egy ügyfél még egy oldalt kér, mondhatod, hogy ez eltolja az átadási dátumot. Ha a dátum már létezik, a kompromisszum látható; ha nem, minden apró kérés ingyen van, és minden határidő fiktív. Egy ügynökség, amely nem tud átadási dátumot nevezni, nem tudja védeni a haszonkulcsát. Ha homályos briefből indulsz, egy ismételhető ügynökségi folyamat ugyanazzá teszi ezt a beszélgetést minden projekten.

Rögzítsd a nem improvizálható tartalmat

A tartalom az, ahol az ügyfélwebhelyek szétesnek, nem a kód. Egy fejlesztő meg tud építeni egy oldalt; nem tudja kitalálni az ügyfél tényleges címét, árait vagy csapatbemutatóját. Szabj meg kemény tartalmi határidőt a dizájn jóváhagyása előtt, és legyen olyan szilárd, mint az átadási dátum.

Használj egy szabványos adatgyűjtő űrlapot minden projekten. Kérdezd meg a telefont, emailt, fizikai címet, nyitvatartást, és azt a három szolgáltatást, amit az ügyfél el akar adni. Az egyik ügyfél egy faxgépre továbbító telefonszámot ad, a másik egy Word dokumentumba mentett logót nyújt át. Ezeket tartalomgyűjtés közben elkapni olcsóbb, mint éles webhely láblécében.

Ha egy elem hiányzik a határidőre, tegyél közzé a helyén egy egyértelműen jelölt helyettesítőt, ahelyett, hogy befagyasztanád a projektet. A határidős helyettesítő jobb, mint egy elakadt fejlesztés. A gyakori hiba az, ha a tartalmat olyasminek tekintjük, amit később hozzá lehet adni – így indul egy webhely rossz térképpel vagy olyan szolgáltatással, amelyet az ügyfél hat hónapja megszüntetett. A tervezés és információarchitektúra azért létezik, hogy ezeket a döntéseket a fejlesztés előtt kényszerítse ki.

Tesztelj úgy, mint az ügyfél egy rossz napon

Hétekig bámultad a webhelyet, így azt látod, amit vársz. Az ügyfél azt látja, ami valójában a képernyőn van. Nyisd meg a webhelyet inkognitóablakban, friss munkamenettel, és fuss végig rajta friss szemmel.

Kattints minden látható linkre, ne csak azokra, amelyekre emlékszel. Küldj el minden űrlapot, és teszteld a hibafolyamatokat is, ne csak a sikeres utat. Töltsd be a webhelyet telefonon, lassú kapcsolaton, és nyitott menüvel. Ellenőrizd, hogy a fejlécben lévő telefonszám egyezik-e a kapcsolat oldalon lévővel.

Ezek azok a helyzetek, amikor a kis késések sztorikká válnak. Egy lassan betöltő hőskép, egy sehová nem vezető gomb, egy ragadós fejléc, amely mobilon eltakarja a telefonszámot – bármelyik meghatározza az ügyfél első benyomását. Nem száz ellenőrzésre van szükséged; arra a néhányra, amelyet lehetetlen lenne megmagyarázni. Egy elírás egy blogbejegyzésben javítható; a megtört fizetés nem. Ha ugyanazt a tesztet futtatod minden ügyfélnél, nem azzal töltöd az indítás utáni első hetet, hogy a gomb nem működik emailekre válaszolsz.

A kapu méretezése a webhelyhez

Futtass egy felmérési pass-t minden projekten, mielőtt bármilyen ellenőrzőlistát futtatnál. Egy négyoldalas brosúra webhely és egy webáruház-katalógus nem ugyanaz a projekt. Ugyanazokat az ellenőrzéseket alkalmazni mindkettőre vagy túltervezés, vagy alultesztelés. Mielőtt lefuttatod az ellenőrzőlistát, döntsd el, mely ellenőrzések számítanak ennél az ügyfélnél.

WebhelytípusKötelező ellenőrzések
Brosúra webhelyÜgyfélszempontú átnézés, elérhetőségek, SSL, alap SEO
CéloldalBetöltési idő, űrlapbeküldés, köszönőoldal, analitika
E-kereskedelemPénztárfolyam, fizetési teszt, termékképek, biztonsági mentések

Tartsd meg a közös kaput – átadási dátum, biztonság, runbook, utókövetés – és add hozzá azokat az ellenőrzéseket, amelyek az adott ügyfelet védik. Ha kihagyod a felmérési lépést, pénteken egy szolgáltatások oldalt tesztelsz, miközben az ügyfél valódi gondja a nem működő pénztár. Vagy úgy indítasz egy e-kereskedelmi webhelyet, hogy nem teszteled a fizetési folyamatot, és az ügyfél csak akkor veszi észre, amikor egy ügyfél rendelése eltűnik.

A biztonsági kapu felépítése egyszer, használata mindenkor

A biztonság az a terület, ahol az ügynökségek elsodródnak. Teljes auditot végzel az e-kereskedelmi ügyfélnek, majd kihagyod a brosúra webhelyet, mert nem gyűjtenek adatot. Ez rossz ösztön. Az UpGuard webhelybiztonsági útmutatója ugyanazokat a gyakorlatokat írja elő minden webhelyre: tartsd naprakészen a platformot, alkalmazz erős hitelesítést, korlátozd a felhasználói jogosultságokat, készíts rendszeres biztonsági mentéseket, és mindent SSL/TLS-en keresztül szolgálj ki. Egy brosúra webhelyet is feltörhetnek; egy ügyfél domainjét spam küldésére is használhatják.

Építs egy közös biztonsági ellenőrzőlistát, és futtasd minden projekten. Többtényezős hitelesítés engedélyezve minden bejelentkezéshez. Szoftverek és bővítmények frissítve. Olyan biztonsági mentés, amelyet ténylegesen teszteltek, nem csak ütemeztek. SSL/TLS tanúsítvány telepítve és élő. Felhasználói jogosultságok arra korlátozva, amire az egyes személyeknek szükségük van.

Tedd a biztonságot igen/nem kapuvá. Ha bármelyik válasz még nincs, a webhely nem ügyfélkész. Futtasd a kaput staging környezetben az indítási hét előtt, mert a tanúsítványhibák az indulás éjszakáján olyan vészhelyzetek, amelyekért nem számlázhatsz. Tartsd a listát elég kicsinek ahhoz, hogy minden elem jelentsen valamit. Ha egy elem mindig átmegy, automatizáld, vagy építsd be a build eszközeidbe. A kihagyás költsége nem elvont; ez egy ügyfél éjszakai üzenete, akinek a webhelyét megrongálták.

Az SEO legyen ellenőrzés, ne remény

Itt van egy indítás, amit már láttál: a webhely élesben van, a dizájn tiszta, egy hónappal később pedig az ügyfél megkérdezi, miért nem jelennek meg a Google-on. Egy kis webhelyen az SEO jövőbeli problémának tűnik, ezért kihagyják. A Digital Marketing Institute kezdő SEO útmutatója a technikai beállítást az alapok részének tekinti, nem marketinglényegtelennek: HTTPS, XML oldaltérkép és robots.txt fájl, amely beengedi a keresőmotorokat.

Adj SEO szekciót az átadási ellenőrzőlistádhoz, és tedd konkrétvá. Erősítsd meg, hogy minden kulcsoldalnak van title tagje és meta leírása. Győződj meg arról, hogy minden oldalon van legalább egy valódi szöveges tartalom, nem csak képek. Készíts XML oldaltérképet, és küldd be. Ellenőrizd, hogy a robots.txt nem blokkolja az indexelni kívánt oldalakat.

Egyik sem drága. Mindegyik fárasztó, ezért kihagyják. A költség néhány hétig láthatatlan, aztán jön a hívás: miért nem jelenik meg a vállalkozásom a Google-on? Ezt nem tudod megválaszolni egy átadási ellenőrzéssel; csak azzal tudod megválaszolni, ha bizonyítod, hogy az alapok a helyükön voltak, mielőtt a webhely éles lett. A teljes beállításhoz indíts no-code webhelyet, amely az első naptól jól szerepel a találatokban. Legalábbis tedd az SEO kaput igen/nem listává, hogy a majd később megcsináljuk az SEO-t ne csússzon be a projektbe.

A kulcsok átadása runbookkal

Az átadás nem fejeződik be, amikor a webhely élesbe megy. Akkor teljes, amikor az ügyfél be tud jelentkezni anélkül, hogy hívna téged. Egy link és egy jelszó nem átadás; az első házi feladat. Az ügyfél megtalálja a beállítások oldalt, kísérletezik, és vagy eltör valamit, vagy felhív egy olyan kérdéssel, amelyre egy egyoldalas dokumentumban is válaszolhattál volna.

Írj egy runbookot. Hogyan jelentkezz be, és hogyan módosítsd a főoldal szövegét. Hogyan cserélj képet. Hol él a domain és a tárhely. Mikor újul meg a domain, és ki a felelős érte. Az ICANN domainregisztrációs folyamata működő, a tulajdonoshoz kötött kapcsolattartási adatokat igényel. Ha az ügyfél birtokolja a domaint, tudnia kell, hol van a fiók, és mi történik, ha lejár. Tüntesd fel a megújítás dátumát a runbookban; nem akarod, hogy az első indulás utáni hívás az legyen, hogy eltűnt a webhelyünk, mert senki nem újította meg a domaint.

A runbook lehet egyoldalas. Nem kell kézikönyvnek lennie. De léteznie kell, és az ügyfélnek meg kell nyitnia, amíg még a hívásban vagytok.

Utókövetés 48 órán belül

Egy ügyfél egy hétre elcsendesedik az indítás után. Feltételezed, hogy elégedettek. Aztán megérkezik a számla email, és rájössz, hogy hat napot töltöttek azzal, hogy nem tudták frissíteni saját áraikat. A leghasznosabb teszt az átadás után történik, nem előtte.

Negyvennyolc órával az élesítés után küldj egy rövid üzenetet. Egy konkrét kérdést tegyél fel, ne azt, hogy minden rendben? A konkrét kérdések valódi válaszokat hoznak felszínre. Próbáltál bejelentkezni? Megjelenik a kapcsolati űrlap a postaládádban? Helyes a láblécben lévő cím? Jegyezd fel, mit jelent az ügyfél, és add hozzá a következő projekt ellenőrzőlistájához.

Ez az a pillanat, amikor elkapod, amit nem tudtál volna: az ügyfél valódi telefonszámát, tényleges termékképeit, az integrációt, amely csak az ő adataikkal működik. Amikor egy ügyfél felfed egy hiányosságot, tedd hozzá a következő átadási kapuhoz. Így marad az ellenőrzőlista élő, ahelyett hogy senki által nem olvasott dokumentummá válna. Ha a nagyobb rendszert keresed, az ügyfélwebhely-karbantartási érettségi modell ott kezdődik, ahol ez az utókövetés véget ér.

Kapu, nem trófea

A cél nem az, hogy neked legyen a legapróbb ellenőrzőlistád az iparágban. Hanem hogy legyen egy kapu, amely elkapja azokat a problémákat, amelyeket valójában látsz az ügyfeleidnél. Ez metszést jelent. Ha egy ellenőrzés az utolsó néhány indításodban egyetlen problémát sem fogott el, akkor vagy automatizáltad, vagy zaj. A mindig átmenő elemekkel teli ellenőrzőlista hamis befejezettségérzetet ad. A fontos ellenőrzések azok, amelyek néha elbuknak, mert ezek akadályozzák meg a kínos hívásokat.

Ne adj hozzá ellenőrzéseket csak azért, hogy folyamatos érzetet kelts. Csak akkor add hozzá őket, ha kiérdemlik a helyüket. A legjobb indítási ellenőrzőlista egy ügynökség számára rövidebb, mint gondolnád: átadási dátum rögzítve, tartalom rögzítve, ügyfélszempontú teszt átment, biztonsági és SEO kapuk zöldek, runbook átadva, 48 órás utókövetés ütemezve. Ha ez a kapu létezik, az indítás megszűnik rettegés lenni, és formalitássá válik. Ez a különbség az ügynökség között, amely webhelyeket épít, és az ügynökség között, amelyeket átad.

Sources (5)