Informowanie klienta o naprawie błędu to ostatni krok, o którym zespoły najczęściej zapominają. Zadanie trafia do kolumny „Gotowe”, zespół przechodzi do kolejnych prac, a osoba, która opisała problem, nadal nie wie, czy może spróbować ponownie. Z jej perspektywy sprawa wygląda na porzuconą, nawet jeśli poprawka działa od tygodnia. Krótka wiadomość po sprawdzeniu wyniku zamyka tę lukę i pokazuje, że zgłoszenie miało sens.
Ten poradnik zaczyna się w chwili, gdy praca nad poprawką trwa albo właśnie się skończyła. Jak zamienić zgłoszenie w zadanie, opisuje poradnik od zgłoszenia do zadania. Tutaj ustalisz, jak nie zgubić zgłaszającego, kiedy wolno napisać „naprawione” i co wysłać, gdy poprawki nie będzie albo jeszcze jej nie ma.
Kiedy klient powinien dostać wiadomość o poprawce
Wiadomość wysyłasz wtedy, gdy zmiana jest dostępna dla klienta i ktoś sprawdził ją w warunkach podobnych do zgłoszenia. Nie wtedy, gdy programista scalił kod, ani wtedy, gdy zadanie zmieniło status. Te zdarzenia opisują postęp pracy zespołu, a klienta interesuje tylko to, czy jego czynność znów działa. Jeśli poprawka trafia do wszystkich dopiero przy kolejnym wydaniu, poczekaj na wydanie.
Dokumentacja GitHub opisuje, że zgłoszenie powiązane słowem kluczowym zamyka się automatycznie po scaleniu pull requestu do domyślnej gałęzi. To informacja o stanie repozytorium, a nie dowód, że poprawka działa już u klienta: GitHub: powiązanie pull requestu ze zgłoszeniem.
Klientowi należy się odpowiedź również wtedy, gdy wynik jest inny niż naprawa. Decyzja „nie naprawimy” albo „sprawdzimy ponownie w określonym terminie” jest informacją, na której może oprzeć własne plany. Cisza zmusza go do ponownego pytania i do zgadywania, czy ktoś w ogóle zajmuje się sprawą.
Zachowaj powiązanie zgłaszającego z zadaniem
Kontakt z klientem urywa się najczęściej przy przekazaniu sprawy. Obsługa tworzy zadanie, a zgłoszenie zostaje zamknięte jako „przekazane dalej”. Gdy kilka tygodni później praca się kończy, nikt nie pamięta, kto o nią prosił. Dlatego połączenie musi istnieć w zadaniu, a nie w pamięci jednej osoby. Gdy ten sam błąd zgłosi pięciu klientów, wszystkie pięć zgłoszeń powinno prowadzić do jednego zadania.
- Zadanie zawiera odnośnik do każdego zgłoszenia, którego dotyczy, także zgłoszeń dołączonych później.
- W zgłoszeniu jest notatka wewnętrzna z numerem zadania i imieniem osoby, która odpisze klientowi.
- Przy duplikatach dopisujesz nowego zgłaszającego do istniejącego zadania zamiast zamykać jego sprawę bez śladu.
- Zapisany jest cytat z pierwszej wiadomości klienta, aby odpowiedź mogła użyć jego słów.
Pole z cytatem łatwo dodać do opisu, jeśli korzystasz z szablonu zadania z błędu klienta. Rozdziel też role: właściciel zadania odpowiada za poprawkę, a właściciel kontaktu za wiadomość. Może to być ta sama osoba, ale wtedy zapisz to wprost.
Sprawdź poprawkę, zanim napiszesz „naprawione”
- Wróć do kroków ze zgłoszenia.Powtórz czynność klienta w środowisku, z którego korzysta: ta sama przeglądarka lub urządzenie, podobne dane, ten sam typ konta.
- Porównaj z oczekiwanym wynikiem.Sprawdź efekt, o który klientowi chodziło, a nie tylko zniknięcie komunikatu błędu.
- Ustal, czy klient musi coś zrobić.Odświeżenie strony, ponowne zalogowanie albo powtórzenie zamówienia trzeba wpisać do wiadomości.
- Zapisz wynik w zgłoszeniu.Notatka „sprawdzone 8.10 w Safari, zapis działa” pozwala innej osobie wysłać wiadomość bez ponownych testów.
Jeśli sprawdzenie się nie udało, nie wysyłaj wiadomości „powinno już działać”. Wróć do zadania. Szczegóły drugiej strony tego procesu, czyli prośby o potwierdzenie i decyzji o zamknięciu sprawy, opisuje poradnik o potwierdzeniu rozwiązania sprawy. Gdy zmiana dotyczy wielu klientów i całego zespołu obsługi, przydatne jest też przekazanie zmiany zespołowi obsługi.
Odpowiadaj słowami klienta, nie językiem zadania
Tytuł zadania jest napisany dla zespołu: zawiera nazwę komponentu, numer wersji albo skrót. Klient opisał problem inaczej i po tym opisie rozpozna swoją sprawę. Zacznij więc od jego sytuacji, a potem powiedz, co teraz zobaczy. Tabela pokazuje na fikcyjnych przykładach, jak przełożyć opis zadania na język klienta.
Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.
| Opis w zadaniu | Słowa klienta | Zdanie w wiadomości |
|---|---|---|
| Walidacja daty w formularzu zmiany terminu | Nie mogę przenieść wizyty na jutro | Przeniesienie wizyty na kolejny dzień znów działa |
| Błąd eksportu CSV przy polskich znakach | W pliku są krzaczki zamiast nazwisk | Nazwiska z polskimi literami eksportują się poprawnie |
| Regresja koszyka po zmianie kuponów | Kod rabatowy znika przy płatności | Kod rabatowy zostaje w koszyku aż do zapłaty |
Nie opisuj przyczyny technicznej, jeśli klient o nią nie pytał. Jedno zdanie wyjaśnienia wystarczy, gdy pomaga zrozumieć, czy problem może wrócić. Unikaj też przeprosin rozciągniętych na trzy akapity: konkretna informacja o zmianie jest lepszym zadośćuczynieniem niż długa formułka.
Trzy wzory: naprawione, nie naprawimy, jeszcze nie
Każdy wzór zawiera te same elementy: nawiązanie do zgłoszenia, stan sprawy, co klient może zrobić teraz i czy ktoś się jeszcze odezwie. Nawiasy kwadratowe zastąp konkretami przed wysłaniem.
„Dzień dobry, [data] pisał Pan, że [słowa klienta]. Poprawka jest już dostępna i sprawdziliśmy ją [na urządzeniu / w przeglądarce]: [co teraz działa]. Jeśli wcześniej strona była otwarta, wystarczy ją odświeżyć. Proszę dać znać w tej rozmowie, gdyby coś nadal wyglądało inaczej. Dziękuję za dokładny opis, bardzo pomógł”.
„Dzień dobry, wracam do Pani zgłoszenia o [słowa klienta]. Po sprawdzeniu zdecydowaliśmy, że nie zmienimy tego działania, ponieważ [krótki, prawdziwy powód]. Rozumiem, że to utrudnia [cel klienta]. Obecnie można [sprawdzone obejście]. Jeśli ta decyzja się zmieni, napiszę w tej samej sprawie”.
„Dzień dobry, problem z [słowa klienta] nadal czeka na poprawkę. Zespół ma go na liście prac, ale nie mogę dziś podać daty wdrożenia. Do tego czasu [obejście lub informacja, że go brak]. Sprawdzę stan prac [konkretna data] i odezwę się wtedy niezależnie od wyniku”.
W trzecim wzorze obietnicą jest data kontaktu, a nie data naprawy. Wpisz ją do kalendarza albo jako notatkę w zgłoszeniu i dotrzymaj. Jeżeli powodem odmowy jest decyzja produktowa, a nie trudność techniczna, sposób uzasadnienia rozwija poradnik o prośbach klientów i roadmapie.
Zasada dla starych zgłoszeń
Poprawka czasem przychodzi pół roku po zgłoszeniu. Klient mógł już zapomnieć o sprawie, zmienić narzędzie albo znaleźć własne obejście. Mimo to wiadomość ma sens, pod warunkiem że jest krótka i nie wymaga od niego odpowiedzi. Zacznij od przypomnienia, czego dotyczyło zgłoszenie, bo bez tego kontekstu wiadomość wygląda na spam.
Przyjmij jedną zasadę dla całego zespołu, na przykład: zgłoszenia sprzed ponad trzech miesięcy dostają jedną wiadomość informacyjną bez prośby o test, a sprawa zostaje zamknięta, jeśli klient nie odpisze. Nie pisz do osób, które wyraźnie zakończyły współpracę i nie chcą dalszego kontaktu. Gdy błąd był częścią szerszej awarii z wieloma zgłoszeniami, kolejność aktualizacji opisuje poradnik o komunikacji awarii z klientami.
Status sprawy widoczny dla klienta w Meetlead
W aplikacji Projekty zadanie można utworzyć ze zgłoszenia albo powiązać z nim istniejące zadanie, a jedno zadanie może mieć powiązanych kilka zgłoszeń. Z karty zadania wrócisz więc do każdej osoby, która opisała ten sam błąd. Notatki wewnętrzne w zgłoszeniu nie są widoczne dla klienta, więc możesz tam zapisać wynik sprawdzenia i osobę odpowiedzialną za wiadomość.
Gdy w witrynie działają trwałe zgłoszenia, klient widzi w widgecie listę swoich spraw z numerem, ostatnią wiadomością i statusem: otwarta, rozwiązana lub zamknięta. Odpowiedź wysłana w zgłoszeniu trafia do tej samej sprawy, a jeśli klient odpisze na rozwiązaną sprawę, zgłoszenie otwiera się ponownie. Zmiana statusu zadania nie wysyła klientowi żadnej wiadomości: treść piszesz sam. Projekty wymagają konta, aktywnej aplikacji w witrynie i dostępu w planie.
Pytania o domykanie zgłoszeń po poprawce
Czy trzeba prosić klienta o sprawdzenie poprawki? Nie zawsze. Jeśli sprawdziłeś wynik w jego warunkach, wystarczy informacja z zaproszeniem do odpisania, gdyby coś nadal nie działało. O test poproś wtedy, gdy nie możesz odtworzyć środowiska klienta, na przykład jego danych lub urządzenia.
Co zrobić, gdy poprawka naprawiła tylko część problemu? Napisz dokładnie, co już działa, a co nadal czeka, i potraktuj pozostałą część jak wzór „jeszcze nie” z datą kolejnego kontaktu. Nie zamykaj sprawy tylko dlatego, że zadanie w Projektach jest ukończone. Brakującą część zapisz jako osobne zadanie powiązane z tym samym zgłoszeniem.
