Portal klienta kancelarii: jak uporządkować wymianę dokumentów i status sprawy

Klient potrzebuje odnaleźć ostatnią wersję dokumentu i sprawdzić, czy kancelaria otrzymała jego odpowiedź. Prawnik szuka z kolei załącznika przesłanego przez drugą osobę, która uczestniczy w tej samej sprawie. Gdy informacje są rozproszone po skrzynkach i folderach, nawet proste pytanie o aktualny stan może wymagać porównania kilku wiadomości.

Portal klienta kancelarii może uporządkować dostęp do dokumentów, zadań i uzgodnionych informacji o sprawie. Jego najważniejszą decyzją projektową nie jest jednak kolor przycisku pobierania. Trzeba ustalić, kto może zobaczyć konkretny materiał, jak pozna jego aktualną wersję i co się stanie, gdy dostęp trzeba odebrać.

Dalsze przykłady są fikcyjne i dotyczą organizacji współpracy. Wymogi tajemnicy zawodowej, ochrony danych oraz przechowywania dokumentów zależą od rodzaju kancelarii, sprawy i jurysdykcji. Projekt systemu trzeba ocenić z osobami odpowiedzialnymi za te kwestie; sama aplikacja nie dowodzi ich spełnienia.

Sprawa jest punktem wyjścia do ustalenia dostępu

Najpierw opiszcie jedną sprawę od rozpoczęcia współpracy do zamknięcia. Kto przekazuje dokumenty? Kto przygotowuje odpowiedź? Czy po stronie klienta działa jedna osoba, czy kilka osób o różnych zadaniach? Czy ktoś potrzebuje dostępu do całej sprawy, a inna osoba jedynie do wybranego dokumentu?

W fikcyjnym przykładzie kancelaria współpracuje z firmą przy dwóch niezależnych projektach. Osoba prowadząca pierwszy projekt nie powinna automatycznie widzieć materiałów drugiego tylko dlatego, że pracuje w tej samej firmie. Zespół musi określić granice dostępu dla każdej sprawy, także gdy jedna osoba reprezentuje klienta w kilku miejscach.

Przy zaproszeniu warto wskazać, jakiej sprawy dotyczy dostęp i kto może go nadać. Osoba zapraszająca powinna mieć odpowiednie uprawnienie, a odbiorca wiedzieć, jak potwierdzić swoją tożsamość. Jeśli zaproszenie trafi na nieaktualny adres albo nie zostanie wykorzystane, potrzebna jest czytelna procedura jego unieważnienia i ponownego wysłania.

Nie każda osoba ma wykonywać te same czynności. Ktoś może pobierać zatwierdzone dokumenty, inna osoba przesyłać materiały, a jeszcze inna zarządzać dostępem po stronie klienta. Podział należy uzgodnić z kancelarią i klientem. Artykuł o portalu klienta B2B pokazuje podobne pytania o przekazywanie informacji w firmowej współpracy.

Przed zaproszeniem nowego użytkownika uzgodnijcie również, jakie informacje o uczestnikach sprawy będą widoczne pozostałym osobom. W niektórych projektach lista kontaktów pomaga we współpracy, w innych może ujawniać dane bez potrzeby. Zakres widoku powinien wynikać z konkretnej sprawy i decyzji osób za nią odpowiedzialnych.

Zaprojektuj wymianę dokumentów jako konkretną czynność

Osoba przesyłająca dokument powinna wiedzieć, do której sprawy go dodaje, jaki materiał jest potrzebny i czy plik dotarł. Nazwa przycisku nie zastąpi informacji o stanie. Wybranie pliku na komputerze, rozpoczęcie przesyłania oraz potwierdzenie odbioru przez system to różne momenty. Jeśli połączenie zostanie przerwane, użytkownik potrzebuje wskazówki, co można bezpiecznie zrobić dalej.

Przed przyjęciem pliku trzeba ustalić dopuszczalne formaty, ograniczenia rozmiaru oraz sposób sprawdzania materiału. OWASP opisuje warstwowe podejście do bezpieczeństwa przesyłanych plików. Projekt powinien uwzględniać również miejsce przechowywania, dostęp do pobrania i obsługę pliku, który nie przejdzie zaplanowanej kontroli. Szczegóły należy dopasować do rzeczywistego rozwiązania.

Uzgodnijcie, czy klient może usunąć plik przed wysłaniem i jak zgłasza pomyłkę po przekazaniu. Samodzielne zniknięcie dokumentu z widoku nie musi oznaczać usunięcia wszystkich kopii. Procedura powinna uwzględniać sposób przechowywania, uzgodnioną historię sprawy i obowiązki wynikające z właściwych zasad. W interfejsie warto jasno wyjaśnić, jaki skutek ma dostępna czynność.

Przy dokumentach wymagających akceptacji pokażcie, kto może ją wyrazić i której wersji dotyczy. Jeśli po zatwierdzeniu zmienia się treść, uczestnicy powinni wiedzieć, czy potrzebna jest kolejna decyzja. Sam status „zaakceptowano” bez wskazania wersji utrudnia późniejsze ustalenie, co faktycznie zostało uzgodnione.

