sty 182013
 

Wstęp

Niniejszy tekst to instrukcja opisująca, jak traktować informacje napływające od użytkowników, co robić, a czego unikać. Przedstawiam tu pewien gotowy model, który, gdyby ktoś miał ochotę lub potrzebę, można przyjąć w zaprezentowanej postaci lub przeskalować i zmodyfikować w zależności od wielkości i potrzeb serwisu internetowego. Nadaje się on do zastosowania nawet w przypadku blogów – będzie to o tyle łatwiejsze, że blogi zazwyczaj nie mają rozbudowanej redakcji (w większości są to projekty jednoosobowe), więc wystarczy zastosować parę prostych zasad (coś w rodzaju zestawu dobrych praktyk). Wersję minimum dla blogerów znajdziecie w ramce w dalszej części tekstu. Na końcu zamieściłem też opis sytuacji, w której zarządzanie informacją zwrotną od użytkownika nie do końca przebiegło poprawnie.

Kto potrzebuje instrukcji?

Prowadzenie serwisu internetowego wiąże się z otrzymywaniem informacji od użytkowników. Zazwyczaj są to komentarze dotyczące opublikowanych treści i adresowane przede wszystkim do autora danej publikacji. Jednak od czasu do czasu czytelnik wyśle redakcji uwagi na temat strony, znalezionych błędów (czy to technicznych, czy też zamieszczonych tekstach) lub po prostu swoją opinię na temat pracy zespołu redakcyjnego. To, w jaki sposób potraktujemy taką komunikację, wpływa na wizerunek i serwisu, i pracujących w nim osób. Na wdrożeniu zasad postępowania z uwagami od czytelników mogą skorzystać przede wszystkim większe serwisy, których redakcje składają się z co najmniej kilkunastu redaktorów i stałych współpracowników, choć mniej liczne zespoły też mogą uznać je za przydatne (teoretycznie w przypadku małych redakcji są mniejsze kłopoty z komunikacją wewnętrzną, choć nie jest to regułą i przyjęcie jednolitych, spisanych zasad pomaga w utrzymaniu porządku).

Informacje napływające od użytkowników są ważne. Po pierwsze, wskazują niedociągnięcia i usterki i dzięki temu przyczyniają się do ulepszenia serwisu. Po drugie, pokazują, że udało się pozyskać jednostki lub grupę na tyle związaną z serwisem, że zadają sobie oni trud, by o poinformować redakcję o czymś tak istotnym jak niedziałający element strony. Nalezy przy tym pamiętać, że użytkownik to klient. Ignorowanie uwag klientów nie jest dobrze widziane, podobnie jak agresywne czy aroganckie odpowiedzi, a także zbywanie ludzi banałami lub pokrętnym tłumaczeniem. Tym bardziej, jeśli uwagi zgłasza aktywny użytkownik zainteresowany tworzeniem treści lub współpracownik (wolny strzelec podsyłający od czasu do czasu artykuły czy też zewnętrzny autor, u którego zamawiane są teksty) – zwłaszcza ten ostatni przypadek należy traktować z uwagą, można bowiem popsuć sobie kontakty nawet przez błahe niedopatrzenie. Jeśli ich uwagi zostaną zignorowane, może się zdarzyć, że ze współpracy zrezygnują i pójdą do konkurencji. W ten sposób można stracić nie tylko autorów – wraz z brakiem treści odejdą też czytelnicy.

Ktoś mógłby stwierdzić, że przecież prowadzi amatorski (fanowski) serwis, więc takie rzeczy nie są mu potrzebne. Amatorski nie oznacza jednak amatorszczyzny. Praca fanowska, wykonywana za darmo, wciąż jest pracą – powinna być wykonywana albo dobrze, albo wcale, a na pewno podlega ona ocenie użytkowników portalu. Czytelnik fanowskiego serwisu niewiele różni się od osoby, która odwiedza portal koncernu medialnego – ma podobne wymagania i oczekiwania, do tego bywa, że chce swoją fanowską pracą serwis wesprzeć (a na pewno generuje ruch, czasem pisze komentarze, linkuje treści i klika w reklamy). Ignorowanie czy odstraszanie użytkowników, zwłaszcza tych aktywnych, to podcinanie gałęzi, na której się siedzi.

