# sześcioro drzwi, jedna rozmowa Twój zespół może odpisywać ze Slacka, dashboardu, API albo przez agenta, a odwiedzający widzi jedną czystą rozmowę. Co robią te drzwi i czemu nic nie pojawia się dwa razy. 2026-11-06 · Kuba 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 1. **Widget.** Tu pisze odwiedzający i tu czyta każdą odpowiedź. 2. **Slack.** Każda rozmowa to wątek na kanale, który wybrałeś. Zespół odpisuje w wątku. Setup jest w [poradniku o Slacku](/pl/blog/answer-website-chat-from-slack/). 3. **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. 4. **Inbox w dashboardzie.** Każda rozmowa, z zakładkami otwarte, moje i zamknięte, wyszukiwaniem, notatkami i polem na odpowiedź. 5. **API.** Klucz i kilka wywołań REST: lista rozmów, odczyt jednej, odpowiedź, przypisanie, zamknięcie. 6. **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](/pl/blog/claude-code-live-chat/) 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](/pl/blog/1000-messages-a-second/). ## 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](/pl/how/), albo wypróbuj go na swojej prawdziwej stronie przez 14 dni, bez karty. --- source: https://spookat.com/pl/blog/reply-from-anywhere/