Po wdrożeniu strony wykonawca powinien przekazać firmie nie tylko link do działającej witryny, ale cały pakiet odbiorowy: dostępy, instrukcję obsługi, backup, informacje o hostingu i domenie, CMS lub repozytorium, listę funkcji, zasady gwarancji oraz sposób zgłaszania poprawek. Jeśli w dniu startu wchodzi w grę podpięcie domeny, potraktuj je jako osobny punkt odbioru, bo błąd w DNS, SSL albo poczcie może zablokować stronę mimo poprawnego projektu.
Najprostsza zasada jest taka: odbiór strony kończy się dopiero wtedy, gdy firma może stronę utrzymać, odtworzyć po awarii, zgłosić błąd i rozwijać ją bez zgadywania, kto ma dostęp do czego. Samo zdanie "strona działa" nie zamyka projektu, jeżeli nie wiadomo, gdzie jest hosting, kto odnawia domenę, jak wejść do panelu, gdzie jest kopia zapasowa i co faktycznie obejmuje gwarancja.
Przy tworzeniu strony internetowej najwięcej problemów po starcie wynika z niedopowiedzeń. Strona wygląda dobrze, ale formularz wysyła wiadomości na zły adres. Klient ma login do CMS, ale nie ma dostępu administracyjnego. Domena jest podpięta, ale zarejestrowana na prywatne konto wykonawcy. Backup "jest", ale nikt nie wie, gdzie i jak go odtworzyć. Właśnie dlatego przekazanie projektu powinno mieć formę krótkiej checklisty, a nie luźnej rozmowy na koniec.
Werdykt w 30 sekund
- Odbierz projekt, jeśli masz konto administracyjne, kontrolę nad domeną i hostingiem, instrukcję obsługi, kopię zapasową, listę funkcji oraz jasne zasady zgłaszania poprawek.
- Doprecyzuj przed zamknięciem, jeśli brakuje jednej instrukcji, listy odbiorców formularza, informacji o odnowieniu hostingu albo formatu zgłoszeń.
- Wstrzymaj odbiór, jeśli nie działa formularz, nie masz dostępu do CMS lub hostingu, domena nie jest pod kontrolą firmy, nie ma backupu albo gwarancja jest tylko ustną obietnicą.
- Nie mieszaj błędu z rozwojem: naprawa ustalonej funkcji to co innego niż dodanie nowej podstrony, integracji albo zmiana zaakceptowanego układu.
Co wykonawca powinien przekazać w 30 sekund
Pakiet przekazania powinien odpowiadać na jedno praktyczne pytanie: czy firma jest w stanie zarządzać stroną po zakończeniu projektu. Jeśli odpowiedź brzmi "tylko wykonawca wie", odbiór jest niepełny.
| Element przekazania | Po co jest potrzebny | Co sprawdzić przed odbiorem |
|---|---|---|
| Dostępy administracyjne | Żeby firma miała kontrolę nad stroną i usługami | Czy konto ma właściwe uprawnienia, a nie tylko dostęp redaktora |
| Instrukcja obsługi | Żeby dało się wykonać proste zmiany bez każdorazowej pomocy | Czy opisuje realny CMS, formularze, media i ograniczenia |
| Backup startowy | Żeby mieć punkt odtworzenia po wdrożeniu | Czy obejmuje pliki, bazę danych i media, jeśli technologia tego wymaga |
| Hosting i domena | Żeby utrzymać stronę online i pilnować odnowień | Kto jest właścicielem usług, gdzie są panele i kto ma DNS |
| CMS lub repozytorium | Żeby edytować stronę albo rozwijać kod | Czy wiadomo, co przekazano: panel, kod, repo, zależności, licencje |
| Lista funkcji | Żeby wiedzieć, co zostało wdrożone i jak działa | Czy opisuje formularze, powiadomienia, role, integracje i elementy edytowalne |
| Gwarancja i poprawki | Żeby nie spierać się po starcie o zakres | Czy jest jasne, co jest błędem, co poprawką, a co nową pracą |
| Kanał zgłoszeń | Żeby błędy nie ginęły w komunikatorach | Czy wiadomo, gdzie zgłaszać, co podać i jak potwierdzać zamknięcie |
Ta tabela nie zastępuje umowy ani protokołu odbioru. Ma pomóc sprawdzić, czy po publikacji strona zostaje realnym narzędziem firmy, a nie projektem zależnym od jednej osoby.
Szybka decyzja: jeśli wykonawca przekazał adres strony, ale nie przekazał dostępu, instrukcji, backupu i zasad poprawek, projekt nie jest domknięty operacyjnie. Może być online, ale firma nie ma jeszcze kontroli nad tym, co kupiła.
Dostępy: co ma być pod kontrolą firmy
Dostęp do strony nie oznacza jednego loginu. Po wdrożeniu trzeba rozdzielić kilka obszarów: panel strony, hosting, domenę, pocztę, bazę danych, analitykę, formularze i integracje. Każdy z nich może być potrzebny w innym momencie.
Najbezpieczniej poprosić wykonawcę o listę kont i uprawnień, a nie o paczkę haseł w wiadomości. Lista powinna pokazywać, gdzie znajduje się usługa, kto jest właścicielem konta, jakie uprawnienia ma firma i do czego służy dany dostęp. Same dane logowania warto przekazywać kontrolowanym kanałem, tak żeby później można było zmienić hasła, odebrać dostęp zewnętrzny i sprawdzić, kto ma aktywne konto.
| Dostęp | Minimalne pytanie przy odbiorze | Czerwona flaga |
|---|---|---|
| CMS lub panel strony | Czy firma ma konto administratora albo właściciela? | Klient ma tylko konto redaktora, a administrator zostaje u wykonawcy |
| Hosting | Gdzie jest panel i kto opłaca usługę? | Hosting jest na prywatnym koncie wykonawcy bez zasad przeniesienia |
| Domena i DNS | Kto jest abonentem domeny i kto zarządza rekordami? | Firma nie wie, gdzie odnawia domenę ani kto zmienia DNS |
| Poczta w domenie | Czy publikacja strony nie naruszyła działania skrzynek? | Nikt nie sprawdził rekordów poczty po zmianach |
| Baza danych, FTP lub SSH | Czy dostęp jest potrzebny i kto go ma? | Nie wiadomo, jak dostać się do plików lub bazy w razie awarii |
| Analityka i Search Console | Kto jest właścicielem kont i danych? | Konta są założone na prywatny adres wykonawcy |
| Formularze i integracje | Dokąd trafiają zgłoszenia i kto zarządza połączeniami? | Formularz działa, ale nikt nie zna odbiorcy ani ustawień powiadomień |
Nie zawsze każdy dostęp musi być codziennie używany przez klienta. Nie każdy właściciel strony będzie logował się do SSH albo bazy danych. Chodzi o to, żeby firma wiedziała, że dostęp istnieje, kto za niego odpowiada i jak odzyskać kontrolę, jeśli wykonawca przestanie obsługiwać projekt.
Przy dostępach warto też uporządkować role. Inne uprawnienia powinien mieć właściciel strony, inne redaktor treści, inne osoba techniczna, a jeszcze inne zewnętrzny wykonawca w czasie poprawek. Wspólne konto "admin" używane przez wszystkich jest wygodne tylko do pierwszego problemu z bezpieczeństwem i odpowiedzialnością.
Czerwona flaga: domena, hosting, CMS, analityka albo narzędzia formularzy są założone na prywatny adres wykonawcy, a firma nie ma jasnej ścieżki przeniesienia. Taki układ może działać przez jakiś czas, ale utrudnia zmianę wykonawcy, odzyskanie dostępu i kontrolę kosztów.
Instrukcja obsługi i lista funkcji
Instrukcja po wdrożeniu nie musi być długim podręcznikiem. Ma odpowiadać na pytania, które pojawią się przy normalnym używaniu strony: jak edytować tekst, jak podmienić zdjęcie, jak dodać wpis, jak sprawdzić formularz, jak zmienić odbiorcę wiadomości i czego lepiej nie ruszać bez wsparcia technicznego.
Jeżeli strona ma CMS, instrukcja powinna dotyczyć tego konkretnego wdrożenia, a nie ogólnego panelu znalezionego w internecie. Ten sam system może mieć różne role, moduły, ograniczenia i miejsca edycji. Klient potrzebuje wiedzieć, co faktycznie może zmienić w swojej stronie.
| Obszar instrukcji | Co powinno być opisane | Dlaczego to ważne |
|---|---|---|
| Edycja treści | Teksty, nagłówki, przyciski, zdjęcia, pliki do pobrania | Firma może poprawić podstawowe informacje bez czekania na wykonawcę |
| Menu i podstrony | Kto może dodawać, ukrywać i zmieniać kolejność stron | Nie każda zmiana struktury jest bezpieczna dla użytkownika i SEO |
| Formularze | Pola, odbiorcy, komunikaty, zgody, test wysyłki | Formularz jest często główną ścieżką kontaktu |
| Blog lub aktualności | Dodawanie wpisów, kategorii, zdjęć i linków wewnętrznych | Publikacja treści nie powinna wymagać pracy programisty |
| Sklep lub katalog | Produkty, ceny, warianty, stany, pliki i zdjęcia | Błąd w edycji może wpływać bezpośrednio na sprzedaż |
| Role użytkowników | Kto jest administratorem, redaktorem, operatorem lub tylko obserwatorem | Ogranicza ryzyko przypadkowych zmian |
| Ograniczenia | Czego nie edytować samodzielnie | Chroni układ, formularze, integracje i elementy techniczne |
Osobno poproś o listę funkcji wdrożonych na stronie. Nie musi to być dokument techniczny pisany dla programisty. Wystarczy praktyczna tabela: nazwa funkcji, gdzie działa, co robi, kto może ją edytować i jaki jest efekt dla użytkownika.
Lista funkcji powinna obejmować między innymi formularze, powiadomienia e-mail, zgody, wyszukiwarkę, wersje językowe, blog, sklep, role użytkowników, integracje, analitykę, mapy, pliki do pobrania i automatyczne komunikaty. Jeśli coś jest ważne dla działania strony, nie powinno istnieć tylko "w głowie" wykonawcy.
Jeżeli lista funkcji obejmuje formularze, telefony, CTA i analitykę, od razu ustal też, jak po starcie będzie wyglądać mierzenie zapytań z nowej strony internetowej. Bez tego łatwo odebrać działającą stronę, ale później nie wiedzieć, czy faktycznie przynosi wartościowe kontakty.
Praktyczny wniosek: instrukcja ma zmniejszać zależność od wykonawcy przy prostych zmianach. Jeśli po odbiorze każda korekta numeru telefonu, zdjęcia albo treści wymaga zgłoszenia technicznego, warto sprawdzić, czy CMS rzeczywiście spełnia ustalony cel.
Backup, repozytorium i pliki projektu
Kopia zapasowa po wdrożeniu to punkt odniesienia. Pokazuje, jaki stan strony został przekazany w dniu odbioru i co można odtworzyć, jeśli aktualizacja, błąd użytkownika, awaria hostingu albo infekcja uszkodzi serwis.
W zależności od technologii backup powinien obejmować pliki strony, bazę danych, katalog mediów, konfigurację środowiska i inne elementy potrzebne do odtworzenia działania. Przy prostych rozwiązaniach część tego może obsługiwać platforma lub hosting, ale nadal trzeba wiedzieć, gdzie jest kopia, z jakiego dnia pochodzi i kto odpowiada za jej odtworzenie.
| Element | Co ustalić | Czerwona flaga |
|---|---|---|
| Backup startowy | Czy istnieje kopia stanu po wdrożeniu | "Backup robi się automatycznie", ale nikt nie wie gdzie |
| Zakres backupu | Czy obejmuje pliki, bazę danych i media | Kopia zawiera tylko pliki, a strona działa na bazie danych |
| Miejsce przechowywania | Gdzie leży kopia i kto ma do niej dostęp | Kopia jest wyłącznie na tym samym koncie, które może ulec awarii |
| Odtworzenie | Kto przywraca stronę i w jakim trybie | Nie ma procedury ani osoby odpowiedzialnej |
| Kolejne kopie | Czy po odbiorze backupy będą cykliczne | Po publikacji istnieje tylko jednorazowa kopia startowa |
Repozytorium jest szczególnie ważne przy stronie z kodem custom, własnymi komponentami, procesem deployu, integracjami albo planowanym rozwojem przez innego wykonawcę. Wtedy warto poprosić o dostęp do repo, opis gałęzi, sposób wdrażania zmian, listę zależności i informację, które elementy są autorskie, a które pochodzą z zewnętrznych bibliotek, szablonów lub wtyczek.
Przy prostszych stronach CMS może być wystarczającym miejscem codziennej pracy, jeśli firma ma pełne konto administracyjne, backup i jasną informację o ograniczeniach. To nie znaczy jednak, że temat plików, licencji i kopii znika. Trzeba wiedzieć, co dokładnie kupiono i co można przekazać kolejnemu wykonawcy.
Kwestie praw do kodu, layoutu, grafik, zdjęć, fontów, wtyczek i komponentów zewnętrznych powinny wynikać z umowy, licencji albo protokołu przekazania. Nie warto zakładać, że wszystko automatycznie przechodzi na klienta w takim samym zakresie. To nie jest miejsce na interpretację prawną na oko, tylko punkt do pisemnego potwierdzenia przed zamknięciem projektu.
Czerwona flaga: wykonawca mówi, że "wszystko jest na serwerze", ale nie przekazuje backupu, repozytorium przy kodzie custom ani informacji, jak odtworzyć stronę po awarii. Taki projekt może działać dziś, ale jest trudny do utrzymania jutro.
Hosting, domena i podpięcie po starcie
Hosting i domena często wychodzą dopiero na końcu projektu, a powinny być częścią odbioru. Strona może wyglądać poprawnie na wersji testowej, ale publikacja nadal może utknąć na DNS, SSL, poczcie, odnowieniu usług albo braku dostępu do panelu.
Przy odbiorze sprawdź nie tylko to, czy adres otwiera stronę. Sprawdź, kto jest właścicielem domeny, gdzie zarządza się DNS, gdzie jest hosting, kto pilnuje odnowień, czy działa SSL, czy wybrano jedną wersję adresu z www lub bez www oraz czy poczta w domenie nie została naruszona.
| Obszar | Co powinno być jasne po wdrożeniu | Kiedy reagować |
|---|---|---|
| Domena | Abonent, panel, termin odnowienia, osoba odpowiedzialna | Firma nie wie, gdzie domena jest zarejestrowana |
| DNS | Kto zarządza rekordami i gdzie jest aktywna strefa | Zmiany są robione w panelu, który nie steruje domeną |
| Hosting | Dostawca, panel, parametry, dostęp administracyjny | Klient nie ma żadnej kontroli nad serwerem |
| SSL | Czy strona działa po HTTPS bez ostrzeżeń | Certyfikat nie obejmuje właściwej wersji adresu |
www lub bez www |
Jedna wersja jest główna, druga przekierowuje | Obie wersje działają osobno albo pokazują różną treść |
| Poczta | Rekordy mailowe nie zostały usunięte przy publikacji | Po zmianie strony przestają działać skrzynki |
| Odnowienia | Kto płaci i kto pilnuje terminów | Domena lub hosting mogą wygasnąć bez ostrzeżenia po stronie firmy |
Jeżeli wykonawca obsługuje hosting w ramach opieki, to może być wygodne rozwiązanie, ale nadal powinno być opisane. Firma powinna wiedzieć, co jest w pakiecie, co jest osobnym kosztem, jak wygląda dostęp w razie zmiany wykonawcy i kto reaguje na awarie.
Szczególnie uważaj na pocztę. Zmiana DNS przy publikacji strony nie powinna przypadkiem usunąć rekordów odpowiedzialnych za skrzynki, autoryzację maila lub narzędzia firmowe. Jeżeli strona i poczta są u różnych dostawców, ten punkt trzeba sprawdzić przed uznaniem wdrożenia za zakończone.
Praktyczny wniosek: strona jest naprawdę przekazana dopiero wtedy, gdy firma wie, gdzie jest domena, kto steruje DNS, gdzie działa hosting, jak działa SSL, kto pilnuje odnowień i co zrobić, jeśli coś przestanie działać.
Gwarancja, poprawki i sposób zgłaszania błędów
Gwarancja na stronę nie powinna być zdaniem "jak coś będzie, proszę pisać". Po wdrożeniu trzeba ustalić, co jest błędem wykonawcy, co jest drobną poprawką, co jest zmianą treści, a co nowym zakresem prac. Bez tego po starcie łatwo o spór, czy dana rzecz powinna być naprawiona w ramach odbioru, czy wyceniona osobno.
Nie ma jednej uniwersalnej długości gwarancji ani jednego czasu reakcji, który można wpisać do każdego projektu. Te wartości powinny wynikać z oferty, umowy, regulaminu współpracy albo protokołu odbioru. Ważne, żeby były zapisane, a nie zostawione jako domysł po stronie klienta i wykonawcy.
| Sytuacja | Jak ją traktować | Co ustalić przed odbiorem |
|---|---|---|
| Formularz nie wysyła wiadomości mimo ustaleń | Błąd do naprawy | Kto naprawia i jak potwierdza test |
| Literówka w zaakceptowanym tekście | Poprawka treści | Czy drobne korekty są w pakiecie po odbiorze |
| Zmiana koloru przycisku po akceptacji projektu | Zmiana estetyczna | Czy mieści się w rundzie poprawek |
| Dodanie nowej podstrony | Nowy zakres | Jak wygląda wycena i termin |
| Integracja z dodatkowym narzędziem | Nowy zakres lub osobny etap | Jakie dane i dostępy są potrzebne |
| Błąd po aktualizacji wtyczki lub systemu | Zależnie od umowy opieki | Kto odpowiada za utrzymanie po starcie |
Kanał zgłoszeń też powinien być konkretny. Może to być e-mail, system zgłoszeniowy albo ustalony kontakt techniczny, ale zgłoszenie powinno zawierać minimum: adres URL, opis problemu, oczekiwane działanie, zrzut ekranu, urządzenie lub przeglądarkę, jeżeli błąd dotyczy wyglądu lub działania.
Warto też ustalić sposób zamykania zgłoszeń. Naprawa formularza powinna kończyć się testem wysyłki. Poprawka widoku mobilnego powinna być sprawdzona na realnym ekranie. Zmiana tekstu powinna być zatwierdzona przez osobę odpowiedzialną po stronie firmy.
Czerwona flaga: wykonawca nie rozróżnia błędów, poprawek i nowych funkcji, a jednocześnie nie wskazuje kanału zgłoszeń. W takiej sytuacji każde zgłoszenie po starcie może stać się negocjacją od zera.
Protokół odbioru: kiedy podpisać, a kiedy wrócić z listą braków
Protokół odbioru nie musi być rozbudowanym dokumentem. Ma potwierdzać, że strona działa, a firma dostała pakiet potrzebny do utrzymania projektu. Najważniejsze jest rozdzielenie trzech decyzji: odbierz, doprecyzuj albo wstrzymaj.
Jeśli protokół ma objąć nie tylko przekazanie dostępów, ale też testy działania przed startem, osobnym filtrem jest to, co sprawdzić przed publikacją nowej strony firmowej: formularze, mobile, SSL, indeksację, zgody, analitykę i podstawową dostępność.
| Obszar odbioru | Dowód przekazania | Decyzja |
|---|---|---|
| Strona publiczna | Adres działa, HTTPS nie pokazuje ostrzeżeń, wersja główna jest jasna | Odbierz, jeśli podstawowe ścieżki działają |
| Formularze | Testowe zgłoszenie dochodzi do właściwej skrzynki | Wstrzymaj, jeśli wiadomość nie dochodzi |
| CMS | Firma ma konto administracyjne i instrukcję | Doprecyzuj lub wstrzymaj, jeśli dostęp jest zbyt ograniczony |
| Dostępy techniczne | Lista paneli, kont i odpowiedzialności | Wstrzymaj przy braku kontroli nad domeną lub hostingiem |
| Backup | Kopia startowa i opis odtworzenia | Wstrzymaj, jeśli nie ma kopii ani procedury |
| Repozytorium lub kod | Dostęp do repo, opis deployu i zależności przy projekcie custom | Doprecyzuj, jeśli projekt będzie rozwijany technicznie |
| Lista funkcji | Spis wdrożonych elementów i ich działania | Doprecyzuj, jeśli funkcje są opisane tylko ustnie |
| Gwarancja i poprawki | Zasady zakresu, kanału zgłoszeń i potwierdzania napraw | Wstrzymaj, jeśli nie wiadomo, jak zgłaszać błędy |
| Licencje i materiały | Informacja o zdjęciach, fontach, wtyczkach, szablonach i prawach | Doprecyzuj w umowie lub protokole |
Jeśli przy odbiorze są braki, nie rozrzucaj ich po kilku wiadomościach. Zrób jedną listę z priorytetami: blokuje odbiór, do uzupełnienia przed startem kampanii, do dopracowania po publikacji. Taki podział ułatwia decyzję, bo nie każda drobna korekta musi zatrzymać projekt, ale nie każdy brak można nazwać kosmetyką.
Blokerami odbioru są zwykle te elementy, które odbierają firmie kontrolę albo uniemożliwiają działanie strony: niedziałający formularz, brak konta administracyjnego, brak dostępu do domeny lub hostingu, brak backupu, niejasne zasady DNS i poczty, brak sposobu zgłaszania poprawek oraz brak informacji, kto odpowiada za awarie po starcie.
Rzeczy do doprecyzowania to na przykład instrukcja do jednej funkcji, lista odbiorców formularza, dokładny format zgłoszeń, informacja o odnowieniu hostingu albo rozpisanie, które elementy CMS można edytować samodzielnie. Te braki nie zawsze blokują publikację, ale powinny być zamknięte zanim projekt zniknie z bieżącej komunikacji.
Decyzja końcowa: podpisz odbiór dopiero wtedy, gdy potwierdzasz nie tylko wygląd strony, ale też dostęp, dokumentację, backup, techniczne utrzymanie i zasady poprawek. Dobrze przekazana strona nie kończy się na publikacji. Kończy się wtedy, gdy firma wie, co dostała, jak tego używać i co zrobić, gdy coś przestanie działać.