Informacja zwrotna: opinie i uwagi merytoryczne

Informację zwrotną od czytelników można najprościej podzielić na opinie i uwagi merytoryczne. Do tej pierwszej kategorii zaliczyć można wszelkiego rodzaju głosy związane z subiektywną oceną strony internetowej, tematyki publikacji bądź pracy redakcji (przykłady: „fajna stronka”, „za mało fantasy”, „nie podoba mi się”). Do drugiej: wszelkie głosy merytoryczne, czyli informacje na temat literówek, błędów rzeczowych, problemów technicznych i innych.

a) opinie

Każdą korespondencję od czytelników należy przeczytać, bez wyjątków. Z głosami z kategorii „opinie” należy się zapoznać i zastanowić, czy należy coś w związku z nimi zrobić. O ile hasło „fajna stronka” nie przekazuje nic istotnego, a jednostkowym „za mało fantasy” można się nie przejmować, to regularne powtarzanie się w mailach tych samych sugestii może oznaczać, że być może warto by było np. poszerzyć repertuar tematyczny strony. W przypadku negatywnych opinii warto się skontaktować z nadawcą i poprosić o doprecyzowanie zarzutów. Natomiast zawsze należy do nadawcy odpisać i podziękować mu za nadesłaną opinię, jaka by nie była – nawet jeżeli był to jednozdaniowy mail.

b) uwagi merytoryczne

Wszelkie uwagi merytoryczne należy przeanalizować, poprawić błędy lub przygotować plan naprawczy (w bardziej skomplikowanych przypadkach) i jak najszybciej skontaktować się z nadawcą: podziękować mu i przedstawić krótko sposób rozwiązania problemu lub plany załatwienia sprawy. Jeśli sytuacja tego wymaga, należy poprosić o więcej informacji (dodatkowe szczegóły sprawy albo przeprowadzenie krótkiego testu funkcjonalności po naprawie) i obiecać ponowny kontakt celem potwierdzenia, że wszystko już działa – należy podać termin i go dotrzymać. W ten sposób wszyscy będą zadowoleni: czytelnik – gdyż jego wkład w poprawę serwisu został doceniony, redakcja – wprowadzono poprawki bądź ulepszenia (doraźne lub mogące zapobiec podobnym zdarzeniom w przyszłości), co przełoży się na lepszy wizerunek serwisu.

Sytuacje awaryjne

Kłopoty zaczynają się, gdy napływająca komunikacja zostanie zignorowana (celowo lub przypadkiem) i użytkownik serwisu zdecyduje się opisać sprawę publicznie. Wtedy pozostaje już tylko gaszenie pożaru, co też należy robić umiejętnie.

Trzeba mieć świadomość, że skoro ktoś był już na tyle zniechęcony lub zdesperowany, żeby publicznie domagać się uwagi ze strony redakcji (w takim momencie jest już nieistotne czy słusznie, czy nie), to jest już pozamiatane – coś nie zadziałało (ustalone sposoby postępowania, komunikacja). W takim wypadku trzeba się publicznie uśmiechnąć i przeprosić, ale w żadnym razie nie należy wchodzić w dyskusję czy wyjaśniać, co się stało. Tutaj niewiele pozostało do zrobienia i bywa, że publiczne tłumaczenie się niewiele pomoże albo i pogorszy sprawę (dojdzie do kłótni, pojawią się inne osoby z podobnym problemem, które też zignorowano itp.). W przypadku większych czy głośnych spraw warto opublikować komunikat, ale dopiero po satysfakcjonującym obie strony rozwiązaniu problemu.

a) minimalizowanie strat

Sprawę należy załatwić szybko: publicznie przeprosić użytkownika, obiecać wyjaśnienie problemu i dalszy kontakt kanałami prywatnymi.

Zaraz potem należy skontaktować się prywatnie z użytkownikiem, przeprosić jeszcze raz, podać przyczynę problemu (jeśli jest znana), zaproponować rozwiązanie sprawy wraz z terminem oraz ewentualnie rekompensatę (nic wielkiego: kupon zniżkowy, gadżet, albo szczególne wyróżnienie tekstu po publikacji, jeśli czytelnikowi zdarza się coś napisać dla serwisu). Co ważne, komunikację z użytkownikiem od początku do końca powinna obsługiwać jedna osoba – to ona odpisuje czytelnikowi publicznie, a potem prywatnie i jest dla niego punktem kontaktowym. To zapewni spójność wysyłanych komunikatów.

