Lansering er en overlevering: Byråets sjekkliste for kundeklare nettsider

Sammendrag

De fleste lanseringsråd behandler en nettside som en engangshendelse. For et byrå er hver lansering en overlevering, og repeterbarhet betyr mer enn en perfekt lanseringsdag. Denne artikkelen gir deg en sjekkliste før overlevering, bygget for å håndtere flere kundeprosjekter. Den dekker å sette en fast overleveringsdato, låse innhold tidlig, teste fra kundens perspektiv, tilpasse kontroller etter nettstedstype, og kjøre sikkerhets-, SEO- og runbook-porter. Det siste trinnet er en oppfølging etter 48 timer som fører lærdommen tilbake til neste prosjekt. Bruk dette som en levende sjekkliste, ikke en kopier-og-lim-liste.

De fleste lanseringsråd er skrevet for én nettside, og det er derfor de mislykkes i et byrå. De forutsetter at du har ubegrenset tid til å teste hver side. Det har du ikke. Du har flere prosjekter i gang, en kunde som endret telefonnummeret to ganger, og en interessent som fortsetter å maile om én liten ting. Rådene som virker, behandler lansering som en overlevering, ikke en hendelse. Ditt egentlige produkt er en repeterbar prosess som produserer en nettside kunden kan leve med uten å ringe deg i panikk. Denne sjekklisten er den prosessen, bygget for byråer som må kjøre den samme kvalitetsporten på tvers av ulike kunder, budsjetter og nettstedstyper. Bruk den som en ryggrad, ikke en liste som passer alle, å kopiere.

Sett overleveringsdatoen først

Sett overleveringsdatoen i kalenderen før du velger en mal. Kall den kundeklar i stedet for lansering. Arbeid deretter bakover: innholdsfrist, designgjennomgang, testvindu og en reell buffer, for kunden vil gli med minst to dager. Skriv datoen der alle kan se den.

Hvis det ikke finnes en dato, har scope creep ingen forankring. Når en kunde ber om én side til, kan du si at det flytter overleveringsdatoen. Hvis datoen allerede finnes, er avveiningen synlig; hvis den ikke finnes, er hvert lite krav gratis og hver frist er fiksjon. Et byrå som ikke kan navngi en overleveringsdato, kan ikke beskytte marginene sine. Når du starter fra et vagt brief, holder en repeterbar byråprosess denne samtalen den samme i hvert prosjekt.

Lås innholdet som ikke kan improviseres

Innhold er der kundenes nettsider faller fra hverandre, ikke i koden. En utvikler kan bygge en side; de kan ikke finne på kundens faktiske adresse, priser eller team-biografier. Sett en hard innholdsfrist før designgodkjenning og gjør den like fast som overleveringsdatoen.

Bruk ett standard innsamlingsskjema i hvert prosjekt. Be om telefon, e-post, fysisk adresse, åpningstider og de tre tjenestene kunden ønsker å selge. Én kunde gir deg et telefonnummer som går til en telefaks; en annen gir deg en logo lagret som et Word-dokument. Å fange opp dette under innsamlingen er billigere enn å fange det i footeren på en live side.

Hvis én del mangler ved fristen, publiser med en tydelig markert plassholder i stedet for å fryse prosjektet. En plassholder med en frist er bedre enn en byggeprosess som står stille. Den vanlige feilen er å behandle innhold som noe som kan legges til senere, og det er slik du lanserer et nettsted med feil kart eller en tjeneste kunden sluttet å tilby for seks måneder siden. Planlegging og informasjonsarkitektur finnes for å tvinge frem disse avgjørelsene før byggingen.

Test som kunden på en dårlig dag

Du har stirret på nettstedet i uker, så du ser det du forventer. Kunden ser det som faktisk er på skjermen. Åpne nettstedet i et inkognitovindu med en ny økt og kjør en gjennomgang med friske øyne.

Klikk på alle lenker du kan se, ikke bare de du husker. Send inn alle skjemaer, og test feiltilstandene, ikke bare suksessveien. Last nettstedet på en telefon, på en treg tilkobling, og med menyen åpen. Sjekk at telefonnummeret i headeren samsvarer med det på kontaktsiden.

