Protokół odbioru strony internetowej zamyka projekt w sposób, do którego obie strony mogą wrócić. Składa się z trzech części: listy kontrolnej sprawdzonej z uzgodnionego zakresu, listy usterek z priorytetem i terminem oraz decyzji o odbiorze potwierdzonej przez klienta. Bez tego dokumentu „start strony” oznacza dla każdego coś innego. Wykonawca uważa, że skończył, a klient po tygodniu odkrywa, że nie ma dostępu do domeny.

Ten poradnik dotyczy jednego momentu: przekazania gotowej strony. Uwagi do projektu graficznego porządkuje osobny tekst o rundach poprawek, a stałą opiekę po starcie opisuje poradnik o zgłoszeniach po wdrożeniu strony. Przykłady dotyczą fikcyjnego studia przekazującego stronę fikcyjnemu gabinetowi fizjoterapii.

Co zawiera protokół odbioru strony

Protokół nie musi być długi. Ma odpowiedzieć na trzy pytania: co sprawdziliście, co jeszcze nie działa i czy klient przyjmuje stronę. Każda część ma innego właściciela, dlatego dobrze rozdzielić je już w szablonie.

Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.

CzęśćCo zawieraKto potwierdza
Lista kontrolnaPozycje z zakresu z wynikiem: spełnione, niespełnione, nie dotyczyWykonawca sprawdza, klient może powtórzyć próbę
UsterkiOpis, priorytet, termin poprawki i osoba odpowiedzialnaWykonawca przyjmuje, klient zgłasza i weryfikuje
DecyzjaOdbiór bez uwag, odbiór z usterkami albo odmowa z powodemWskazana osoba po stronie klienta

Do protokołu dopisz datę, wersję strony, którą sprawdzaliście, oraz adres, pod którym była dostępna. Wynik z wersji testowej nie przenosi się automatycznie na publiczną domenę, więc ważne pozycje sprawdź po publikacji jeszcze raz.

Lista kontrolna wynika z zakresu, nie z szablonu

Gotowe listy z internetu mają po kilkadziesiąt punktów, z których połowa nie dotyczy twojego projektu. Zacznij od oferty lub umowy i zamień każdy uzgodniony element w sprawdzalny warunek. Jeśli formularz kontaktowy był w zakresie, pozycja brzmi „wiadomość z formularza dociera na adres gabinetu”, a nie „formularz jest”. Poniższe pozycje pojawiają się prawie w każdym projekcie małej firmy.

  • Dostępy i konta: domena, hosting, panel strony i narzędzia pomiaru są na kontach klienta albo klient ma w nich rolę właściciela.
  • Pliki: kopia zapasowa, źródłowe grafiki, logo i zdjęcia przekazane w uzgodnionym miejscu.
  • Instrukcja edycji: krótki opis, jak zmienić tekst, zdjęcie i godziny otwarcia, sprawdzony przez osobę klienta.
  • Formularze: każda wysłana próbna wiadomość dociera do właściwej skrzynki, a osoba wysyłająca widzi potwierdzenie.
  • Kontakt i czat: numer telefonu klika się na telefonie, adres e-mail jest poprawny, okno czatu otwiera się i wiadomość trafia do zespołu.
  • Pomiar: kod analityki lub widgetu jest zainstalowany, a testowa wizyta pojawia się w panelu.
  • Wersja mobilna: najważniejsze podstrony i formularz sprawdzone na telefonie, bez uciętego tekstu i nachodzących elementów.

Każdą pozycję zapisz tak, by dwie osoby oceniły ją tak samo. Jak budować taki warunek z kontekstu i obserwacji, pokazuje poradnik o kryteriach odbioru zadania. Jeśli klient przy odbiorze prosi o coś spoza zakresu, zapisz to osobno jako nową prośbę, nie jako niespełnioną pozycję.

Dostępy przekazuj zaproszeniem, nie hasłem na czacie

Częsty problem po latach to strona, której domena albo konto analityki należy do byłego wykonawcy. Najbezpieczniej, gdy klient zakłada konta na własny adres firmowy, a wykonawcę zaprasza jako użytkownika. Wtedy przy odbiorze nie trzeba przekazywać żadnego hasła, wystarczy zmienić lub odebrać rolę. Nie wysyłaj haseł w mailu ani na czacie; jeśli jakieś konto musiało powstać po twojej stronie, przekaż je przez menedżer haseł klienta i poproś o zmianę hasła po przejęciu.

Pomoc Google Search Console opisuje właścicieli zweryfikowanych i delegowanych, podaje, że usługa musi mieć co najmniej jednego zweryfikowanego właściciela, i ostrzega, że usunięty właściciel może ponownie potwierdzić własność, dopóki jego token weryfikacyjny zostaje na stronie. Przy przejmowaniu witryny trzeba więc usunąć też tokeny poprzednich właścicieli. Źródło dotyczy tylko tego narzędzia, nie domeny ani hostingu: Zarządzanie właścicielami i użytkownikami w Search Console.

