Analityka obsługi klienta z LLM

Zarząd nie wiedział, w jakich sprawach klienci naprawdę piszą i dzwonią, które pytania mógłby przejąć bot albo FAQ, gdzie baza wiedzy ma luki ani jak szybko odpowiadają operatorzy. Dane leżały w Respond.io, które nie oferuje zbiorczego eksportu treści wiadomości, oraz w bazie ocen rozmów telefonicznych.

Ekstraktory w Node.js pobierają przez API każdą wiadomość z Respond.io dla każdego kontaktu, z paginacją kursorową i przyrostowymi aktualizacjami opartymi na znacznikach (watermark), do osobnego schematu Postgres. Kroki SQL łączą wiadomości z rozmowami, dzielą je na epizody kontaktu i wyliczają poziomy obsługi. Następnie kontakty wyeksportowano jako zwarte paczki transkrypcji dla modeli.

Każdy kontakt sklasyfikowano pod kątem tematów, możliwości obsłużenia bez operatora, nierozwiązanych spraw, sentymentu i błędów bota, głównie przy użyciu Gemini Flash, a Claude posłużył do zestawów referencyjnych. Każdy model skalibrowano względem zestawu referencyjnego, a metryki, co do których modele się nie zgadzają, podano jako przedziały. Osobny pięcioetapowy pipeline (Gemini 3.1 Pro z cache’owaniem kontekstu, potem podsumowanie od Claude Opus) porównał ocenione przez AI transkrypcje rozmów z bazą wiedzy agenta obsługi klienta, by znaleźć brakujące tematy. Wyniki złożyły się na raport po gruzińsku, skoroszyt Excel, listę 1 180 nierozwiązanych kontaktów z negatywnym sentymentem do ponownego kontaktu i 19-stronicową prezentację z rekomendacjami; część z nich przygotowali agenci Claude działający pod moją koordynacją.