Jak AI połączone z CRM przygotowuje handlowca do spotkania i co robi z notatką po nim?

Asystent AI połączony z CRM przez serwer MCP może w kilka sekund zebrać historię kontaktów z klientem, pokazać otwarte oferty, ostatnie notatki i zaplanowane zadania, a po spotkaniu zapisać notatkę w systemie po jednorazowym potwierdzeniu handlowca. Nie wymaga zmiany CRM-u ani migracji danych. Wystarczy serwer MCP po stronie firmy i kilka zdefiniowanych narzędzi.

Piotr ma dziś pięć spotkań. O 8:45 otwiera czat i pisze: "Powiedz mi, co wiem o firmie Nowak Logistics przed spotkaniem za kwadrans." Za chwilę dostaje odpowiedź: ostatni kontakt 18 dni temu, rozmowa telefoniczna, notatka mówi, że czekają na decyzję zarządu w sprawie licencji dla 12 użytkowników. Otwarta szansa wygasa za 11 dni. W zadaniach jest dziś zaplanowany follow-up, żaden mail od trzech tygodni. Piotr wie, o co spytać na wejściu. Bez klikania po zakładkach, bez szukania w skrzynce, bez "poczekaj, sprawdzę" wypowiedzianego na korytarzu.

Taki efekt jest osiągalny na istniejących danych w CRM-ie, który już macie. Asystent nie wymaga przepisywania historii ani żadnego przygotowania po stronie handlowca.

Jak serwer MCP łączy asystenta AI z Waszym CRM-em?

MCP, czyli Model Context Protocol, to otwarty standard łączenia asystentów AI z zewnętrznymi programami i bazami danych. Projekt jest rozwijany pod opieką Linux Foundation. Serwer MCP to proces uruchomiony po stronie firmy, który tłumaczy pytania asystenta AI na zapytania do API Waszego CRM-u i zwraca wyniki w formacie zrozumiałym dla asystenta.

CRM nie wie, że po drugiej stronie jest AI. Widzi zwykłe zapytanie API z tokenem autoryzacyjnym, takie samo jak z aplikacji mobilnej albo innej integracji. Asystent dostaje zestaw narzędzi: pobierz kontakt po nazwie firmy, pokaż szanse sprzedaży przypisane do handlowca, wyświetl historię aktywności dla danej organizacji, dodaj notatkę. Sam decyduje, które narzędzie wywołać i w jakiej kolejności, żeby odpowiedzieć na pytanie handlowca.

Ważna rzecz: serwer MCP nie tworzy osobnej bazy danych ani nie kopiuje danych z CRM-u do żadnego zewnętrznego miejsca. Każde zapytanie handlowca trafia do CRM-u w czasie rzeczywistym i zwraca aktualne dane. To, co asystent pokazuje, jest tym samym, co zobaczyłby handlowiec po otwarciu karty kontaktu w CRM-ie.

Co dokładnie widzi handlowiec przed spotkaniem?

Zależy to od tego, które dane CRM-u udostępnicie przez serwer MCP. Typowy zestaw to:

• Dane kontaktu i firmy: nazwa organizacji, osoba kontaktowa, stanowisko, telefon, adres, branża. Wszystko, co macie wypełnione w kartotece.
• Szanse sprzedaży: nazwa szansy, etap w lejku, wartość oferty, data ostatniej zmiany statusu, data planowanego zamknięcia.
• Historia aktywności: notatki z rozmów telefonicznych, zarejestrowane wiadomości e-mail, spotkania z datami i podsumowaniami.
• Zadania i następne kroki: otwarte zadania przypisane do kontaktu lub szansy, kto jest odpowiedzialny, termin realizacji.

Handlowiec pisze jedno pytanie. Asystent zbiera dane z kilku narzędzi równocześnie i oddaje je jako briefing: kto to jest, gdzie są w procesie sprzedaży, co jest otwarte, co trzeba zrobić. Nie surowe dane z API, ale czytelny tekst do przeczytania w 30 sekund.

Można też pytać szczegółowo. "Kiedy ostatnio rozmawialiśmy z Kowalski & Partners i co ustaliliśmy?" albo "Które szanse w moim lejku wygasają w ciągu 14 dni?" To nadal jedno pytanie w czacie, bez przechodzenia przez zakładki. Asystent przeszukuje CRM za każdym razem, gdy dostaje pytanie, nie pamięta danych z poprzedniej rozmowy.

Jakie CRM-y można podłączyć?

Każdy CRM z REST API można obsłużyć przez serwer MCP. W praktyce najczęściej pracujemy z:

