Service Safari to metoda badawcza, w której projektant wciela się w klienta i przechodzi usługę od początku do końca — płacąc, czekając i frustrując się naprawdę, a przy okazji notując każdy punkt styku. Zwykle robi się to planowo, z arkuszem obserwacji. Mnie się po prostu przydarzyło: chciałem kupić wakacje, a zawodowy odruch włączył się sam. Im dłużej trwała rezerwacja, tym więcej miałem notatek. A Service Safari is a research method where a designer steps into the customer's shoes and walks a service end to end — genuinely paying, waiting and getting frustrated, while noting every touchpoint along the way. Normally you plan it, observation sheet in hand. Mine simply happened to me: I wanted to buy a holiday, and the professional reflex switched itself on. The longer the booking took, the more notes I had.
Zastrzeżenie, które uczciwie stawiam na początku: nie znam branży travel od środka. Nie wiem, jak wyglądają systemy rezerwacyjne touroperatorów, umowy między agentami ani ekonomia tego biznesu. Może aplikacja mobilna słusznie nie jest tu priorytetem, a duplikaty ofert mają głęboki sens handlowy. Dlatego wszystko poniżej to hipotezy klienta-projektanta, nie audyt — a swoje uwagi najpierw wysłałem prywatnie znajomemu z grupy, do której należy serwis. Publicznie zostawiam wersję, z którą można dyskutować. The caveat I put up front, honestly: I don't know the travel industry from the inside. I don't know what tour-operator reservation systems look like, how agent agreements work, or the economics of this business. Maybe the mobile app rightly isn't a priority here, and duplicate offers make deep commercial sense. So everything below is a customer-designer's hypothesis, not an audit — and I first sent my notes privately to a friend at the group that owns the service. What I publish is the version one can argue with.
Zacząłem tak, jak chyba większość: od otwarcia kilku serwisów naraz — Itaka, Rainbow, TUI, Coral Travel i wakacje.pl. Wygrało to ostatnie, świadomie i zasłużenie: największa baza ofert i przyzwoite filtry. Jako multiagent agregują oferty kilkudziesięciu touroperatorów, więc z jednego miejsca widziałem praktycznie cały rynek — u pojedynczego organizatora widzę tylko jego kawałek. Na etapie odkrywania to przewaga nie do przebicia. I started the way most people probably do: several sites open at once — Itaka, Rainbow, TUI, Coral Travel and wakacje.pl. The last one won, deliberately and deservedly: the biggest inventory and decent filters. As a multi-agent they aggregate offers from dozens of tour operators, so from one place I could see practically the whole market — a single operator only ever shows me its own slice. At the discovery stage that advantage is hard to beat.
Skala robi wrażenie także na papierze: to flagowa marka największego multiagenta turystycznego w Polsce (w grupie Wirtualnej Polski od 2015), z ofertą ok. 80 organizatorów, siecią kilkuset salonów i — według ich własnego biura prasowego — ponad milionem obsłużonych klientów rocznie. Piszę to z uznaniem, bo krytyka bez kontekstu jest tania: discovery wygrali w przedbiegach. Safari zaczęło się później. The scale impresses on paper too: it's the flagship brand of Poland's largest travel multi-agent (part of the Wirtualna Polska group since 2015), carrying offers from about 80 operators, a network of several hundred physical branches and — according to their own press office — over a million customers served a year. I write this with respect, because criticism without context is cheap: they won discovery hands down. The safari started later.
Przy przeglądaniu na dużą skalę zaczyna się rzucać w oczy: ten sam hotel wraca co kilka pozycji, w innym pakiecie i innej cenie — na moje oko dotyczyło to nawet 40% listy, z rozbieżnościami sięgającymi kilku tysięcy złotych. Klient nie porównuje ofert, klient porównuje hotele. Lekcja: architektura oferty to nie to samo co architektura informacji. Porównywarka, która sama ze sobą konkuruje ceną, aż prosi się o widok grupowany po hotelu — model, który w polskim e-commerce spopularyzowało Ceneo. Browse at scale and a pattern jumps out: the same hotel returns every few rows, in a different package at a different price — to my eye up to 40% of the list, with gaps reaching thousands of złoty. Customers don't compare offers; customers compare hotels. Lesson: offer architecture is not information architecture. A comparison site that price-competes with itself is begging for a hotel-grouped view — the model Ceneo popularised in Polish e-commerce.
Filtrowanie zawęziło mi tysiąc ofert sprawnie, ale między „listą wyników" a „decyzją" jest jeszcze etap, którego serwis nie obsługuje: porównanie kilkudziesięciu kandydatów według własnych kryteriów. Skończyłem z 70 zakładkami w przeglądarce. Lekcja: lejek nie kończy się na liście — najwięcej pracy klient wykonuje dokładnie tam, gdzie kończą się narzędzia. Filtering narrowed a thousand offers down efficiently, but between “results list” and “decision” there's a stage the service doesn't support: comparing a few dozen candidates against your own criteria. I ended up with 70 browser tabs. Lesson: the funnel doesn't end at the list — the customer does the most work exactly where the tools end.
W aplikacji jest asystent AI — i to dobrze. Ale na prośbę o porównanie dwóch ofert z ulubionych odpowiedział wprost: „Niestety nie mam informacji na ten temat" — i zaproponował kontakt z konsultantem. To odwrócona kolejność wdrażania AI: czat jest, a zadania, które naprawdę bolą (porównanie, weryfikacja opinii, pilnowanie terminów), zostają u klienta. Lekcja: asystent, który nie zdejmuje pracy, jest gadżetem — wartość AI zaczyna się od najcięższego zadania w ścieżce, nie od okienka czatu. The app has an AI assistant — good. But asked to compare two offers from my favourites, it replied flatly: “Unfortunately, I have no information on this topic” — and offered me a human consultant. That's AI adoption in reverse order: the chat is there, while the genuinely painful jobs (comparison, review verification, deadline watching) stay with the customer. Lesson: an assistant that doesn't take work off your hands is a gadget — AI's value starts at the heaviest task in the journey, not at the chat window.