b) ustalenie przyczyny problemu

Nie wolno wymyślać powodów, dla których coś nie zadziałało. Jeśli nie wiemy (nie mieliśmy czasu ustalić przyczyny awarii lub pomyłki), należy użytkownikowi napisać, że postaramy się dowiedzieć, co nie zadziałało. Jeśli wiemy, trzeba napisać ogólnie, ale rzeczowo, co poszło nie tak (czynnik ludzki, błąd techniczny, nieadekwatne procedury). W żadnym wypadku nie można tłumaczyć się brakiem personelu, trybem pracy w redakcji, priorytetami, brakiem czasu, czy też wymyślać awarie. To czytelnika nie interesuje. Tym bardziej nie interesuje to współpracownika (stałego, okresowego, gościa) czy też osoby chętnej do współpracy. Taką informację autor piszący dla serwisu powinien był otrzymać, gdy oddawał tekst, a nie w momencie, gdy redakcja spóźnia się z obróbką materiału (i – co gorsza – nie informuje o poślizgach).

Zdarzają się oczywiście niespodziewane wypadki czy awarie, ale wtedy należy wszystkich zainteresowanych natychmiast poinformować o możliwych opóźnieniach. Choroby i duże awarie (np. pożar w serwerowni) atakują niespodziewanie i taka sytuacja zostanie przyjęta z większym zrozumieniem, ale nie brak komunikacji. O niedostępności personelu z powodów innych niż wymienione można poinformować w ostateczności (na wizerunek wpływa też otwarta polityka komunikacji z użytkownikami), ale trzeba brać pod uwagę, że nietrafne oszacowanie dostępnych zasobów kadrowych zasobów oznacza zwykle (i tak może zostać odebrane) albo złe zarządzanie serwisem, albo kiepską organizację pracy (w takiej sytuacji planowanie i podział obowiązków w redakcji powinny zostać poddane przeglądowi i poprawione).

c) działania naprawcze

Zawsze należy zaproponować tymczasowe rozwiązanie sprawy, jeśli problem nie może zostać naprawiony od ręki. Ustalanie przyczyn awarii może potrwać, ale problem użytkownika nie będzie czekał – skoro już wypłynął na światło dzienne, jest do rozwiązania natychmiast (może to być np. szybkie poprawienie i publikacja tekstu poza kolejnością, zasugerowanie użycia innej przeglądarki do czasu poprawy kodu strony – zależnie od zgłoszonego problemu). Trzeba też zaznaczyć, że rozwiązanie jest tymczasowe lub wymuszone sytuacją, natomiast prace nad likwidacją przyczyny problemu zostaną podjęte jak najszybciej i że użytkownik zostanie o przyjętym rozwiązaniu i wdrożeniu poprawek powiadomiony (należy dotrzymać obietnicy). Jeśli załatwienie sprawy leży po stronie redakcji (nie są zaangażowane strony trzecie – firma hostująca serwer, wynajęty programista itd.), należy podać termin i bezwzględnie go dotrzymać.

Kiedy już znana będzie przyczyna awarii i przeprowadzone zostaną działania naprawcze, trzeba skontaktować się z użytkownikiem i poinformować go o tym (bez wdawania się w szczegóły, wystarczy ogólna informacja o przyczynie kłopotów i przyjętym rozwiązaniu) oraz podziękować za pomoc w ulepszeniu serwisu.

Na koniec należy dopilnować, żeby wszelkie wdrożone zmiany zostały zakomunikowane i zrozumiane przez redakcję (jeśli jest to konieczne, o poprawkach kodu wszyscy wiedzieć nie muszą, ale o zmianie sposobu pracy czy komunikacji w redakcji już tak). Jest to istotne, zwłaszcza jeśli chodzi o czynnik ludzki (np. ktoś nie odpisywał autorowi na maile, bo nie miał czasu albo ochoty itp. – wtedy powinien był powiadomić resztę redakcji, żeby przejęli komunikację i takie właśnie polecenie redakcja otrzymała w ramach działań naprawczych, aby informować innych członków zespołu o pojawiających się problemach).

