Jeden ekran zamiast czterech, z asystentem, który widzi to samo co Ty

Sprawa jako obiekt, nie zestaw modułów

Cała platforma jest zbudowana wokół jednego obiektu, który zmienia stany, a nie wokół osobnych modułów na osobne czynności.

Faza sprawy jest wyprowadzana z kategorii, etapu i statusu menu. Siedem faz, od szumu operacyjnego przez nowe, proponowanie, negocjacje i realizację po archiwum. Faza steruje układem ekranu: która karta jest rozwinięta jako główna, które zwinięte, jakim kolorem świeci pasek wiersza na liście.

Osobno działa status dwuosiowy. Kategoria mówi, czym sprawa jest. Stan akcji mówi jednym mocnym oznaczeniem, co należy zrobić teraz: odpowiedz, odpowiedz pilnie, czekamy, przypomnij się, po realizacji. Rozdzielenie tych dwóch osi jest zapisane w legendzie systemu jako świadoma reguła wizualna, żeby nikt ich później nie zlepił z powrotem w jedną kolumnę.

Brief w czterech zakładkach, każde pole ze swoim statusem

Ustalenia z klientem są rozłożone na cztery grupy: logistyka, goście, menu i sprzedaż. W środku siedzą konkrety, od czterech osobnych pól godzin i kontaktu na miejscu, przez diety i styl klienta, po naczynia, stoły koktajlowe i dane do faktury.

Każde pole ma własny status z zamkniętej listy: brak, w toku, czekamy, potwierdzone, zmienione, niepewne, nie dotyczy. Kierunek menu ma osobny, siedmioetapowy przepływ, od „brak kierunku” przez „propozycja wysłana” i „klient chce zmian” aż do „zaakceptowane”.

Dzięki temu pytanie „na czym stoimy z tym klientem” ma odpowiedź na ekranie, a nie w czyjejś pamięci.

Asystent widzi dokładnie to, co operator

Asystent jest obecny na każdym ekranie i zna kontekst tego ekranu. Na widoku sprawy przełącza się w trwałą sesję zapisaną w bazie, wspólną z notatkami i historią szkiców.

Do modelu trafiają te rekordy, które są w danej chwili wyrenderowane na ekranie. Pytanie „ilu z tych klientów ma więcej niż trzy realizacje” liczy się po widocznej liście, nie po całej bazie. Model nigdy nie odpowiada o czymś, czego człowiek nie ma przed oczami, więc odpowiedź da się sprawdzić wzrokiem w tej samej sekundzie.

Notatkę można przypiąć do konkretnego fragmentu konkretnej wiadomości i trafia do asystenta razem z cytatem, którego dotyczy. Wycofanie notatki jest miękkie, więc asystent widzi, że coś zostało dodane i potem wycofane, zamiast dostać wyczyszczoną historię.

Pięć suwaków osobowości steruje wyłącznie rozmową operatorki z asystentem. Na treść wychodzącą do klienta nie mają wpływu żadnego. Tam rejestr jest wykrywany z wątku, nie ustawiany ręcznie.

Prompty na wierzchu

Osobny ekran pokazuje katalog wszystkich zadań AI w systemie. Dla każdego widać aktualny model, statystyki wywołań i kosztu, treść instrukcji systemowej i wzorzec instrukcji użytkownika.

Administrator może dopisać dodatkową instrukcję do wybranego zadania bez zmiany kodu i sprawdzić efekt w piaskownicy.

Powód takiego rozwiązania jest prosty. Prompt, którego nikt nie widzi, po pół roku staje się magią. Prompt na ekranie razem z rachunkiem za jego wywołania jest zwykłym elementem systemu, który da się ocenić i poprawić.

Role, granice i to, co nigdy nie wychodzi na zewnątrz

Trzy role: administrator z pełnym dostępem łącznie z promptami, kosztami i kontami, właściciel z pełnym dostępem operacyjnym oraz pracownik ograniczony do spraw, szkiców, asystenta i notatek. Sesje żyją w podpisanym ciasteczku wyłącznie po HTTPS, hasła są solone i przeliczane dwustoma tysiącami iteracji.

Wewnętrzne notatki zespołu nigdy nie trafiają do klienta i nie wchodzą do promptów, które piszą wiadomości ani wyciągają fakty. Notatkę można dodatkowo oznaczyć jako niewidoczną dla asystenta i wtedy nie wchodzi też do jego kontekstu. Jest to sprawdzane testem, nie deklaracją.

Silnik pocztowy nie ma prawa zapisu na serwerze pocztowym poza dopisaniem kopii wysłanej wiadomości do folderu wysłanych.

Widać, co system robi i ile to kosztuje

Dziennik działań jest dopisywany bez możliwości edycji i pokazuje pełną, stronicowaną historię każdej akcji systemu z odnośnikami do sprawy i klienta. Obok wykres aktywności za siedem, trzydzieści i dziewięćdziesiąt dni oraz tabela rodzajów działań z przejściem do pojedynczych wywołań.

Rejestr wywołań modeli zapisuje cel, model, liczbę tokenów wejściowych i wyjściowych, tokeny odczytane z pamięci podręcznej, koszt, czas odpowiedzi i status.

Ekran stanu systemu sprawdza na żywo trzynaście warunków logicznych i przy każdym daje przycisk naprawy. System zauważa własną awarię, zamiast czekać, aż ktoś odkryje, że coś przestało działać dwa tygodnie temu.