Wersja dokumentu to coś więcej niż nazwa pliku

Pliki nazwane „umowa_finalna”, „umowa_finalna2” i „umowa_finalna_naprawde” pokazują problem, który zna wiele zespołów. Portal powinien umożliwiać odróżnienie wersji roboczej od materiału udostępnionego klientowi oraz wskazywać, kto wprowadził zmianę. Zakres historii należy uzgodnić z kancelarią; nie każdy szkic musi być dostępny wszystkim osobom.

Warto zapisać datę udostępnienia i czytelny opis zmiany. Jeżeli dokument zastępuje wcześniejszą wersję, odbiorca powinien móc rozpoznać, której ma użyć. W zależności od ustaleń starsza wersja może pozostać dostępna w historii albo wymagać innej obsługi. Projekt nie powinien zakładać automatycznego usuwania materiałów potrzebnych do wyjaśnienia przebiegu sprawy.

Rozdzielcie dokumenty otrzymane od klienta, szkice kancelarii i materiały gotowe do udostępnienia, jeśli tak wygląda rzeczywisty proces. Przy każdej grupie ustalcie, kto może ją odczytać, poprawić i przekazać dalej. Jeżeli klient ma kilka osób kontaktowych, sprawdźcie, czy wszystkie powinny widzieć identyczny zakres.

W integracji systemów i ustalaniu źródła danych ważne jest również wskazanie miejsca, w którym przechowywana jest aktualna wersja. Jeśli portal i wewnętrzny system kancelarii mogą zmieniać ten sam plik, trzeba uzgodnić sposób rozstrzygania rozbieżności i postępowanie po przerwanym przesyłaniu.

Jeśli proces wymaga podpisania uzgodnionej wersji, przed integracją trzeba określić uczestników i status dokumentu. Te decyzje opisujemy w artykule o podpisywaniu dokumentów w aplikacji.

Status powinien mówić, co dzieje się dalej

Klient nie zawsze potrzebuje szczegółów każdej wewnętrznej czynności. Potrzebuje wiedzieć, czy kancelaria czeka na jego materiał, czy sprawa jest analizowana oraz gdzie może zadać pytanie. Ustalcie kilka stanów, które mają zrozumiałe znaczenie i odpowiadają rzeczywistemu przebiegowi. Status nie powinien sugerować terminu ani wyniku, którego nikt nie potwierdził.

Przy zadaniu dla klienta pokażcie, czego dokładnie oczekujecie, kto może je wykonać i jaki jest kolejny krok. Jeśli wymagany dokument nie został jeszcze otrzymany, przypomnienie powinno prowadzić do właściwej sprawy, a nie ujawniać jej treść w wiadomości wysłanej na przypadkowy adres. Ustalcie też, czy i kiedy powiadomienia można grupować.

Oznaczenie „wysłano” różni się od „odebrano” i „sprawdzono”. Gdy portal korzysta z poczty elektronicznej do powiadomień, trzeba wiedzieć, co dokładnie potwierdza dostawca usługi. Jeśli wiadomość nie dotrze, użytkownik nadal powinien móc sprawdzić stan sprawy po zalogowaniu. O projektowaniu odpowiedzialności za błędy piszemy przy monitorowaniu automatyzacji.

W razie nieobecności osoby prowadzącej potrzebna jest procedura zastępstwa. Kto przejmie nowe materiały i kto może odpowiedzieć klientowi? Przydzielenie zadania zastępcy powinno uwzględniać zakres jego dostępu, a po zakończeniu zastępstwa system powinien pozwalać odpowiednio go zmienić. Udostępnienie wspólnego hasła nie rozwiązuje kwestii odpowiedzialności.

Jeżeli osoba korzystająca z portalu nie rozumie znaczenia statusu, powinna mieć możliwość zapytania o sprawę właściwego zespołu. Przed wdrożeniem sprawdźcie tę drogę kontaktu na przykładowym koncie oraz ustalcie, kto odbierze zgłoszenie podczas nieobecności prowadzącego.

Poufność zależy także od operacji poza ekranem

Sprawdźcie wyszukiwanie, eksport, pobieranie plików oraz dostęp z urządzeń, na których klient wcześniej się zalogował. Ukrycie sprawy na liście nie wystarczy, jeśli dawny odnośnik nadal pozwala pobrać dokument bez sprawdzenia aktualnych uprawnień. Reguły kontroli powinny być egzekwowane w części systemu odpowiedzialnej za udostępnianie danych.

Jeśli kancelaria używa narzędzia do przeszukiwania materiałów, jego wyniki też muszą respektować zakres dostępu osoby pytającej. Dotyczy to również krótkich fragmentów i odpowiedzi wygenerowanej przez asystenta. Szersze omówienie znajduje się w artykule o uprawnieniach do dokumentów w systemie RAG.

