AI układa kalendarz: wolne okienko nie zawsze oznacza możliwe spotkanie

W kalendarzu wszyscy mają wolne od dziesiątej. Sala również. Asystent proponuje spotkanie na dziesiątą i uznaje sprawę za zamkniętą. Jedna osoba kończy wtedy warsztat w drugim budynku, druga zaczyna dzień w innej strefie czasu, a salę trzeba jeszcze przygotować. Wolny prostokąt ma tę zaletę, że nie męczy się chodzeniem po schodach. Ludzie niestety mają bardziej rozbudowane wymagania.

Przy ocenie planowania z AI nie wystarczy znaleźć wspólnej luki. Trzeba sprawdzić, czy propozycja spełnia ograniczenia uczestników, miejsca i zadania, a potem oddzielić ją od rezerwacji oraz wysłania zaproszenia. To trzy różne rezultaty. Każdy potrzebuje własnego potwierdzenia.

Najlepiej zacząć od kontrolowanego przykładu z fikcyjnymi kalendarzami. Pozwala on odtworzyć kolizję, brak informacji i zmianę terminu bez wysyłania prawdziwym osobom zaproszeń na szkolenie o ósmej rano w niedzielę. Taki eksperyment szybko pokazuje, co narzędzie rzeczywiście wie, a co jedynie dopowiada do pustego miejsca.

Zapisz warunki, zanim pokażesz kalendarz

Wyobraźmy sobie firmę przygotowującą demonstrację produktu w dwóch lokalizacjach. Spotkanie wymaga prowadzącej, osoby technicznej i sali ze stanowiskiem. Między demonstracjami potrzebne są przygotowanie oraz przejście do drugiego budynku. Odbiorcy mogą dołączyć zdalnie, ale prowadząca musi być na miejscu. Ten opis zawiera więcej niż listę uczestników.

Rozdziel warunki obowiązkowe i preferencje. Obecność osoby technicznej może być niezbędna, a pora przed południem jedynie wygodniejsza. Jeśli model nie znajduje terminu, powinien wskazać, który warunek blokuje zadanie. Nie powinien sam zmieniać osoby wymaganej na opcjonalną tylko dlatego, że wtedy powstaje atrakcyjna propozycja.

Przy każdym warunku wskaż źródło. Godziny pracy mogą pochodzić z konfiguracji kalendarza, dostępność sali z jej rezerwacji, a czas przygotowania z ustaleń zespołu. To ostatnie nie musi być zapisane jako wydarzenie. Audyt powinien sprawdzić, czy proces dostaje tę informację i jak ją stosuje, zamiast zakładać, że wszystko znajduje się na jednej planszy.

Microsoft Graph w opisie findMeetingTimes przedstawia propozycje oparte na dostępności oraz przekazanych ograniczeniach czasu i lokalizacji. Opisuje również powód braku propozycji. To zakres konkretnej funkcji; nie oznacza automatycznej znajomości wszystkich warunków organizacyjnych twojej firmy.

Własną kartę zadania uzupełnij o długość spotkania, dopuszczalny przedział dat, wymagane zasoby i czas pomiędzy zdarzeniami. Dopisz, czy spotkanie można podzielić oraz kto może zatwierdzić zmianę warunku. Dzięki temu ocena nie zależy od tego, czy prowadząca po zobaczeniu propozycji przypomni sobie o przenoszeniu sprzętu.

Rozdziel także uprawnienie do odczytu od zakresu wiedzy. Jeśli narzędzie nie widzi kalendarza jednej wymaganej osoby, nie ma podstaw do stwierdzenia, że jest wolna. Przygotuj taki przypadek i sprawdź, czy proces prosi o potwierdzenie, czy wypełnia lukę dogodnym założeniem. Raport powinien wskazać, której dostępności nie udało się ustalić.

Przy braku danych wybierz rozpoznawalny stan. „Nie znam czasu przygotowania” to inne zdanie niż „czas przygotowania wynosi zero”. Jeżeli system przyjmuje wartość domyślną, pokaż ją przed zatwierdzeniem i sprawdź, czy osoba planująca rozumie jej znaczenie. Ukryte zero może być najskuteczniejszym sposobem produkowania niemożliwych harmonogramów.

Dodaj zmianę daty wyrażoną potocznie: „przełóż na następny piątek”. Jeśli termin pochodzi z formularza, sprawdź również sposób podawania daty na stronie, aby niejednoznaczność nie powstała jeszcze przed pracą asystenta. W kontrolowanym przykładzie ustal dzień odniesienia i oczekiwaną datę, a potem sprawdź podsumowanie przed operacją. Przy niejednoznaczności proces powinien uzyskać konkretną datę. Przekonujący ton odpowiedzi nie rozwiązuje różnicy między dwoma możliwymi piątkami.