Rezerwowałem dwa pokoje dla rodziny — i tu ścieżka cyfrowa po prostu się skończyła. W salonie w galerii handlowej spędziliśmy blisko dwie godziny, bo system nie przepuszczał wybranej konfiguracji: pokój z widokiem na morze był w ofercie, ale rezerwacja z nim nie przechodziła dalej. Uratował dopiero telefon do biura obsługującego ofertę i ręczna poprawka po drugiej stronie. Lekcja: happy path kończy się tam, gdzie zaczyna się prawdziwa rodzina. Sprzedaż domknął człowiek — wbrew systemowi, nie dzięki niemu. I was booking two rooms for a family — and here the digital path simply ended. We spent close to two hours at a shopping-mall branch, because the system wouldn't accept the chosen configuration: the sea-view room was in the offer, yet the booking wouldn't proceed with it. What saved it was a phone call to the servicing office and a manual fix on the other end. Lesson: the happy path ends where a real family begins. A human closed the sale — against the system, not thanks to it.
Po godzinach spędzonych w serwisie www o istnieniu aplikacji mobilnej dowiedziałem się właściwie przypadkiem — coś mnie tknęło, żeby sprawdzić sklep z aplikacjami. Pierwsze wrażenie miała bardzo dobre; potencjał jest. Lekcja: najlepszy kanał nie istnieje, jeśli nikt o nim nie wie — odkrywalność kanału to też projekt, nie dodatek. (A jeśli apka celowo nie jest promowana, bo transakcje i tak żyją na www — to po co jej rozwijany asystent AI? Jedno z pytań badawczych poniżej.) After hours on the website, I learned the mobile app existed almost by accident — something nudged me to check the app store. Its first impression was very good; the potential is there. Lesson: the best channel doesn't exist if nobody knows about it — channel discoverability is design work, not an afterthought. (And if the app is deliberately unpromoted because transactions live on the web anyway — why does it get a growing AI assistant? One of the research questions below.)

Finał: całość trzeba było opłacić do 20:45, a bramka płatności w aplikacji wyrzucała mnie z procesu — za każdym razem. Rezerwację uratowało przejście na stronę w mobilnej przeglądarce, tuż przed deadline'em. Lekcja: niezawodność płatności to UX, nie „sprawa backendu" — ostatnie 30 sekund ścieżki waży więcej niż cały piękny onboarding przed nim. Do kompletu: zdjęcia moich rezerwacji w apce nie załadowały się nigdy. The finale: everything had to be paid by 20:45, and the in-app payment gateway kept throwing me out of the flow — every single time. The booking was saved by switching to the website in a mobile browser, just before the deadline. Lesson: payment reliability is UX, not “a backend issue” — the last 30 seconds of the journey outweigh all the beautiful onboarding before them. For completeness: the photos on my bookings in the app never loaded at all.
Najdłuższy etap tej usługi zaczyna się po przelewie: tygodnie czekania, dokumenty, odprawa, transfery. To czas, w którym aplikacja mogłaby być najmocniejszym punktem całej relacji — a na razie wita mnie potwierdzoną rezerwacją z szarym prostokątem w miejscu zdjęcia hotelu. Lekcja: post-purchase to najczęściej osierocony etap ścieżki, choć właśnie tam rozstrzyga się, czy klient wróci. The longest stage of this service starts after the transfer: weeks of waiting, documents, check-in, transfers. That's when the app could be the strongest point of the whole relationship — and for now it greets me with a confirmed booking and a grey rectangle where the hotel photo should be. Lesson: post-purchase is the most orphaned stage of the journey, even though that's where a customer's return is decided.

