Blog
Az ügynökséged tárhelystratégiája: 4 szakasz a káosztól az irányításig
Ne ügyfelenként válassz tárhelyet. Építs ismételhető, négylépcsős rendszert az ügynökségednek.
Összefoglaló
Ha ügynökségnél dolgozol, valószínűleg minden ügyfélhez más tárhelykezelő felületet használsz. Ez egészen addig működik, amíg nem. A tárhelyhez való hozzáállásodnak változnia kell, ahogy növekedsz. Ez a cikk végigvezet a négy érettségi szakaszon: az egyszeri korszakon, a konszolidációs fázison, a portfólióstacken és a termékesített szolgáltatáson. Megtanulod, mikor érdemes szabványosítani, mikor diverzifikálni, és mikor eladni a tárhelyet termékként. A végére ismételhető folyamata lesz, ahelyett, hogy mindennap tüzet oltanál.
Hány tárhelykezelő felületre fogsz bejelentkezni ezen a héten? Őszintén. Ha egy ügynökségnél dolgozol, és több mint egy maroknyi ügyfeled van, a válasz valószínűleg az, hogy minden ügyfélhez más-más bejelentkezési adat kell. Ez probléma. Időt vesztegetsz a hitelesítő adatok keresésére, találgatod, melyik csomag melyik webhelyre vonatkozik, és olyan dolgokért fizetsz, amelyekről megfeledkeztél. Ez a cikk végigvezet az ügynökségi tárhely érettségének négy szakaszán. Minden szakasznak van egy hibamódja, és az egyik szakaszban a megoldás a másikban csapda. Olvasd el a táblázatot, találd meg a saját szakaszodat, és cselekedj.
Itt van az ív:
| Szakasz | Mi működik | Mi törik el |
|---|---|---|
| Egyszeri korszak | Minden ügyfél egyedi tárhelyválasztást kap | A kognitív terhelés minden ügyféllel nő |
| Konszolidációs fázis | Egy szolgáltató mindenki számára | A szolgáltató nem illik minden munkaterhelésre |
| Portfólióstack | Tárhelyszintek az ügyfél értéke alapján | Több szállítóval zsonglőrködsz, mint korábban |
| Termékesített szolgáltatás | A tárhely havidíjas termék | Mostantól te felelsz a rendelkezésre állásért |
Első szakasz: Minden webhely hópehely (és ez körülbelül egy hónapig rendben is van)
Képzeld el, hogy most szerezted az első néhány ügyfeledet. Az A ügyfél egy helyi pékséget vezet, és WordPress-webhelyre van szüksége. A B ügyfél egyedi fejlesztésű alkalmazással rendelkezik, és Node-szervert kell telepítenie. A C ügyfél csak egy landolóoldalt szeretne egy héten belül. Feliratkozol a Bluehostra a pékséghez, a Hostingerre az alkalmazáshoz, mert olcsó, és az A2 Hostingra a landolóoldalhoz, mert valaki azt mondta, hogy gyors. Most több bejelentkezésed, megújítási dátumod, támogatási sorod van, és fogalmad sincs, melyik ügyfél nyereséges valójában.
Ez az egyszeri korszak. Természetesnek tűnik, mert a mennyiség alacsony. De minden új ügyfél újabb bejelentkezést, újabb számlát, újabb döntést hoz arról, hogy melyik tárhely a „legjobb” ehhez a konkrét projekthez. Elkezded hinni, hogy tájékozott döntéseket hozol. Pedig nem. Csak változókat adsz egy olyan rendszerhez, amit nem látsz.
A megoldás még nem a szabványosítás. A megoldás egy nyomonkövetési rendszer kialakítása. Nyiss egy táblázatot. Minden ügyfélhez rögzítsd: a szolgáltatót, a csomagot, a megújítás dátumát, a havi költséget, a fiók tulajdonosát és egy durva forgalombecslést. Igen, egy táblázatot. Unalmas, de csak így látod meg a mintát, hogy valójában mire költesz, és hova megy az időd. Azt is rögzítsd, miért választottad azt a szolgáltatót. A „barát ajánlotta” érvényes indok, de tudnod kell, hogy ez az. Ha már van néhány sorod, a táblázat többet fog mondani, mint a megérzésed.
Mi történik, ha ezt kihagyod? Keményen megtanulod: egy ügyfél domainje lejár, mert nem követted a megújítást, egy csomag automatikusan frissül, és megduplázza a számlát, vagy egy ügyfél megkérdezi, miért lassú a webhelye, és nincs nyilvántartásod arról, hogy mit is fizet. A táblázat a memóriád. Nélküle nem ügynökséget vezetsz, hanem tüzet oltasz. Ha még mindig nem tudod, merre indulj, kezdd egy mainstream megosztott tárhellyel, mint a Bluehost vagy a HostGator. Nem izgalmasak, de működnek, és megtanítják, mire van igazán szükséged. Ha nem szeretnél találgatni, itt egy útmutató a webes tárhely kiválasztásáról, amikor nem engedheted meg magadnak a rossz döntést.
Második szakasz: A konszolidációs csapda
Mostanra növekvő ügyféllistád van, és minden webhelyhez tartozik egy saját felület. Minden új ügyfél újabb felületet és újabb megújítási e-mailt hoz. Eleged van belőle. Ezért úgy döntesz, hogy mindenkit átköltöztetsz a SiteGroundra. Egy bejelentkezés. Egy támogatási vonal. Egy számla. Úgy érzed, végre rendbe jön az életed. Aztán a pékség elindít egy nagy ünnepi akciót, és a WooCommerce-áruháza lelassul. Egy másik ügyfél posztja vírussá válik, és a megosztott csomag egyszerűen nem reagál. Most két külön kiesést magyarázol, miközben azt mondod magadnak, hogy jól döntöttél a szabványosítással.
Itt van az az elv, amit a legtöbb ügynökségi cikk kihagy: a konszolidáció megoldja a felület-problémát, de létrehoz egy illeszkedési problémát. Nincs egyetlen tárhelyszolgáltató, amely minden munkaterhelésre megfelel. A SiteGround valóban jó támogatással és infrastruktúrával rendelkezik, de nem univerzális megoldás. A Bluehost és a HostGator megfelelő a tartalmi webhelyekhez. A Hostinger a költségkímélő opció. Az A2 Hosting a sebességre hajt. A feladatod nem az, hogy megtaláld az egyetlen igazi tárhelyet. Hanem az, hogy kialakíts egy két-három szolgáltatóból álló rövidlistát, amelyek lefedik az ügyfeleid igényeinek nagy részét.
Ebben a szegmensben az a gyakori tanács, hogy válassz egy tárhelyet, és tedd azt a standarddá. Ez a tanács a néhány webhelyet kezelő szabadúszóknak szól. Egy ügynökség számára ez csapda. Egyetlen tárhely egyetlen hibamódot jelent. Ha a hálózatuk leáll, minden ügyfél leáll vele. Ha a támogatásuk romlik, nincs alternatívád. A diverzifikáció a redundancia operatív változata.
Szóval állíts fel egy irányelvet. Megosztott tárhely a brosúra webhelyeknek. Minden, ami aktív e-kereskedelmet vagy kiszámíthatatlan forgalmat futtat, egy szinttel feljebb kerül. Írd le ezt az irányelvet. Mutasd meg az ügyfeleknek a bevezetéskor. És ne hagyd, hogy elcsábítson egyetlen szolgáltató marketingje. Az ügynökség számára a legjobb tárhely az, amelyet hajnali 3-kor, korlátozott információkkal is képes vagy hibakeresni. Nem az, amelyiknek a legszebb felülete vagy a leghangosabb üzemidő-garanciája van. Az üzemidő-garanciák rendben vannak, de ezek ígéretek, nem mérnöki munka. A webhely helyreállításának képessége fontosabb, mint egy százalék a szerződésben. Mielőtt elköteleznéd magad, olvasd el miért omlott össze a webhelyed, és hogyan válassz olyan tárhelyet, amely nem hagy cserben.
Harmadik szakasz: Oszd szintekre a dolgokat, aztán a szinteket is
Egy ügyfél megkér, hogy vedd át a meglévő webhelyét. Olyan szolgáltatónál van tárolva, akit még soha nem használtál. Az előző ügynökség nem hagyott dokumentációt. Az első ösztönöd az, hogy átköltöztesd a standard stack-edre, hogy könnyebb legyen az életed. Ne tedd. A migráció pont az a pillanat, amikor dolgok elromlanak. Ehelyett egy olyan döntési keretrendszerre van szükséged, amely azelőtt működik, mielőtt bármihez hozzányúlnál.
Sorold be minden ügyfelet a bevezetéskor. Tegyél fel három kérdést. Mit csinál a webhely? Mennyi bevétel függ tőle? Mennyire kiszámíthatatlan a forgalom? A válaszok segítségével rendelj hozzá egy szolgáltatási szintet. 1. szint: alacsony forgalmú brosúra-webhelyek megosztott tárhelyen, szabványos biztonsági mentések, e-mailes támogatás. 2. szint: WordPress- vagy WooCommerce-webhelyek jelentős forgalommal – tedd őket VPS-re vagy sebességközpontú szolgáltatóhoz, mint az A2 Hosting. 3. szint: kritikus fontosságú webhelyek, amelyek dedikált erőforrásokat, valódi SLA-t és a leggyorsabb válaszidőt igénylik.
A szintek nem az ügyfelek felfelé értékesítését szolgálják. Hanem azt, hogy a saját támogatási terhelésed kiszámítható legyen. Egy szint meghatározza, mit várhat az ügyfél tőled, és mit kell teljesítenie az infrastruktúrának. Amikor kommunikálod a szinteket, ne beszélj hardverről. Beszélj eredményekről. „Az 1. szint napi szabványos biztonsági mentést és 24 órán belüli e-mailes támogatást jelent.” „A 3. szint dedikált szervert, egy hívható telefonszámot és percekben mért válaszidőt jelent.” Az ügyfelek az eredményeket értik, nem a VPS-specifikációkat.
A szinteket negyedévente vizsgáld felül. Egy pékség, amely brosúra-webhelyként indult, egy év múlva 2. szintű e-kereskedelmi üzletté válhat, és a biztonsági mentési és válaszadási tervednek is követnie kell ezt. A felülvizsgálat kihagyása miatt lesz a tegnapi webhelyből a mai kiesés. És amikor valami elromlik, az első kérdésed mindig az: melyik szint ez? Mert a hibakeresési út egy megosztott tárhelynél nem ugyanaz, mint egy VPS-nél. A szint meghatározza a válaszidődet, az eszkalációs utadat és az ügyfél elvárásait. Szintek nélkül visszatérsz oda, hogy minden tüzet vészhelyzetként kezelsz.
Negyedik szakasz: Add a tárhelyet termékként, ne szívességként
Mostanra több tucat ügyfél tárhelyét kezeled. Van egy csapatod. Még mindig te vagy az, akit hívnak, ha egy webhely leáll. Nem vagy tárhelyszolgáltató cég, de úgy viselkedsz, mint egy. Az üzleti modellnek utol kell érnie a valóságot.
Nézz le a tárhelyről mint költségről, amit lenyelsz, hogy számlázhasd az ügyfélnek a dizájnt. Kezdd el tárhelyet termékesített szolgáltatásként árulni. Egy havi díj (retainer), amely fedezi az infrastruktúrát, a karbantartást, a szerveroldali biztonságot, a biztonsági mentéseket és a válaszidő-garanciádat. Az ügyfél egy fix összeget fizet. Te kiszámítható bevételt kapsz. Az ügyfél nem nyit több támogatási jegyet a megújításokkal kapcsolatban, és neked sem kell magyaráznod a számla tételsorait.
Mi kerüljön a havidíjba? Mondd ki világosan. A szolgáltató és a csomag, a biztonsági mentési ütemterv és a megőrzési idő, a monitorozás és a riasztás, a felelős személy, valamint az egyes szintekre vonatkozó válaszidő-vállalás. Írd le, mi történik, ha a tárhelyszolgáltatónál kiesés van: a kommunikációs protokollod, a tartalék terved, az első lépés a helyreállításhoz. Ez az a szerződés, amely megvéd téged, amikor egy ügyfél webhelye vasárnap hajnali 2-kor leáll.
De vannak feltételek. Ha tárhelyet adsz el, te viseled a következményeket. A SiteGround ígérhet 100%-os rendelkezésre állást egész nap, de egy ügyfél webhelye akkor is le fog állni valamikor, és a telefonod csörögni fog. A te SLA-d számít. A biztonsági mentési és helyreállítási folyamatod számít. Az a képességed számít, hogy ügyfelet leállás nélkül költöztetsz új tárhelyre. Mielőtt termékesítesz, futtass le egy helyreállítási gyakorlatot. Teszteld a migrációidat. Aztán tedd írásba ezeket a kötelezettségvállalásokat.
A tárhely termékesítése nem az árak emeléséről szól. Hanem arról, hogy felelősséget vállalsz az irányításért cserébe. Ha nem vagy hajlandó vállalni a következményeket, ne kérj érte pénzt. Csak légy őszinte az ügyféllel, hogy a tárhely egy továbbhárított költség, amit neki kell kezelnie. Ez egy érvényes választás. De ez nem egy skálázható ügynökségi gyakorlat. És ha készen állsz arra, hogy egy ügyfelet jobb tárhelyre költöztess, tudd, hogyan költöztess webhelyet új tárhelyre leállás nélkül.
Összegzés
Hagyd abba a találgatást. Az ügynökséged tárhelygyakorlata végigmegy ezeken a szakaszokon, akár tervezed, akár nem. Az egyszeri korszak addig rendben van, amíg nem. A konszolidáció addig működik, amíg nem. A szintek rendet teremtenek, amíg el nem felejted felülvizsgálni őket. A termékesítés üzletté tesz, amíg be nem következik az első kiesés. A megoldás az, hogy tudd, melyik szakaszban vagy, és tudatosan cselekedj.
Kezdd a táblázattal. Építs rövidlistát. Szintezd az ügyfeleidet. Aztán add a tárhelyet termékként. Ha ezt teszed, a tárhely egy olyan rendszer lesz, amit te irányítasz, nem pedig egy tűz, amit oltasz. A jövőbeli éned – és az ügyfeleid – hálásak lesznek.