Ta sama godzina nie zawsze oznacza ten sam moment

Google Calendar rozróżnia strefę kalendarza i strefę wydarzenia. W zdarzeniach cyklicznych strefa jest także potrzebna do rozwinięcia kolejnych wystąpień. Dla kontroli propozycji oznacza to potrzebę zachowania informacji o strefie wraz z datą i godziną, zamiast przesyłania samego „10:00”.

Nie musisz ręcznie przeliczać każdej godziny, aby odebrać proces. Przygotuj przykłady ze znanym oczekiwanym momentem i sprawdź widok dla poszczególnych uczestników. Zapisz datę, godzinę lokalną oraz strefę używaną w ocenie. Jeśli ktoś widzi inny dzień, ta różnica powinna być widoczna w podsumowaniu przed wysłaniem zaproszenia.

Do próby dodaj serię przechodzącą przez zmianę czasu w używanych regionach. Nie opieraj jej na zapamiętanej stałej różnicy godzin. Chodzi o sprawdzenie, czy kolejne wystąpienia odpowiadają uzgodnionej regule: na przykład tej samej lokalnej porze prowadzącej. Oczekiwanie zapisz z wyprzedzeniem i porównaj kilka dat serii.

Przy współpracy Polski z Azją w różnych strefach uzgodniona pora jest częścią sposobu pracy. Asystent powinien respektować dopuszczalny zakres dla wszystkich wymaganych osób. Wspólna luka techniczna nie oznacza jeszcze, że spotkanie w środku czyjejś nocy odpowiada ustaleniom zespołu.

Dodaj przypadek całodniowego wyjazdu lub niedostępności. Sprawdź, jak narzędzie interpretuje taki zapis w konkretnym kalendarzu i czy uwzględnia go przy proponowaniu godzin. Nie przenoś zachowania jednego typu wydarzenia na wszystkie inne. W raporcie nazwij stan wejściowy, ustawienia i zaobserwowany wynik, aby druga osoba mogła powtórzyć próbę.

Jedna zmiana powinna ujawnić, czego pilnuje system

Najpierw uruchom prosty przypadek, w którym wszystkie warunki dają jeden znany termin. Następnie zmień tylko dostępność sali. Potem przywróć ją i dodaj kolizję osoby technicznej. W kolejnej próbie wydłuż przygotowanie. Taki układ pozwala zobaczyć, który warunek proces rzeczywiście stosuje, bez zgadywania na podstawie skomplikowanego końcowego grafiku.

Sprawdź granicę końca spotkania. Jeżeli demonstracja trwa do jedenastej, a kolejne zadanie zaczyna się o jedenastej w innym miejscu, sam brak nakładania godzin nie wystarcza. Zespół powinien wcześniej uzgodnić bufor oraz sposób jego uwzględniania. Nie dopisuj jednej uniwersalnej liczby minut do wszystkich sytuacji; zadania mogą wymagać różnych przygotowań.

Przetestuj zasób, który jest dostępny tylko przez część proponowanego okresu. Wolna sala na początku nie oznacza rezerwacji na całe spotkanie. Podobnie prowadząca obecna przez pierwsze pół godziny nie spełnia warunku prowadzenia godzinnej demonstracji. Wybierz przypadek, w którym częściowa zgodność wygląda kusząco, i sprawdź końcową decyzję.

Dodaj salę o podobnej nazwie. „Warsztat A” w pierwszej lokalizacji i „Warsztat A” w drugiej mogą wyglądać identycznie na skróconej liście. Przed potwierdzeniem pokaż identyfikator miejsca z informacją zrozumiałą dla użytkownika: budynkiem lub adresem. Sama poprawna nazwa bez lokalizacji nie dowodzi, że zarezerwowano właściwy zasób.

Jeżeli wynik trafia dalej w strukturze danych, powiąż próbę z kontrolą znaczenia JSON generowanego przez AI. Rekord może mieć poprawny format daty, a dotyczyć niewłaściwej sali albo innego wystąpienia serii. Formalny odbiór odpowiedzi nie kończy kontroli harmonogramu.

Porównaj dwie dopuszczalne propozycje, które różnią się jedynie preferencją. Czy model potrafi wyjaśnić kolejność, odwołując się do ustaleń? Jeśli wybrano porę wygodną dla prowadzącej, nie opisuj jej jako jedynego możliwego terminu. Użytkownik powinien rozpoznać różnicę między wymogiem a wyborem spośród poprawnych możliwości.

