Oprogramowanie obsługujące rezerwacje i konflikt terminów musi wiedzieć, co dokładnie przydziela klientowi. Sama wolna godzina może nie wystarczyć, jeśli usługa wymaga sali, pracownika i sprzętu. Dwie osoby mogą zobaczyć tę samą dostępność, zanim którakolwiek zakończy formularz. To moment przyjęcia rezerwacji powinien chronić uzgodnioną regułę, a nie wcześniejszy widok kalendarza.
Wyobraźmy sobie fikcyjne centrum szkoleń, które udostępnia stanowiska do zajęć indywidualnych. Do spotkania potrzebna jest osoba prowadząca oraz określone urządzenie. Klient zmienia termin, kiedy recepcja wpisuje zgłoszenie telefoniczne. System powinien wyjaśnić, który przydział został zaakceptowany i jak kontynuować drugą sprawę bez utraty informacji przekazanych przez zainteresowaną osobę.
Nazwij zasoby i ograniczenia
Wypisz elementy konieczne do wykonania usługi i reguły dotyczące ich czasu. Czas przygotowania, przerwa między spotkaniami i różna długość usługi mogą zmieniać dostępność. Osoba odpowiedzialna za organizację musi określić te warunki na przykładach. Zespół techniczny nie powinien samodzielnie rozstrzygać, czy dwie sąsiadujące wizyty są operacyjnie możliwe w danej placówce.
Ustal, czy rezerwacja dotyczy konkretnej osoby i miejsca, czy dowolnego zasobu spełniającego wymagania. Te modele prowadzą do innych decyzji przy zmianie grafiku. Interfejs powinien opisywać właściwe zobowiązanie, żeby klient nie otrzymał potwierdzenia usługi, której recepcja nie może następnie przypisać do odpowiedniego zespołu albo wyposażenia w uzgodnionym terminie.
Oddziel wybór od potwierdzenia
Jeśli system stosuje czasową blokadę, pokaż jej znaczenie i warunek zakończenia. Otwarcie formularza nie musi oznaczać bezterminowego zajęcia zasobu. Określ, co dzieje się po opuszczeniu strony i czy ponowne wejście kontynuuje wcześniejsze zgłoszenie. Użytkownik powinien rozumieć, jaki etap został zachowany oraz co trzeba jeszcze zrobić.
Poproś wykonawcę o demonstrację dwóch zgłoszeń docierających niemal równocześnie. Kontrola musi obejmować operację zatwierdzającą przydział. Ważny jest rezultat możliwy do sprawdzenia: brak sprzecznych rezerwacji i zrozumiała odpowiedź dla osoby, która nie może otrzymać wybranego terminu. Ogólna deklaracja aktualizacji w czasie rzeczywistym nie pokazuje jeszcze takiego zachowania.
Zaplanuj zmianę i brak odpowiedzi
Przeniesienie wizyty powinno mieć jasno zdefiniowany skutek dla starego terminu. Zdecyduj, czy zwalnia się dopiero po przyjęciu nowego, czy wcześniej. Wybór zależy od usługi, ale musi być świadomy. W przeciwnym razie przerwana zmiana może pozostawić klienta z dwiema rezerwacjami albo bez żadnej z nich.
Uwzględnij informacje przychodzące z opóźnieniem z innych systemów. Jeżeli potwierdzenie dodatkowego etapu dotrze po wygaśnięciu blokady, aplikacja potrzebuje ustalonej ścieżki wyjaśnienia. Nie powinna tworzyć dostępności, której już nie ma, ani przedstawiać oczekiwania jako zakończonego przydziału. Recepcja i klient muszą widzieć zgodny stan sprawy.
Przeprowadź próbę odbiorową
Otwórz dwie sesje i poproś o ostatni dostępny termin. Pozostaw jeden formularz otwarty, zmień grafik z konta recepcji i spróbuj potwierdzić stary wybór. Następnie przetestuj przerwane przenoszenie wizyty. Porównaj kalendarz, komunikaty i widok pracownika, zapisując sprawy wymagające decyzji zamiast uznawać samą odpowiedź serwera za zakończenie testu.
Brainbaby Labs może pomóc przełożyć reguły grafiku na pierwszy zakres aplikacji. Warto przynieść przykładowy dzień pracy i typową trudną zmianę terminu, bez niepotrzebnych danych klientów. Odbiór powinien objąć pełną rezerwację oraz jej wyjątek. Dzięki temu propozycja łączy projekt interfejsu, logikę przydziału i sposób, w jaki zespół naprawdę obsługuje użytkowników.