Automatyzacja rezerwacji: test zmiany terminu

Przed zakupem automatyzacji rezerwacji warto przejść zmianę już zapisanej wizyty. Nowy termin może być zajęty, poprzednie przypomnienie nadal czekać, a ponowne kliknięcie przycisku powtórzyć operację. W lokalnym demonstratorze Syntalith sprawdziliśmy te sytuacje na fikcyjnych danych. Po całym przebiegu baza zawierała dwie anulowane wizyty i pięć zapisanych działań. Żadna wiadomość nie została wysłana.

Próbę wykonaliśmy 11 października 2026. Kod, dane i testy można pobrać w ZIP; instrukcja uruchomienia pozwala powtórzyć je lokalnie. Program działa bez modelu AI i zewnętrznego kalendarza.

Co sprawdzić podczas przełożenia wizyty?

Recepcjonista powinien zobaczyć aktualną wizytę, wybrać nowy termin i otrzymać jednoznaczny wynik zapisu. Sam odczyt „wolne” sprzed chwili nie wystarcza: inna osoba mogła już zająć miejsce. Jeżeli nowego terminu nie uda się zapisać, dotychczasowy powinien pozostać zachowany.

W naszym przykładzie są dwie fikcyjne osoby i jeden zasób. Po utworzeniu obu wizyt próbujemy przełożyć pierwszą na termin drugiej. Program odrzuca zmianę. Następnie anulujemy drugą wizytę i ponawiamy przełożenie pierwszej, już na wolny termin. Powtórzenie tej samej zapisanej komendy zwraca jej wcześniejsze potwierdzenie, bez dodawania kolejnej zmiany.

To rozróżnienie przydaje się po przerwaniu połączenia. Pracownik może nie wiedzieć, czy zapis się udał, mimo że system go wykonał. W demonstratorze ponowienie wymaga tego samego identyfikatora i dokładnie tego samego wejścia. Nowy identyfikator oznacza nową komendę. Przy podłączeniu rzeczywistego kalendarza trzeba osobno ustalić, jak dostawca obsługuje takie ponowienia.

Stare przypomnienie po zmianie terminu

Wizyta i jej powiadomienia mają wersje. Po przełożeniu wcześniejsze szkice są oznaczane jako nieaktualne, a nowe odnoszą się do zmienionego terminu. Dzięki temu można ustalić, której wersji dotyczy lokalny rekord.

W końcowym przebiegu pobraliśmy offline jedno potwierdzenie pierwszej wizyty, a później ją anulowaliśmy. Pobrany rekord zachował stan UNKNOWN. Program nie ma informacji o doręczeniu ani możliwości cofnięcia kopii, która została już pobrana. Pozostałe pięć rekordów powiadomień miało stan STALE, czyli dotyczyło nieaktualnej wersji wizyty.

Przy zamawianiu integracji warto zapytać o ten moment wprost: co stanie się, gdy klient przełoży wizytę już po przekazaniu SMS-a dostawcy? Odpowiedź zależy od jego kolejki i dostępnych operacji. Usunięcie lokalnego szkicu nie dowodzi, że wcześniej przekazana wiadomość została zatrzymana. Zakres takiego połączenia opisujemy osobno przy automatyzacji SMS.

Ta sama godzina może oznaczać dwa terminy

Do próby wybraliśmy 25 października 2026 i strefę Europe/Warsaw. W użytej bazie stref godzina 02:00 występuje tego dnia z dwoma offsetami: +02:00 oraz +01:00. Dwa przedziały od 02:00 do 02:30 mogą więc oznaczać dwa różne półgodzinne terminy, oddalone od siebie o godzinę.

Dokumentacja Python zoneinfo opisuje rozróżnianie takich chwil przez parametr fold. W naszym formularzu użytkownik wybiera wcześniejsze albo późniejsze wystąpienie osobno dla początku i końca. Brak wyboru przy niejednoznacznej godzinie zatrzymuje zapis. Osobne testy odrzucają także godzinę, która nie istnieje podczas wiosennej zmiany czasu.

Pierwsza wersja panelu domyślnie wybierała wcześniejsze wystąpienie. Backend wymagał wyboru, lecz formularz dokonywał go za użytkownika. Usunęliśmy tę podpowiedź. W powtórnym przebiegu na pustej bazie najpierw sprawdziliśmy błąd bez wyboru, a dopiero potem zapisaliśmy terminy. Ten problem ujawnił przegląd formularza po pierwszej udanej ścieżce obsługi.

Jak sprawdziliśmy wynik?

Cztery zestawy testów uruchomione z nowo rozpakowanego pakietu zakończyły się powodzeniem. Ich zakresy częściowo się łączą; suma 42 oznacza liczbę metod testowych.

Przejście interfejsu obejmowało dziesięć widoków na szerokościach 1440 i 390 pikseli. Stan końcowy sprawdziliśmy dodatkowo przez HTTP, bezpośredni odczyt SQLite i odczyt w nowym procesie. Zgodne wyniki potwierdziły dwie anulowane wizyty, pięć komend i pięć zdarzeń. Nie wywołano dostawcy wiadomości.

Kod, testy i przegląd przygotował ten sam agent w oddzielnych etapach. Materiał nie jest niezależnym audytem. Liczba testów nie mierzy skuteczności AI, a wykonanie dwóch konkurujących operacji nie jest badaniem obciążenia systemu.

Czego ta próba jeszcze nie obejmuje?

Demonstrator używa jednego zasobu, jawnego grafiku i stałego zegara. Nie sprawdza współpracy kilku pracowników, płatności, rezerwacji cyklicznych ani synchronizacji z kalendarzem zewnętrznym. Jedno konto lokalne służy do próby; produkcyjne logowanie i zarządzanie dostępem wymagają osobnej realizacji.

Nie używaliśmy danych pacjentów ani klientów. Wynik nie potwierdza obsługi konkretnego gabinetu, hotelu czy warsztatu, bo każdy z nich ma inne reguły dostępności. Nie mierzy też liczby nieobecności ani oszczędzonego czasu recepcji. Rozumienie swobodnej wiadomości przez model byłoby kolejną próbą, z własnymi przykładami błędów i sposobem doprecyzowania prośby.

Co zamówić po takiej próbie?

Najpierw sprawdź, czy posiadany system obsługuje zmianę terminu, ponowienia i zatrzymywanie starych powiadomień. Jeśli spełnia wymagania, pracą do wykonania może być konfiguracja oraz przeszkolenie recepcji. Własny obieg warto rozważyć, gdy zmiana musi przejść przez kilka narzędzi, a zespół nadal poprawia ją ręcznie.

Syntalith może przygotować automatyzację procesu lub własną aplikację po ustaleniu reguł i możliwości połączenia. Progi tych kategorii w cenniku wynoszą odpowiednio 7 500 zł i 12 500 zł netto. Nie są ceną gotowej integracji rezerwacji. Licencje, wiadomości, utrzymanie i praca nad konkretnym kalendarzem wymagają uzgodnionej wyceny.

Na pierwszą rozmowę wystarczą nazwa obecnego kalendarza i opis jednej zmiany wizyty. Warto wskazać, kto ją zapisuje, gdzie czeka przypomnienie oraz jak recepcja dowiaduje się o nieudanym przełożeniu. Opisz ten przebieg, bez przesyłania danych klientów.