W przypadku, kiedy problemu nie da się rozwiązać na stałe, należy wyjaśnić użytkownikowi, dlaczego sprawa pozostanie nierozwiązana (np. ze względu na koszty lub brak możliwości technicznych), przeprosić za niedogodności i podsunąć jakąś alternatywę (jeśli to możliwe). Drobna rekompensata niedogodności też będzie na miejscu.

W rezultacie czytelnik będzie zadowolony (jego uwagi nie poszły na marne, ktoś się nimi zainteresował), a serwis zyska, poprawiając błędy lub wewnętrzne procedury.

Wersja minimum dla blogerów
Odpisz na każdy mail. Popraw, co możesz poprawić. Wyjaśnij, czego nie jesteś w stanie poprawić i dlaczego. Przeproś za niedoskonałości. Podziękuj za uwagi. Zapamiętaj sprawę i zadbaj, jeśli to możliwe, by nie powtórzyła się w przyszłości.

Przykład sytuacji awaryjnej

Użytkownik portalu internetowego poskarżył się publicznie na długotrwały proces publikacji tekstów (od wysłania artykułów do redakcji do momentu publikacji minęły ponad dwa miesiące) oraz na kiepską komunikację (podawanie nierealnych terminów). Problem został opisany dokładnie – redaktorzy pracują dobrze (teksty są poprawiane sprawnie), jest kontakt (odpisują na maile), ale mimo zakończenia obróbki artykuł nie jest publikowany (na stronę wchodzą inne, mniej istotne zdaniem blogera treści, a jego tekst się dezaktualizuje), a do tego przekazywane mu informacje dotyczące daty publikacji nie są dla redakcji wiążące („niebawem/w tym tygodniu”). Co ważne, użytkownik jest zadowolony ze współpracy (nie będzie problemów z dogadaniem się z nim), zwraca jednak uwagę na istotny dla niego problem – na tyle palący, że postanowił o nim napisać na forum publicznym.

Kilku członków redakcji postanowiło zająć się skargą, odpisując w komentarzach. Z blogerem skontaktowano się też prywatnie. Sprawa nie wygląda najgorzej, ale paru błędów można było uniknąć.

Poniższe omówienie opiera się na tym, co można zaobserwować na zewnątrz, w publicznej komunikacji do użytkownika, stąd też końcowe wnioski zawarte w podsumowaniu są raczej pewnym przybliżeniem, mogą też być zupełnie chybione, ale ma to być przede wszystkim przykład przebiegu sprawy. Do sporządzenia faktycznej analizy potrzebne by było więcej danych, w tym wgląd w pracę redakcji i zapewne kilka wywiadów.

Błąd 1.: wiele źródeł komunikacji

