Obsługa klienta: ontologia dla MŚP

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. Jeśli dopiero zaczynasz, przeczytaj jak odróżnić ontologię od taksonomii i modelu danych.

Zobacz model jako graf

Otwórz pełny graf: 13 encje, 14 relacje ↗

Obsługa klienta13 encje · 14 relacje

−Całość+Zamknij ×

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ć. 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. Kolejny model w katalogu: Handel internetowy.