Etap porównania, którego zabrakło w serwisie, zbudowałem sobie sam — z Claude'a. To nie była żadna inżynieria: wrzucałem linki i pisałem po ludzku, czego chcę. Różnica względem wbudowanego asystenta była brutalna: ich AI nie potrafiło porównać dwóch ofert, mój agent porównał siedemdziesiąt. The comparison stage missing from the service, I built for myself — out of Claude. No engineering involved: I pasted links and wrote in plain language what I wanted. The difference versus the built-in assistant was brutal: their AI couldn't compare two offers; my agent compared seventy.
Podobne zjawisko opisywałem wiosną na Mobile Trends Conference — w bankowości: kiedy klient przychodzi z własnym AI, przewaga pięknego interfejsu topnieje, a zaczyna się liczyć to, co usługa potrafi wystawić agentowi. Wtedy była to teza ze sceny (AI-driven Liquid UI). Tu przeżyłem ją jako klient. I described the same phenomenon in banking this spring at Mobile Trends Conference: once the customer arrives with their own AI, the advantage of a beautiful interface melts away, and what matters is what the service can expose to the agent. Back then it was a stage thesis (AI-driven Liquid UI). Here I lived it as a customer.
Zabrakło jednego: interfejsu po stronie sklepu. Musiałem otwierać 70 zakładek i wklejać linki ręcznie — pewnie istnieje sprytniejszy sposób, ale nie powinienem go szukać. Gdyby platforma wystawiała ustrukturyzowane dane ofert dla agentów klienta (choćby przez MCP — otwarty protokół, którym narzędzia AI podłącza się do usług), byłbym najlepiej obsłużonym klientem w historii tego sklepu. A sklep wiedziałby o moich kryteriach więcej niż jakikolwiek formularz preferencji. One thing was missing: an interface on the shop's side. I had to open 70 tabs and paste links by hand — there's probably a cleverer way, but I shouldn't have to hunt for it. If the platform exposed structured offer data to customers' agents (say via MCP — the open protocol for plugging AI tools into services), I'd be the best-served customer in that shop's history. And the shop would know more about my criteria than any preference form ever captured.
Stąd teza, z którą wychodzę z tego safari: e-commerce niedługo nie będzie projektowany tylko dla ludzi. Będzie projektowany dla ludzi, którzy przychodzą z agentami. Wygra ten, kto pierwszy potraktuje agenta klienta jak kanał sprzedaży — a nie jak scrapera do zablokowania. Hence the thesis I take away from this safari: e-commerce will soon not be designed for humans only. It will be designed for humans who arrive with agents. The winner will be whoever first treats the customer's agent as a sales channel — not as a scraper to block.
To rozdział, którego w klasycznym rancie by nie było — ale Service Safari bez pytań badawczych to tylko pamiętnik.A classic rant wouldn't have this chapter — but a Service Safari without research questions is just a diary.
Pracuję w bankowości, więc ból systemów legacy, integracji i regulacji znam z pierwszej ręki — łatwo mi sobie wyobrazić, że za każdą z moich obserwacji stoi powód, którego nie widzę. Dlatego to nie jest tekst „jak oni mogli", tylko zestaw hipotez od klienta, który akurat zawodowo projektuje usługi. Jeżeli pracujesz w travelu i wiesz, gdzie się mylę — napisz, chętnie się doedukuję i poprawię ten tekst. I work in banking, so I know the pain of legacy systems, integrations and regulation first-hand — it's easy for me to imagine that behind every observation stands a reason I can't see. So this isn't a “how could they” piece; it's a set of hypotheses from a customer who happens to design services for a living. If you work in travel and know where I'm wrong — write to me; I'll gladly learn and correct this text.
A jeśli nie pracujesz w travelu, zostawiam pytanie, które zabieram z tego safari do własnej roboty: w którym miejscu Twojej usługi sprzedaż ratuje dziś człowiek — wbrew systemowi? Bo dokładnie tam jest następny projekt do zrobienia. Najlepiej dyskutuje się o tym na LinkedIn. And if you don't work in travel, here's the question I take from this safari back to my own work: where in your service does a human currently rescue the sale — against the system? Because that's exactly where the next project lives. The best place to discuss it is LinkedIn.
Cały proces z tego tekstu — dekodowanie linków z ofertami, twarde filtry, weryfikacja opinii na niezależnych platformach, ukryte koszty, komary, pogoda i shortlisty scenariuszowe — zapisałem jako skill dla Claude'a. Ta wersja jest zgeneralizowana: bez naszych rodzinnych kryteriów, do wypełnienia własnymi. Bierz, używaj, przerabiaj — a następne wakacje wybierzesz w godzinę, nie w trzy wieczory. The whole process from this essay — decoding offer links, hard filters, review verification across independent platforms, hidden costs, mosquitoes, weather and scenario-based shortlists — saved as a Claude skill. This version is generalized: our family criteria stripped out, ready for your own. Take it, use it, remix it — and pick your next holiday in an hour, not three evenings.
Instalacja: Claude → Ustawienia → Capabilities → Skills. Plik .skill to zwykły zip z instrukcją SKILL.md w środku — zajrzyj, co instalujesz (tak należy robić z każdym skillem z internetu). Więcej plików do pobrania znajdziesz w case study Zbudowane vibe-codingiem.Installing: Claude → Settings → Capabilities → Skills. A .skill file is a plain zip with a SKILL.md inside — peek before you install (as you should with any skill from the internet). More downloads live in the Built by vibe-coding case study.