Klient chce umówić usługę. Dzisiaj zwykle otwiera stronę, szuka oferty, sprawdza termin i wypełnia formularz. A jeśli poprosi asystenta AI: "Znajdź serwis okien w Zawierciu i zapytaj o wolny termin"? Agent musi wybrać właściwą usługę, podać poprawne dane i nie pomylić wysłania zapytania z potwierdzoną rezerwacją.
WebMCP powstaje właśnie z myślą o takich sytuacjach. Pozwala udostępnić agentowi konkretne działania na stronie, zamiast zostawiać mu rozpoznawanie przycisków i odgadywanie kolejnych kroków. Dla właściciela firmy interesujące jest to, czy klient dzięki temu rzeczywiście załatwi swoją sprawę. Sama obecność nowego skrótu w specyfikacji strony niewiele zmienia.
Nie przebudowywałbym jednak każdej witryny tylko dlatego, że pojawiło się WebMCP. Przy prostej stronie usługowej lepszym pierwszym wydatkiem może być poprawienie formularza. Przy rozbudowanej wyszukiwarce, konfiguratorze albo systemie rezerwacji warto już rozważyć test jednej konkretnej funkcji.
Stan dokumentacji: 15 października 2026 r. To poradnik oparty na dokumentacji projektu i Chrome, z moimi rekomendacjami dotyczącymi wdrożenia. Scenariusze są ilustracyjne. Nie przedstawiam ich jako wyników testu ani wdrożeń wykonanych dla klientów.
Co to jest WebMCP?
WebMCP, czyli Web Model Context Protocol, to propozycja standardu przeglądarkowego, dzięki któremu strona może udostępnić agentom AI opisane narzędzia. Narzędzie oznacza tu konkretną funkcję: wyszukanie produktu, ustawienie filtrów, przygotowanie formularza albo wykonanie działania w aplikacji.
Autor strony określa, do czego funkcja służy i jakie dane przyjmuje. Agent korzystający z odpowiedniego środowiska może wywołać ją w kontekście otwartej strony. Dokumentacja opisuje WebMCP jako dodatkową warstwę nad istniejącym interfejsem, a nie zamiennik strony dla człowieka. Wprowadzenie do WebMCP w dokumentacji Chrome.
Najłatwiej wyobrazić to sobie na przykładzie formularza serwisu okien. Człowiek widzi pola z rodzajem usterki, miejscowością i danymi kontaktowymi. Agent powinien dostać równie jednoznaczny opis tych pól. Jeśli formularz służy tylko do zapytania o wycenę, opis narzędzia nie może sugerować, że jego wysłanie zamawia naprawę.
Ta różnica brzmi drobiazgowo, dopóki klient nie usłyszy od asystenta, że fachowiec przyjedzie jutro, choć firma otrzymała jedynie wiadomość.
Agent AI, chatbot i robot Google robią różne rzeczy
W rozmowach o AI łatwo połączyć kilka osobnych tematów. Tymczasem tekst przeczytany przez wyszukiwarkę i formularz obsłużony przez agenta to dwa różne zadania.
| Rozwiązanie | Zadanie | Przykład na stronie firmy |
|---|---|---|
| Robot wyszukiwarki | Pobiera treść do przetworzenia przez wyszukiwarkę | Odczytuje podstronę opisującą naprawę okien |
| Asystent odpowiadający na pytania | Przygotowuje odpowiedź na podstawie dostępnych informacji | Wyjaśnia, co obejmuje regulacja okuć |
| Agent korzystający z przeglądarki | Wykonuje kolejne czynności w interfejsie | Wybiera usługę i wypełnia pola formularza |
| Narzędzie WebMCP | Udostępnia konkretną funkcję strony agentowi | Pozwala przygotować zgłoszenie z określonymi parametrami |
To uproszczony podział zadań, nie rozłączne kategorie produktów. Jeden asystent może odpowiadać na pytania, korzystać z wyszukiwarki i wykonywać działania.
WebMCP nie jest samodzielnym chatbotem ani modelem językowym. Dla agentów jest dodatkową drogą do funkcji witryny. Projekt zakłada również możliwość korzystania ze zwykłej automatyzacji przeglądarki, gdy udostępnione narzędzia nie wystarczają do zadania. Założenia projektu WebMCP.
W praktyce nie wymagałbym od właściciela firmy zapamiętania całej terminologii. Wymagałbym za to od wykonawcy odpowiedzi na pytanie: co dokładnie będzie można zrobić na tej stronie i jak sprawdzimy, że działa poprawnie?
Jak działa WebMCP na stronie internetowej?
Zwykła automatyzacja przeglądarki może korzystać ze zrzutów ekranu, struktury dokumentu i drzewa dostępności. Agent rozpoznaje elementy i wykonuje działania podobne do kliknięć czy wpisywania tekstu. W WebMCP kod witryny udostępnia funkcję bezpośrednio. Nadal można korzystać z interfejsu, ale część operacji nie wymaga przechodzenia przez serię przycisków. Opis sposobów działania w repozytorium WebMCP.
Tak zaprojektowałbym przebieg zapytania o usługę:
Klient opisuje potrzebę
↓
Agent ustala brakujące informacje
↓
Narzędzie strony sprawdza dostępne opcje
↓
Strona pokazuje przygotowane zgłoszenie
↓
Klient sprawdza treść i zatwierdza wysłanie
↓
Serwer zapisuje zgłoszenie
↓
Strona i agent otrzymują wynik operacjiPrzy takim procesie nie wystarczy komunikat "gotowe". Wynik powinien mówić, co się wydarzyło: zapisano szkic, wysłano zapytanie czy zarezerwowano termin. Szczególnie wtedy, gdy firma musi jeszcze potwierdzić dostępność.
Jeżeli połączenie zerwie się po wysłaniu, agent nie powinien w ciemno ponawiać operacji. Najpierw trzeba ustalić, czy pierwsze zgłoszenie dotarło. Inaczej właściciel firmy może otrzymać kilka identycznych wiadomości, a klient nadal nie będzie wiedział, czy cokolwiek załatwił.
WebMCP a MCP: czym się różnią?
MCP służy do łączenia aplikacji AI z narzędziami i danymi. Takie połączenie może obsługiwać pracę poza otwartą witryną, np. przez serwer MCP. WebMCP dotyczy funkcji dostępnych w działającej stronie w przeglądarce. Nie jest następcą MCP ani jego bezpośrednią implementacją w JavaScript. Porównanie WebMCP i MCP.
| Pytanie | MCP | WebMCP |
|---|---|---|
| Gdzie udostępniasz funkcję? | W integracji z narzędziami lub danymi, np. na serwerze | W otwartej stronie internetowej |
| Czy potrzebujesz interfejsu witryny? | Nie zawsze | Interakcja jest związana z działającą stroną |
| Z jakim kontekstem pracujesz? | Z danymi i uprawnieniami udostępnionymi integracji | Z bieżącym stanem strony i sesji |
| Przykład zastosowania | Pobranie danych z systemu przez integrację | Zmiana filtrów w otwartym katalogu |
Nie wybierałbym między nimi na podstawie popularności nazwy. Jeżeli potrzebujesz nocnego przetwarzania dokumentów, zacznij od wymagań dotyczących integracji i pracy w tle. Jeżeli klient pracuje w konfiguratorze i chce sterować nim przez asystenta, WebMCP jest bliższe temu zadaniu.
Można też nie potrzebować żadnego z tych rozwiązań. Przy prostym obliczeniu w formularzu zwykła funkcja aplikacji może być wystarczająca.
Czy WebMCP już działa w przeglądarkach?
Tak, można je testować, ale trzeba odróżnić implementację eksperymentalną od powszechnej obsługi. Oficjalne zestawienie projektu wymienia origin trial w Chrome od wersji 149 i w Edge od wersji 150. Dla Brave opisuje eksperymentalną obsługę w Leo. Przy Firefoxie i Safari odsyła do stanowisk i prac nad standardem, co samo w sobie nie potwierdza gotowej funkcji dla użytkowników. Aktualny status implementacji.
Origin trial pozwala testować funkcję w określonych warunkach na prawdziwych witrynach. Nie należy z tego wyciągać wniosku, że każdy klient z aktualną przeglądarką i dowolnym asystentem skorzysta z narzędzi strony.
Przed wdrożeniem ustaliłbym konkretny zestaw: przeglądarka, jej wersja, agent oraz sposób udostępnienia funkcji. Potem sprawdziłbym go na środowisku testowym. Wpisanie do oferty "obsługa AI" bez wskazania tego zestawu utrudnia późniejszy odbiór prac.
Zwykła strona musi działać także bez WebMCP. Użytkownik powinien móc samodzielnie wyszukać usługę i wysłać formularz. Dodatkowa funkcja nie może zamknąć podstawowej drogi do kontaktu.
Dwa sposoby wdrożenia: formularz HTML albo funkcja JavaScript
Formularz HTML z opisem narzędzia
Declarative API wykorzystuje istniejący formularz. Atrybuty toolname i tooldescription opisują narzędzie, a pola formularza dostarczają jego parametrów. Można też doprecyzować znaczenie pola przez toolparamdescription.
W opisanym w dokumentacji przebiegu agent uzupełnia formularz, który pozostaje widoczny. Wysłanie może wymagać kliknięcia przez użytkownika. Osobny atrybut toolautosubmit umożliwia automatyczne wysłanie po wywołaniu narzędzia. Dokumentacja Declarative API.
Przy formularzu kontaktowym zacząłbym od wariantu z ręcznym zatwierdzeniem. Klient ma szansę zobaczyć, jaki adres e-mail i treść agent zamierza przekazać firmie. Automatyczne wyszukiwanie w publicznym katalogu oceniłbym inaczej niż wysłanie danych kontaktowych.
Narzędzie zarejestrowane w JavaScript
Imperative API pozwala zarejestrować funkcję przez document.modelContext.registerTool(). Definicja obejmuje nazwę, opis, schemat danych wejściowych i wykonanie operacji. To podejście przydaje się, gdy działanie wykracza poza pojedynczy formularz, np. zmienia stan konfiguratora. Dokumentacja tego API została zaktualizowana 15 października 2026 r. Dokumentacja Imperative API.
Sam wybór JavaScript nie przesądza o jakości integracji. Narzędzie o nazwie zrobWszystko będzie trudniejsze do kontrolowania niż funkcja przygotowująca konkretną konfigurację do sprawdzenia. Przy odbiorze poprosiłbym o opis działań, danych wejściowych i możliwych wyników, a dopiero później oglądał kod.
| Co ma robić integracja? | Od czego zacząłbym analizę |
|---|---|
| Uzupełnić prosty formularz | Declarative API i obecna obsługa formularza |
| Zmieniać kilka powiązanych opcji konfiguratora | Imperative API i reguły aplikacji |
| Przetwarzać dane bez otwartej strony | Integracja po stronie serwera, nie samo WebMCP |
| Wyświetlić opis oferty | Najpierw czytelna treść i zwykła nawigacja |
To propozycja doboru rozwiązania, nie gotowa wycena. Formularz połączony z kilkoma zewnętrznymi systemami może wymagać więcej pracy niż własny, dobrze uporządkowany konfigurator.
Przykład: zapytanie o naprawę okna w Zawierciu
Wyobraźmy sobie lokalny serwis. Klient prosi asystenta: "Chcę zapytać o regulację okna w Zawierciu. Mogę być w domu po południu".
Nie mamy jeszcze zgłoszenia gotowego do wysłania. Brakuje danych kontaktowych, a "po południu" nie oznacza konkretnego dnia ani terminu. Nie wiemy też, czy firma udostępnia kalendarz rezerwacji, czy oddzwania po otrzymaniu zapytania.
W takim projekcie rozdzieliłbym sprawdzenie oferty od przygotowania wiadomości. Agent mógłby najpierw ustalić, czy firma obsługuje wskazaną miejscowość i usługę. Następnie dopytałby o informacje potrzebne do kontaktu. Klient zobaczyłby podsumowanie przed wysłaniem.
| Etap proponowanego procesu | Co powinno się wydarzyć | Czego unikać |
|---|---|---|
| Sprawdzenie zakresu | Strona zwraca obsługiwane usługi i miejscowości | Dopisywania usług, których firma nie oferuje |
| Uzupełnienie danych | Agent pyta o brakujący sposób kontaktu | Wymyślania numeru telefonu lub adresu |
| Przygotowanie zgłoszenia | Klient widzi treść i zakres przekazywanych danych | Ukrytego wysłania wiadomości |
| Wysłanie | Serwer przyjmuje zgłoszenie i zwraca jego wynik | Komunikatu sukcesu przed odpowiedzią serwera |
| Odpowiedź dla klienta | Agent mówi, że firma otrzymała zapytanie | Ogłaszania potwierdzonej wizyty bez rezerwacji |
Jeśli serwis nie prowadzi internetowego kalendarza, WebMCP go za niego nie stworzy. Najpierw trzeba mieć wiarygodne źródło dostępności i ustalić zasady rezerwacji.
Ustalenie, kto potwierdza wizytę i kiedy, może zająć więcej pracy niż samo opisanie narzędzia. Niejasności między formularzem, skrzynką pocztową a kalendarzem właściciela pozostaną, nawet jeśli agent bezbłędnie odczyta wszystkie pola.
WebMCP a SEO: czy wdrożenie poprawi pozycje w Google?
Nie ma podstaw, żeby sprzedawać WebMCP jako gwarantowany sposób na wyższą pozycję albo cytowanie strony przez AI. Google podaje, że do obecności w AI Overviews i AI Mode nie są potrzebne specjalne pliki dla AI ani odrębne dane strukturalne. Nadal obowiązują wymagania wyszukiwarki i zasady dotyczące jakości strony. Google: funkcje AI i Twoja witryna.
Ja rozdzieliłbym te prace na dwa pytania. Pierwsze: czy klient może znaleźć firmę i zrozumieć jej ofertę? Drugie: czy po wejściu na stronę potrafi wykonać zadanie, samodzielnie lub z pomocą agenta? WebMCP jest bliższe drugiemu problemowi.
Nie zastępuje to pozycjonowania strony, poprawienia treści usług ani usunięcia przeszkód w indeksowaniu. Z kolei schema.org opisująca firmę czy artykuł nie wykonuje rezerwacji. Opis danych wejściowych narzędzia i dane strukturalne strony mają inne zastosowania, nawet jeśli w obu tematach pojawia się słowo "schema".
Jeżeli interesuje Cię przede wszystkim widoczność w odpowiedziach wyszukiwarek i asystentów, osobno opisałem SEO pod AI, AI Overviews i ChatGPT. Tutaj chodzi o korzystanie z funkcji witryny.
Bezpieczeństwo: czego nie oddawałbym agentowi bez kontroli?
Dokumentacja Chrome ostrzega przed prompt injection, czyli próbami podsunięcia modelowi nieuprawnionych instrukcji w czytanej treści. Opisuje też wskazówki oznaczające m.in. dane niezaufane, operacje tylko do odczytu i działania z istotnymi konsekwencjami. Są to sygnały dla agenta i przeglądarki. Nie traktowałbym ich jako zamiennika kontroli dostępu w aplikacji. Zasady bezpieczeństwa narzędzi WebMCP.
Moje minimum przy planowaniu takiej integracji wyglądałoby następująco:
| Działanie | Kontrola, której wymagałbym w projekcie |
|---|---|
| Odczyt publicznego cennika | Jasne jednostki, warunki i informacja, czego cena nie obejmuje |
| Przygotowanie wiadomości | Widoczne podsumowanie oraz możliwość poprawienia danych |
| Wysłanie zapytania | Potwierdzenie użytkownika i zabezpieczenie przed duplikatami |
| Odczyt prywatnego zamówienia | Sprawdzenie sesji i uprawnień do konkretnego zamówienia na serwerze |
| Płatność lub anulowanie rezerwacji | Wyraźna autoryzacja działania, z zakresem i konsekwencjami |
To rekomendacje wdrożeniowe, a nie obietnica, że sam standard egzekwuje wszystkie wymienione zasady.
Szczególnie ostrożnie podszedłbym do narzędzi opisanych jako "tylko do odczytu". Odczyt historii zamówień lub danych klienta nadal może ujawnić prywatne informacje. Chrome również zwraca uwagę, że brak zmiany stanu nie oznacza braku ryzyka przy udostępnianiu danych. Bezpieczeństwo i udostępnianie narzędzi.
W formularzu serwisowym nie zbierałbym informacji potrzebnych dopiero na późniejszym etapie. Do pierwszego kontaktu nie musi być potrzebny pełny adres mieszkania. W logach technicznych zapisałbym wynik operacji i identyfikator zgłoszenia, a nie całą rozmowę klienta z asystentem. Zakres danych trzeba ustalić świadomie, podobnie jak dostęp zespołu do tych logów.
Jak przygotować stronę na agentów AI bez przebudowy wszystkiego?
Zacząłbym od sprawdzenia jednej ścieżki użytkownika: od wejścia na usługę do odebrania wiadomości z formularza. Dopiero wtedy ustaliłbym, co poprawić i gdzie agent może pomóc.
Najpierw sprawdź, czy wiadomo, co oferujesz
Opis "kompleksowe rozwiązania dla każdego" nie pomaga w wyborze usługi. Potrzebne są nazwy usług, zakres, miejscowości i zasady kontaktu. Jeżeli cena zależy od oględzin, warto to napisać przy cenniku, a nie dopiero w odpowiedzi na reklamację.
Nie dopisywałbym treści wyłącznie dla botów. Na podstronie regulacji okien klient i tak chce wiedzieć, czy firma zajmuje się jego problemem, przyjeżdża do jego miejscowości i jak ustali koszt. Te informacje są przydatne niezależnie od sposobu przeglądania strony.
Przejdź formularz jak nowy klient
Sprawdź go na telefonie i klawiaturą. Zostaw puste wymagane pole. Wpisz błędny adres e-mail. Zobacz, czy komunikat wyjaśnia, co poprawić, i czy po poprawce treść wiadomości nadal jest w formularzu.
Jeżeli wysłanie kończy się cichym odświeżeniem strony, najpierw naprawiłbym informację o wyniku. Jeżeli właściciel nie otrzymuje wiadomości, analizowałbym wysyłkę. W takim stanie dodatkowa integracja tylko dostarczy kolejną drogę do tego samego błędu. Więcej przykładów znajdziesz we wpisie Strona ma wejścia, ale nikt nie pisze. Co sprawdzić?.
Wybierz jedno zadanie, które warto udostępnić
Dobrym kandydatem do pilotażu może być filtrowanie katalogu według kilku warunków. Słabszym: przewinięcie krótkiej strony do numeru telefonu. Oceniałbym rzeczywistą trudność zadania, częstotliwość jego wykonywania i koszt pomyłki.
Dokumentacja projektowania narzędzi zaleca określenie celu użytkownika, stanu początkowego oraz ograniczeń, a następnie przejście przez przykładową rozmowę. Wskazuje też potrzebę obsługi niepełnych danych i błędów. Projektowanie zadań dla WebMCP.
Na warsztacie z wykonawcą poprosiłbym o odegranie takiego scenariusza bez kodu. Klient zmienia zdanie, nie zna dokładnej nazwy usługi i wraca do wcześniejszego kroku. Jeżeli już w rozmowie nie wiadomo, co system powinien zrobić, nie ma sensu zaczynać od implementacji.
Ustal warunek wyłączenia eksperymentu
Przed pilotażem zapisałbym, kiedy wracamy do zwykłego interfejsu. Może to być brak obsługi w środowisku użytkownika, niejednoznaczna odpowiedź z systemu rezerwacji albo błąd, po którym nie potrafimy bezpiecznie ustalić wyniku operacji.
Wycofanie integracji powinno być możliwe bez wyłączenia formularza i całej strony. Przy zmieniającym się API to ważniejsze niż efektowna prezentacja jednego poprawnego przebiegu.
Jak sprawdzić, czy wdrożenie WebMCP rzeczywiście pomaga?
Nie wystarczy pokazać, że asystent raz poprawnie wypełnił formularz. Przy odbiorze zaproponowałbym zestaw powtarzalnych prób na danych testowych. Poniżej przykładowy plan, nie wyniki przeprowadzonego badania.
| Próba | Oczekiwany wynik |
|---|---|
| Klient podaje komplet danych | Formularz zawiera dokładnie te dane, bez dopisanych informacji |
| Brakuje wymaganej informacji | Agent pyta lub strona zwraca czytelny błąd; nie zgaduje |
| Klient zmienia usługę w trakcie | Podsumowanie i pola odpowiadają nowemu wyborowi |
| Termin znika przed zatwierdzeniem | System odmawia rezerwacji i pozwala wybrać inną opcję |
| Żądanie zostaje ponowione | Nie powstaje drugie zgłoszenie tej samej operacji |
| Sesja użytkownika wygasa | Operacja wymagająca logowania nie dochodzi do skutku |
| Przeglądarka nie obsługuje funkcji | Zwykła ścieżka formularza nadal działa |
| Zewnętrzna treść zawiera polecenie zmiany celu | System nie wykonuje niezatwierdzonego działania |
Przy porównaniu z obsługą przez zwykły interfejs mierzyłbym odsetek poprawnie zakończonych zadań, liczbę interwencji człowieka, czas oraz duplikaty. Wynik musi uwzględniać porażki. Jeśli agent wykonał operację, ale podał klientowi błędne podsumowanie, nie uznałbym próby za w pełni poprawną.
Trzeba też zapisać wersję modelu, przeglądarki, instrukcję początkową i stan aplikacji. Inaczej dwa pomiary mogą dotyczyć różnych warunków. Przy małej liczbie prób pokazałbym konkretne liczby i opisał przypadki, zamiast budować z nich procentową obietnicę poprawy konwersji.
Wykres skuteczności warto przygotować dopiero z takich pomiarów. Mniejsza liczba kroków na schemacie nie dowodzi jeszcze krótszego czasu ani większej liczby poprawnie wykonanych zadań.
Kiedy warto wdrażać WebMCP, a kiedy poczekać?
Najwięcej sensu widzę w testach tam, gdzie użytkownik wybiera spośród wielu opcji, wraca do wcześniejszych ustawień albo musi przenieść informacje między kilkoma widokami. Na prostej stronie usługowej próg opłacalności będzie inny.
| Rodzaj witryny | Moja rekomendacja na początek |
|---|---|
| Wizytówka firmy z telefonem i krótką ofertą | Poprawić ofertę, dostępność i kontakt; WebMCP zwykle odłożyć |
| Strona z prostym formularzem zapytania | Najpierw przetestować formularz, potem ocenić sens pilotażu |
| Katalog z wieloma filtrami | Rozważyć test wyszukiwania i filtrowania bez operacji zakupu |
| Konfigurator produktu lub usługi | Sprawdzić udostępnienie wyborów i podsumowania do zatwierdzenia |
| Aplikacja z rezerwacjami lub kontem klienta | Osobno ocenić spójność danych, uprawnienia i konsekwencje błędów |
Nie zakładam, że każda z tych firm ma już klientów korzystających z odpowiedniego agenta. To również trzeba sprawdzić. Nawet dobrze wykonana integracja może mieć mały sens biznesowy, jeśli nikt z odbiorców nie może z niej skorzystać albo zwykły formularz jest szybszy i prostszy.
W wycenie uwzględniłbym nie tylko dodanie narzędzia, lecz także testy błędnych danych, zabezpieczenia, utrzymanie i aktualizacje. Nie podaję jednej ceny za WebMCP, bo wyszukiwarka publicznego katalogu i operacja na prywatnym koncie klienta to różne zakresy odpowiedzialności.
Pytania, które warto zadać przed zamówieniem integracji
Czy potrzebuję nowej strony, żeby korzystać z WebMCP?
Nie zakładałbym tego z góry. Najpierw trzeba ocenić obecny kod i wybraną funkcję. Czasem rozsądne będzie rozszerzenie istniejącego formularza, a czasem wcześniej trzeba uporządkować sposób przetwarzania zgłoszeń. Sama nazwa CMS-a nie wystarczy do decyzji.
Czy muszę mieć na stronie okienko czatu?
Nie. Projekt przewiduje narzędzia używane także przez agentów działających w przeglądarce lub rozszerzeniu. Okienko czatu to osobny wybór interfejsu. Założenia WebMCP.
Czy po wdrożeniu każdy asystent AI zacznie obsługiwać moją stronę?
Nie zakładaj tego w umowie ani w planie sprzedażowym. Wymagaj wskazania obsługiwanego środowiska i demonstracji konkretnego zadania. Dostępność eksperymentalnego API nie jest testem kompatybilności z każdym produktem.
Czy WebMCP zastępuje dostępność strony?
Nie. W projekcie wprost rozdzielono narzędzia dla agentów od bezpośredniej współpracy z technologiami asystującymi. Nadal trzeba dbać o zwykły interfejs. Cele i ograniczenia projektu.
Co powinienem dostać od wykonawcy?
Opis udostępnionych działań, warunków ich użycia i sposobu zatwierdzania operacji. Do tego wyniki testów, listę wspieranych środowisk oraz instrukcję wyłączenia integracji. Poprosiłbym też o pokazanie błędu lub anulowania, nie tylko pomyślnego wysłania formularza.
Od czego zacząłbym na stronie małej firmy?
Od jednej rozmowy o tym, co klient ma na niej załatwić. Jeżeli celem jest telefon z pytaniem o usługę, być może wystarczy poprawić ofertę i widoczność kontaktu. Jeśli klient musi przejść konfigurację, porównać parametry i wysłać szczegółowe zapytanie, mamy konkretny proces do przeanalizowania pod kątem pomocy agenta.
WebMCP warto znać, ale nie wpisałbym go dziś automatycznie do każdej oferty tworzenia strony internetowej. Wolałbym najpierw pokazać właścicielowi firmy jedno zadanie, które działa poprawnie również wtedy, gdy klient poda niepełne dane albo zmieni zdanie.
Masz formularz, konfigurator lub system rezerwacji, który chcesz usprawnić? Podeślij adres i opisz, co klient powinien móc zrobić. Ustalimy, czy problem rozwiąże poprawa obecnego interfejsu, czy warto przygotować mały test integracji z agentem AI.
Co klient ma załatwić na Twojej stronie?
Podeślij formularz, konfigurator lub system rezerwacji. Sprawdzimy, co warto uprościć i czy pomoc agenta AI ma tu sens.
Porozmawiajmy o Twojej stronie