W protokole wypisz konta w tabeli: narzędzie, właściciel, role wykonawcy po odbiorze i data sprawdzenia. Wpisz same nazwy kont i ról, nigdy hasła. Klient powinien po odbiorze sam zalogować się do każdego z nich, zanim podpisze decyzję.

Usterki zapisuj jako zadania z priorytetem i terminem

Usterka to pozycja z listy kontrolnej, która nie przeszła próby. „Coś jest nie tak z kontaktem” nie da się poprawić; „na telefonie przycisk wysyłki formularza jest zasłonięty przez baner cookies” już tak. Każda usterka dostaje osobne zadanie, żeby jej status był widoczny niezależnie od pozostałych.

  1. Opisz objaw.Podaj stronę, urządzenie, wykonaną czynność i to, co się stało zamiast oczekiwanego wyniku.
  2. Nadaj priorytet.Oddziel usterki blokujące start, np. niedziałający formularz, od takich, które mogą poczekać, np. odstęp pod zdjęciem.
  3. Ustal termin i osobę.Przy każdej usterce zapisz datę poprawki i jedną osobę odpowiedzialną po stronie wykonawcy.
  4. Zamknij po sprawdzeniu.Usterka jest usunięta dopiero wtedy, gdy ktoś powtórzył próbę i zapisał wynik, nie gdy autor oznaczył ją jako gotową.

Kolejność poprawek ustalaj według wpływu na klienta, a nie według tego, co najszybciej zrobić; pomaga w tym rozróżnienie priorytetu i ważności błędu. Przy zamykaniu zapisz krótki dowód wykonania zadania: wersję, urządzenie i obserwowany wynik. W Projektach Meetlead usterka może być zadaniem lub błędem z priorytetem, opiekunem, statusem i komentarzami; termin wpisz w opisie zadania.

Decyzja o odbiorze potwierdzona przez klienta

Decyzja ma trzy możliwe warianty: odbiór bez uwag, odbiór z listą usterek do usunięcia w terminie albo odmowa z podaniem pozycji, które nie przeszły. Drugi wariant jest najczęstszy i pozwala uruchomić stronę, gdy zostały drobiazgi. Potwierdzenie powinno przyjść od osoby wskazanej przez klienta, w kanale, który da się później odnaleźć.

Wzór wiadomości z prośbą o decyzję

„W załączeniu protokół odbioru strony w wersji z [data]. Wszystkie pozycje listy kontrolnej przeszły próbę poza dwiema usterkami: [usterka 1] z terminem [data] i [usterka 2] z terminem [data]. Prosimy o odpowiedź do [dzień]: odbiór bez uwag, odbiór z tymi usterkami albo lista pozycji, które Pani zdaniem nie zostały spełnione.”

Skutki odbioru, takie jak płatność końcowa czy przeniesienie praw do projektu, określa umowa. Ten tekst nie jest poradą prawną; jeśli umowa ich nie reguluje, ustal je z prawnikiem przed startem. Nie zakładaj z góry, co oznacza milczenie klienta: w niektórych systemach prawnych, na przykład w niemieckim prawie umowy o dzieło (§ 640 ust. 2 BGB), brak odmowy w wyznaczonym terminie może skutkować uznaniem dzieła za odebrane, więc sprawdź umowę i prawo, któremu podlega.

Kto obsługuje co po starcie i przegląd po 30 dniach

Ostatnia część protokołu to podział ról. Wpisz właściciela strony po stronie klienta, osobę odpowiadającą na wiadomości z formularza i czatu oraz kanał, którym klient zgłasza problemy po odbiorze. Zasady tej opieki, typy zgłoszeń i czasy reakcji opisuje osobny poradnik; w protokole wystarczy jedno zdanie z nazwą kanału.

Umów przegląd po około 30 dniach. Sprawdź wtedy, czy z formularza i czatu przychodzą realne wiadomości, i porównaj dane z okresem przed startem, jeśli strona zastąpiła starą; na co uważać, wyjaśnia tekst o przebudowie strony a pomiarze. Gdy na stronie działa widget Meetlead, mapy ciepła i nagrania sesji w planie, który je obejmuje, pokażą, czy odwiedzający docierają do formularza i ścieżek kontaktu. Uwagi z przeglądu zgłaszaj tym samym kanałem co inne sprawy po odbiorze.

Pytania o odbiór strony

Czy drobna usterka blokuje odbiór? Zwykle nie. Jeśli nie przeszkadza w kontakcie ani nie wprowadza w błąd, wpisz ją do protokołu z terminem i wybierz odbiór z usterkami. Blokujące są pozycje, bez których strona nie spełnia swojej roli, na przykład niedziałający formularz albo brak dostępu klienta do domeny.

Co, jeśli klient zgłasza usterkę miesiąc po odbiorze? Porównaj ją z listą kontrolną i wersją, którą sprawdzaliście. Jeśli pozycja była w zakresie i przestała działać, to poprawka w ramach ustaleń z umowy. Jeśli to nowe oczekiwanie, potraktuj je jako zmianę i oceń osobno, bez cichego dopisywania do starego protokołu.