ITblog

Są dwie metody podejścia do klienta: można przyznać się do błędu/awarii, wytłumaczyć i naprawić albo kłamać jak z nut, starając się po cichutku załatać dziurę. Jeśli z pierwszego podejścia firma może wyjść obronną ręką, a nierzadko zyskać sympatię klienta, tak to drugie po prostu drażni i zmusza do zastanawienia się nad alternatywą.
Od pewnego czasu, pewna firma hostingowa gra ze mną w kulki. Pewnego dnia postanowili zrobić nie ogłoszoną dla klientów aktualizację serwera ftp, skutecznie blokując jakikolwiek do niego dostęp na kilka dobrych godzin. Na panelu administracyjnym ukazała się lakoniczna informacja, że serwer będzie nieczynny … A ja dzień wcześniej udostępniłem dla klienta kilka plików … Kiedy wysłałem do nich emaila odpowiedzieli, że po ich stronie problemów z ftp nie ma (najwidoczniej zapominając o notce na stronie, którą zresztą sami napisali).

Następnego dnia widzę na kilku stronach błędy 404. Zanim wysłałem kolejne zgłoszenie o problemie upewniłem się, że błędy 404 (file not found) nie są bezpodstawne, i by nie wyjść na głupka poprzez ftp (już działający!) sprawdziłem pliki - były na swoich miejscach. Wysłałem emaila. I jaką dostałem odpowiedź? “U nas działa” i “proszę sobie wyczyścić cache przeglądarki”. Najwidoczniej muszę mieć wspólny cache dla dwóch przeglądarek na dwóch komputerach, które mają różne podłączenia do Internetu!
Zanim pojawiły się problemy zgłaszałem im kilka pomysłów na walkę ze spamem, udoskonalenie strony administracyjnej i kilka podobnych. Robiłem to, bo wydawało mi się, że wpłynę na poprawienie jakości firmy, którą wtedy uznawałem za wysoką. Cóż, pomyliłem się. A że na idiotę nie trafili, zaczynam wojnę …

Update

Właśnie dostałem od nich kolejną pocztę w sprawie błędów 404. Otóż, uważają oni, że jeśli dostaję stronę z błędem z logiem tejże właśnie firmy hostingowej w rogu strony (tzw. customized 404 error page), to jest to wina mojego ISP i każą mi sprawdzić na innym … Pozwolę sobie nie prosić ich o logi httpd z tego dnia …