Dette er der små forsinkelser blir historier. Et hero-bilde som lastes sakte, en knapp som ikke fører noen steder, en sticky-header som dekker telefonnummeret på mobil – hvilket som helst av disse rammer kundens førsteinntrykk. Du trenger ikke hundre kontroller; du trenger de få som ville være umulige å forklare. En skrivefeil i et blogginnlegg er fiksbart; en ødelagt kasseside er ikke. Hvis du kjører den samme testen på hver kunde, slutter du å bruke den første uken etter lansering på å svare på e-poster om at knappen ikke virker.

Tilpass porten til nettstedet

Kjør en avgrensningsgjennomgang på hvert prosjekt før du kjører noen sjekkliste. Et fire siders brosjyrenettsted og en butikkatalog er ikke det samme prosjektet. Å bruke identiske kontroller på begge er enten over-engineering eller under-testing. Før du kjører sjekklisten, avgjør hvilke kontroller som betyr noe for denne kunden.

Nettstedstype	Ikke-omsettelige kontroller
Brosjyrenettsted	Kundeperspektiv-gjennomgang, kontaktinformasjon, SSL, grunnleggende SEO
Landingsside	Lastetid, skjemainnsending, takkeside, analyse
E-handel	Kjøpsflyt, betalingstest, produktbilder, sikkerhetskopier

Behold den felles porten – overleveringsdato, sikkerhet, runbook, oppfølging – og legg til kontrollene som beskytter denne spesifikke kunden. Hopp over avgrensningstrinnet, og du vil bruke fredagen din på å teste en tjenesteside mens kundens egentlige bekymring er en kasseside som ikke behandler betalingen. Eller du vil lansere et e-handelsnettsted uten å teste betalingsflyten, og kunden finner det ikke ut før en kundes ordre forsvinner.

Bygg sikkerhetsporten én gang, kjør den hver gang

Sikkerhet er der byråer driver. Du gjør en full revisjon for e-handelskunden, men hopper over brosjyrenettstedet fordi de ikke samler inn data. Det er feil instinkt. Veiledningen til UpGuard for nettsidesikkerhet legger de samme praksisene på hvert nettsted: hold plattformen oppdatert, håndhev sterk autentisering, begrens brukerrettigheter, ta sikkerhetskopier regelmessig, og server alt over SSL/TLS. Et brosjyrenettsted kan fortsatt bli kompromittert; et kundedomene kan fortsatt brukes til å sende spam.

Bygg én felles sikkerhetssjekkliste og kjør den på hvert prosjekt. Flerfaktorautentisering aktivert for hver innlogging. Programvare og plugins oppdatert. En sikkerhetskopi som faktisk er testet, ikke bare planlagt. SSL/TLS-sertifikat installert og live. Brukerrettigheter begrenset til det hver person trenger.

Gjør sikkerhet til en ja/nei-port. Hvis et svar ikke er ennå, er ikke nettstedet kundeklart. Kjør porten i staging før lanseringsuken, fordi sertifikatfeil på lanseringskvelden er nødssituasjoner du ikke kan fakturere for. Hold listen liten nok til at hvert element betyr noe. Hvis et element alltid passerer, automatiser det eller innlem det i byggeverktøyene dine. Kostnaden ved å hoppe over det er ikke abstrakt; det er meldingen midt på natten fra en kunde hvis nettsted ble hacket.

Gjør SEO til en sjekk, ikke et håp

Her er en lansering du har sett: nettstedet går live, designet ser rent ut, og en måned senere spør kunden hvorfor de ikke dukker opp på Google. SEO på et lite nettsted føles som et fremtidig problem, så det blir hoppet over. Nybegynnerveiledningen til Digital Marketing Institute behandler teknisk oppsett som en del av grunnleggende ferdigheter, ikke markedsføringssnakk: HTTPS, et XML-sitemap og en robots.txt-fil som slipper søkemotorer inn.

Legg til en SEO-seksjon i overleveringssjekklisten din og gjør den konkret. Bekreft en tittel-tag og meta-beskrivelse for hver nøkkelside. Sørg for at hver side har minst én del med ekte tekstinnhold, ikke bare bilder. Generer et XML-sitemap og send det inn. Kontroller at robots.txt ikke blokkerer sidene du vil skal indekseres.

