Wsparcie strony internetowej po uruchomieniu

Wsparcie strony internetowej po uruchomieniu

Wsparcie strony internetowej po uruchomieniu zaczyna się od jednego praktycznego pytania: co dokładnie obejmuje? Jeśli odpowiedź jest niejasna, każda drobna prośba przeradza się w dyskusję. Formularz przestaje wysyłać e-maile. W etykiecie menu trzeba coś zmienić. Ktoś chce dodać nowy plik PDF, do którego ma prowadzić link na stronie głównej, i nikt nie wie, kto za to odpowiada.

Ustal granice już pierwszego dnia. W tym projekcie wsparcie po uruchomieniu może obejmować poprawki błędów, niedziałające linki, pomoc przy CMS-ie i drobne zmiany treści. Może natomiast nie obejmować nowych szablonów stron, próśb o funkcje ani zmian projektowych, które wymagają nowej wyceny. To rozróżnienie ma znaczenie, bo zespół 5 osób może interpretować tę samą prośbę na 5 różnych sposobów, jeśli zasady nie są zapisane.

Pomocne oświadczenie o zakresie powinno wskazywać trzy rzeczy: co należy do wsparcia, kto się tym zajmuje i co nie wchodzi w zakres. Jeśli lider marketingu zmieni nagłówek w piątek, a strona przestanie działać w sobotę, odpowiedź nie powinna zależeć od tego, kto akurat jest dostępny na czacie. Zgłoszenie powinno już mieć swoje miejsce, a zespół powinien wiedzieć, jak przyjmować zgłoszenia po wdrożeniu strony bez zbędnych pytań.

Właśnie tutaj utrzymanie i wsparcie strony internetowej powinny pozostać w procesie rozdzielone. Utrzymanie to zaplanowana praca. Wsparcie to zgłoszenie, które trafia do zespołu, bo coś wymaga natychmiastowej uwagi. Te dwa obszary mogą się przenikać, ale nie powinny być traktowane jako ta sama kolejka.

Mapuj pierwsze 30 dni realnego użycia

Pierwsze 30 dni po przekazaniu projektu pokazuje więcej niż miesiąc spotkań planistycznych. Nowa strona często działa dobrze w testach, a potem przynosi bardzo zwyczajne niespodzianki, gdy zaczyna jej używać prawdziwy zespół. Jeden klient aktualizuje 12 stron produktów z rzędu i odkrywa, że kadrowanie obrazów nie jest spójne. Inny dowiaduje się, że pracownicy mogą publikować wersje robocze, ale tylko 2 osoby wiedzą, jak je zatwierdzać. To są dane do wsparcia, a nie szum.

Śledź typy zgłoszeń, które pojawiają się po uruchomieniu, a nie te, których spodziewałeś się z listy kontrolnej. Nowi klienci mogą korzystać z koszyka w sposób, którego nikt nie symulował. Zespół sprzedaży może wklejać linki śledzące do niewłaściwych pól. Zespół operacyjny może potrzebować 3 rund, zanim proces przesyłania plików stanie się naturalny. Takie wzorce pokazują, gdzie strona jest niejasna, gdzie instrukcje są słabe i gdzie workflow jest zbyt kruchy do codziennego użytku.

Nie oznaczaj wszystkiego jako błędu. Część zgłoszeń to tak naprawdę luki w szkoleniu. Część to problemy z treścią. Część jest skutkiem nowego procesu, który jeszcze się nie ustabilizował. Jeśli to samo pytanie pojawia się 4 razy w ciągu 2 tygodni, problemem może być dokumentacja, a nie kod. Takie rozróżnienie oszczędza czas i zmniejsza liczbę fałszywych alarmów.

Dla zespołów, które chcą szerszych ram, bezpieczeństwo strony internetowej jest często pierwszym obszarem, na który zwracają uwagę ludzie, ale wsparcie po uruchomieniu jest szersze niż bezpieczeństwo. Strona może być bezpieczna, a mimo to dezorientować pracowników, ukrywać ważny przycisk albo źle kierować zgłoszenie do właściwej skrzynki. Realne użycie szybko pokazuje takie słabe punkty.

Stwórz prostą ścieżkę przyjmowania zgłoszeń

Jedno miejsce do rejestrowania problemów. Ta jedna zasada sama w sobie zapobiega wielu utraconym zgłoszeniom.

Jeśli zgłoszenia trafiają do Slacka, e-maila, WhatsAppa i rozmów na korytarzu, nikt nie potrafi stwierdzić, czy problem jest nowy, powtarzalny czy już naprawiony. Wybierz jedną ścieżkę przyjmowania zgłoszeń. Może to być formularz, współdzielona tablica albo adres wsparcia, który zasila tracker. Format ma mniejsze znaczenie niż dyscyplina.