• Pipedrive: bardzo dojrzałe API z osobnymi endpointami dla osób, organizacji, szans, aktywności, notatek i zadań. Zapis i odczyt działają od ręki, dokumentacja jest szczegółowa.
• HubSpot: rozbudowane API dla kontaktów, firm, transakcji i logowania e-maili. Pełna historia komunikacji jest dostępna, jeśli macie HubSpot Sales Hub z aktywną integracją skrzynki pocztowej.
• Salesforce: najbardziej rozbudowane API z dostępnych, ale konfiguracja uprawnień jest złożona. Wymaga ustawienia odpowiedniego profilu API i połączonych obiektów po stronie Salesforce zanim cokolwiek zadziała.
• Livespace: polski CRM z dostępnym API, obsługuje kontakty, szanse sprzedaży i historię aktywności.

Własny CRM zbudowany na bazie MySQL albo PostgreSQL też da się podłączyć: albo przez wewnętrzne API, albo bezpośrednio przez serwer MCP z dostępem do bazy. Tu potrzeba więcej pracy przy definiowaniu narzędzi, bo nie ma gotowej dokumentacji publicznej.

Jedno zastrzeżenie na start: jeśli Wasz CRM jest starą instalacją bez API i bez możliwości bezpośredniego dostępu do bazy, najpierw trzeba zadbać o dostęp do danych. Serwer MCP nie pomoże, gdy dane są zamknięte w systemie bez żadnego wyjścia dla integracji.

Jak działa zapis notatki do CRM po spotkaniu?

Po spotkaniu Piotr wraca do czatu i pisze: "Notatka po Nowak Logistics: zarząd zaakceptował zakup, ale chcą wdrożenie dopiero w lutym, czekają na zamknięcie budżetu na Q1. Zadzwonię za dwa tygodnie." Asystent formatuje to jako notatkę i pokazuje podgląd: data, treść, przypisanie do kontaktu i szansy, typ aktywności.

Piotr sprawdza, poprawia ewentualne nieścisłości, potwierdza. Dopiero wtedy serwer MCP wywołuje endpoint API CRM-u i notatka ląduje w historii aktywności. Asystent pyta też od razu: dodać zadanie z terminem za dwa tygodnie? Jedno kliknięcie i zadanie pojawia się w CRM.

Krok potwierdzenia przed zapisem jest obowiązkowy i nie powinno się go pomijać. U jednego klienta trafiliśmy na sytuację, gdzie wersja bez akceptacji przez tydzień powodowała, że asystent czasem przypisywał notatkę do kontaktu aktywnego w poprzedniej rozmowie, nie do tego, o którym właśnie mówił handlowiec. Dane w CRM-ie są czułe: zły wpis trudno potem wyśledzić. Pięć sekund na podgląd to mała cena za pewność, że historia klienta jest czysta.

Uprawnienia: kto przez asystenta widzi co?

To pytanie pada przy każdym wdrożeniu. Handlowiec nie powinien przez asystenta widzieć klientów kolegi. Menedżer powinien widzieć wszystkich. Dyrektor może chcieć widoku zagregowanego, bez szczegółów poszczególnych kontaktów.

Serwer MCP może nakładać reguły widoczności na poziomie każdego narzędzia. Narzędzie "pobierz szanse sprzedaży" zwraca wtedy tylko rekordy przypisane do użytkownika, który zadaje pytanie. Wymaga to, żeby serwer MCP wiedział, kto pyta, co rozwiązuje się przez token sesji przekazywany przy każdym zapytaniu asystenta.

W CRM-ach z rozbudowanym modelem uprawnień, jak Salesforce, można polegać na wbudowanych regułach systemu: serwer MCP loguje się tokenem konkretnego użytkownika, a Salesforce sam pilnuje widoczności zgodnie z konfiguracją ról i profili. W Pipedrive i HubSpot reguły filtrowania po właścicielu rekordu trzeba zdefiniować ręcznie w serwerze MCP. Żadne z tych podejść nie jest trudniejsze technicznie, ale wybór ma wpływ na to, gdzie konfiguracja uprawnień żyje: w serwerze MCP czy w samym CRM-ie.

Dla programisty: jak to wygląda od strony technicznej?

Serwer MCP definiuje narzędzia w schemacie JSON, który asystent AI dostaje przy uruchomieniu. Każde narzędzie ma nazwę, opis i parametry wejściowe. Asystent sam decyduje, kiedy i które narzędzie wywołać w trakcie rozmowy z handlowcem.

