Założenie
Nie bot do odpisywania. System do zbadania sprawy
W obsłudze sklepu ten sam mail może dotyczyć dostawy, płatności, brakującego produktu, błędnego wariantu albo bezpieczeństwa produktu. Sam model językowy potrafi dobrze streścić wiadomość, ale nie powinien sam decydować, co wydarzyło się w magazynie lub systemie płatniczym.
Dlatego projekt łączy AI z danymi operacyjnymi i regułami. Model wskazuje kierunek analizy, a system sprawdza konkretne fakty w Supabase i dopiero z takiego zestawu buduje raport dla pracownika.
Gmail jako wejście
Supabase jako źródło faktów
Slack jako panel konsultanta
Przebieg
Co dzieje się po otrzymaniu wiadomości
Workflow najpierw zabezpiecza wejście i ustala kontekst. Dopiero później uruchamia analizę AI.
System wykrywa duplikat wiadomości, wyciąga numer zamówienia i sprawdza, czy dane w temacie i treści są spójne.
Adres nadawcy jest porównywany z właścicielem zamówienia. Brak zgodności blokuje ujawnienie szczegółów.
Model rozpoznaje obszar sprawy, poziom pewności i sygnały bezpieczeństwa.
Workflow pobiera tylko potrzebne źródła i sprawdza konkretne reguły dla dostawy, płatności, zawartości i produktu.
AI tworzy podsumowanie, hipotezę i draft. Osobny validator sprawdza, czy wynik nie wykracza poza fakty i zasady.
Incydent jest zapisywany w Supabase, a konsultant dostaje na Slacku gotowy panel do dalszej decyzji.
Logika
AI dostaje zadanie. Reguły pilnują granic
Najważniejsze decyzje nie są oparte na jednym promptcie. Część wniosków wynika bezpośrednio z danych.
AI klasyfikuje zgłoszenie
Rozpoznaje główny obszar, problemy dodatkowe i sygnały bezpieczeństwa. Niska pewność automatycznie wymusza ręczną kontrolę.
System wybiera źródła danych
Sprawa płatnicza nie uruchamia bez potrzeby całej ścieżki produktowej. Workflow buduje listę potrzebnych danych na podstawie klasyfikacji.
Twarde reguły potwierdzają fakty
Wykrywane są m.in. dwie płatności w krótkim czasie, brakująca ilość, niezgodny SKU, zmiana treści produktu i brak przekazania paczki.
AI buduje wyjaśnienie
Model składa dane w czytelne podsumowanie, oddziela claims od facts, tworzy hipotezę, brakujące informacje i następny krok.
Validator sprawdza odpowiedź AI
Blokuje m.in. niepotwierdzone obietnice, zbyt mocne hipotezy, techniczny język dla klienta, ryzykowne dane finansowe i niebezpieczne instrukcje.
Człowiek pozostaje w procesie
Sprawa ma priorytet, rekomendację i draft, ale decyzja dotycząca klienta pozostaje po stronie pracownika.
Przypadki
Ten sam workflow obsługuje różne typy incydentów
Raport na Slacku pokazuje to, czego konsultant potrzebuje do decyzji. Bez technicznego dumpu danych z workflow.
Safety
Powerbank z sygnałem bezpieczeństwa
Silne nagrzewanie, zapach spalenizny i wybrzuszenie podnoszą priorytet. System nie diagnozuje technicznej przyczyny i nie każe klientowi ponownie testować urządzenia.
Płatność
Dwie płatności po 349 zł
System potwierdza dwa zapisy płatnicze, ale nie przedstawia ich jako dowodu, że rachunek klienta został faktycznie obciążony dwa razy.
Zamówienie
Brak jednej z dwóch sztuk
Dane zamówienia pokazują 2 sztuki zamówione i 1 zrealizowaną. AI nie rozbudowuje sprawy o niepotrzebne zdjęcia, monitoring czy kontakt z przewoźnikiem.
Ochrona danych
System zna zamówienie, ale nie zawsze może o nim mówić
Jeżeli adres nadawcy nie pasuje do właściciela zamówienia, pełne dane nadal mogą być użyte do wewnętrznej analizy. Draft dla klienta jest jednak ograniczony i nie ujawnia numeru zamówienia, płatności, produktów ani statusu przesyłki.
identity mismatch
blokada szczegółów
bezpieczny draft
human review
Privacy guardrail
Niepotwierdzona tożsamość
Konsultant widzi ostrzeżenie, a odpowiedź dla nadawcy nie zdradza danych zamówienia.
Workflow
Jedna ścieżka główna, kilka niezależnych warstw kontroli
Screeny pokazują kolejne fragmenty workflow. Można je powiększyć.
System
Cały Order Incident Investigator
Główny workflow łączy intake, identyfikację, klasyfikację, pobieranie danych, reguły, AI, walidację, zapis incydentu i raport.
01
Intake i tożsamość
Duplikaty, numer zamówienia, klient i możliwość ujawnienia danych są sprawdzane przed analizą.
02
Klasyfikacja i routing danych
AI rozpoznaje rodziny problemu, a workflow wybiera tylko źródła potrzebne do danej sprawy.
03
Reguły biznesowe
Oddzielne ścieżki sprawdzają dane dostawy, płatności, zawartości zamówienia i produktu.
04
Analiza AI, walidator i manual review
Wynik modelu przechodzi kontrolę przed wyliczeniem priorytetu, zapisaniem incydentu i wysłaniem raportu do konsultanta.
Audit
Slack jest panelem pracy. Supabase przechowuje pełny zapis
Incydent nie znika po wysłaniu powiadomienia. W bazie zostaje kategoria, priorytet, claims, fakty, niespójności, hipoteza, brakujące informacje, rekomendacja i draft.
Supabase
Lista incydentów
Każda wiadomość ma własny identyfikator, kategorię, priorytet, status i wynik analizy.
Audit trail
Rozdzielone elementy analizy
Twierdzenia klienta, potwierdzone fakty, hipoteza i rekomendowane działanie są zapisane osobno. To ułatwia późniejszą kontrolę wyniku.
Stack
n8n jako orkiestracja, dane i AI w jednym procesie
Projekt został zbudowany jako środowisko demonstracyjne dla sklepu ElectroFuture.pl. Dane, zamówienia i incydenty są testowe.
n8nOpenAISupabaseGmailSlackJavaScriptStructured OutputHuman Review