Za każdym razem proś o jeden obowiązkowy pakiet: zrzut ekranu lub nagranie ekranu, adres URL strony, godzinę zauważenia problemu i krótką notatkę o tym, co dana osoba próbowała zrobić. Wiadomość typu „przycisk nie działa” jest zbyt uboga, by na niej pracować. Wiadomość typu „na stronie z cennikiem przycisk nie otwiera formularza po stuknięciu na iPhone 13 o 9:15 rano” jest przydatna w ciągu kilku minut.

Używaj też jednej ścieżki decyzyjnej. Jeśli problem dotyczy tylko treści, trafia do osoby odpowiedzialnej za content. Jeśli obejmuje logikę lub kod, trafia do właściciela technicznego. Jeśli sprawa jest niejasna, jedna osoba wykonuje triage, zanim cały zespół zacznie odpowiadać. Chodzi nie o szybkość samą w sobie. Chodzi o to, by ten sam ticket nie był obsługiwany 3 razy w 3 miejscach.

Grupuj problemy według wpływu na biznes

Wsparcie jest łatwiejsze do opanowania, gdy problemy są sortowane według konsekwencji, a nie według warstwy technicznej. Awaria strony płatności najpierw wpływa na przychód. Niedziałający formularz leadów wpływa na pozyskiwanie kontaktów. Problem z panelem pracowniczym spowalnia pracę administracyjną. Literówka na stronie FAQ może zaszkodzić zaufaniu do marki. Myliący krok na mobile może po prostu irytować użytkowników, ale irytacja też ma swój koszt.

Taka kolejność pomaga zespołowi działać bez nadmiernego analizowania każdego zgłoszenia. Nieszkodliwa usterka wizualna we wpisie blogowym nie powinna wyprzedzać problemu z koszykiem, który blokuje 7 zamówień. Niedziałające pobieranie PDF-a na stronie wewnętrznej może mieć większe znaczenie niż niezgodny kolor na stronie głównej, jeśli 15 pracowników korzysta z tego pliku każdego dnia.

Jest też praktyczny powód, by zachować prostotę: ludzie rzadziej się spierają, kiedy widzą wpływ na biznes. Projektant, developer i menedżer mogą mieć różne zdania co do ciężkości technicznej, ale wszyscy troje mogą się zgodzić, że utracone zgłoszenie z formularza jest gorsze niż źle wyrównana ikona. Jeśli potrzebujesz użytecznego odniesienia wewnętrznego, zobacz ile kosztuje utrzymanie strony internetowej, jeśli chcesz porównać cykliczny wysiłek wsparcia z bieżącą opieką nad witryną.

Nie ukrywaj priorytetu pod techniczną etykietą typu CSS albo backend. To zaciera wpływ na biznes. Lista wsparcia, która zaczyna się od przychodu, pozyskiwania leadów, pracy administracyjnej, zaufania do marki i frustracji użytkowników, jest łatwiejsza do przejrzenia w 20 sekund.

Ustal priorytety reakcji i odpowiedzialność

Każda kolejka wsparcia potrzebuje osoby odpowiedzialnej za triage. Bez niej wygrywa najgłośniejsza wiadomość.

Osoba prowadząca triage decyduje o 4 rzeczach: na czym polega problem, kto go naprawia, kto zatwierdza zmianę i czy zgłoszenie wymaga eskalacji. Ta osoba nie musi wszystkiego rozwiązywać. Ma zapobiegać rozmyciu odpowiedzialności. Jeśli zmiany treści wymagają akceptacji marketingu, powinno to być jasne jeszcze zanim zgłoszenie trafi do redaktora. Jeśli problem ze śledzeniem należy do innego dostawcy, przekazanie powinno nastąpić tego samego dnia, a nie po 5 wymianach wiadomości.

Odpowiedzialność może być podzielona, ale musi być widoczna. Jedna osoba może odpowiadać za poprawkę. Druga za decyzję dotyczącą treści. Trzecia za akceptację klienta lub interesariusza. Taki układ działa tylko wtedy, gdy wszyscy znają następny krok. Niejasne „zajmiemy się tym” może zamienić 10-minutową poprawkę w 2-dniowe opóźnienie.

W większych zespołach ścieżka triage powinna być zapisana jako małe drzewo decyzyjne. Jeśli problem jest poważny i blokuje sprzedaż, eskaluje się go natychmiast. Jeśli chodzi o drobną korektę treści, trafia do standardowej kolejki. Jeśli dotyczy API innego dostawcy, ten dostawca zostaje włączony w sprawę wraz z przejrzystym podsumowaniem. Im mniej zgadywania, tym lepiej.

Przygotuj minimalny kontekst, który powinien wysłać każdy zgłaszający