Przykładowe narzędzie dla Pipedrive to get_person_activities: przyjmuje parametr query (nazwa firmy albo imię osoby kontaktowej) i opcjonalny limit określający liczbę ostatnich aktywności. Serwer po wywołaniu tego narzędzia robi zapytanie do Pipedrive API, szuka osoby lub organizacji, pobiera aktywności z pola subject, note i done, formatuje wynik jako tekst i zwraca go asystentowi. Asystent wplata dane w odpowiedź dla handlowca.

Przy wdrożeniu CRM ważny jest też zestaw narzędzi do zapisu: dodaj notatkę do kontaktu, utwórz zadanie, zaktualizuj etap szansy. Każde z nich powinno mieć w logice serwera flagę "wymaga potwierdzenia": zamiast od razu pisać do CRM, serwer zwraca handlowcowi podgląd wpisu. Zapis następuje dopiero przy ponownym wywołaniu z potwierdzeniem. To logika na poziomie serwera MCP, nie standardowy parametr protokołu.

Dla firm bez własnego zespołu programistów, wdrożenie MCP dla firmy obejmuje przygotowanie serwera, definicję narzędzi i konfigurację połączenia z konkretnym CRM-em.

WebMCP a CRM: skąd to połączenie?

WebMCP to projekt specyfikacji prowadzony przez grupę W3C Community Group, przygotowywany przez Google i Microsoft. Nie jest jeszcze standardem. Chrome ma WebMCP w fazie origin trial, wejście do stabilnej wersji planowane na koniec 2026 roku. Edge też go testuje. Safari na razie nic nie zapowiedział. Przeglądarka bez WebMCP po prostu pomija opisy narzędzi, więc wdrożenie niczego nie psuje w istniejącym serwisie.

W kontekście CRM i przygotowania do spotkań WebMCP ma ograniczone znaczenie. Handlowiec korzysta z asystenta po stronie firmy, nie przez przeglądarkę klienta odwiedzającego Waszą stronę. Przepływ wygląda tak: asystent handlowca, serwer MCP, API CRM-u. Przeglądarka nie jest w tym łańcuchu.

WebMCP staje się istotne, gdy chcecie, żeby klient zewnętrzny mógł zapytać swojego własnego asystenta AI o Wasz produkt przez stronę www. To osobny temat. Do przygotowania handlowca przed spotkaniem potrzebujecie serwera MCP po stronie firmy i nic więcej.

Lista kontrolna przed wdrożeniem

• Sprawdźcie, czy Wasz CRM ma aktywne API i czy jest udokumentowane. Większość współczesnych systemów ma, ale zdarzają się starsze instalacje lub plany abonamentowe bez dostępu do API.
• Zdecydujcie, które pola i obiekty są potrzebne handlowcowi przed spotkaniem: tylko kontakt i szanse, czy też historia mailowa, zadania i pola niestandardowe?
• Przemyślcie model uprawnień: każdy handlowiec widzi tylko swoich klientów, czy może pytać o dowolny kontakt w systemie?
• Ustalcie, które operacje zapisu będą dostępne przez asystenta: notatki, zadania, zmiana etapu szansy. Każda z nich z obowiązkowym podglądem przed zapisem.
• Sprawdźcie pola wymagane przy tworzeniu notatki lub zadania w Waszym CRM-ie. Brakujące pole wymagane zablokuje zapis i trzeba to obsłużyć w serwerze MCP z góry, nie podczas pilotażu.
• Zaplanujcie dwutygodniowy pilot z jednym handlowcem zanim rozszerzycie wdrożenie na cały dział sprzedaży.

Od czego zaczynamy

Pierwsza rozmowa to audyt CRM-u: jakie dane są w systemie, jak wyglądają pola, czy API jest aktywne, jakie tokeny są potrzebne do połączenia. To zazwyczaj godzina przez screen sharing z osobą, która w firmie administruje CRM-em.

Potem przygotowujemy serwer MCP z minimalnym zestawem narzędzi: odczyt kontaktu, historia aktywności, otwarte szanse, zapis notatki. Pilot z jednym handlowcem. Na tym etapie często wychodzi, że jedno lub dwa pola w CRM-ie są puste albo wypełniane niespójnie, i to trzeba poprawić w danych, zanim asystent będzie naprawdę użyteczny. Lepiej to odkryć przy jednym handlowcu niż przy dwudziestu.

Dopiero po pilotażu i potwierdzeniu, że dane działają zgodnie z oczekiwaniami, rozszerzamy wdrożenie na cały dział.

Jeśli chcecie sprawdzić, czy to zadziała na Waszym CRM-ie i co konkretnie da się zrobić na danych, które już macie, umówcie 15 minut rozmowy o MCP. Możecie też przejrzeć realne wdrożenia, żeby zobaczyć, jak to wygląda w działających firmach.