Przy serii spotkań sprawdź, czy niewygodna pora nie przypada stale tej samej osobie, jeżeli zespół uzgodnił rotację. To reguła organizacyjna, którą trzeba jawnie dostarczyć i odebrać na kolejnych wystąpieniach. Sam widok jednego poprawnego spotkania nie pokazuje, jak plan rozkłada obciążenie w całej serii.

Sprawdź, czy zadanie wymagające sprzętu uwzględnia go jako osobny zasób. Dwie sale mogą być wolne jednocześnie, a jedyny zestaw demonstracyjny dostępny tylko dla jednej z nich. W kontrolowanej próbie zaplanuj dwa pozornie poprawne spotkania korzystające z tego samego stanowiska. Odbiór powinien wykazać konflikt wspólnego zasobu, zanim obie rezerwacje zostaną uznane za wykonalne.

W raporcie pokaż przy takim błędzie nie tylko odrzucony termin, lecz także warunek, którego zabrakło w wejściu albo który pominięto w ocenie. Te dwa przypadki wymagają innej poprawki: uzupełnienia opisu zadania lub zmiany działania procesu.

Ułóż też przypadek bez możliwego terminu. Oczekiwany wynik powinien wskazywać konflikt i drogę rozstrzygnięcia. Być może można zmienić lokalizację, skrócić zadanie albo zapytać o szerszy zakres dat. Model nie powinien wybierać za właściciela procesu, który obowiązkowy warunek zostaje po cichu odrzucony.

Do przeglądu w Aeneia Audit przygotuj jedno zadanie, jego obowiązkowe warunki i fikcyjne przykłady kalendarzy. Pozwoli to ocenić proces bez uruchamiania prawdziwej wysyłki zaproszeń podczas pierwszej próby.

Między propozycją a zaproszeniem kalendarz nadal żyje

Termin mógł być wolny w chwili odczytu, a zajęty w momencie zatwierdzenia. Sprawdź zmianę dostępności w tej przerwie. Czy proces ponownie ocenia warunki, czy wysyła zaproszenie na podstawie dawnej propozycji? W raporcie zachowaj czas sprawdzenia i moment operacji, aby odróżnić błąd planowania od zmiany stanu.

W zatwierdzaniu działań AI pokaż przed zgodą termin, strefy, uczestników, miejsce i zakres zmiany. Jeżeli chodzi o przesunięcie istniejącej serii, odbiorca powinien wiedzieć, czy dotyczy jednego spotkania, przyszłych wystąpień czy całości. Słowo „przełóż” nie rozstrzyga tego samodzielnie.

Przetestuj odrzucenie propozycji oraz zmianę jednego warunku przez człowieka. System powinien zachować pozostałe ustalenia albo jasno pokazać, że potrzebuje ich ponownego potwierdzenia. Powrót do początku z utratą wymagań może prowadzić do atrakcyjnej propozycji dla zadania, którego nikt już nie zlecał.

Sprawdź także anulowanie części planu. Jeśli znika jedna demonstracja, co dzieje się z rezerwacją sali i osobnym blokiem przygotowania? Zasób nie powinien pozostać zajęty przez czynność, której już nie ma. Jednocześnie anulowanie jednego wystąpienia nie może skasować uzgodnionej serii, jeżeli zadanie tego nie obejmowało.

Po operacji sprawdź właściwe kalendarze i zasoby. Utworzony szkic, wysłane zaproszenie oraz zaakceptowany udział nie są tym samym stanem. Określ, który z nich stanowi wynik uzgodnionego zadania, i opisuj go precyzyjnie. „Spotkanie gotowe” bez tej definicji łatwo zamienia plan w relację z przyszłości.

Wykonaj jeszcze próbę przerwania po przygotowaniu propozycji, a przed potwierdzeniem. Po powrocie pokaż, co zostało zapisane, co czeka na decyzję i co wymaga ponownego odczytu. Osoba planująca nie powinna zgadywać, czy zamknięcie okna oznaczało wysłanie zaproszenia. Ten przypadek warto odebrać z kimś, kto nie obserwował wcześniejszych kroków.

Gdy wiele terminów powstaje równolegle, potrzebujesz trwałego związku propozycji ze sprawą i wersją wejścia. Rozwija to odbiór wyników wsadowych AI. Spóźniona odpowiedź nie powinna nadpisywać planu, który człowiek zdążył już zmienić.

Taką granicę umieść również w odpowiedzialnym workflow agentów: kto proponuje, kto zatwierdza i gdzie potwierdzany jest skutek. Harmonogram staje się użyteczny, gdy jego warunki da się wyjaśnić, a zmiany odtworzyć. Wtedy przy każdym terminie widać, kogo obejmuje, na jakich warunkach powstał i jaki stan rzeczywiście potwierdzono.