Notion jako CRM: 5 błędów, które sabotują wdrożenie

Notion jako CRM ma złą reputację u ludzi, którzy próbowali go raz, poddali się po miesiącu i wrócili do arkusza albo kupili gotowe narzędzie. W większości przypadków problemem nie był Notion — tylko sposób, w jaki baza została poskładana na starcie. Widzieliśmy ten sam zestaw błędów w dziesiątkach wdrożeń robionych samodzielnie, zanim trafiały do nas do naprawy. Oto pięć, które szkodzą najbardziej.

1. Klient istnieje w trzech bazach naraz

Klasyczny scenariusz: baza Kontakty, osobna baza Firmy, osobna baza Oferty — i żadna z nich nie jest ze sobą połączona przez relację. Ten sam klient pojawia się jako tekst wpisany ręcznie w trzech miejscach, więc zmiana numeru telefonu oznacza trzy edycje, a literówka w nazwie firmy tworzy w praktyce drugiego, „nowego" klienta.

Naprawa: jedna baza Kontakty/Firmy jako źródło prawdy, a Oferty, Zadania i Projekty łączą się z nią przez właściwość Relation. Dane klienta (telefon, e-mail, NIP) wpisujesz raz — reszta baz odwołuje się do tego rekordu przez Rollup, zamiast go kopiować.

2. Lejek sprzedaży jako pole tekstowe zamiast statusu

Property typu Text z wpisanym ręcznie „w trakcie" w jednym rekordzie i „W TRAKCIE" w drugim to lejek, którego nie da się policzyć ani przefiltrować — bo dla Notion to dwie różne wartości. Brak jasno zdefiniowanych etapów to najczęstszy powód, dla którego właściciel firmy nie wie, ile realnie ma otwartych szans sprzedażowych.

Naprawa: właściwość Status (nie Select — Status ma wbudowane grupy „do zrobienia / w trakcie / zrobione") z zamkniętą, krótką listą etapów ustaloną raz na starcie: np. Lead → Kontakt → Oferta → Negocjacje → Wygrana/Przegrana. Zamknięta lista wymusza spójność i pozwala budować widoki grupowane po etapie.

3. Baza z 40 kolumnami, z których nikt nie korzysta

„Na wszelki wypadek" dodane pole „Źródło leada 2", „Notatka dodatkowa", „Priorytet B" — każde z dobrą intencją, żadne systematycznie nie wypełniane. Efekt: baza wygląda na rozbudowaną, ale realnie tylko 8 kolumn z 40 ma jakąkolwiek wartość informacyjną, a nowa osoba w zespole nie wie, które to które.

Naprawa: zasada „dodajesz pole dopiero wtedy, gdy masz konkretne pytanie biznesowe, na które ono odpowiada". Istniejącą, przerośniętą bazę warto raz na kwartał przejrzeć i schować (nie usuwać — Hide property) pola, które od trzech miesięcy są puste u połowy rekordów.

4. Brak automatycznego przypomnienia o follow-upie

Notion sam z siebie nie zadzwoni ani nie wyśle e-maila — ale też nie przypomni Ci, że klient czeka na odpowiedź od dziesięciu dni, jeśli nie zbudujesz do tego widoku. Najczęstsza przyczyna „zimnych" leadów w CRM zbudowanym na kolanie to brak jednego, prostego widoku: „kontakty bez aktywności dłużej niż X dni", posortowanego malejąco.

Naprawa: właściwość Data ostatniego kontaktu aktualizowana ręcznie lub automatycznie (np. przez integrację z pocztą — coś, co robi bāApps Relay), plus widok-filtr, który każdego ranka pokazuje, kto czeka najdłużej. To piętnaście minut roboty, które ratuje realne pieniądze.

5. Uprawnienia i widoki nieprzemyślane pod zespół

Jedna wspólna baza, do której każdy ma pełny dostęp edycji, bez rozróżnienia na „mój widok jako handlowiec" i „widok właściciela na cały lejek" — to prosta droga do przypadkowo skasowanych rekordów i chaosu w polach, które ktoś „poprawił po swojemu". Brak osobnych, filtrowanych widoków sprawia też, że każdy scrolluje przez rekordy, które go nie dotyczą.

Naprawa: osobne widoki (nie osobne bazy) filtrowane po osobie odpowiedzialnej, z jasną zasadą, kto może edytować właściwości strukturalne (etapy, automatyzacje), a kto tylko swoje rekordy.

Żaden z tych błędów nie wynika z ograniczeń Notion — wynika z tego, że CRM budowany samodzielnie rzadko ma za sobą kogoś, kto już to poukładał źle gdzie indziej i wie, gdzie leżą pułapki. To dokładnie ta praca, którą robimy przy wdrożeniach bāIMN — nie sprzedajemy szablonu, tylko układamy strukturę pod Twój faktyczny proces sprzedaży, zanim zdąży się on rozjechać.