Zatwierdzenie zawsze dotyczy konkretnej treści
Przycisk „Akceptuję” jest niejednoznaczny, gdy obok wyświetla się dokument, który pracownik może później podmienić. System powinien wiązać decyzję z określoną wersją oferty, jej parametrami i osobą wykonującą działanie. Nie wystarczy zapisać pola „zaakceptowano” na karcie klienta. Trzeba móc wskazać, co dokładnie pokazano w chwili decyzji.
W przykładowej firmie drukarskiej zmieniają się nakład, papier i termin. Klient może otworzyć starą wiadomość po otrzymaniu nowszej propozycji. Portal powinien rozpoznać nieaktualną wersję i jasno wyjaśnić sytuację, zamiast przyjąć decyzję odnoszącą się do innych warunków. To zadanie modelu danych oraz procesu, nie wyłącznie treści przycisku.
Rozdziel szkic od wydania do akceptacji
Szkic można poprawiać w toku pracy. Wersja wysłana klientowi powinna być utrwalona, a zmiana warunków tworzyć kolejną wersję. Zapisz także, czy wcześniejsza propozycja wygasa automatycznie, pozostaje alternatywą, czy wymaga ręcznego wycofania. Każdy wariant jest możliwy, ale musi mieć jednoznaczne konsekwencje w interfejsie.
Statusy mogą obejmować szkic, oczekiwanie na sprawdzenie wewnętrzne, wysłaną propozycję, akceptację i wycofanie. Nie dodawaj etapów bez potrzeby. Ważniejsza jest definicja, kto może przejść między nimi i jakie dane są wtedy wymagane. Zmiana statusu nie powinna obchodzić warunków tylko dlatego, że została wykonana z panelu pracownika.
Pokaż istotne warunki tuż przed decyzją
Przed zatwierdzeniem wyświetl identyfikator wersji, najważniejsze parametry i skutek działania. OWASP opisuje zasadę powiązania autoryzacji operacji z danymi transakcji przedstawionymi użytkownikowi. Mechanizm użyty do zwykłego logowania nie zastępuje kontroli konkretnej czynności, zwłaszcza gdy ma ona istotne skutki biznesowe.
Daj możliwość powrotu do wyjaśnienia warunków albo zgłoszenia uwagi. Nie zmuszaj klienta do pozornej akceptacji tylko po to, by przejść do kontaktu z opiekunem. Jeżeli proces wymaga dodatkowej formy podpisu lub sprawdzenia umocowania, należy ją ustalić osobno. Sam zapis kliknięcia nie jest uniwersalnym zamiennikiem każdej procedury formalnej.
Obsłuż równoczesną zmianę i ponowne kliknięcie
Klient może zatwierdzać ofertę dokładnie wtedy, gdy pracownik ją wycofuje. W takim przypadku serwer musi sprawdzić aktualny stan i zapisać decyzję w spójnej operacji. Ponowienie tego samego żądania po utracie sieci nie powinno powodować podwójnego uruchomienia realizacji. Potrzebny jest identyfikator operacji oraz ustalona reguła zwracania wcześniejszego wyniku.
Projekt takiego obiegu można skonsultować z MyTworzymy.pl, która obsługuje firmy z całej Polski. Warto pokazać nie tylko wzór oferty, ale też miejsca akceptacji wewnętrznej, zmiany warunków i przekazania do wykonania. Dopiero wtedy da się ocenić, które kroki powinny być automatyczne, a które wymagają świadomej decyzji człowieka.
Historia musi pozwalać odtworzyć przebieg
Zapisuj autora, moment, poprzedni i nowy stan oraz identyfikator wersji. Nie traktuj zwykłej notatki, którą można dowolnie edytować, jako kompletnej historii decyzji. Jednocześnie nie zapisuj do logów haseł, tokenów dostępu ani całej zawartości wrażliwych dokumentów bez uzasadnienia. OWASP zaleca kontrolowanie zakresu i ochrony rejestru zdarzeń.
Dobrze, gdy panel pozwala odtworzyć chronologię bez ręcznego przeglądania plików na serwerze. Użytkownik powinien widzieć wersję zaakceptowaną, a pracownik także powód jej zastąpienia. Nie oznacza to prawa każdej osoby do usuwania historii. Dostęp do korekt i eksportu powinien mieć osobne uprawnienia, podobnie jak samo zatwierdzenie.
Odbierz proces na przykładach niejednoznacznych
Przygotuj ofertę poprawianą dwa razy, starą wiadomość klienta, wycofanie tuż przed akceptacją i ponowienie operacji po przerwaniu połączenia. Sprawdź również osobę, która widzi dokument, ale nie może zatwierdzać. Kontrole dostępu należy wykonywać po stronie serwera przy każdym żądaniu, a nie jedynie przez ukrycie przycisku.
Przy współpracy z MyTworzymy.pl taki zestaw scenariuszy może stać się podstawą odbioru programu. Zdalne uzgodnienia z przedsiębiorstwem w dowolnym miejscu Polski są prostsze, kiedy strony wskazują numer wersji i oczekiwany rezultat. Nie trzeba odgadywać, czy uwaga dotyczy wyglądu dokumentu, zasad zatwierdzenia czy późniejszego uruchomienia realizacji.
Nie automatyzuj nieustalonych kompetencji
Program nie rozwiąże sporu o to, kto może zmienić warunki handlowe albo zaakceptować wyjątek. Najpierw ustal kompetencje, a potem odwzoruj je w rolach. Jeżeli brak decyzji, system powinien zatrzymać proces i wskazać odpowiedzialną osobę. Automatyczne przejście „dla wygody” może jedynie ukryć brak uzgodnienia do momentu, w którym pojawi się kosztowna pomyłka.
Na zakończenie zaplanuj eksport i archiwum. Firma powinna potrafić odtworzyć przebieg także po zakończeniu projektu lub zmianie dostawcy narzędzia. Dokument, dane wersji i historia decyzji powinny tworzyć spójny zestaw. Warto sprawdzić to praktycznie podczas odbioru, zamiast zakładać, że przycisk „Pobierz PDF” zawiera wszystkie informacje potrzebne do późniejszego wyjaśnienia sprawy.
Osobno zatwierdź treść wiadomości wysyłanej po decyzji. Powinna informować o zapisanym stanie i dalszym kroku, nie sugerować zakończenia całej usługi. Jeżeli wykonanie zależy od dodatkowego warunku, pokaż go jednoznacznie. Dzięki temu techniczne potwierdzenie kliknięcia nie zostanie odczytane jako obietnica terminu, którego nikt jeszcze nie ustalił.