# Ferrari, szpital i dwie różne odpowiedzi dla tego samego klienta > Chirurdzy z Great Ormond Street podpatrzyli pit stop w F1 i zmniejszyli liczbę błędów przy przekazywaniu pacjenta o 42%. Ta sama mechanika psuje komunikację z klientem, gdy masz osobnego bota na stronie i osobnego na telefonie. Source: https://chatmerce.eu/blog/dwa-kanaly-jedna-odpowiedz/ Language: pl-PL Published: 2026-08-21 --- W 2003 roku dwóch lekarzy z Great Ormond Street Hospital w Londynie — kardiochirurg Martin Elliott i intensywista Allan Goldman — wracało z konferencji i w hotelowym telewizorze zobaczyło Grand Prix. Patrzyli na pit stop: siedmiu ludzi, trzy sekundy, zero słów. Nikt nikogo nie pytał, co ma robić. Mieli wtedy konkretny problem. Nie w sali operacyjnej — operacje szły dobrze. Problem był w windzie i na korytarzu. Dziecko po operacji serca jedzie z bloku na oddział intensywnej terapii. Trzeba przekazać: pacjenta, trzy pompy infuzyjne, respirator, dreny, i to wszystko, co chirurg wie, a intensywista jeszcze nie. Dwadzieścia osób w małej sali, wszyscy mówią naraz, każdy robi swoje. I regularnie coś się gubi. Zamiast szukać lepszej procedury w literaturze medycznej, napisali do Ferrari. Ferrari odpowiedziało. Nigel Stepney z zespołu F1 obejrzał nagrania przekazań w szpitalu i powiedział to, co dla niego było oczywiste: wy nie macie problemu z szybkością, wy macie problem z tym, że nikt nie wie, kto jest dowódcą. W pit stopie jest jeden człowiek, który patrzy na całość i nie dotyka samochodu. Zespół z Londynu pojechał do Maranello, a potem dołączyli do tego dwaj byli kapitanowie lotniczy, Trevor Dale i Guy Hirst, od których wzięli listę kontrolną. Nowa procedura miała trzy elementy: jasno wyznaczonego koordynatora, ustaloną kolejność (najpierw sprzęt, potem informacja, na końcu pytania) i kartkę z listą punktów do przekazania. Wynik opublikowali w 2007 roku w _Pediatric Anesthesia_. Zaobserwowali 50 przekazań — 23 przed zmianą i 27 po. Średnia liczba błędów technicznych spadła z 5,42 do 3,15. Pominięć informacji: z 2,09 do 1,07. A przekazanie, wbrew intuicji, **skróciło się** — z 10,8 do 9,4 minuty. Odsetek pacjentów, u których nakładało się kilka błędów, spadł z 39% do 11,5%. Zwróć uwagę na to, czego w tej historii nie ma. Nie zatrudnili lepszych chirurgów. Nie kupili sprzętu. Nie skrócili operacji. Zmienili wyłącznie **moment przekazania** — jedyny fragment procesu, którego nikt wcześniej nie traktował jak procesu. ## To samo dzieje się, gdy klient przechodzi między Twoimi kanałami Klient pisze na czacie na stronie: „czy ta kurtka jest w rozmiarze L?”. Bot odpowiada. Klient wychodzi, bo dzwoni telefon. Trzy godziny później dostaje SMS z informacją o statusie zamówienia i odpisuje na niego: „to co z tym L?”. I tu jest Twoja winda ze szpitala. Bo po drugiej stronie SMS-a jest coś innego niż to, z czym rozmawiał na stronie. Inna konfiguracja, inna baza wiedzy, inna wersja polityki zwrotów. Klient tego nie wie i nie ma obowiązku wiedzieć — dla niego to jedna firma i jedna rozmowa. ## Co dokładnie się psuje Trzy rzeczy, w tej kolejności. **Klient powtarza się.** Najtańszy z tych problemów, ale najbardziej irytujący. Podał już numer zamówienia. Podaje go drugi raz. Kontekst nie przeszedł przez przekazanie, bo nie było przekazania. **Odpowiedzi się rozjeżdżają.** To poważniejsze. Widget mówi „zwrot do 30 dni”, bo tam ktoś wgrał nowy regulamin. SMS mówi „14 dni”, bo tam wgrywał ktoś inny, w marcu. Klient dostał od Twojej firmy dwie różne informacje o tym samym i jedna z nich jest nieprawdziwa. Jeśli powoła się na tę korzystniejszą, masz problem, którego nie da się wygrać dyskusją. **Zespół przestaje wierzyć danym.** W statystykach masz dwa osobne raporty, których nie da się zsumować, bo ta sama rozmowa figuruje raz jako dwie. Pytanie „ile rozmów obsłużyliśmy” przestaje mieć jedną odpowiedź, a to jest moment, w którym ludzie przestają otwierać dashboard. ## Dlaczego kanały zawsze się rozjeżdżają To nie kwestia niechlujstwa. To kwestia tego, jak większość firm dochodzi do drugiego kanału. ### Konfiguracja jest kopią, nie źródłem Pierwszy kanał powstaje jako projekt. Drugi powstaje jako **kopia pierwszego** — ktoś przekleja prompt, wgrywa te same PDF-y, ustawia ten sam ton. W dniu wdrożenia oba są identyczne, więc problemu nie widać. Rozjazd zaczyna się przy pierwszej zmianie, której nikt nie zreplikował. Nie przy dużej — przy małej. Zmiana godzin dostawy w grudniu. Nowy dostawca płatności. Poprawka jednego zdania w regulaminie. Każda z nich osobno jest niewinna, ale one się kumulują i nie ma nikogo, kto by to kumulowanie widział. Po roku masz dwa boty, które odpowiadają różnie, i nikt nie potrafi wskazać momentu, w którym to się stało. ### Nie ma koordynatora Wróć do uwagi Stepneya: nikt nie wie, kto jest dowódcą. W komunikacji z klientem jest dokładnie tak samo. Kto odpowiada za to, że kanały mówią to samo? Zwykle odpowiedź brzmi „no, marketing i obsługa razem”, co znaczy: nikt. Szpital nie rozwiązał tego lepszą komunikacją między ludźmi. Rozwiązał to wyznaczeniem jednej osoby, której zadaniem było **patrzeć na całość i nie dotykać samochodu**. To rola, nie dobra wola. ### „Zintegrujemy to później” to najdroższa wersja Integracja post factum oznacza, że masz już dwa źródła prawdy i musisz zdecydować, które wygrywa. A to nie jest decyzja technologiczna, tylko biznesowa: który regulamin jest obowiązujący, ta wersja z widgetu czy ta z SMS-a? Ktoś musi to przeczytać i porównać. Tego nie zrobi żaden konektor. Dlatego jedna konfiguracja jest tańsza na starcie niż dwie, które później zszywamy — nie dlatego, że mniej kosztuje wdrożenie, ale dlatego, że nie generuje pracy, która nie ma właściciela. ### Czego jedna konfiguracja nie naprawi Żeby było uczciwie: wspólny prompt i wspólna baza wiedzy nie rozwiążą wszystkiego. Kanały mają różne ograniczenia i to jest nieusuwalne. RCS ma limity znaków i inne zasady po stronie operatora niż widget na stronie. SMS nie pokaże karuzeli produktów. To, co na stronie jest wygodnym formularzem, w wiadomości musi być trzema pytaniami po kolei. Wspólna konfiguracja znaczy „ta sama wiedza i ten sam ton”, nie „identyczny format” — i firma, która obiecuje to drugie, obiecuje coś, czego kanały fizycznie nie pozwalają dowieźć. Nie naprawi też złej treści. Jeśli Twój regulamin jest napisany tak, że nikt go nie rozumie, będzie równie niezrozumiały w obu kanałach, tylko konsekwentnie. ## Co z tym zrobić Trzy rzeczy, w kolejności, w jakiej mają sens — i pierwsze dwie możesz zrobić w tym tygodniu, bez zmiany narzędzia. **1. Ustal jedno źródło prawdy.** Jeden zestaw dokumentów, z którego karmione są wszystkie kanały. Nie „ten sam plik w dwóch miejscach” — jedno miejsce, z którego oba czytają. Jeśli technicznie nie da się tego zrobić w Twoim obecnym setupie, to jest właśnie ten koszt, o którym mówiłem wyżej. **2. Wyznacz koordynatora.** Imiennie. Jedna osoba, która przy każdej zmianie w treści odpowiedzi pyta „a drugi kanał?”. To pół godziny pracy w miesiącu, jeśli robi się to na bieżąco, i dwa tygodnie audytu, jeśli się nie robi. **3. Sprawdź rozjazd, zanim sprawdzi go klient.** Weź dziesięć najczęstszych pytań i zadaj je w każdym kanale, ręcznie, raz w miesiącu. To najprostszy test, jaki istnieje, i większość firm nigdy go nie zrobiła. Prawdopodobnie znajdziesz co najmniej jedną rozbieżność już przy pierwszym podejściu. ### Jak to wygląda u nas W Chatmerce ten sam agent — ten sam prompt, ta sama baza wiedzy — obsługuje widget na stronie, RCS i dwukierunkowy SMS. To nie jest funkcja dołożona z boku, to jest teza produktu: konfigurujesz raz, więc nie ma czego rozjeżdżać, i nie potrzebujesz koordynatora do pilnowania czegoś, co technicznie nie może się rozejść. Zmieniasz regulamin w jednym miejscu i zmienia się wszędzie. Jeśli masz dziś dwa kanały i podejrzewasz, że mówią różne rzeczy — [napisz do nas](/contact), pokażemy to na Twoich pytaniach. Więcej o samym kanale RCS: [RCS a SMS: czym się różni](/blog/rcs-a-sms-czym-sie-rozni). --- Źródło danych ze szpitala: K.R. Catchpole i in., _Patient handover from surgery to intensive care: using Formula 1 pit-stop and aviation models to improve safety and quality_, „Pediatric Anesthesia” 17(5), 2007, s. 470–478. Stan tekstu: sierpień 2026.