Podpis na protokole w aplikacji: jak zaprojektować obieg, który obroni się przed klientem i kontrolą
Podpis na ekranie telefonu wygląda na drobiazg: pole, palec, gotowe. W praktyce to moment, w którym treść protokołu zamienia się w dokument, za który ktoś odpowiada. Jeśli aplikacja pozwala podpisać wersję, którą biuro potem poprawi, albo edytować protokół po podpisie bez śladu — nie masz dowodu, tylko ładny PDF. Oto jak projektujemy obieg podpisów w systemie przeglądów ppoż. Safe-Pro i czego nauczył nas teren.
Zasada pierwsza: najpierw akceptacja, potem podpisy
Najczęstszy błąd projektowy, jaki widzimy w aplikacjach serwisowych: technik kończy przegląd, klient podpisuje na miejscu, a dopiero potem kierownik w biurze przegląda protokół i poprawia literówki, oceny albo listę usterek. Formalnie klient podpisał więc coś innego niż to, co dostaje w PDF-ie. Przy pierwszym sporze taki dokument jest wart niewiele.
We wrześniu 2026 przebudowaliśmy obieg w Safe-Pro według prostej reguły: podpisy technika i klienta stają się aktywne dopiero po akceptacji protokołu przez kierownika. Technik wysyła protokół do akceptacji w ostatnim kroku kreatora. Jeśli czegoś brakuje (zdjęcia, pomiaru, uwagi), system pokazuje listę braków i pozwala wysłać mimo to — ale tylko za świadomym potwierdzeniem, a kierownik widzi tę listę przy akceptacji.
| Etap | Kto | Co jest zablokowane |
|---|---|---|
| Wykonanie czynności, zdjęcia, usterki | technik | wysyłka bez podpisu technika |
| Wysłanie do akceptacji (z listą braków) | technik | edycja treści w czasie akceptacji |
| Akceptacja | kierownik | podpisy przed akceptacją |
| Podpis technika i klienta | technik + klient | zmiana treści bez ponownego otwarcia |
| PDF i wysyłka do klienta | system / biuro | — |
Trzy drogi do podpisu klienta
Klient nie zawsze stoi obok technika. Dlatego system obsługuje trzy ścieżki i każda z nich kończy się w tym samym miejscu — przy tym samym zamrożonym protokole:
- na miejscu, na telefonie technika — najczęstszy przypadek; to ten sam komponent podpisu co u technika, otwierany na cały ekran, żeby dało się złożyć czytelny podpis także w rękawiczkach roboczych
- przez link wysłany mailem — wyłącznie po akceptacji i wyłącznie przez biuro, nigdy przez technika; ponowne wysłanie przedłuża ważność tego samego linku zamiast mnożyć aktywne linki do jednego dokumentu
- papierowo — wydruk z podpisem technika, a po powrocie skan dołączany przez kierownika; protokół dostaje wtedy status podpisanego ze skanem, a system nie pozwala już nadpisać PDF-u wygenerowanego ponownie
Zmiana po podpisie: nigdy po cichu
Pomyłki się zdarzają — zła data, pominięta gaśnica, literówka w adresie. Pytanie nie brzmi „czy pozwolić poprawić”, tylko „co ma się stać z podpisem”. U nas kierownik może ponownie otworzyć zamrożony protokół, ale wtedy: podpis klienta jest unieważniany, aktywne linki do podpisu wygasają, protokół wraca do akceptacji, a powód otwarcia trafia do historii zadania razem z nazwiskiem osoby i datą. Klient podpisuje ponownie — już właściwą wersję.
Zakładka Historia przy każdym zadaniu pokazuje pełną oś zdarzeń: kto wysłał do akceptacji, kto zaakceptował, kto otworzył ponownie i dlaczego, kiedy wysłano link, kiedy wygenerowano PDF. To ona jest właściwym dowodem przy sporze, a nie sam obrazek podpisu.
Czego nauczył nas teren (a czego nie wyłapie żaden projekt)
- pusty podpis: przypadkowe dotknięcie zapisywało „podpis” bez kreski; dziś pusty obraz odrzuca baza danych, niezależnie od tego, co przepuści interfejs
- obrót telefonu: po obróceniu z pionu do poziomu kreska rysowała się obok palca, bo obszar rysowania pamiętał stare wymiary; naprawiliśmy przeliczanie po każdej zmianie rozmiaru i dopisaliśmy automatyczny test, który mierzy przesunięcie tuszu — dopuszczamy najwyżej 4 piksele
- tryb terenowy kierownika: kierownik, który sam jedzie na przegląd, nie musi akceptować własnej pracy, żeby zebrać podpis — w statusach roboczych może podpisywać od razu, bo jest właścicielem procesu
- zmęczenie klikaniem: kreator nie przeskakuje już automatycznie do następnego kroku po zaznaczeniu odpowiedzi; na małym ekranie auto-przejście powodowało więcej pomyłek, niż oszczędzało kliknięć
A co z mocą prawną?
Podpis złożony palcem na ekranie nie jest kwalifikowanym podpisem elektronicznym i nie udajemy, że jest. Ma wartość dowodową, a tę wartość buduje przede wszystkim otoczenie: niezmienność treści po podpisie, ślad zdarzeń, powiązanie z konkretnym zadaniem, osobą i czasem. Jeśli umowa z klientem wymaga podpisu kwalifikowanego, to osobna integracja z dostawcą zaufanym — do zrobienia, ale warto wiedzieć o tym przed startem projektu, a nie po nim.
Pytania kontrolne do wykonawcy
- czy klient może podpisać wersję protokołu, która potem zostanie zmieniona — i co się wtedy dzieje z podpisem
- gdzie egzekwowana jest kolejność obiegu: tylko w interfejsie czy także w bazie danych
- ile aktywnych linków do podpisu może istnieć dla jednego dokumentu i kto może je wysłać
- czy system zapisuje powód każdej zmiany po podpisie i kto go widzi
- czy podpis był testowany na prawdziwych telefonach po obrocie ekranu
Najczęstsze pytania
Czy podpis klienta na telefonie technika jest ważny?
Jest to podpis odręczny złożony w formie elektronicznej — nie kwalifikowany, ale z wartością dowodową. Tę wartość wzmacnia system: zamrożenie treści po podpisie, historia zdarzeń i powiązanie podpisu z konkretnym protokołem, osobą i czasem. W praktyce przeglądów i serwisu taka forma jest powszechnie stosowana; wymóg podpisu kwalifikowanego wynika zwykle z konkretnej umowy.
Dlaczego link do podpisu może wysłać tylko biuro, a nie technik?
Bo link wychodzi do klienta po akceptacji protokołu, a akceptacja to decyzja biura. Gdyby technik mógł wysłać link sam, klient mógłby podpisać wersję jeszcze niezatwierdzoną. Technik ma za to podpis na miejscu, który jest najczęstszą ścieżką.
Co jeśli klient podpisał, a w protokole jest błąd?
Kierownik ponownie otwiera protokół, podając powód. Podpis klienta zostaje unieważniony, linki wygasają, poprawiona wersja przechodzi akceptację i klient podpisuje ponownie. Obie wersje i powód zmiany zostają w historii zadania.