Blogerowi odpisywały cztery osoby z redakcji serwisu. Każda pisała co innego i broniła swojej działki, żadna nie zaproponowała rozwiązania sprawy. Kuriozalnie na wstępie zarzucono blogerowi, że skarży się w sprawie tekstu, którego nie jest autorem Na wstępie spytano blogera, czy na pewno dopytuje się o właściwy tekst („A jak to jest, że piszesz o 'Stalowej Policji’ a nie ma jej w wykazie Twoich tekstów?”). Jeden z redaktorów skontaktował się z blogerem mailowo – od czego trzeba było zacząć.

Błąd 2.: niespójny przekaz

Dwukrotnie zasugerowano użytkownikowi, że powinien w takich sprawach kontaktować się bezpośrednio z redakcją („Jeśli rzeczywiście zależy ci, żeby tekst […] poszedł na stronę szybko, przypominaj się redaktorom” oraz „Zachęcam jednak do kontaktu mailowego”). Sęk w tym, że użytkownik już się kontaktował, podał też odpowiedzi, jakie otrzymał. Później nieco pierwszą wypowiedź złagodzono („W przypadku userów/współpracowników oczywiście nikt w serwisie nie każe userowi dopraszać się o publikację”) i w razie wystąpienia problemów w przyszłości zachęcono do kontaktu ze zwierzchnikami działów, do których wysyłane były teksty.

Autor tekstów czy też współpracownik nigdy nie powinien usłyszeć od redakcji, że ma dopominać się o swoje. To obowiązkiem redaktorów jest zadbać o autora. Niekoniecznie przytoczona wypowiedź o przypominaniu się redaktorom (i później złagodzona) przestawia codzienną sytuację w serwisie, ale nigdy nie powinna była się pojawić (stanowisko redakcji musi być spójne, a redaktorzy powinni znać swoje obowiązki, do których należy dbanie o interesy autora – bez niego nie mieliby zajęcia).

Największym problemem są maile, w których podawano termin publikacji, którego nie dotrzymywano. Taka sytuacja nie powinna mieć miejsca. Podawanie wymyślonych dat lub rzucenie terminem, którego nikt nie ma zamiaru dotrzymać to lekceważenie użytkownika (co w tym przypadku skończyło się wyciągnięciem sprawy na forum publiczne), za czym może pójść utrata wiarygodności i zaufania.

Błąd 3.: rozbieżne wersje wydarzeń

Redakcja próbowała tłumaczyć się na różne sposoby, niekoniecznie związane z rzeczywistym problemem. Blogerowi wyjaśniono, że obróbka redakcyjna scenariuszy trwa długo, na co się nie skarżył („W przypadku tekstów RPG, zwłaszcza scenariuszy, to norma. To teksty, które zazwyczaj wymagają najwięcej pracy”). Przywołano też istnienie kolejki tekstów gotowych do publikacji („Do tego w dziale przeważnie jest kolejka tekstów do wrzucenia”) – tyle że taką informację autor powinien był otrzymać wraz z przyjęciem tekstu, wtedy przynajmniej znałby powód oczekiwania. Dalej było o złym oszacowaniu zasobów („recek jest bardzo dużo, czego nie można powiedzieć o liczbie dyspozycyjnych korektorów”) – dla autora oczekującego publikacji braki kadrowe nie są żadnym wytłumaczeniem (chyba że wybuchła epidemia); od zapewnienia bezproblemowej pracy redakcji są odpowiednie osoby i ich zadaniem jest taki podział zadań, żeby wszystkie można było wykonać na czas (jeśli pracy jest za dużo, należy znaleźć dodatkowych pracowników, albo zrezygnować z zadań o mniejszym priorytecie, co może oczywiście oznaczać także odsunięcie w czasie publikacji pewnych treści, ale tu znowu należy poinformować ich autora).

Opóźnienie próbowano też wytłumaczyć brakiem szefa jednego z działów i tym, że nowa osoba na tym stanowisku „musiała się wdrożyć w serwis”. Można odnieść wrażenie (niekoniecznie słuszne), że nowy szef działu został pozostawiony samemu sobie wraz ze wszystkimi sprawami i przez ponad miesiąc nie znalazł się nikt, kto mógłby poświęcić kilka minut, by pomóc w publikacji gotowego tekstu, który i tak czekał już dość długo.

Podsumowanie

Użytkownikowi przedstawiono kilka źródeł problemu, do wyboru, do koloru. Może przyczyną opóźnienia była kolejka oczekujących, ważniejszych tekstów? Może stały za nim braki kadrowe – jeśli nie absencja szefa działu, to zbyt mały zespół redaktorów w stosunku do liczby tekstów oczekujących na poprawki? Być może wszystkie wymienione czynniki składają się na przyczynę problemu – albo też żaden z nich. Niestety, nikt nie odpowiedział jasno na pytanie, co naprawdę zawiodło. Szkoda też, że nikt nie odniósł się do wziętych z sufitu terminów publikacji podawanych autorowi.

W efekcie w ciągu trzech dni odpisywania użytkownikowi nie widać na razie rozwiązania sprawy. Nieopublikowany tekst wciąż się dezaktualizuje (być może podano datę publikacji w komunikacji prywatnej, oby tym razem termin został dotrzymany), do tego pod blogowym wpisem pojawiły się w komentarzach głosy krytyczne, niekoniecznie związane ze sprawą, ale powiększające zamieszanie.

Rozwiązaniem doraźnym byłaby szybka publikacja oczekującego tekstu – wszyscy byliby zadowoleni. Jako rozwiązanie długofalowe być może przydałoby się oszacowanie zasobów redakcyjnych i realna ocena wydajności zespołu – na nic zda się i setka czekających w kolejce tekstów, jeśli nie ma się kto nimi zająć lub które nie są publikowane z powodu zbyt sztywnego planu wydawniczego. Może czas na reorganizację sposobu pracy i przegląd przyjętych celów?

Schemat procesu

Schemat zarządzania komunikacją zwrotną od użytkowników

 Zamieścił: dn. 18/01/2013 o 02:55

  28 komentarzy do “Zarządzanie informacją zwrotną od użytkowników”

Komentarze (28)
  1. Fachowy konsulting odwaliłeś. A z Polteru i tak nikt nie przeczyta, bo tam udają, że poza nim blogosfera nie istnieje.

    • Dzięki. Miałem zrobione trochę notatek i uznałem, że szkoda je trzymać w szufladzie. Może się komuś przyda. Polteru było inspiracją, choć od dawna mam ochotę napisać parę rzeczy o zarządzaniu jakością w fanowskim serwisie internetowym.

  2. Dzięĸi za tekst – jest potrzebny. Przy okazji znajdź w tekście: „komunikację komunikację”

    • Zdaje się, że znalazłeś gdy pisałem komentarz.

      • Flowchart mi zajął większość wieczoru (to zadziwiające, jak przy przeskalowaniu linie proste zmieniają się w łamane), przez co pewne rzeczy przegapiłem i teraz poprawiam, jak zauważę. Dzieki. :)

  3. Nudzisz się Seji, że też się Tobie chciało… Rozumiem, że można na Twitterze napisać „HiHi, znowu jazda na Pff+”, ale podawać im na tacy tak obszerną instrukcję działania? Nawet jeśli zadziała to podziała przez 1k6 miesięcy+1.
    Odbiegnę od głółnego wątku i jako przykład podam newsy, których regularnie czepiam się co rok, półtora.
    Po jakimś tekście typu Wieś(ć)many czy ostatni mój o Dzienkarstwie erpegowym, wszystko wraca do normy na kilkanaście njusów, potem pojawiają się już newsy o fenomenalnych tchórzofredkach RPG na 8 stron, brejkingnjusy z bloga Neurocide o grach sprzed lat i inne copypasty. Szczęśliwie Google od tamtego roku pogrąża copypaściarzy także pozycja tych „serwisów” spada.
    I na koniec.
    Chciałem wnieść poprawkę do tekstu o poprawkach.
    „jeśli nie absencja szefa działu, to zbyt mała liczba reaktorów w stosunku do liczby tekstów wymagających poprawy”.
    Chodziło o „redaktorów” Kolego Blogerze, prawda?
    Załączam pozdrowienia dla Kolegi Blogera i wszystkich Czytelników.
    Przystojny Pan Adrian, syn Henryka

    • Reaktory też mają swój urok. ;) Sugestię Kolegi Blogera uwzględniłem i niezbędną poprawkę naniosłem.

      Tak, chciało mi się. :) Jak wspomniałem, miałem gotowe notatki (sporządzone przy innej okazji), wystarczyło je nieco obrobić i wrzucić. Świat nie kończy się na Polterze, nie jest to teks napisany z myślą o nich ani dla nich, choć linkowany wpis blogowy przyczynił się do tego, że wreszcie zebrałem razem parę rzeczy – jak im się przydadzą te informacje, to fajnie.

      Do trzymania się instrukcji potrzebna jest dyscyplina i nadzór, ale też świadomość, dlaczego coś powinno być robione w taki a nie inny sposób. Ty zganisz redaktora, może uzyskasz chwilową poprawę, ale jeśli nie będzie go pilnował zwierzchnik (wymagał i egzekwował), a do tego redaktor nie będzie rozumiał, dlaczego powinien trzymać się przyjętych procedur, efekt nie będzie długoterminowy. To jest temat na osobny wpis.

      • Dziękuję Kolego za wyczerpującą odpowiedź. Tak, wyniosłem sporo z tego tekstu ( a nie ramki dla blogerów), bo uczyć się należy od najlepszych serwisów i Redakcji w Polsce jak: gry-fabularne czy własnie Polter.

        Natomiast odnośnie ostatniego akapitu zgadzam się z Kolega całkowicie. Takie „kocioł garnkowi” działa przez 1k3 mies. +1 czy w wersji optymistycznej 1k6+1 mies. jeśli nie ma kompetentnych zwierzchników. Przykładem może być pismo, w którym Kolega pracuje i zapewne dzięki niemu zarabia na rozboje po Europie i różnych wyspach. Pomijając już jego zawartość, można mówić o nim „od lat na poziomie”. Czego niestety nie można powiedzieć o serwisach, czy blogach.
        Serdecznie pozdrawiam i dziękuję za publikację mojego komentarza na łamach Błekitnego Świtu.

  4. Fajny tekst, szkoda ze nie puszczony jakies 5-6 lat temu, kiedy uczylem sie tego na wlasnych bledach :P

    BTW chcialbym dostawac feedback od uzytkownikow ;P

  5. A bardziej serio, to na Polterze ten schemat działa, tylko wygląda nieco inaczej: http://i.imgur.com/vCxvM.gif

    A jeszcze bardziej serio, to mniejsza z Polterem. Tylko jedna uwaga, tam robi się – jak zawsze – politykę, nie serwis. A to oznacza, że „Rozwiązaniem doraźnym byłaby szybka publikacja oczekującego tekstu – wszyscy byliby zadowoleni.” nie jest rozwiązaniem wchodzącym w grę. Wszakże nie można dopuścić do stworzenia precedensu, iż publiczne zruganie redakcji za niewywiązywanie się ze swoich słów wywiera presję skutkującą wywiązaniem się redakcji ze swoich słów.

    PS „Wdrażanie się w serwis” jest arcykomiczne. Nie jestem w stanie wskazać, czy w Repek w większym stopniu obraził intelekt redaktora, czy użytkowników. Ale być może to ja się mylę i rzeczywiście mają tam taki burdel, iż taki powód jest sensownym usprawiedliwieniem. Niemniej zabawnie brzmi porównywanie prowadzenia działu bitewniaków do przeszkolenia do nowego miejsca pracy. Jednak w redakcji łopatą węgiel cały dzień przerzucają, gdy są dni z rodzaju tych fizycznych, zatem zaskakiwać to nie powinno.

  6. Świetny tekst, a do tego potrzebny, co w sumie jest dość zaskakujące, bo większość zawartych w nim porad można wydedukować, zaprzęgając do roboty tzw. „zdrowy rozsądek” – zaskakujące, jak bardzo się on gubi w tych całych Internetach. ;)

  7. „Kuriozalnie na wstępie zarzucono blogerowi, że skarży się w sprawie tekstu, którego nie jest autorem („A jak to jest, że piszesz o ‚Stalowej Policji’ a nie ma jej w wykazie Twoich tekstów?”). ”

    Seji, nie wkładaj mi, proszę, w usta tego, czego nie napisałem, czyli zarzutów jakie podobno uczyniłem. To nie był zarzut tylko pytanie, zwłaszcza, że dotyczyło faktycznie tekstu, który dopiero repek umieścił w profilu Kratistosa po moim komentarzu. Nadinterpretacja słów, z intencją oczernienia tego, kto tych słów użył, jest przejawem braku kultury, zwłaszcza u kogoś, kto nie ma nic do roboty tylko sam chce ludzi tej kultury uczyć. Więc najpierw szukaj belki u siebie a potem drzazgi u innych. Jasne?

    • „zwłaszcza u kogoś, kto _nie ma nic do roboty_ tylko sam chce ludzi tej kultury uczyć. Więc najpierw szukaj belki u siebie a potem drzazgi u innych. _Jasne_?”
      Jednoczesne obrażanie kogoś i wytykanie mu braku kultury stawiając się w wyższej moralnie pozycji to niezbyt dobre combo. Zwłaszcza w tak agresywnym tonie.

    • Postuluje, aby na blogu w komentarzach umiescic przycisk „Spierdalaj!’.

    • @Earl

      Bardzo dziękuję za komentarz.
      Być może na mój odbiór Twojej wypowiedzi wpłynęły niedostatki komunikacji internetowej, która jako wyłącznie tekstowa nie oddaje wszystkich niuansów konwersacji. Zapewne również to, że ja w opisanej sytuacji zadziałałbym inaczej (zadał inne pytania i w inny sposób, odniósł się do istoty problemu). Zewnętrzny obserwator w Internecie nie zna, niestety, intencji piszącego, stąd pozostaje mu jedynie interpretacja tekstu (dlatego też w Internecie przydają się emotikony :)). Jak zaznaczyłem, opis oparty jest wyłącznie na dostępnym materiale, ograniczonym w formie – na pewno wszelkie niejasności zostałyby rozwiane podczas rozmowy na żywo, gdyby głębiej przeanalizować sprawę (zebrać dodatkowe informacje, prześledzić przebieg procesów). Naniosłem stosowne poprawki. Dziękuję za wyjaśnienie i doprecyzowanie faktów.

      Natomiast trudno jest mi odnieść się do zarzutu dotyczącego „uczenia ludzi kultury”. Mój tekst opisuje pewien proces biznesowy, który z uczeniem kultury czy też manier nie ma nic wspólnego (co najwyżej może się wpisywać w kulturę organizacji, czyli zupełnie inny obszar pojęciowy; maniery i kultura będą miały znaczenie na poziomie wykonawców procesu, ale szkolenie pracowników z tzw. „customer care” to temat na kiedy indziej). To opis ścieżki postępowania (przebiegu procesu), instrukcja przedstawiająca zestaw zachowań poprawnych z punktu widzenia organizacji (firmy, serwisu). Tu mogę jedynie polecić ponowną lekturę. Liczę, że znajdziemy wspólne tematy do rozmowy, dotyczące opisywanego problemu – jestem pewien, że mógłbyś przedstawić kilka ciekawych przypadków.

      Na zakończenie dodam, że jeśli kiedyś będę przygotowywał tekst o skutecznej komunikacji i takich jej elementach, jak etykieta, stosowane słownictwo czy czynniki wpływające na jakość przekazu, pozwolę sobie wykorzystać Twój komentarz jako materiał źródłowy – jest w nim kilka interesujących aspektów, wartych omówienia. Jeszcze raz dziękuje i pozdrawiam. :)

  8. @ paralaktyczny

    Akurat to Seji postawił się w pozycji mentora dobrych manier, ale sam akurat tych manier nie przestrzega, więc miej pretensje do niego.

    @ Chavez

    I co byś z tym przyciskiem zrobił?

  9. Pozostaje zapytać, w jakim narzędziu robisz wykresy.

  10. Gowera czeka bezsenna noc… not!

  11. Administracyjne. ;) Wyciąłem, co trzeba (zarchiwizowane, jakby ktoś chciał treść). Trivia: użyto proxy sitenable.com. Moderacja komentarzy chwilowo włączona, testuję whitelistę.

    Jeszcze słowo na koniec, gdyby ktoś miał wątpliwości: to nie jest tekst o Polterze. To nieco przykrojony opis procesu zarządzania informacją zwrotną, dostosowany do potrzeb fanowskiego lub półprofesjonalnego serwisu internetowego (wciąłem prowadzenie dokumentacji działań naprawczych i rzeczy z tym związane, root cause analysis itd., zostawiając sam rdzeń i nieco bardziej wiążąc całość z użytkownikiem końcowym, stąd nacisk na kontakt) – jeśli ktoś ma wdrożony system zarządzania jakością albo świadczy rozbudowane usługi dla klienta (np. typu service desk), to wie, o co chodzi. Polter dostarczył fajnego przykładu, który akurat był pod ręką – zlinkowałem, ponieważ linkuję źródła (mogłem poszukać jakiejś naprawdę skopanej sytuacji – ta była przeciętna – ale nie było potrzeby). Jak ktoś mi poda podobny przykład z innego serwisu, chętnie dopiszę.

  12. Bardzo fajny tekst. Szkoda jednak, że trzeba o tym pisać. Wydawało mi się, że każdy rozsądny serwis działa na podobnej zasadzie. To tak jakby mówić dorosłemu człowiekowi, że po siusianiu należy umyć dłonie. Wydaje się, że każdy o tym wie. A prawda jest inna :)

    Tekst nie jest o Polterze, ale jak widać wielu odnosi go do tego serwisu. Także, wygląda na to, że z Polterem jest coś nie tak. Za dużo ostatnio na ten temat dyskusji. Zbyt wiele osób przechodzi do blogosfery. Coraz więcej osób mówi, że coś „nie halo” z Polterem. Czy tak jest w rzeczywistości?

    • @Piastun: Jest rok 2013, prezydentem jest Komorowski, nie było wybuchu bomby G, a „coś nie halo” z Pff+ było kilka lat temu jużci.

 Zostaw odpowiedź