Blogg
Sluta välja webbhotell. Börja välja mönster.
Ett återanvändbart arbetsflöde som räddar din byrå från att behöva undersöka webbhotell för varje kund.
Sammanfattning
Den dyraste meningen i en webbbyrås arbete är 'låt oss hitta det bästa webbhotellet för den här kunden.' Sluta säga det. Ditt jobb är inte att hitta det bästa webbhotellet; det är att bygga en liten uppsättning webbhotellmönster som täcker de flesta kunder, och spara ny research för de sällsynta undantagen. Den här artikeln går igenom en hypotetisk detaljhandelskund genom en standardiserad process: ett intagformulär med fyra fält, tre webbhotellprofiler, en migreringschecklista, en tillförlitlighetsplan och en runbook på en sida. Du får också en kvartalsvis granskningsrutin som håller din webbhotellslista ärlig. Resultatet är färre nödlägen klockan 3 på natten, bättre marginaler och kunder som litar på dig för att inget gick sönder. Använd dessa steg för att förvandla webbhotell från en brandövning per projekt till en återkommande del av ditt arbetsflöde.
Den dyraste meningen i en webbbyrås arbete är också den vanligaste: "Låt oss hitta det bästa webbhotellet för den här kunden." Sluta säga det. Ditt jobb är inte att hitta det bästa webbhotellet. Ditt jobb är att välja en liten uppsättning webbhotellmönster som fungerar för majoriteten av dina kunder, och sedan använda din begränsade hjärnkapacitet på de få som verkligen faller utanför. Så här förvandlar du webbhotell från en brandövning per projekt till ett återkommande steg i ditt arbetsflöde. Här är genomgången, från en ny kunds första samtal till en överlämning du glömmer bort sex månader senare – för att inget gick sönder.
Föreställ dig en ny kund: en detaljhandelskedja med en katalogsajt, en blogg och en nätbutik. De har legat på ett billigt delat webbhotell som kraschar på Black Friday. De ber dig "fixa webbhotellet." Det här är ditt ögonblick att göra det de flesta byråer aldrig gör: köra dem genom en process, inte en panik.
Steg 1: Ställ rätt frågor en gång
Bygg ett intagformulär för webbhotell och låt varje kund fylla i det innan du pratar med dem. Formuläret ska innehålla fyra fält: beräknad månatlig trafik, innehållstyp (statisk, databasdriven, e-handel eller mediatung), efterlevnadskrav (PCI, HIPAA, GDPR) och supportförväntningar – vem som ska röra webbplatsen när något går sönder. Det är allt. Allt annat är brus.
När en kund säger "vi behöver det bästa webbhotellet" menar de egentligen "vi behöver att det inte kraschar under vår största rea." Ditt formulär fångar det på en rad: trafik. Det visar sig att den enda verkliga skillnaden mellan de flesta kunder är skala. En lågtrafikerad broschyrsajt och en högtrafikerad e-handelsbutik behöver olika resurser, men de behöver inte olika webbhotell om du redan har valt rätt mönster.
Formuläret dödar också spekulativa samtal. Utan det får du oändliga "tänk om vi växer?" och "ska vi använda det här webbhotellet vi såg på en skylt?" Filtrera bort dem innan de börjar. Om en kund inte kan svara på fyra frågor om sin egen webbplats är de inte redo för webbhotellråd; de är redo att få veta vad de ska göra.
För vår detaljhandelskund visar formuläret en webbplats med hälsosam men inte massiv trafik, en produktdatabas och noll efterlevnadskrav utöver grundläggande kortbetalningshantering. De förväntar sig att du hanterar allt, eftersom deras förra webbhotell "tappade bort" deras supportärende. Den sista detaljen betyder mer än något specifikationsblad.
Steg 2: Standardisera på tre profiler
När formuläret är inne, matcha kunden till en profil. Du bör inte ha fler än tre. Budget, support-först och prestanda. Det är hela menyn. Definiera dem en gång, dokumentera dem, och omförhandla dem inte per kund.
| Profil | Bäst för | Se upp för |
|---|---|---|
| Budget (delat) | Lågtrafikerade broschyrsajter, stram budget | Supporten är tunn, du tillhandahåller den |
| Support-först (hanterat) | Kunder som inte rör teknik, vill ha ett telefonnummer | Kostar mer, låser dig till deras stack |
| Prestanda VPS/dedikerad | E-handel, högtrafikerade, databastunga webbplatser | Kräver mer installations- och underhållskunskap |
Vilka webbhotell som hör till vilken profil är din läxa, inte kundens. En metod som fungerar: testa en kandidat per profil med ett projekt med låga insatser, och dokumentera sedan allt – etableringstid, prestanda, supportsvarstid, faktureringsöverraskningar. Den forskning som redan finns tillgänglig för dig ger en utgångspunkt: webbhotell som Bluehost och Hostinger positioneras ofta för budgetmedvetna användare; SiteGround har rykte om sig att ha stark support; A2 och HostGator förknippas med hastighetsfokuserade alternativ. Men lita inte på dessa beskrivningar förrän du har öppnat ett supportärende och mätt svarstiden med ett tidtagarur.
Vår detaljhandelskund hamnar i prestandaprofilen. De behöver snabba databasfrågor och förmågan att hantera en trafiktopp under en hektisk helg. Beslutet fattas på minuter, inte dagar, eftersom du inte "forskar om webbhotell" – du konsulterar din egen matris.
Om du inte har gjort det än, stanna här och bygg din matris. Du kommer att tacka dig själv vid nästa projektstart. Och om du fortfarande är frestad att skräddarsy per kund, läs varför din webbplats kraschade och se hur en enda krasch kan spåra ur ett kvartal. Lås sedan in dina profiler. Motstå frestelsen att lägga till en fjärde "premium"-profil för en exklusiv kund. Varje profil du lägger till tar tillbaka den per-projekt-överläggning du försöker eliminera. Tre är taket; för många byråer räcker två.
Steg 3: Migrera med en checklista, inte en bön
Nu flyttar du kunden. Gör det på samma sätt varje gång. Här är ordningen: säkerhetskopiera allt från det gamla webbhotellet, inklusive databasen; sätt upp den nya servern och installera samma mjukvarustack; importera filer och databas; installera SSL och testa varje sida; byt namnservrar; verifiera e-postleverans och tredjepartsintegrationer; håll det gamla webbhotellet vid liv under en faktureringscykel.
Skriv den här listan en gång och gör den till en delad checklista i ditt projektverktyg. Från och med nu är personen som genomför migreringen inte en senior ingenjör som improviserar; det är vem som helst som kan följa en checklista. I vår detaljhandelskunds fall tar flytten en bråkdel av tiden jämfört med om du beslutade varje steg under resans gång. Den bråkdelen spelar roll när du jonglerar flera kunder.
Två varningar från verkliga migreringar. För det första: om det gamla webbhotellet hanterade e-post, glöm inte MX-posterna. Det är så migreringar blir inaktuella och varför kunden tror att du har förstört deras e-post. För det andra: gör aldrig DNS-ändringen klockan 17 på en fredag. Gör den tisdag morgon när du har de två följande arbetsdagarna på dig att fixa vad som än går sönder. Mekaniken för en flytt utan driftstopp finns i den här migreringsguiden. Läs den innan din första migrering, radera den sedan ur minnet – checklistan är allt du behöver nu.
Och kör en repetition innan den riktiga bytet. Sätt upp en staging-subdomän, kopiera sajten dit och testa varje sida. Det kostar en timme och fångar felet som annars skulle ha tagit din kund offline en hel eftermiddag. Den timmen är den billigaste försäkringen du köper hela kvartalet.
Steg 4: Sälj tillförlitlighet, inte upptidsiffror
Varje webbhotell på din lista kommer så småningom att misslyckas. De som annonserar "100 % upptid" säljer marknadsföring, inte ingenjörskonst. Så när du utvärderar ett webbhotell, fråga inte om garantier. Fråga om incidentkommunikation. Om en server dör, får du ett statusmejl inom fem minuter? Finns det en statussida? Publicerar de post-mortems? Om webbhotellet inte kan svara på det i en mening är de inte redo för en kund vars intäkter beror på en webbplats.
Din kund behöver ingen 100 % upptidsgaranti. De behöver en plan för när webbplatsen ligger nere. Bygg den tillsammans med dem: en underhållssida, en telefonkedja, en lista över vem som ringer vem. Testa sedan planen med en övning. Det är den minst glamorösa timmen du kommer att tillbringa, och den kommer att rädda dig från årets mest stressiga timme. Detaljhandelskunden kommer aldrig att få veta om övningen det här kvartalet, men de kommer att få veta om den gången sajten låg uppe under en rea för att din plan fungerade.
Det här är också platsen att vara ärlig mot kunden om vad som kan gå sönder. "Vi har dagliga säkerhetskopior. En omstartstjänst brukar få sajten tillbaka på några minuter. Men om servern misslyckas helt kan en återställning ta några timmar. Här är numret att ringa." Den ärligheten är värd mer än en falsk garanti. Den hindrar dig också från att vara den som blir uppringd klockan 3 på natten för att du lovade det omöjliga. Ta med runbook-mallen till det här samtalet och säg: "Så här gör vi om sajten går ner. Du får en statusuppdatering direkt." Gör sedan det.
Steg 5: Skriv runbooken på en sida
Det som gör webbhotell återanvändbart mellan kunder är inte själva webbhotellet; det är dokumentationen. Vid överlämningen ger du din kund en runbook på en sida med: webbhotellinloggning, domänregistrator, DNS-leverantör, säkerhetskopieringsschema, supporttelefonnummer och en sektion "vad du gör om sajten går ner". Begrav inte detta i en 30-bilders presentation. En sida. Varje kund får samma mall. De enda fält som ändras är inloggningsuppgifterna och profilen.
För detaljhandelskunden är runbooken skillnaden mellan ett supportärende och ett lugnt telefonsamtal. När de ringer dig i november och frågar om ett konstigt mejl från sitt gamla webbhotell kan du säga: "Ignorera det, vi flyttade allt. Inloggningarna finns i din runbook." Det är då du tar examen från "webbbyrå" till "webbhotellpartner som tänker i förväg."
Att få plats med allt på en sida tvingar dig att besluta vad som faktiskt är kritiskt. Om du inte får plats med det förstår du inte din egen uppsättning. Ha mallen i en delad enhet och uppdatera den när din infrastruktur ändras. Tillämpa minsta behörighet, rotera inloggningsuppgifter och skicka aldrig lösenord via e-post. Din interna version av runbooken ska vara en kopia av kundens sida plus en sektion för ditt team: server-IP:er, lagringsplats för säkerhetskopior och inloggningsuppgifter till övervakningsverktyget. Den interna versionen är den du använder i den kvartalsvisa granskningen.
Steg 6: Granska kvartalsvis, inte per projekt
Sätt en återkommande kalenderhändelse första måndagen varje kvartal. Den dagen tar du fram tre rapporter: supportärendena från förra kvartalet, upptidsdata från ditt övervakningsverktyg och dina webbhotellsfakturor. Leta efter mönster. Om ett webbhotell står för de flesta av dina supportärenden är det borta. Om ett annat webbhotells support aldrig svarar i telefon är det borta. Om en ny leverantör har dykt upp med ett dramatiskt bättre pris för samma tjänsteklass, testa den – med en icke-kritisk kund – och lägg till den i matrisen om den förtjänar sin plats.
Den här granskningen är skillnaden mellan att reagera på misslyckanden och att förebygga dem. Du kommer fortfarande att ha misslyckanden, men de kommer att vara webbhotellets fel, inte din process fel. När en ny webbhotellkandidat dyker upp på din radar, kör den genom ett riktigt stresstest innan du förbinder dig. Ett billigt webbhotell kan se bra ut på papper och vika sig under belastning; testet kommer att berätta sanningen.
Den kvartalsvisa granskningen är också när du rensar. Om en profil inte har använts på två kvartal, antingen ta bort den eller ta reda på varför. Målet är en levande matris som återspeglar vad du faktiskt har lärt dig, inte ett statiskt dokument du skrev en gång och ignorerade. Hoppa inte över granskningen för att du är upptagen. Tiden du lägger där sparar dig en fakturerbar vecka senare.
Slutsats
Webbhotell är inte platsen för kreativitet. Det är platsen för mönster. Bygg intagformuläret, lås in dina tre profiler, kör migreringschecklistan, sälj tillförlitlighet, skriv runbooken på en sida och granska kvartalsvis. Detaljhandelskunden får en stabil sajt, du får ett lugnare kvartal och du slutar äntligen googla "bästa webbhotell för" varje gång ett nytt projekt dyker upp. Det är vinsten. Gå och standardisera.