Ingen av dette er dyrt. Alt sammen er kjedelig, og det er derfor det blir hoppet over. Kostnaden er usynlig i noen uker, så får du telefonen: hvorfor dukker ikke bedriften min opp på Google? Du kan ikke svare på det med en overleveringssjekk; du kan bare svare med bevis for at det grunnleggende var på plass før nettstedet gikk live. For full oppsett, lanser et no-code-nettsted som rangerer fra dag én. I det minste, gjør SEO-porten til en ja/nei-liste slik at 'vi gjør SEO senere' ikke kan snike seg inn i prosjektet.

Overlever nøklene med en runbook

Overleveringen er ikke fullført når nettstedet går live. Den er fullført når kunden kan logge inn uten å ringe deg. En lenke og et passord er ikke en overlevering; det er en første hjemmelekse. Kunden vil finne innstillingssiden, eksperimentere, og enten ødelegge noe eller ringe deg med et spørsmål du kunne ha besvart i et dokument på én side.

Skriv en runbook. Hvordan logge inn og endre teksten på startsiden. Hvordan bytte ut et bilde. Hvor domenet og hostingen ligger. Når domenet fornyes og hvem som er ansvarlig for det. ICANNs domeneregistreringsprosess krever fungerende kontaktinformasjon knyttet til eieren. Hvis kunden eier domenet, må de vite hvor kontoen ligger og hva som skjer hvis det utløper. Legg fornyelsesdatoen i runbooken; du vil ikke at den første samtalen etter lansering skal være 'nettstedet vårt er borte' fordi ingen fornyet domenet.

Runbooken kan være én side. Den trenger ikke være en manual. Men den må eksistere, og kunden må åpne den mens du fortsatt er i samtalen.

Følg opp etter 48 timer

En kunde blir stille i en uke etter lansering. Du antar at de er fornøyde. Så kommer faktura-e-posten, og du innser at de brukte seks dager på å ikke vite hvordan de oppdaterer sine egne priser. Den mest nyttige testen skjer etter overleveringen, ikke før.

Førtiåtte timer etter at nettstedet går live, send en kort melding. Still ett spesifikt spørsmål, ikke 'er alt bra?' Spesifikke spørsmål avdekker ekte svar. Prøvde du å logge inn? Dukker kontaktskjemaet opp i innboksen din? Stemmer adressen i footeren? Loggfør hva kunden rapporterer tilbake og legg det til i neste prosjekts sjekkliste.

Dette er øyeblikket der du fanger opp det du ikke kunne ha fanget: kundens ekte telefonnummer, deres faktiske produktbilder, integrasjonen som bare fungerer med deres data. Hver gang en kunde avdekker et gap, legg det til i neste overleveringsport. Slik holder sjekklisten seg levende i stedet for å bli et dokument ingen leser. Hvis du ser etter det større systemet, starter modenhetsmodellen for vedlikehold av kundenettsteder der denne oppfølgingen slutter.

En port, ikke et trofé

Målet er ikke å ha den mest grundige sjekklisten i bransjen. Det er å ha en port som fanger problemene du faktisk ser på tvers av kundene dine. Det betyr beskjæring. Hvis en sjekk ikke har fanget opp et eneste problem i de siste lanseringene dine, har du enten automatisert den, eller den er støy. En sjekkliste full av elementer som alltid passerer, gir deg en falsk følelse av fullføring. Sjekkene som betyr noe, er de som av og til feiler, fordi det er de som forhindrer de pinlige samtalene.

Ikke legg til sjekker for å føle deg prosessrik. Legg dem bare til når de fortjener plassen sin. Den beste lanseringssjekklisten for et byrå er kortere enn du tror: overleveringsdato satt, innhold låst, kundeperspektiv-test bestått, sikkerhets- og SEO-porter grønne, runbook overlevert, 48-timers oppfølging planlagt. Når den porten finnes, slutter lansering å være et øyeblikk av frykt og blir en formalitet. Det er forskjellen mellom et byrå som bygger nettsider og et byrå som leverer dem.