--- title: "Obsługa klienta: ontologia dla MŚP" url: "https://majchrzycki.com/blog/katalog-ontologii-obsluga-klienta-dla-msp" description: "Model zgłoszeń, odpowiedzi, terminów i eskalacji dla MŚP, który odróżnia zamknięcie sprawy od usunięcia problemu." --- # Obsługa klienta: ontologia dla MŚP 29 stycznia 2026·4 min czytania·Krzysztof Majchrzycki Temat: [Ontologia firmy](https://majchrzycki.com/blog/filar/ontologia-firmy) **Ontologia obsługi klienta łączy zgłoszenie z kanałem, odpowiedzialną osobą, terminem i potwierdzonym wynikiem, dzięki czemu widać przebieg sprawy zamiast samego statusu.** To autorski, przykładowy model dla MŚP, a nie specyfikacja gotowa do wdrożenia w każdej firmie. Odpowiada na pytanie: **Kto prowadzi sprawę klienta i czy rozwiązanie spełnia uzgodniony termin?** Zawiera 13 encji i 14 nazwanych relacji. Przed użyciem trzeba uzgodnić definicje z właścicielami procesu i sprawdzić je na rzeczywistych rekordach. Ten tekst należy do [katalogu ontologii w filarze Ontologia firmy](https://majchrzycki.com/blog/filar/ontologia-firmy). Jeśli dopiero zaczynasz, przeczytaj [jak odróżnić ontologię od taksonomii i modelu danych](https://majchrzycki.com/blog/ontologia-taksonomia-model-danych-prosto-dla-msp). ## Zobacz model jako graf Graf pojęć i relacji: Obsługa klientaOtwórz pełny graf: 13 encje, 14 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. Miniatura otwiera pełny graf, w którym można wybrać encję lub relację i odczytać jej znaczenie. Tabele poniżej zawierają tę samą informację w formie tekstowej. ## Jaką decyzję pomaga podjąć ten model? Firma serwisowa odbiera e-mail o awarii, po czym klient dzwoni w tej samej sprawie. Powstają dwa wpisy w systemie. Jeden pracownik zamyka pierwszy jako duplikat, drugi czeka na część. Kierownik widzi zielony wskaźnik zamkniętych zgłoszeń, choć urządzenie nadal nie działa. Model pomaga ustalić jedną sprawę, zachować oba kontakty, wskazać właściciela i sprawdzić obiecany termin rozwiązania. Granica modelu jest równie ważna jak jego zakres: Nie przesądza, czy roszczenie klienta jest zasadne; wymaga oddzielnej decyzji i właściwej podstawy. ## Jakie pojęcia trzeba rozróżnić? W tabeli każda encja ma własną definicję, klucz identyfikacyjny i przykładowe źródło. Nazwa rekordu w dwóch systemach nie dowodzi jeszcze, że chodzi o ten sam obiekt. Tożsamość trzeba potwierdzić kluczem lub świadomą regułą mapowania; status i prognozę należy datować. Encja Znaczenie w tym modelu Identyfikator Przykładowe źródło **Klient** Podmiot korzystający z produktu lub usługi. identyfikator klienta CRM **Osoba kontaktowa** Człowiek zgłaszający sprawę w określonym zakresie. identyfikator osoby CRM **Kanał** Sposób przyjęcia kontaktu, na przykład e-mail lub telefon. kod kanału system obsługi **Kontakt** Pojedyncza rozmowa albo wiadomość z datą i treścią. identyfikator kontaktu poczta, centrala **Zgłoszenie** Sprawa wymagająca działania z historią stanów. numer zgłoszenia system obsługi **Urządzenie** Egzemplarz produktu którego dotyczy problem. numer seryjny rejestr urządzeń **Pracownik** Osoba odpowiedzialna za obsługę. identyfikator pracownika system kadrowy **Termin** Obiecana data wykonania określonego etapu z wersją. identyfikator terminu system obsługi **Zadanie** Działanie przypisane do zgłoszenia i wykonawcy. identyfikator zadania system obsługi **Eskalacja** Przekazanie sprawy do innego poziomu odpowiedzialności. identyfikator eskalacji system obsługi **Odpowiedź** Komunikat wysłany do klienta. identyfikator wiadomości system obsługi **Rozwiązanie** Udokumentowane działanie usuwające problem i jego wynik. identyfikator rozwiązania system serwisowy **Potwierdzenie** Dowód przyjęcia lub odrzucenia rozwiązania przez klienta. identyfikator potwierdzenia system obsługi **Kontakt** to pojedyncza wiadomość lub rozmowa; **zgłoszenie** to sprawa do obsłużenia. **Odpowiedź** potwierdza komunikację, a **rozwiązanie** opisuje działanie i wynik. Sam status „zamknięte” nie dowodzi, że klient potwierdził usunięcie problemu. ## Jak encje łączą się w graf biznesowy? Krawędź ma kierunek, czasownik i znaczenie. Krotność w tabeli opisuje założenie tego modelu, które trzeba zweryfikować w konkretnej firmie. Gdy powiązanie ma własną kwotę, datę albo dowód, warto zachować je jako osobną encję zamiast ukrywać w atrybucie. Od Relacja Do Krotność Co potwierdza Osoba kontaktowa **reprezentuje** Klient 0..n : 0..n Reprezentacja ma zakres i czas. Kontakt **przychodzi kanałem** Kanał 0..n : 1 Zachowuje źródło rozmowy. Osoba kontaktowa **inicjuje** Kontakt 1 : 0..n Wskazuje rozmówcę. Kontakt **dotyczy** Zgłoszenie 0..n : 0..1 Kilka kontaktów może tworzyć jedną sprawę. Zgłoszenie **dotyczy** Klient 0..n : 1 Określa stronę obsługi. Zgłoszenie **dotyczy egzemplarza** Urządzenie 0..n : 0..1 Łączy serwis z konkretnym urządzeniem. Pracownik **prowadzi** Zgłoszenie 0..n : 0..n Historia przydziału zachowuje czas. Zgłoszenie **ma termin** Termin 1 : 0..n Każda obietnica ma wersję. Zgłoszenie **wymaga** Zadanie 1 : 0..n Rozbija sprawę na działania. Pracownik **wykonuje** Zadanie 0..n : 0..n Wskazuje odpowiedzialnego wykonawcę. Eskalacja **dotyczy** Zgłoszenie 0..n : 1 Utrwala powód i czas przekazania. Odpowiedź **dotyczy** Zgłoszenie 0..n : 1 Oddziela komunikację od efektu. Rozwiązanie **zamyka problem w** Zgłoszenie 0..1 : 1 Zapisuje wynik naprawy. Potwierdzenie **ocenia** Rozwiązanie 0..n : 1 Zachowuje odpowiedź klienta. ## Jak przejść po grafie w jednej sprawie? W przykładzie kontakt K11 otwiera zgłoszenie Z8. Telefon K12 zostaje dopięty do Z8 po potwierdzeniu numeru urządzenia i nabywcy. Zgłoszenie ma termin T3, zadanie A5 i eskalację E2 z powodu braku części. Odpowiedź O4 informuje klienta o nowym planie, lecz rozwiązanie R1 pojawia się dopiero po naprawie. Przed zamknięciem trzeba jeszcze potwierdzić odbiór urządzenia i ustalić, czy przerwa w działaniu została objęta warunkami umowy. Puste powiązanie ma pozostać widoczną luką. Model nie powinien dopowiadać relacji tylko dlatego, że rekordy mają podobne nazwy lub bliskie daty. ## Jak połączyć dane i nie zgubić kontekstu? Połącz skrzynkę, centralę telefoniczną i system obsługi przez identyfikatory kontaktów oraz zgłoszeń. Duplikat łącz dopiero po sprawdzeniu urządzenia, osoby kontaktowej i czasu; zachowaj oryginalne wiadomości jako dowody. Dla każdego mapowania zapisz system źródłowy, lokalny identyfikator, czas aktualizacji i regułę, która połączyła rekordy. Sprzeczne dane powinny trafić do kolejki wyjaśnienia, a nie zostać po cichu nadpisane. Właściciel procesu zatwierdza znaczenie relacji, a właściciel systemu potwierdza sposób jej pobierania. Dane klienta i treść sprawy mogą zawierać informacje poufne. Raport zarządczy powinien pokazywać terminowość i stan bez ujawniania zbędnych szczegółów korespondencji. Dostęp do połączonych danych musi odzwierciedlać cel pracy i uprawnienia. Sam fakt, że graf potrafi przejść między dwiema encjami, nie oznacza, że każda osoba może zobaczyć wszystkie atrybuty po obu stronach. ## Jak sprawdzić pierwszy wycinek modelu? Weź kilka prawdziwych, ale bezpiecznie udostępnionych spraw. Dla każdej ustal oczekiwaną ścieżkę i dokument, który potwierdza każdą krawędź. Na początek wystarczą poniższe próby: 1. Dwa kontakty w jednej sprawie pozostają dwoma zdarzeniami. 2. Zamknięcie duplikatu nie jest liczone jako rozwiązanie awarii. 3. Zmiana terminu zachowuje poprzednią obietnicę i powód. 4. Eskalacja ma właściciela oraz czas przyjęcia. Jeżeli dwie osoby inaczej interpretują ten sam węzeł lub relację, popraw definicję przed budową interfejsu. Przy niewielkiej liczbie stabilnych powiązań [istniejąca baza i widok mogą wystarczyć](https://majchrzycki.com/blog/ontologia-i-bazy-grafowe-w-ai-dla-msp). Graf pomaga rozmawiać o znaczeniu danych; nie naprawia automatycznie błędów w źródłach. ## Co zrobić dalej? Wybierz jedno pytanie operacyjne z początku tekstu i wskaż osobę, która potwierdzi znaczenie kluczowych pojęć. Następnie sprawdź pięć spraw w systemach źródłowych. Szerszą procedurę opisuje [poradnik budowy ontologii firmy](https://majchrzycki.com/blog/jak-zbudowac-ontologie-firmy-dane-reguly-agenci). Kolejny model w katalogu: [Handel internetowy](https://majchrzycki.com/blog/katalog-ontologii-handel-internetowy-dla-msp). - Ontologia - Model danych - MŚP ## 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 - [Komunikacja w firmie: ontologia dla MŚP](https://majchrzycki.com/blog/katalog-ontologii-komunikacja-w-firmie-dla-msp) - [Sieć relacji i poleceń: ontologia dla MŚP](https://majchrzycki.com/blog/katalog-ontologii-siec-polecen-dla-msp) - [Kadry i kompetencje: ontologia dla MŚP](https://majchrzycki.com/blog/katalog-ontologii-kadry-i-kompetencje-dla-msp) - [Projekty usługowe: ontologia dla MŚP](https://majchrzycki.com/blog/katalog-ontologii-projekty-uslugowe-dla-msp)