U ovom članku pišem svoje mišljenje i iskustvo sa tehničkim podrškama hosting provajdera – generalno. Šta se može očekivati od tehničke podrške, kakvi problemi se mogu pojaviti i slično. Post na WebHostingTalk forumu me je naveo da konačno sve ovo stavim na “papir”. Sve ovde napisano je iz perspektive klijenta (tj. mene). Svaka povratna informacija kako to tačno izgleda iz perspektive tehničke podrške je više nego dobrodošla u sekciji za komentare u dnu ove strane.
Sadržaj:
- Uvod – o tehničkoj podršci generalno
1.1. Posao tehničke podrške - Postavljanje pitanja / prijava problema
2.1. Nemojte… ako baš ne morate
2.2. Obraćanje tehničkoj podršci
2.3. Dodatni saveti za komuniciranje sa tehničkom podrškom - Opseg tehničke podrške – iz ugla klijenta
3.1. Problemi sa računarom klijenta
3.2. Postavljanje “glupih pitanja”
3.3. Problem sa serverom – na strani provajdera
3.4. Softver trećih lica – “Kvaka 22” - Zaključak
1. Uvod – o tehničkoj podršci generalno
Lično nisam radio ni za jednog hosting provajdera, ali imam oko 20 godina iskustva rada u IT-u, između ostalog puno i u pružanju i organizaciji tehničke podrške. Dok usluge hostinga koristim dosta aktivno već oko pet godina. Tako da imam dosta dobru sliku kako to izgleda “sa obe strane”.
Da bi se mogao (o)ceniti kvalitet tehničke podrške, mislim da je važno shvatiti kakav je to posao – kako to izgleda sa druge strane. Oni koji misle da to ne treba da ih zanima – da teh. podrška treba da namesti sve i brzo – mogu slobodno preskočiti ceo ovaj članak i želim im svu sreću u pronalaženju usluge hostinga i podrške koja im odgovara (nisam sarkastičan – razumem i poštujem takav stav – uz dovoljno visoku cenu i to se može pronaći).
1.1. Posao tehničke podrške
Posao tehničke podrške u suštini se svodi na vraćanje stvari kako su bile – kada je sve radilo. Koristiš svo svoje znanje, iskustvo i energiju za popravku stvari. Praktično nikad ne kreirajući/dizajnirajući nešto novo.
Većina komunikacije koja se obavlja je sa ljudima koji su frustrirani jer im nešto ne radi. Na loš dan, nakon bukvalno oko 100 telefonskih poziva, čak i ako vas nazove Beyonce i pita za sastanak, odgovorićete: “Gospođo, molim Vas da pokušate rešiti stvari sa Jay Z-jem, to je izvan našeg opsega podrške. Hvala što Ste zvali i javite se ako Vam mogu pomoći u vezi još nečega. Prijatan dan želim.” Spuštanje slušalice, dok druga linija počinje da zvoni u isto vreme… Da, više volim tikete, i kao korisnik (pisao sam o telefonskoj naspram podrške tiketima). Naravno, ima i lepih dana, kada problema nema previše, a prijavljeni se rešavaju i svi su sretni. 🙂
Velika većina problema/pitanja koji se postavljaju su već oko 10.000 puta odgovoreni. Nalaze se u bazi znanja/uputstvima, a lako se mogu i “izguglati”.
Ako za 5 problema treba po 5 minuta da se reše, a za šesti je potrebno pola sata, rešavanje “manjih” problema prvo čini ukupno prosečno vreme čekanja klijenata kraćim, nego ako se prvo rešava problem koji traži pola sata (22 minuta, naspram 43 minuta).
“Trivijalni” problemi znaju da postanu komplikovani i da se ne reše brzo. Klijenti uglavnom, najčešće, ne mogu proceniti koliko je koji problem “velik” – uglavnom je to nama “samo pet minuta”, po njihovom mišljenju.
Velikoj većini klijenata je njihov problem hitan. Dok je retko ko objektivan, a i ne može znati kakva je priroda ostalih problema koji su “na čekanju”. Tako da kada klijent kaže da je nešto hitno, to znači “ovaj klijent bi voleo da to bude rešeno odmah”, ništa manje, ali ni više od toga.
Suština posla hostinga i tehničke podrške, kao i svakog drugog uslužnog, je u tome da klijenti budu sretni. Ne u tome da sve radi savršeno. Ovo je nešto što mnogi ne shvataju. Naravno, bolje je kad sve radi – ako ima puno problema, ljudi neće biti zadovoljni.
Iz mog iskustva, rešavanje problema za sekund i javljanje “rešeno”, često bude lošije primljeno nego da se vidno uloži napor, objasni kakvi sve problemi postoje, strpljivo sasluša klijent, bez da se na kraju reši problem!? Ne uvek, ali često. Da, čudno je, ljudi su takvi.
Čuo sam ljude da se žale na ovo kod nekih hosting provajdera:
“Samo su mi zatvorili tiket!”
” – Jesu li rešili problem?”
“Pa, jesu, ali…”
2. Postavljanje pitanja / prijava problema
Verujem da ovaj podnaslov zvuči malo glupavo. Kad navedem prve korake, sigurno će mnogima zvučati još gluplje. Ali ima smisla. Kako postaviti pitanje, ili prijaviti problem?
2.1. Nemojte… ako baš ne morate
Proverite prvo je li sve u redu “sa vaše strane”. Počev od napajanja računara, rutera/modema (kako utvrditi potencijalne uzroka problema sa konekcijom na sajt).
Pišite sve izmene koje radite na sajtu. Možda je nešto od njih napravilo problem, pa vraćanje na staro stanje može pomoći. Pravite i čuvajte bekape, uvek.
Proverite provajderov F.A.Q, bazu znanja i Google: možda odgovor već postoji – najčešće je tako. Ovakav pristup omogućava da steknete dragoceno znanje i iskustvo. Zapisujte rešenja koja rade. Ne morate na sajtu (kao ja), ali ih čuvajte negde – to štedi dosta vremena na duži rok.
Takođe pogledajte i provajderovu stranicu za objave (problema sa mrežom i sl.) – kako ne biste bili 1.000-ta osoba koja im prijavljuje problem za koji već znaju.
Konačno, ako sve padne u vodu, zapišite tačno šta ste sve radili / testirali da utvrdite postojanje problema, kao i šta ste sve probali kako biste ga rešili. Lepo, hronološki. Ovo često pomogne da se desi “Eureka!” momenat i da ipak sami rešite problem. Ako ne pomogne, svakako će te informacije biti dragocene tehničkoj podršci (primer povratnih informacija korisnika u pomoći teh. podršci pri rešavanju problema).
2.2. Obraćanje tehničkoj podršci
Ako problem ne možete rešiti sami, naravno, treba se obratiti za (stručnu) pomoć. Pretpostaviću da želite da problem bude rešen (što pre), pa ću u tom smislu navesti neke dobre i loše primere:
“Ništa ne radi!”
Ovo je potpuno beskorisna informacija. Česte varijacije na temu su: “Nešto nije kako treba (sa mojim sajtom)”, “Imam problem” i slično.
Navođenje uzroka problema, bez objašnjavanja simptoma.
Na šta mislim pod ovim? Na primer: prijava “Blokirana mi je IP adresa”, kada ne možete da se ulogujete na kontrol panel svog sajta, ili/i otvorite svoj sajt. Može biti puno razloga/uzroka ovoga.
Korisnija informacija bila bi: “ne mogu da otvorim svoj sajt, niti da se ulogujem u bek – end. Dobijam ‘tu i tu’ poruku u browseru kada pokušam. Ostale sajtove otvaram normalno. Kada pokušam posetiti svoj sajt sa mreže provajdera mobilne telefonije, sa pametnog telefona, sve radi normalno. Sumnjam na to da mi je blokirana (kućna) IP adresa.”
Drugi pristup objašnjava uočene uzroke, kako se problem manifestuje, u kojim situacijama. Uz vašu pretpostavku uzroka na kraju. Tehnička podrška će se uvek pre osloniti na informacije o problemu, nego na dijagnozu nekoga u čiju stručnost nisu 100% sigurni.
Primer detaljno pruženih informacija tehničkoj pordršci.
2.3. Dodatni saveti za komuniciranje sa tehničkom podrškom
Budite jasni i precizni.
Više kratkih rečenica je dobro. Jedna preduga rečenica je često kontra-produktivna. Kao ovaj pasus. Mogao je biti napisan u jednoj dužoj rečenici, ali nije.
Zapamtite da ste samo jedan od hiljadu.
Imajte na umu da osoba koja pokušava da vam pomogne (a obično to rade, kako god izgledalo) možda ima još nekoliko telefonskih poziva, ili još puno drugih tiketa, sa različitim problemima. Uz to, može doći i do promene smene, pa da druga osoba u sličnoj “situaciji” preuzme vaš problem. Ovo je donekle povezano sa prvim i narednim paragrafom u ovom poglavlju.
Nema glupih pitanja.
Neka pitanja možda deluju glupo, ili suvišno, ili mislite da ste na njih već odgovorili, ali odgovaranje na njih je važno za tehničku podršku. Iz mog iskustva: “Da li imate struje?” nije uvek glupo pitanje – desilo mi se da problem sa računarom bude prijavljen dok je ceo kvart ostao bez struje.
Postoje i “pokrivanja” sa pravne strane – neka pitanja/odgovori se tačno formulišu kako je advokat savetovao i beleže/čuvaju. Čak i kada su besmislena za sve učesnike – nužno zlo.
Efekat “gluvih telefona”.
Postavite pitanje/zahtev/opis problema tako da se lako može preneti drugim kolegama. Niko ne zna sve, ali obično ima nekog ko može rešiti vaš problem.
Kao deca igrali smo se “gluvih telefona”. Stane se u red. Prvi šapne rečenicu onom do sebe. Onda se to prenosi dalje. Nije bilo dozvoljeno “ponovi, nisam razumeo”. Konačan rezultat je često bio veoma smešan. Ali, ako je rečenica dovoljno jednostavna i jasna, bez “komplikovanih” reči, znala je stići do samog kraja neizmenjena.
Jedini praktičan primer ovoga koji mi pada na pamet je komunikacija sa pretprodajnom podrškom hosting provajdera u vezi načina virutualizacije, postavljanja i sprovođenja limita za resurse i slično. Bio sam shvatio da osoba sa kojom komuniciram ne zna odgovore, ali je voljna da pita druge kolege za pomoć. Tako, nakon nekih 5 mejlova bezuspešnih pokušaja, preformulisao sam sva pitanja tako da mi odgovor DA/NE bude dovoljan. To je pomoglo.
Važno je biti fin.
Budite strpljivi i ljubazni. Doživljavao sam da mi tehnička podrška pomogne oko stvari koje su mimo njihovog opisa posla, samo tako što sam bio strpljiv i pokazao koliko mi znači pomoć, uz objašnjavanje šta sam sve probao i zašto ne mogu sam.
Računari i softver se kvare. I poprave se. Nema potrebe biti grub, ili neprijatan, to svakako retko pomogne.
Zapisujte sve.
Kako biste znali šta ste sve radili i kojim redosledom. Pružite te informacije tehničkoj podršci u vidu P.S.-a, ili attachmenta. Možda se neće baviti time, ali ako sve napišete jasno, taksativno, oni koji su dobri u poslu će se možda poslužiti i time da brže reše vaš problem (ako su se “zaglavili”).
Jezičke barijere.
Imajte razumevanja za jezičke barijere. Neki od vrhunskih stručnjaka sa kojima sam sarađivao veoma loše pričaju engleski. Vrhunski u smislu “svetska klasa, ne znam koga drugog bih pitao”, ne u smislu “ne mogu platiti dobru uslugu, ovo je najbolje za te novce”. Mada se ovo promenilo u poslednjoj deceniji donekle – veći procenat IT radnika dosta dobro barata engleskim. O ovome sam, na engleskom, pisao u članku: Prejudice with “overseas” technical support.
Ružni i zli.
Pored svega napisanog: neke kompanije jednostavno ne zapošljavaju dobru tehničku podršku, ili ih preopterete – tako da dobijete lošu uslugu. Ako/kada je ovo slučaj – tražite alternativu. Osim ako ste vezani dugoročnim ugovorm za hosting kompaniju (ili čak i tada, gubljenje nešto novca se ponekad više isplati).
3. Opseg tehničke podrške – iz ugla klijenta
Drugim rečima: za šta sve je razumno za očekivati da tehnička podrška priskoči u pomoć?
…osim što noću oblače helanke i bore se protiv kriminala…
Stvari oko kojih tehnička podrška može i hoće da pomogne se razlikuju od provajdera do provajdera. Zavise i od vrste hostinga. Recimo: “pravi” Managed WordPress hosting provajder će pružiti podršku i u vezi podešavanja plaginova, sajta i slično. Dok je uz “običan” shared hosting, pogotovo ako je cena niska, nerealno očekivati bilo šta mimo samog ispravnog funkcionisanja hosting servera.
Ako vam je potrebno puno pomoći i širi spektar tehničke podrške (u žargonu: “držanje za ručicu”), to je najbolje proveriti u TOS-u (eng. Terms Of Service) provajdera, ili/i pitati pre “kupovanja” hosting usluge.
U ljudskoj je prirodi da žele i vole da pomognu, tako da podrška često hoće da pomogne i mimo “opisa posla”, pogotovo ako ste strpljivi, lepo zamolite i ne zloupotrebljavate dobru volju.
Sada ću navesti neke tipične scenarije sa tehničkom podrškom i svoje iskustvo u takvim situacijama, iz uloge klijenta hosting provajdera:
3.1. Problemi sa računarom klijenta
Ako se ispostavi da je uzrok problema računar korisnika, provajder nema nikakvog razloga da se time bavi. Ako teh. podrška ipak odluči da se “iscima” oko ovoga, dobro je objasniti klijentu da je to preko onoga što plaća i može da očekuje – praktično usluga, dobra volja, ne obaveza hosting provajdera. Čak i tada, neki ljudi neće imati razumevanja, naravno.
3.2. Postavljanje “glupih pitanja”
Osećam se kao idiot kada postavim pitanje na koje je već odgovoreno u bazi znanja provajdera, ili se može lako “izguglati”. Trudim se da ovo bude redak izuzetak, ali dešavalo se.
Većina provajdera hoće da pomogne sa ovim, nekad uz slanje linka sa objašnjenjem iz njihove baze znanja (pretpostavljam uz odolevanje porivu da napišu: “Gospodine, želite li možda i da daljinski to sve uradimo na vašem računaru?” 🙂 ).
3.3. Problem sa serverom – na strani provajdera
Ovo je čist slučaj posla za tehničku podršku hosting provajdera. Ja se trudim jasno napisati šta sam radio, kojim redosledom, šta i kako sam pokušavao / testirao i sl. – stavljajući svoju pretpostavku o uzroku problema na kraju tiketa, za slučaj (manje verovatan) da i to pomogne tehničkoj podršci.
Mnogi provajderi će teško priznati da je problem sa njihove strane (možda iz nekih pravnih razloga, ne znam), čak i kada jeste i reše ga. Češće ćete dobiti odgovor: “sad radi”, nego: “rešili smo taj problem sa serverom”. Ali meni ovo nije bitno – dok god je problem rešen i ne ponavlja se.
Neki provajderi objasne i tačno u čemu je bio problem, kao i kako je otklonjen – što su meni dragocene informacije jer mi pomažu da shvatim kako sve radi, a nekad i kako da izbegnem probleme u budućnosti.
Imao sam i nekoliko situacija sa kratkim, ali relativno čestim prekidima u radu: kada me je tehnička podrška molila da probam različite stvari sa svakim novim tiketom, bez da su uspevali otkloniti problem trajno u početku. Onda, nekad i nakon mesec dana, budem premešten na novi server i od tada sve super radi – uz objašnjenje da je “stari” server bio “problematičan”.
Ovakvi kvarovi koji se dešavaju samo na kratko, pa nestanu “sami od sebe”, su teški za rešavanje iz mog iskustva. Dok bilo ko, uključujući mene, stigne da pogleda – problem je nestao, opet sve radi. Nisam siguran koliko informacija iz logova je raspoloživo sa strane provajdera, ali pošto mi se ovo desilo sa dva različita provajdera, u različito vreme, a nakon promene servera je sve radilo odlično i pošto su brzo rešavali sve druge (“normalne”) probleme, pretpostavljam da su ovakvi “povremeni” teški za rešavanje zbog teškog pronalaženja uzroka.
3.4. Softver trećih lica – “Kvaka 22”
Ovo je moje iskustvo sa nečim što bih nazvao “Kvaka 22“, ili “Vrzino kolo”, kako ko voli: 🙂
Digresija
Radnja knjige “Kvaka 22” odvija se za vreme 2. Svetskog Rata, prateći priču pilota bombardera koje šalju na praktično samoubilačke misije, a “kvaka” se svodi na sledeće:
Doktore, mora da sam lud kad prihvatam ovako samoubilačke misije. Mogu li se prijaviti da nisam normalan, da se pokušam izvući?
– Svakako, ali neće upaliti.
Ima neka kvaka?
– “Naravno da ima kvaka,” odgovorio je doktor Daneka. “Kvaka-22. Svako ko želi da se izvuče iz takvih samoubilačkih misija nije stvarno lud.”
BackWPup plagin nije radio kako treba na novom hosting provajderu, a kod starog je sve radilo. Isti sajt, isto sve podešeno, sve sam dvaput bio proverio.
Pitao sam tehničku podršku provajdera da li je ovaj plagin slučajno blokiran.
Podrška je probala svašta, ali nisu uspeli postići da plagin proradi. Na kraju su me uputili na kreatora plagina (što je razumljivo, prijatno sam se bio iznenadio što su uopšte i krenuli da se bakću s time, nakon odgovora da oni ne blokiraju taj plagin i njegove funkcije).
Tako sam se obratio kreatoru plagina, da vidim može li mi pomoći. Pružio sam sve tražene / potrebne informacije.
Nije pomoglo. Na kraju su me uputili na hosting provajdera (Kvaka 22 🙂 ).
Nakon nekog vremena, došao sam na ideju: cPanel nalog koji sam napravio za sajt bio je ograničen na 2 GB prostora (sajt je bio manji od 500 MB). Povećao sam prostor na 5 GB i pokušao ponovo. To je pomoglo. Koga zanima: više detalja o ovom problemu sa BackWPup plaginom.
Niko od nas koji smo se bavili time nije se setio ovo probati. Iako je sasvim logično: plagin koristi dodatni prostor za pakovanje i bekapovanje, pre nego što to uploaduje na zadatu lokaciju.
Realno gledano: ovo nije bio problem do hosting provajdera, a ni do kreatora plagina. Njihovi proizvodi su radili kako treba. Ali meni to nije ništa pomoglo – i dalje mi nije radilo. 🙂
Normalno, ne može se očekivati od tehničke podrške hosting provajdera da zna svaku caku za svaki softver, ili kombinaciju softvera.
Kreator plagina: pa, možda su se oni i mogli setiti ovoga, ali isto se ne može očekivati da znaju tačan setap hosting servera.
U svakom slučaju, nakon što sam problem rešio sam, dao sam te informacije kreatoru plagina i hosting provajderu – za slučaj da se još neko nađe u sličnom problemu.
Pošto je to bio moj problem, posvetio sam dovoljno vremena i truda rešavanju, ali nisam imao “rutinsko” rešenje odmah. Svako ko je u stanju da rešava ovakve probleme bi se mogao smatrati vrhunskom tehničkom podrškom (barem po mom mišljenju) – bilo na strani hosting provajdera, ili kreatora plagina.
Rešavanje ovakvih stvari nije nešto što se može očekivati, a opet sam siguran da ima puno ljudi sa sličnim problemima – koji su praktično prepušteni sami sebi (možda je Managed WordPress hosting rešenje za ovakve probleme, barem kada je WP u pitanju). Ne krivim nikoga za ovo – tako je kako je, ne mogu očekivati da ljudi provode sate sa svakim setapom/softverom, bez da su adekvatno plaćeni za to. Ali ovakve situacije su verovatno najteže za objasniti klijentima. Siguran sam da ne budu oduševljeni odgovorom: “što se nas tiče sve radi – vidite sa proizvođačem softvera koji koristite” – pogotovo ako i od proizvođača softvera dobiju sličan odgovor koji ih upućuje na hosting provajdera.
Ovakvi problemi se teško mogu rešiti. Radnike tehničke podrške koji znaju većinu ovakvih (i sličnih, možda češćih, “caka”) bi trebalo čuvati kao malo vode na dlanu, pošto su najbolji, dugoročni, marketing koji hosting provajder može dobiti: dobra usluga i tehnička podrška – koju zadovoljni klijenti preporučuju od usta do usta.
U tom smislu, iz mog iskustva: Veerotech tehnička podrška je veoma blizu ovog ideala. Kod MDDHosting-a, na sličan način, vlasnik lično nekad odgovara na tikete – što pokazuje da se trudi da sve bude kako treba. Treba spomenuti i Gnu Host – gde se vlasnik takođe bavi “zaguljenim problemima”.
Sve tri pomenute kompanije nude tehničku podršku iznad onoga što se može očekivati za dati novac – a opet, sa nekim problemima poput ovde pomenutog, nekad je klijent prepušten sam sebi (ako ne želi platiti nekome da provodi dane pokušavajući rešiti problem).
Ažuriranje: za još jedan primer Kvake 22, vidite ovo na stranici Problemi sa hosting serverima i sajtovima.
4. Zaključak
Čak i najbolja tehnička podrška nije svemoguća – nekad je potrebno angažovati stručnjaka (ili biti stručnjak) da bi se rešio nezgodan problem. Ipak, za većinu stvari: ako pružite dobre informacije, imate strpljenja i nemate nerealnih očekivanja, ovi ljudi mogu učiniti čuda – često daleko iznad onoga što im je u opisu posla.