Jedna osoba pisze „lead”, druga „kontakt”, trzecia „klient”, a czwarta „sprawa”. Model grupuje wszystko jako klientów i przypisuje złą kolejkę. Potem dodaje „użytkownik” do listy, bo lubi synonimy. Słownik nie jest projektem dla lingwistów. Jest sposobem na mniej zgadywania w danych i decyzjach.
Dobry słownik opisuje pojęcia używane w procesie, ich źródła i ograniczenia. Nie musi zawierać każdego słowa. Ma pomagać ludziom i agentom wybierać właściwy rekord i krok.
Zacznij od pojęć wpływających na decyzje
Wypisz terminy dotyczące klientów, statusów, ról, dokumentów, danych i działań. Nie dodawaj „AI”, „model” i „automatyzacja” tylko dlatego, że są modne. Zacznij od rzeczy, których błędne zrozumienie kosztuje.
Przy każdym zapisz pytanie: co system ma zrobić po rozpoznaniu? Na przykład zgłoszenia oznaczone jako „reklamacja” i „skarga” mogą wymagać różnych ścieżek w danym procesie. Ustal ich znaczenie z właścicielem i, jeśli trzeba, prawnikiem. Nie zakładaj, że sama nazwa rozstrzyga obowiązki.
Nie twórz definicji bez właściciela. Może zespół używa dwóch pojęć i trzeba najpierw zdecydować zakres. Słownik dokumentuje decyzje, nie zgaduje ich.
Definicja ma ograniczać znaczenie
Zapisz, co pojęcie obejmuje, czego nie obejmuje i jaki jest przykład. „Aktywny klient” powinno mieć warunek i okres. Samo „klient korzysta z usługi” zostawia za dużo miejsca dla wariantów.
Dodaj źródło prawdy i właściciela. Jeżeli definicja pochodzi z umowy lub procesu, odwołaj się do wersji. Nie przepisuj potocznego znaczenia jako oficjalnego.
Przy pojęciach niejednoznacznych zaznacz różnice kontekstu. „Data” może mieć osobne nazwy dla wystawienia, odbioru i płatności. To lepsze niż jedna ogólna definicja.
Zachowaj synonimy bez utraty rozróżnień
Zapisz warianty językowe używane przez klientów i zespół, ale wskaż preferowaną nazwę procesu. Nie usuwaj naturalnego języka z wyszukiwania. Model powinien mapować je na właściwe pojęcie.
Nie każdy synonim jest dokładny. „Lead” i „klient” mogą różnić się etapem relacji. Zachowaj rozróżnienie i regułę mapowania. Nie zgłaszaj wszystkiego jako jednego typu.
Przy tłumaczeniach dodaj warianty zatwierdzone i unikaj automatycznych zamian nazw własnych. Przewodnik o tłumaczeniach AI opisuje pracę ze słownikiem.
Pola i statusy wymagają reguł
Przy statusach zapisz dozwolone wartości, przejścia i skutki. „Zamknięte” może oznaczać odpowiedź, rozwiązanie albo archiwum. To nie jest to samo. Model nie powinien wybierać znaczenia na podstawie stylu.
Opisz puste i nieznane wartości. Brak nie zawsze jest zerem, a nowy status nie powinien być traktowany jako zgoda. Słownik powinien wspierać bezpieczne zachowanie przy błędzie.
Przy integracjach zapisz mapę pól i wersje. Zmiana nazwy w jednym systemie nie powinna automatycznie zmieniać historii wszystkich raportów.
Rola nie jest nazwiskiem
Opisz odpowiedzialność i uprawnienia ról. „Właściciel” może oznaczać opiekuna, decydenta lub osobę wykonującą. Rozdziel je. Agent nie powinien przypisywać pracy na podstawie tego, kto najwięcej mówił.
Zachowaj zastępstwo i kontekst. Przy zmianie osoby definicja roli zostaje, ale przypisanie zmienia się w źródle. Słownik nie powinien zawierać prywatnych profili.
Przy przekazaniu zgłoszenia użyj wspólnych pojęć. To ogranicza ping-pong. Przewodnik o przypisaniu właściciela zgłoszenia AI pokazuje skutek w praktyce.
Dane wrażliwe i kategorie poufności
Zdefiniuj, co jest publiczne, wewnętrzne, osobowe i poufne w twoim procesie. Nie używaj ogólnego „bezpieczne dane” jako kategorii. Przy każdej zapisz dozwolony kanał i ograniczenia.
Nie zgaduj kategorii z samego tekstu. Dokument może wyglądać niewinnie i zawierać tajemnicę. Właściciel powinien przypisywać źródła i zakres.
Przy RODO i NDA łącz słownik z zasadami z przewodników o RODO przy AI i NDA przy AI. Wspólne pojęcia pomagają przy odbiorze.
Słownik dla agenta i ludzi
Człowiek potrzebuje przykładów i kontekstu, agent dodatkowo stabilnych identyfikatorów, formatów i reguł. Nie przenoś definicji bez identyfikatorów pól. Jedno pojęcie może mieć różne nazwy w systemach.
Zachowaj wspólne źródło i wersję. Nie kopiuj słownika do każdego promptu bez kontroli. Zmiana powinna aktualizować zależne procesy i testy.
Agent powinien zwracać nieznane pojęcia zamiast zgadywać. Dodaj przypadek testowy z nowym statusem lub terminem. Oczekiwane zachowanie powinno być zatrzymaniem lub eskalacją.
Jak dodawać nowe pojęcia
Zgłaszaj z przykładem źródła, pytaniem i skutkiem. Nie dodawaj definicji tylko dlatego, że model jej użył. Właściciel ocenia, czy termin jest potrzebny i jaki ma zakres.
Przy konflikcie zachowaj stare i nowe znaczenie z datą. Nie przepisuj historii. Nowa wersja może wymagać aktualizacji dokumentów, mapowania i testów.
Nie dodawaj każdego slangu z social mediów do oficjalnego słownika. Może zostać w analizie kontekstu bez stawania się standardem firmy.
Przykład: „klient” i „potencjalny klient”
Zespół używa obu pojęć zamiennie, ale raport sprzedażowy wymaga etapu. Model opisuje stare kontakty jako klientów i zawyża wynik. Słownik rozdziela relację od momentu decyzji.
Zapisz warunki i źródło etapu. Przy migracji zachowaj stare wartości z mapą. Nie zmieniaj historii na nowe definicje bez opisu.
Test obejmuje kontakt przed zakupem, klienta aktualnego i nieznaną relację. Model powinien oznaczać brak zamiast przypisywać klienta automatycznie.
Odbiór przez dwie role
Właściciel procesu sprawdza skutek, a osoba od danych mapowanie i pola. Prawnik lub specjalista ocenia pojęcia wrażliwe przy potrzebie. Nie wymagaj wszystkich przy każdej zmianie.
Poproś osobę spoza zespołu o opisanie procesu na podstawie słownika. Jeżeli rozumie go inaczej, definicje są za ogólne. Model nie jest jedynym recenzentem.
Po odbiorze zaktualizuj źródła i testy. Słownik ma zmieniać pracę, a nie tylko zostać w dokumencie.
Utrzymanie bez wielkiego programu
Przypisz właściciela i krótki przegląd przy zmianach procesu. Nie dodawaj cotygodniowego spotkania dla każdego terminu. Aktualizuj przy nowych polach, rolach i błędach.
Zachowaj historię zmian i wersję. Stare dokumenty mogą używać innych definicji, więc nie oceniaj ich bez kontekstu. Raport powinien wiedzieć, kiedy zmiana nastąpiła.
Słownik nie powinien blokować naturalnego języka
Nie zamieniaj każdego zdania klienta na wewnętrzną terminologię. Zachowaj naturalne słowa i dodaj mapowanie do procesu. Ludzie nie muszą uczyć się firmowego slangu, żeby zadać pytanie. Model powinien tłumaczyć kontekst, a nie wymuszać formę.
Przy odpowiedziach używaj preferowanego pojęcia tam, gdzie pomaga, ale nie twórz sztucznego korporacyjnego tonu. Czytelnik powinien rozpoznać swój problem. Słownik ma ułatwiać komunikację, a nie nagradzać trudne słowa.
Przy social mediach zachowaj ironię i warianty znaczeń jako osobny kontekst. Nie przenoś każdego żartu w definicję procesu. Artykuł o komentarzach z AI opisuje ograniczenia analizy.
Pytania przy nowym polu lub statusie
Zapytaj, co oznacza pole, kto jest właścicielem, jakie ma skutki i jakie są nieznane wartości. Nie dodawaj go tylko dlatego, że API je zwraca. Integracja powinna mapować znaczenie do procesu.
Sprawdź, czy nowe pole nie koliduje z istniejącym pojęciem. „Status” bez nazwy może być etapem, dostępem albo zgodą. Nadaj jednoznaczną nazwę i zaktualizuj słownik.
Dodaj test pustego i nieznanego. System nie powinien traktować nowej wartości jako zgody. Odbiór obejmuje źródło i wersję mapy.
Jak utrzymać słownik przy zmianach zespołu
Przy nowej osobie lub agencji przekaż tylko pojęcia potrzebne do zadania i źródła. Nie wymagaj czytania całego dokumentu. Krótki pakiet z definicjami i przykładami wystarcza na początek.
Zapisz pytania i błędy interpretacji. Dodaj je jako przykłady lub zmień definicję. Nie zakładaj, że każdy rozumie pojęcia tak samo po jednym spotkaniu.
Przy zmianie właściciela pojęcia przekaż źródło, przykłady i listę zależności. Nowa osoba powinna wiedzieć, które procesy używają definicji i które testy trzeba powtórzyć. Nie aktualizuj samego dokumentu bez mapowania wpływu.
Przy nowej wersji zachowaj starą definicję z datą obowiązywania. Raporty historyczne mogą jej wymagać. Nie przepisuj przeszłych rekordów na nowe znaczenie bez decyzji i mapy.
Jeżeli termin nie jest już używany, oznacz go jako archiwalny zamiast usuwać bez śladu. Stare dokumenty nadal mogą go zawierać i wymagać interpretacji.
Przy odbiorze sprawdź, czy agent nie zgaduje nowych terminów. Nieznane powinno być zgłaszane z cytatem i pytaniem, a nie przypisywane do najbliższej kategorii.
Przy kolejnych wersjach porównaj mapowanie pól i wyników procesu. Zmiana definicji bez zmiany nazwy może wpływać na raporty i decyzje. Zapisz datę i właściciela.
Przy nowym źródle nie kopiuj jego słownika automatycznie. Może używać innego znaczenia tej samej nazwy. Mapuj pojęcia z przykładami i właścicielem.
Przy zakończeniu procesu zachowaj słownik archiwalny dla starych dokumentów. Usuń tylko bieżące powiązania, nie historię potrzebną do odczytu przeszłych decyzji.
Przy odbiorze nowej definicji poproś dwie role o przykład zastosowania. Jeżeli każda opisuje inny skutek, pojęcie jest nadal za szerokie. Popraw definicję przed aktualizacją modelu.
Zapisz, kiedy termin obowiązuje i kiedy wymaga przeglądu. Nie zmieniaj go przy każdej nowej odpowiedzi AI. Słownik ma być stabilnym źródłem decyzji.
Przy nowym procesie wybierz tylko krytyczne pojęcia i przypadki. Nie przenoś całego słownika bez mapy zależności. Mały zestaw łatwiej utrzymać i testować.
Przy kolejnych dokumentach sprawdź, czy stara nazwa jest używana z nowym znaczeniem. Może wymagać osobnego terminu zamiast aktualizacji wszystkiego. Zapisz różnicę i źródło.
Przy odbiorze zespołu poproś o przykład decyzji z nowym pojęciem. To pokazuje, czy definicja działa w praktyce, a nie tylko brzmi poprawnie w tabeli.
Przy zmianie właściciela przekaż wersję i listę procesów zależnych. Nowa osoba powinna wiedzieć, które mapowania i testy trzeba zaktualizować. Nie przenoś samej definicji bez kontekstu.
Zapisz niepewność przy terminach zależnych od regionu lub umowy. Model nie powinien przypisywać jednego znaczenia wszystkim klientom. Właściciel potwierdza zakres i wyjątki.
Przy odbiorze końcowym sprawdź, czy źródło i wersja słownika są dostępne przy zadaniu. Definicja nie może zostać w prywatnej skrzynce. Zachowaj właściciela i termin kolejnej oceny.
Przy kolejnych projektach porównaj pojęcia z nowymi źródłami i przypadkami. Nie zmieniaj definicji tylko dla nowego narzędzia. Aktualizuj ją po decyzji procesu, zachowując wersję i skutek.
Przy architekturze wiedzy pomocna jest mapa Aeneia Signal, a przy procesie Aeneia Audit.
Jeśli dwa zespoły inaczej rozumieją status zgłoszenia, zapisz obie definicje i wskaż właściciela decyzji. Dopiero po uzgodnieniu znaczenia dodaj je do instrukcji agenta oraz formularza. Przy następnym przekazaniu pracy nowa osoba znajdzie źródło ustalenia, zamiast odgadywać je z nazwy pola.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