Zgłoszenia wsparcia są szybsze, gdy pierwsza wiadomość zawiera 6 konkretów: stronę, wykonaną czynność, oczekiwany rezultat, rzeczywisty rezultat, urządzenie lub przeglądarkę, jeśli ma to znaczenie, oraz godzinę zauważenia problemu. Sześć elementów wystarczy, by zacząć. Później można dodać więcej, ale te 6 zapobiega najgorszemu rodzajowi dopytywania.

Ten szablon jest na tyle prosty, że mogą go używać osoby nietechniczne. Wypełni go kierownik sprzedaży. Wypełni go redaktor treści. Wypełni go klient bez zgadywania, co oznacza „stack trace”. Chodzi o to, by zebrać kontekst, zanim pamięć zacznie zawodzić. Po 2 godzinach ludzie przestają pamiętać, czy problem wystąpił w Chrome, czy w Safari, a szczegóły stają się mniej wiarygodne.

Dobre zgłoszenie unika też interpretacji. „Strona jest dziwna” nie jest pomocne. „Na stronie kontaktowej przycisk Wyślij nic nie robi po zaznaczeniu checkboxa, na desktopowym Chrome, zauważone o 11:40” jest pomocne. Jedna taka linijka może oszczędzić 3 pytania uzupełniające. Może też uchronić zespół wsparcia przed traceniem czasu na niewłaściwej stronie.

Utwórz szablon raz, a potem używaj go wszędzie. Wstaw go do formularza wsparcia, automatycznej odpowiedzi e-mail i wewnętrznych notatek. Jeśli ludzie mają za każdym razem pamiętać inny format, nie będą. Tutaj wygrywa prostota.

Zdecyduj, kiedy zamienić wsparcie w powtarzalny proces

Część prac po uruchomieniu nie powinna pozostać na zawsze ad hoc. Jeśli to samo zgłoszenie pojawia się 4 razy, zamień je w rutynę.

Powtarzalne zadania wsparcia obejmują często comiesięczne aktualizacje treści, okresowe sprawdzanie dostępów, regularne przeglądy wtyczek lub modułów oraz krótkie punkty kontrolne po nowych kampaniach. Jeśli zespół contentowy prosi co tydzień o ten sam proces podmiany obrazka, można z tego zrobić stałe przekazanie. Jeśli dostęp do konta wygasa co miesiąc, powinien być monitorowany przed terminem, a nie po tym, jak ktoś straci dostęp do panelu administracyjnego. Utrzymanie dostępu może brzmieć nudno, ale zapobiega niepotrzebnym przerwom.

Lekki proces nie potrzebuje dużej instrukcji. Potrzebuje kalendarza, checklisty i jednej osoby odpowiedzialnej. Checklistę mogą tworzyć tylko 5 punktów. Kalendarz może mieć 2 daty w miesiącu. To wystarczy, jeśli praca się powtarza. Większa struktura może stać się narzutem; mniejsza zwykle kończy się możliwymi do uniknięcia poprawkami.

To również moment, w którym wsparcie staje się łatwiejsze do zaplanowania budżetowo. Powtarzalny proces daje zespołowi sposób szacowania nakładu na podstawie rzeczywistych wzorców, a nie przypuszczeń. Jeśli chcesz porównać rytm wsparcia z szerszymi cyklami realizacji, pełny cykl tworzenia strony internetowej pokazuje, jak punkty przekazania wpływają później na obciążenie pracą.

Przejrzyj notatki z przekazania wsparcia po pierwszym miesiącu

Pierwszy miesiąc powinien zakończyć się przeglądem, a nie wzruszeniem ramion. Zapisz, co się powtarzało, czego brakowało i co trzeba zmienić przed następnym uruchomieniem. Taki przegląd powinien zawierać co najmniej 3 konkretne elementy: najczęstsze zgłoszenie, najbardziej mylący krok i najczęstsze opóźnienie. Jeśli nie zostaną zapisane, ten sam problem wróci przy kolejnym projekcie.

Notatki z przekazania powinny też pokazywać, gdzie zespół uruchamiający miał błędne założenia. Może zespół contentowy potrzebował 2 dodatkowych sesji szkoleniowych. Może klient oczekiwał, że edycje będą przechodziły przez jedną osobę akceptującą, ale zmian dokonywały 3 osoby. Może skrzynka wsparcia otrzymała 18 wiadomości, bo nikt nie znał ścieżki przyjmowania zgłoszeń. To nie są wstydliwe szczegóły; to są użyteczne informacje.

Przechowuj notatki tam, gdzie następny zespół naprawdę je znajdzie. Folder, którego nikt nie otwiera, jest tylko magazynem. Krótki dokument z nazwiskami, datami i prawdziwymi przykładami jest pamięcią wsparcia. Następnym razem, gdy ktoś zapyta, jak powinno działać wsparcie strony po uruchomieniu, odpowiedź będzie już w dokumentacji, a nie na spotkaniu zaczynającym od zera.