--- title: "Klient 360: ontologia dla MŚP krok po kroku" url: "https://majchrzycki.com/blog/katalog-ontologii-klient-360-dla-msp" description: "Autorski model Klient 360 dla MŚP: 24 polskie encje, relacje biznesowe, zasady identyfikacji, ryzyko odejścia i test na danych z kilku systemów." --- # Klient 360: ontologia dla MŚP krok po kroku 17 września 2026·5 min czytania·Krzysztof Majchrzycki Temat: [Ontologia firmy](https://majchrzycki.com/blog/filar/ontologia-firmy) **Klient 360 to model, który łączy tożsamość klienta, sprzedaż, realizację, płatności i obsługę przez nazwane relacje.** Dla MŚP jego wartość polega na odpowiedzi na konkretne pytanie: „co wiemy o tej sprawie, z jakiego źródła i czy wolno nam na tej podstawie działać?”. Poniżej pokazuję autorską ontologię przykładowej firmy sprzedającej urządzenia i świadczącej serwis. Zawiera 24 encje i 35 relacji. Nie jest gotowym modelem danych do wgrania bez uzgodnienia definicji z firmą. To końcowy odcinek cyklu **Katalog ontologii dla MŚP** w [filarze ontologii firmy](https://majchrzycki.com/blog/filar/ontologia-firmy). Jeśli potrzebujesz najpierw rozróżnić pojęcie, taksonomię i graf, zacznij od [prostego słownika ontologii](https://majchrzycki.com/blog/ontologia-taksonomia-model-danych-prosto-dla-msp). Wcześniejszy model [ruchu na stronie i konwersji](https://majchrzycki.com/blog/katalog-ontologii-ruch-na-stronie-dla-msp) pokazuje, kiedy anonimowe zdarzenie może prowadzić do rzeczywistego zapytania. Tutaj przechodzimy do pełniejszego modelu relacji z klientem. ## Zobacz model jako graf Graf pojęć i relacji: Klient 360 dla MŚPOtwórz pełny graf: 24 encje, 35 relacje ↗ Miniatura pokazuje cały model. Otwórz graf, aby przesuwać, powiększać i odczytywać opisy wszystkich pojęć oraz relacji. Pełna lista znajduje się także w tabelach artykułu. Kliknij lub wybierz węzeł albo relację, aby przeczytać opis. Przeciągnij tło, aby przesunąć graf. Graf pokazuje wszystkie pojęcia i relacje opisane dalej. Miniatura otwiera duży, interaktywny widok; tekstowe tabele poniżej pozwalają prześledzić model bez korzystania z grafu. ## Jaką decyzję wspiera ten model? Wyobraź sobie firmę, której klient zgłasza awarię urządzenia i pyta, czy może dostać sprzęt zastępczy. Pracownik musi ustalić, **która spółka kupiła konkretny egzemplarz, jakie warunki obowiązują, czy dostawa została zrealizowana, kto prowadzi zgłoszenie i jaka jest podstawa działania**. Dane leżą w systemie sprzedażowym, finansowym, logistycznym i obsługowym. Sam ekran z „wszystkimi danymi klienta” nie rozstrzyga, czy podobnie nazwane rekordy dotyczą tej samej strony umowy. Model ma pomóc pracownikowi przejść po potwierdzonych powiązaniach i dostrzec brak danych. Nie zastępuje prawnej interpretacji umowy, decyzji o reklamacji ani kontroli uprawnień. To rozwinięcie problemu [jednego widoku klienta](https://majchrzycki.com/blog/jeden-widok-klienta-granice): zamiast jednej płaskiej karty pokazujemy, skąd wynika każda odpowiedź. ## Co jest encją, a co tylko rolą lub oceną? W tym modelu **Podmiot** to osoba prawna albo fizyczna występująca w procesie. **Klient** jest rolą takiego podmiotu w relacji handlowej z naszą firmą. Ten sam podmiot może być nabywcą na fakturze, a inny odbiorcą urządzenia. **Osoba kontaktowa** reprezentuje podmiot w określonym zakresie i czasie; jej wiadomość nie jest automatycznie zmianą umowy. Ten podział chroni przed częstym błędem: sklejeniem nabywcy, płatnika i rozmówcy w jeden rekord „klient”. Poniższy katalog podaje wszystkie typy obiektów. Pełne definicje, identyfikatory i przykładowe źródła zapisano także w wersjonowanym pliku, z którego powstaje widok grafowy na tej stronie. Obszar Encje Rola w modelu Tożsamość i odpowiedzialność **Podmiot**, **Klient**, **Osoba kontaktowa**, **Identyfikator źródłowy**, **Pracownik** Kto jest kim, w jakim systemie ma rekord i kto odpowiada za sprawę. Historia relacji **Relacja handlowa**, **Interakcja**, **Zgoda** Kiedy trwała współpraca, kto rozmawiał i jaki kontakt był dopuszczalny. Sprzedaż **Szansa sprzedaży**, **Oferta**, **Umowa**, **Zamówienie**, **Pozycja zamówienia** Od możliwości zakupu do uzgodnionych warunków i konkretnych pozycji. Produkt i realizacja **Produkt**, **Urządzenie**, **Dostawa** Typ wyrobu, jego fizyczny egzemplarz i przekazanie odbiorcy. Finanse **Faktura**, **Płatność**, **Rozliczenie** Dokument należności, przepływ środków i przypisanie kwoty do faktury. Obsługa i utrzymanie **Zgłoszenie**, **Reklamacja**, **Sygnał ryzyka**, **Ocena ryzyka odejścia**, **Działanie utrzymaniowe** Od zaobserwowanego problemu do oceny i odpowiedzialnego działania. **Rozliczenie** jest osobną encją, bo jedna płatność może pokrywać kilka faktur, a jedna faktura może być spłacona w częściach. **Ocena ryzyka odejścia** też jest osobnym obiektem: musi mieć datę, metodę i zakres. Nie wolno traktować jej jak stałej cechy klienta. Sygnał ryzyka to fakt lub obserwacja, na przykład kilka zgłoszeń w krótkim okresie; ocena jest wnioskiem opartym na takich sygnałach. ## Jak encje łączą się w graf biznesowy? Każda strzałka ma kierunek i czasownik. „Faktura **wystawiona dla** Podmiotu” znaczy coś innego niż „Osoba kontaktowa **reprezentuje** Podmiot”. Poniżej znajduje się komplet relacji modelu, pogrupowany według ścieżki pracy: Ścieżka Relacje Ustalenie tożsamości **Klient jest rolą Podmiotu**; **Podmiot ma Identyfikator źródłowy**; **Osoba kontaktowa reprezentuje Podmiot**. Historia współpracy **Klient ma Relację handlową**; **Pracownik prowadzi Relację handlową**; **Interakcja dotyczy Relacji handlowej**; **Osoba kontaktowa uczestniczy w Interakcji**; **Osoba kontaktowa udziela Zgody**. Sprzedaż **Klient ma Szansę sprzedaży**; **Oferta dotyczy Szansy sprzedaży**; **Umowa jest zawarta z Podmiotem**; **Zamówienie jest złożone przez Klienta**; **Zamówienie wynika z Umowy**; **Zamówienie ma Pozycję zamówienia**; **Pozycja zamówienia dotyczy Produktu**. Dostawa **Urządzenie jest egzemplarzem Produktu**; **Dostawa realizuje Zamówienie**; **Dostawa jest skierowana do Podmiotu**; **Dostawa obejmuje Urządzenie**. Rozliczenie **Faktura rozlicza Zamówienie**; **Faktura jest wystawiona dla Podmiotu**; **Płatność jest wykonana przez Podmiot**; **Rozliczenie dotyczy Płatności**; **Rozliczenie pokrywa Fakturę**. Obsługa **Zgłoszenie dotyczy Klienta**; **Zgłoszenie dotyczy Urządzenia**; **Reklamacja wynika ze Zgłoszenia**; **Pracownik prowadzi Zgłoszenie**. Ryzyko i reakcja **Sygnał ryzyka wynika ze Zgłoszenia**; **Sygnał ryzyka wynika z Faktury**; **Ocena ryzyka odejścia dotyczy Klienta**; **Ocena ryzyka odejścia korzysta z Sygnału ryzyka**; **Działanie utrzymaniowe odpowiada na Ocenę ryzyka odejścia**; **Pracownik odpowiada za Działanie utrzymaniowe**; **Działanie utrzymaniowe dotyczy Klienta**. To graf relacji **biznesowych**, a nie drzewo typów. Czytelnik może przejść od Zgłoszenia do Urządzenia, Dostawy, Zamówienia, Umowy i Podmiotu. Przy każdym kroku powinien umieć zapytać o źródło powiązania. Jeśli numer seryjny nie został zapisany, graf ma pokazać brak krawędzi zamiast dopasować urządzenie po podobnej nazwie produktu. ## Jak wygląda jedno przejście po modelu? Przykład jest hipotetyczny. Klient K17 dzwoni o urządzenie U8. Zgłoszenie S4 **dotyczy** U8. Dostawa D3 **obejmuje** U8 i **realizuje** Zamówienie Z52. Z52 **wynika z** Umowy M6 zawartej z Podmiotem P2. Faktura F9 **rozlicza** Z52, ale rozliczenie pokrywa tylko część kwoty. Pracownik widzi więc powiązany zakup i warunki umowy, lecz nie powinien automatycznie stwierdzić, że całe zamówienie jest opłacone. Teraz pytanie: „czy możemy wysłać urządzenie zastępcze?”. Model wskazuje dokument umowy, zgłoszenie, egzemplarz i osobę prowadzącą. **Nie zawiera jeszcze reguły uprawnienia do wydania sprzętu zastępczego** ani potwierdzenia, że zgłoszenie uznano za reklamację. To świadoma granica. Pracownik sprawdza właściwy zapis umowy i podejmuje decyzję zgodnie z procesem. Agent AI może zebrać dowody i wskazać lukę, ale nie powinien dopisać brakującej reguły. ## Jak połączyć cztery systemy bez fałszywego scalenia? Pierwszy krok to mapa identyfikatorów. Dla każdego Podmiotu przechowuj parę „system i lokalny klucz”, a decyzję o połączeniu rekordów opieraj na potwierdzonych danych. Podobna nazwa firmy jest kandydatem do sprawdzenia, nie dowodem. [Przykład trzech nazw klienta w systemach](https://majchrzycki.com/blog/klient-pod-trzema-nazwami-w-systemach) pokazuje, dlaczego zbyt szybkie scalenie psuje historię umów i uprawnienia. Drugi krok to właściciel znaczenia. Sprzedaż zatwierdza definicję szansy, finanse — zasady rozliczenia, obsługa — stan zgłoszenia, a odpowiedzialna osoba biznesowa uzgadnia, co oznacza „aktywny klient”. [Właściciel danych o kliencie](https://majchrzycki.com/blog/wlasciciel-danych-o-kliencie) nie musi poprawiać każdego wiersza, ale musi rozstrzygać sporne definicje. Każdy odczyt powinien pokazywać czas aktualizacji i źródło; status z poprzedniego tygodnia nie jest automatycznie statusem dzisiejszym. Trzeci krok to dostęp. Handlowiec może potrzebować informacji, że istnieje zaległość, ale nie całego wyciągu bankowego. Osoba z serwisu może znać historię urządzenia, ale nie wszystkie warunki innych spółek tej samej grupy. Zgoda na kontakt ma określony cel i osobę. Połączenie grafowe rekordów nie rozszerza samo przez się prawa ich odczytu. ## Gdzie kończy się sens takiego modelu? Nie każda firma potrzebuje od razu 24 encji w produkcji. Dla pierwszego wdrożenia wystarczy często Podmiot, Klient, Zamówienie, Urządzenie, Zgłoszenie i Umowa, jeśli to one odpowiadają na wybrane pytanie. Pozostałe pojęcia są mapą rozszerzenia, a nie listą tabel do natychmiastowego utworzenia. Gdy relacji jest niewiele i są stabilne, [istniejąca baza oraz widok mogą wystarczyć](https://majchrzycki.com/blog/ontologia-i-bazy-grafowe-w-ai-dla-msp). Grafowa wizualizacja pomaga zrozumieć model, ale sama nie poprawia jakości danych. Szczególnie ostrożnie trzeba traktować ocenę odejścia. W niewielkim MŚP może brakować danych do sensownej prognozy; wtedy lepiej rejestrować sprawdzalne sygnały i przeglądać je z opiekunem klienta. Ocena nie może zastępować rozmowy ani stawać się ukrytą podstawą gorszej obsługi. Zanim dodamy automatyczne działania, ustalmy, kto je zatwierdza, jakie dane są dozwolone i jak sprawdzić skutek. ## Jak sprawdzić pierwszy wycinek w swojej firmie? Wybierz pięć rzeczywistych spraw: prosty zakup, zakup z dwiema dostawami, częściową płatność, reklamację urządzenia oraz klienta z dwoma podobnie nazwanymi podmiotami. Dla każdej zapisz oczekiwaną ścieżkę od zgłoszenia albo zamówienia do strony umowy. Sprawdź, czy pracownik może odtworzyć źródło każdej relacji i wskazać brakujące dane. Jeśli dwie osoby wyciągają inne wnioski z tej samej ścieżki, wróć do definicji relacji przed budową interfejsu. Pełny sposób przejścia od decyzji do mapowania źródeł opisuje [poradnik budowy ontologii firmy](https://majchrzycki.com/blog/jak-zbudowac-ontologie-firmy-dane-reguly-agenci). Zacznij od jednego pytania i niewielkiej próbki danych. Dopiero po sprawdzeniu tożsamości, czasu i uprawnień warto rozbudować model o kolejne procesy. - Dane klienta - Ontologia - Jakość danych ## Uporządkuj pierwszy krok z AI Bezpłatny poradnik pomaga wybrać proces, pytania diagnostyczne i kolejność działań. [Pobierz poradnik](https://majchrzycki.com/darmowy-poradnik-transformacji-ai-dla-firmy) Strony poradnika transformacji AI: rysunki i opisy cyfrowego modelu firmy ## Czytaj dalej - [Obsługa klienta: ontologia dla MŚP](https://majchrzycki.com/blog/katalog-ontologii-obsluga-klienta-dla-msp) - [Faktury ustrukturyzowane i sygnały nadużyć: ontologia dla MŚP](https://majchrzycki.com/blog/katalog-ontologii-faktury-ksef-sygnaly-dla-msp) - [Finanse międzynarodowe: ontologia dla MŚP](https://majchrzycki.com/blog/katalog-ontologii-finanse-miedzynarodowe-dla-msp) - [Handel internetowy: ontologia dla MŚP](https://majchrzycki.com/blog/katalog-ontologii-handel-internetowy-dla-msp)