sześcioro drzwi, jedna rozmowa
Odwiedzający na twojej stronie widzi jedną rzecz: mały czat, a w nim twój zespół. Za nim twój zespół może siedzieć w sześciu różnych miejscach. Ktoś odpisuje z wątku na Slacku, ktoś inny z dashboardu na telefonie, a agent w edytorze kodu łapie pytanie o API. Odwiedzający widzi jedną rozmowę, po kolei, z imionami, i nic dwa razy.
Ten post jest o tym, jak to działa: czym są te drzwi, co się dzieje, kiedy przez nie przechodzi wiadomość, i jakie zasady pilnują, żeby sześcioro drzwi nie zrobiło się sześcioma wersjami prawdy.
sześcioro drzwi
- Widget. Tu pisze odwiedzający i tu czyta każdą odpowiedź.
- Slack. Każda rozmowa to wątek na kanale, który wybrałeś. Zespół odpisuje w wątku. Setup jest w poradniku o Slacku.
- Discord. Już wkrótce, więc na dziś pięcioro drzwi. Będzie działać tak samo, jako post na forum albo wątek na kanale tekstowym.
- Inbox w dashboardzie. Każda rozmowa, z zakładkami otwarte, moje i zamknięte, wyszukiwaniem, notatkami i polem na odpowiedź.
- API. Klucz i kilka wywołań REST: lista rozmów, odczyt jednej, odpowiedź, przypisanie, zamknięcie.
- MCP. Te same narzędzia dla agentów, więc Claude Code albo dowolny klient MCP może czytać i odpisywać. Poradnik o Claude Code pokazuje to od początku do końca.
Każde drzwi mogą odpowiedzieć w każdej rozmowie, w każdej chwili. Nikt nie musi z góry decydować, gdzie czat „mieszka”.
najpierw zapis, potem wszędzie
Każda wiadomość, z każdych drzwi, idzie tą samą drogą. Spookat najpierw ją zapisuje. Dopiero kiedy jest zapisana, leci gdziekolwiek dalej:
- do widgetu odwiedzającego, na żywo, jeśli akurat tam jest,
- do wątku na Slacku, jeśli wiadomość nie przyszła właśnie stamtąd,
- do każdego z zespołu, kto ma otwarty dashboard, bez odświeżania,
- do twoich webhooków, jeśli je masz.
W tej kolejności jest cały trik. Spookat jest zapisem rozmowy, a każde inne miejsce to jej widok. Nigdy nie czytamy historii ze Slacka, żeby się dowiedzieć, co padło. Więc zarchiwizowany kanał, usunięty wątek czy awaria Slacka nie zmienią tego, co jest w rozmowie. Jeśli podepniesz nowy kanał, rozmowy dalej tam są.
Dlatego też odwiedzający nigdy nie czeka na twoje narzędzia. Widget pokazuje „dostarczono” w chwili zapisu, a dostarczenie do wątku to nasza robota, nie jego.
odwiedzający widzi imiona, nie drzwi
Odpowiedź ze Slacka i odpowiedź z dashboardu wyglądają w widgecie tak samo: tekst, godzina i imię osoby, która pisała. Każdy członek zespołu wybiera to imię raz, przez /spookat me na Slacku, i to samo imię idzie ze wszystkich drzwi. Kto woli odpisywać jako strona, też może.
Kiedy w twoim imieniu odpowiada agent, bo strona ma włączonego asystenta, widget oznacza to jako asystenta, a odwiedzający jednym kliknięciem może poprosić o człowieka. Kiedy człowiek przejmuje rozmowę, asystent przestaje.
nic nie pojawia się dwa razy
Sześcioro drzwi to sześć okazji, żeby tę samą wiadomość dostarczyć dwa razy. Oto jak każda jest zamknięta.
- Odwiedzający na słabym łączu. Każda wiadomość z widgetu ma własne losowe id. Jeśli połączenie padnie po zapisie, ale zanim widget dostał potwierdzenie, widget wysyła ją jeszcze raz, a Spookat rozpoznaje id i potwierdza wiadomość, którą już ma. Jedna wiadomość, niezależnie od liczby prób.
- Slack ponawia. Slack wysyła zdarzenie jeszcze raz, kiedy nie jest pewny, czy doszło. Każda wiadomość z wątku zapisuje się z własnym id platformy, a druga kopia z tym samym id jest ignorowana.
- Nasze własne posty wracają. Kiedy Spookat wrzuca odpowiedź do wątku, platforma daje nam znać i o tej nowej wiadomości. Wiemy, że jest nasza, więc nie zapisuje się drugi raz.
po kolei, w każdej rozmowie
Wiadomości na jeden kanał Slacka wychodzą jedna po drugiej, w kolejności zapisu, więc wątek nigdy nie pokaże ich pomieszanych. Odpowiedzi wracające z jednego workspace’u obsługujemy w kolejności pisania, więc „tak”, a po nim „sorry, chodziło mi o nie”, docierają w tej kolejności. A widget pokazuje każdą wiadomość według chwili zapisu, niezależnie od tego, którymi drzwiami przyszła.
edycje i usunięcia idą za wiadomością
Wiadomość, która się zmienia, musi się zmienić wszędzie, inaczej drzwi się rozjadą.
- Edytuj w dashboardzie, a widget pokaże nowy tekst z małym „edytowano”, a kopia na Slacku się zaktualizuje.
- Edytuj albo usuń własną wiadomość na Slacku, a zmiana wróci do Spookata i pójdzie dalej do widgetu.
- Usuń wiadomość, z dowolnych drzwi, a zniknie dla odwiedzającego, dla członków i dla agentów, a kopia, którą Spookat wrzucił do wątku na Slacku, też zniknie. Wiadomość, którą ktoś sam napisał na Slacku, należy tam do niego, więc usuwa ją tam, a to wraca do Spookata jak każde inne usunięcie. Owner i admini dalej widzą ją w dashboardzie, z tekstem sprzed edycji, więc zawsze jest ktoś, kto może sprawdzić, co padło.
rozmowa ma wszędzie jedną nazwę
Każda rozmowa ma krótki ref, np. SP-00A1. Jest na karcie statusu na górze wątku na Slacku, w dashboardzie, w API i w webhookach. Powiedz komuś z zespołu „weź SP-00A1” w którymkolwiek z tych miejsc, a znajdzie tę samą rozmowę.
Tak samo z tym, kto się nią zajmuje. Weź rozmowę przyciskiem na karcie w Slacku, przypisz w dashboardzie albo każ agentowi przypisać przez API: karta, inbox i API pokazują tę samą osobę, a „moje” w dashboardzie znaczy wszędzie to samo.
notatki i przekazania też przechodzą przez drzwi
Nie wszystko w rozmowie jest dla odwiedzającego. Notatka napisana w dashboardzie jest tylko dla zespołu. Odwiedzający nigdy jej nie widzi, a agent czytający rozmowę przez API albo MCP widzi, więc notatka to też sposób, żeby zostawić agentowi instrukcję: „to reseller, odeślij do sprzedaży”.
Przekazania działają tak samo. Kiedy asystent strony uzna, że pytanie potrzebuje człowieka, albo odwiedzający o niego poprosi, rozmowa dostaje flagę dla zespołu, wątek na Slacku dostaje jeden ping, a karta statusu mówi dlaczego. Kto ją weźmie, z dowolnych drzwi, odpisuje w tej samej rozmowie, a odwiedzający widzi, że dołączyła osoba z zespołu.
co sprawdzamy
Każde drzwi mają własne testy i sprawdzają to samo ze swojej strony: wiadomość zapisuje się raz, ląduje w tej samej rozmowie, dociera do pozostałych drzwi, a edycja albo usunięcie idzie za nią. Dashboard, Slack, widget, API i MCP, wszystko tam jest. Zmiana, która psuje jakimś drzwiom widok rozmowy, wywala build, zanim wyjdzie.
Przed launchem puściliśmy też pętlę widget i Slack pod obciążeniem: 1000 wiadomości od odwiedzających na sekundę bez Slacka i 800 z każdą wrzuconą na Slacka, rozłożone na 1200 stron, bez ani jednego błędu i bez ani jednej zgubionej wiadomości. Metoda jest w teście obciążeniowym.
co to znaczy dla ciebie
Twój zespół odpisuje stamtąd, gdzie i tak siedzi. Osoba od płatności odpisuje z dashboardu, developer ze Slacka, a agent szkicuje odpowiedź na pytanie o API. Nikt niczego nie kopiuje między narzędziami i nikt się nie zastanawia, czy odwiedzający zobaczył odpowiedź.
Odwiedzający nie wie o niczym z tego. Widzi jeden czat, z ludźmi w środku, i każdą wiadomość dokładnie raz.
Zobacz, jak to działa, albo wypróbuj go na swojej prawdziwej stronie przez 14 dni, bez karty.