Zespół utrzymujący portal może potrzebować informacji o błędach, ale nie zawsze treści dokumentu. Ustalcie zakres dzienników technicznych, dostęp do nich i sposób postępowania przy zgłoszeniu problemu. Przykładowy identyfikator sprawy często wystarczy, by rozpocząć diagnozę. Hasła i klucze dostępowe nie powinny trafiać do korespondencji ani otwartych notatek.

CCBE opisuje poufność relacji z klientem jako jedną z zasad wykonywania zawodu prawnika. Dokument dotyczy kontekstu europejskiego i nie rozstrzyga wszystkich wymagań konkretnej kancelarii. Dlatego przed wdrożeniem trzeba sprawdzić właściwe zasady zawodowe, umowy i warunki korzystania z dostawców usług dla danego projektu.

Przygotuj sposób odzyskania i odebrania dostępu

Klient może zmienić telefon, zapomnieć danych logowania albo zakończyć współpracę z osobą, która dotychczas odbierała materiały. Procedura odzyskania dostępu powinna pozwalać potwierdzić tożsamość w sposób uzgodniony z kancelarią i ograniczyć ryzyko przekazania sprawy niewłaściwej osobie. Samo wskazanie adresu e-mail nie zawsze rozstrzyga, kto aktualnie powinien mieć dostęp.

Zapiszcie, kto może zatwierdzić zmianę osoby kontaktowej oraz jak informowani są pozostali uczestnicy sprawy. Jeśli nowa osoba ma widzieć tylko część dokumentów, zakres trzeba ustalić przed jej zaproszeniem. Zmiana powinna obejmować również oczekujące zadania i powiadomienia, a nie wyłącznie listę użytkowników.

Przetestujcie sytuację, w której dostęp odebrano w trakcie aktywnej sesji. Oczekiwane zachowanie zależy od przyjętej architektury oraz zasad bezpieczeństwa, lecz powinno zostać zapisane i sprawdzone na wszystkich ważnych ścieżkach. Przy pobieraniu dokumentu szczególnie ważna jest weryfikacja aktualnych uprawnień osoby, która wykonuje operację.

Ustal granice integracji z narzędziami kancelarii

Portal może korzystać z wewnętrznego rejestru spraw lub repozytorium dokumentów. Przed podłączeniem ustalcie, które dane są pobierane, co portal może zmieniać oraz gdzie zapisana jest aktualna wersja materiału. Jeśli jedna aplikacja nadaje numer sprawy, druga powinna zachować możliwość powiązania dokumentu z właściwym rekordem bez zgadywania na podstawie samej nazwy klienta.

Dla każdej wymiany informacji zaplanujcie obsługę błędu. Jeżeli dokument został przyjęty przez portal, ale nie dotarł do wewnętrznego systemu, osoba prowadząca sprawę powinna wiedzieć o nieudanej operacji. Status dla klienta musi odpowiadać temu, co faktycznie udało się potwierdzić, a kolejna próba nie powinna po cichu tworzyć drugiej kopii.

Zapytajcie też, kto utrzymuje konta usługowe, gdzie znajdują się ustawienia i jak wygląda odłączenie integracji po zakończeniu współpracy z dostawcą. Przy przekazaniu rozwiązania kancelaria powinna otrzymać informacje potrzebne do kontroli dostępu oraz kontaktu z osobą odpowiedzialną za dalsze utrzymanie.

Przetestuj portal z klientem i zespołem kancelarii

Przygotujcie fikcyjne sprawy oraz konta o różnych uprawnieniach. Osoba testująca powinna znaleźć właściwą sprawę, przesłać dokument, sprawdzić potwierdzenie i wrócić do wcześniejszej wersji zgodnie z ustalonym dostępem. Druga osoba może sprawdzić, czy nie widzi materiałów dotyczących innego klienta. Nie używajcie rzeczywistych poufnych dokumentów, jeśli nie są potrzebne do próby.

Dodajcie przypadek nieaktualnego zaproszenia, pomyłki w wyborze pliku i odebrania dostępu po wygenerowaniu odnośnika. Sprawdźcie też, co widzi użytkownik, gdy przesyłanie zostanie przerwane. Jeśli projekt obejmuje integrację z wewnętrznym systemem kancelarii, porównajcie wynik w obu miejscach. Sam komunikat o wysłaniu nie potwierdza jeszcze poprawnego zapisania dokumentu.

Przed odbiorem zapiszcie oczekiwane zachowanie i osobę, która potwierdzi każdy scenariusz. Pomaga w tym artykuł o kryteriach odbioru aplikacji. Warto wcześniej pokazać prosty prototyp przedstawicielom klientów i pracownikom kancelarii, zgodnie z podejściem opisanym przy testowaniu prototypu z użytkownikami.

Jeśli planujesz portal, opisz w krótkim briefie rodzaje spraw, uczestników i sposób wymiany materiałów. Możemy omówić oprogramowanie na zamówienie, zakres dostępu oraz kryteria odbioru. Skontaktuj się z Archifutura, używając fikcyjnego przykładu zamiast dokumentów objętych poufnością.