Realizacje › Poczta i odpowiedzi
RealizacjaPięć lat skrzynki zamienione w rejestr spraw
Skrzynka pocztowa nie ma pojęcia sprawy. Rozmowa o przyjęciu na sto osób rozpada się w niej na kilkanaście wiadomości poprzedzielanych fakturami i newsletterami, a wiedza o tym, co ustalono, siedzi w głowie jednej osoby. Zaimportowaliśmy pięć lat korespondencji i zbudowaliśmy nad nią rejestr, w którym rozmowa jest jednym obiektem z historią, fazą i następnym krokiem.
5 min czytania
- 5 latzaimportowanej korespondencji
- ponad 30 tys.wiadomości w rejestrze
- ponad 5 tys.spraw
- ponad 20 tys.pól z cytatem źródłowym
Co dostał klient
- Ponad trzydzieści tysięcy wiadomości z pięciu lat uporządkowanych w ponad pięć tysięcy spraw i blisko dwa tysiące kartotek klientów.
- Ponad dwadzieścia tysięcy pól wypełnionych automatycznie, każde z dosłownym cytatem, z którego pochodzi, i wskazaniem, kto je ustawił.
- Odpowiedź powstaje w rejestrze i języku, w którym pisze klient, bez ustawiania czegokolwiek suwakiem.
- Żadna ścieżka w kodzie nie prowadzi do wysyłki bez kliknięcia człowieka.
Silnik czyta, ale niczego nie rusza
Na serwerze pocztowym pracujemy w trybie wyłącznie do odczytu. Nie zmieniamy flag, nie kasujemy, nie przenosimy. Skrzynka odbiorcza i folder wysłanych są odpytywane niezależnie, każdy z własnym znacznikiem postępu, żeby jeden nie blokował drugiego.
Normalizacja zamienia HTML na tekst, obcina zacytowaną historię i stopkę, sprząta osierocone fragmenty nagłówków. Osobny parser tłumaczy polskie daty z nagłówków cytatu na format maszynowy. Bez niego kilkanaście tysięcy wierszy trzymało w polu czasu surowe polskie napisy, co psuło sortowanie, grupowanie i progi archiwizacji.
Formularz ze strony wysyła maila z adresu firmy, a prawdziwy klient siedzi w treści. System podmienia nadawcę na właściwego, ale przeszukuje wyłącznie oczyszczoną treść, nigdy surowego ciała wiadomości. Inaczej zwykła odpowiedź pracownika cytująca stare zgłoszenie przypisałaby cały wątek nie tej osobie.
Wiadomość, której nie da się zaimportować, ląduje w rejestrze niepowodzeń. Znacznik synchronizacji nigdy nie przechodzi obok pozycji czekającej na ponowienie, bo to byłoby ciche zgubienie maila na zawsze. Jedna trująca wiadomość nie zatrzymuje reszty skrzynki i nic nie znika po cichu.
Jak wiadomość trafia do właściwej sprawy
To jest różnica między rejestrem a skrzynką i pytanie, które przy takich systemach pada najczęściej. Dopasowanie idzie w ustalonej kolejności.
Najpierw strażnik tożsamości. Jeżeli adresem kotwiczącym jest adres własny firmy, wiadomość jest pomijana w całości. Bez tego powstawały dziesiątki fantomowych spraw założonych na samych siebie.
Potem dopasowanie po łańcuchu odpowiedzi, czyli po nagłówkach technicznych maila. Wygrywa nawet wtedy, gdy temat się zmieni, więc odpowiedź zatytułowana „RE: faktura” zostaje w sprawie „Zapytanie o Wigilię firmową”.
Dopiero przy braku nagłówków wchodzi podobieństwo tematu, liczone wyłącznie wśród spraw tego samego klienta z ostatnią wiadomością w oknie dwóch tygodni, liczonym od daty wiadomości, nie od daty importu. Przy wgrywaniu pięciu lat historii wstecz to rozróżnienie decyduje o wszystkim. Większość małych systemów CRM zatrzymuje się na samym rozmytym dopasowaniu tematu.
Jeden mail, kilka wiadomości
Pojedynczy e-mail często niesie w sobie całą zacytowaną historię korespondencji. Rozpoznajemy sześć wzorców nagłówka cytatu równolegle, od polskiego Gmaila po blok przekazanej wiadomości z Outlooka i Roundcube.
Deduplikacja działa na znormalizowanym prefiksie treści, bo to samo zacytowane zdanie ma inną gęstość pustych linii przy każdym przeskoku między programami pocztowymi. Model wchodzi wyłącznie jako rezerwa, gdy wzorce zawiodą na długim mailu.
Odzyskane w ten sposób wiadomości są oznaczone jako odtworzone z cytatu i domyślnie schowane za przełącznikiem, żeby nie mieszały się z realną pocztą.
CRM, w którym pola wypełniają się same
Po każdej nowej wiadomości klienta rusza ekstrakcja. Model czyta cały wątek i proponuje wartości pól: datę, godziny, miejsce, liczbę gości, diety, kierunek menu, budżet, dane do faktury.
Każda propozycja niesie ze sobą dosłowny cytat, wskazanie wiadomości źródłowej i wskazanie, kto jest autorem tej informacji: klient, nasza strona, model czy człowiek ręcznie. Zapisanych zdarzeń wartości pola jest ponad dwadzieścia tysięcy, więc dla dowolnego pola widać całą oś czasu jego zmian razem z pochodzeniem każdej wersji.
Ikona statusu przy polu pokazuje po najechaniu dokładny cytat, autora i datę. Operatorka nigdy nie musi wierzyć systemowi na słowo. Pole poprawione ręcznie jest zablokowane, a każde da się przywrócić do ostatniej wartości, która nie pochodziła z ręcznej edycji.
Propozycje są zapinane sygnaturą wątku z chwili przeglądu. Zaakceptowanie zmian nie może zastosować świeżo innego wyniku modelu, jeżeli w międzyczasie przyszła nowa wiadomość.
Odpowiedź napisana głosem firmy
Prompt pisarza odpowiedzi nie jest instrukcją w stylu „bądź pomocny i uprzejmy”. Otwiera go sekcja granic wiedzy: model zna wyłącznie ten wątek, brief, pamięć o poprzednich zamówieniach klienta i podane fakty firmowe. Nie zna kalendarza rezerwacji, cennika, stanu płatności, grafiku ekip ani rozmów telefonicznych. Zanim napisze zdanie z konkretem, musi wskazać jego źródło. Brak źródła oznacza, że zdanie nie powstaje.
Dalej idzie kilkanaście twardych zakazów, każdy opatrzony adnotacją, że ten błąd zdarzył się naprawdę. Nigdy nie podawaj numeru konta ani kwoty zaliczki. Nigdy nie potwierdzaj dostępności terminu. Nigdy nie podawaj stawki, której nie ma już w wątku.
Forma zwracania się i język są rozpoznawane z wątku, nie ustawiane suwakiem. Przykłady tonu są dobierane kontekstowo z biblioteki realnych, zanonimizowanych wiadomości operatorki, filtrowanej po intencji i po tym, czy klient jest powracający.
Na końcu tekst przechodzi przez deterministyczne przepisanie: usuwane są wzorce zdradzające maszynę, myślniki łączące zamieniają się w przecinki, podpis jest domykany. Ten filtr działa niezależnie od tego, jak dobrze model wykonał instrukcję, bo modele ignorują tego rodzaju polecenie mniej więcej w połowie przypadków.
Jedna wiadomość może realizować różne intencje na różnych polach naraz: potwierdzić jedno, dopytać o drugie, zaproponować trzecie. Podyktowana instrukcja operatorki ma pierwszeństwo nad planem wygenerowanym automatycznie. To rozróżnienie powstało po konkretnej skardze, gdy plan systemu odpowiedział na jednozdaniowe pytanie klienta jedenastoma pytaniami.
Kto decyduje o wysyłce
Po każdym wygenerowaniu i każdej edycji szkicu rusza klasyfikator, który działa bez udziału modelu. Skanuje wygenerowany tekst i rozstrzyga, czy wiadomość może pójść bez decyzji właścicielki.
Dwie intencje handlowe, czyli oferta i potwierdzenie zamówienia, z definicji wymagają człowieka. Poza tym pracuje osiem wyzwalaczy tekstowych: cena, dostępność konkretnego terminu, obietnica wykonalności, przyjęcie zamówienia, dane do płatności, gwarancja dietetyczna lub alergenowa, konkretna godzina przy słowach o dostawie i konkretna propozycja dań. Każdy zwraca własne uzasadnienie po polsku.
Brak modelu w tej decyzji jest wyborem, nie oszczędnością. Wygenerowanie tekstu przez model, nawet dobry, nie jest wystarczającą przesłanką do wysyłki. Pytanie „czy to bezpieczne” zadane kolejnemu promptowi mogłoby samo zostać zmyślone na „tak”.
Wysyłka wychodzi wyłącznie po jawnym kliknięciu i wyłącznie jako odpowiedź. System odmawia wysłania, jeżeli w wątku nie ma ani jednej wiadomości od klienta, co zamyka drogę, którą przypadkowy zimny kontakt mógłby wyjść tą samą ścieżką.
Operatorka może też podyktować, co ma być w odpowiedzi. Dosłowna transkrypcja jest pokazywana przed przepisaniem przez model, żeby błąd rozpoznania mowy, zła cena albo zła data, złapał człowiek, zamiast pójść po cichu do klienta.
Policzmy to na Twoich danych.
Audyt AI: konkretne zadania, spodziewane oszczędności i co zbudowalibyśmy najpierw.