Kontrola jakości w Salesforce Service Cloud polega na ocenie odpowiedzi napisanych przez konsultanta, kanału i stanu, w jakim sprawa została pozostawiona. Najpierw trzeba ustalić, co uznajemy za rozmowę, bo jedna sprawa obejmuje wiele powiązanych rekordów.
W skrócie
- Właściciel sprawy często nie jest autorem odpowiedzi.
- Każde kryterium trzeba powiązać z polem, które istnieje w Państwa organizacji.
- Populację próbki należy zdefiniować raportem.
- Przed wdrożeniem trzeba zdecydować, jak oceniać sprawy obejmujące kilka kanałów.
Co w praktyce oznacza kontrola jakości w Salesforce Service Cloud
Większość porad dotyczących QA zakłada zgłoszenie: jeden klient, jeden wątek, jedna osoba przypisana, czytane od góry do dołu. Service Cloud tak nie działa i właśnie ta jedna różnica w strukturze sprawia, że ogólne porady dotyczące QA zwykle rozpadają się już w pierwszym tygodniu.
Sprawa to rekord. Ma pola takie jak status, źródło, powód, priorytet i właściciel, przy czym wartości tych list wyboru konfiguruje Państwa administrator, a nie platforma. Wokół tego rekordu znajduje się to, co klient i konsultant faktycznie zrobili: e-maile, transkrypcje czatu lub komunikatora, wpisy wewnętrzne, zadania oraz, jeśli organizacja ma skonfigurowany kanał głosowy, rekordy połączeń. Kanał aktywności sprawy (feed) pokazuje chronologię tej aktywności, ale chronologia to nie to samo co rozmowa. Miesza odpowiedzi konsultanta z wpisami systemowymi, zmianami pól i wpisami osób, które nigdy nie rozmawiały z klientem.
Dlatego pierwsze pytanie w kontroli jakości w Service Cloud nie brzmi „co powinniśmy oceniać”. Brzmi co nazywamy rozmową. Istnieją trzy odpowiedzi, których da się bronić, i jedną trzeba wybrać świadomie:
- Tylko wymiana widoczna dla klienta. Każda wiadomość, którą klient mógł zobaczyć, po kolei, z pominięciem wpisów wewnętrznych i historii pól. To najbliższy odpowiednik wątku zgłoszenia i najłatwiej to wytłumaczyć konsultantowi.
- Wymiana plus stan rekordu. Te same wiadomości, oceniane razem ze sposobem, w jaki sprawę skategoryzowano i zamknięto. Właściwe dla zespołów, których jakość danych zasila raportowanie.
- Cała sprawa, łącznie z pracą wewnętrzną. Wiadomości, notatki wewnętrzne, przekazania i zadania. Najpełniejszy obraz i najtrudniejszy do spójnej oceny, bo recenzenci nie zgadzają się co do tego, ile pracy wewnętrznej wystarczy.
Prosimy zapisać odpowiedź, zanim powstaną kryteria. Jeśli Państwo tego nie zrobią, każdy recenzent po cichu wybierze własną i pojawi się wzorzec rozbieżności, który zna każdy lider QA: dwie osoby oceniają tę samą sprawę na sześćdziesiąt i osiemdziesiąt pięć punktów i żadna nie potrafi powiedzieć dlaczego. Mechanika karty oceny, która opiera się na tej decyzji, jest taka sama jak w każdym programie kontroli jakości obsługi klienta, a jeśli Państwo jeszcze takiej karty nie mają, warto zacząć od tekstu jak zbudować kartę oceny rozmów i potem tu wrócić.
Co można ocenić w sprawie, a czego nie
Przed napisaniem kryteriów warto wziąć jedną niedawno zamkniętą sprawę i spisać, co rzeczywiście się w niej znajduje. Najlepiej zrobić to we własnej organizacji, a nie na podstawie szablonu, bo to, co jest dostępne, zależy w ogromnym stopniu od konfiguracji organizacji.
Zwykle dostępne
- Wiadomości napisane przez konsultanta. Odpowiedzi e-mailowe, wypowiedzi na czacie lub w komunikatorze oraz ewentualne wpisy publiczne. To podstawowy materiał dowodowy dla wszystkiego, co dotyczy komunikacji.
- Znaczniki czasu. Kiedy klient napisał, kiedy konsultant odpowiedział, kiedy zmienił się właściciel, kiedy sprawę zamknięto. Wystarczy to do oceny szybkości reakcji, z zastrzeżeniami opisanymi niżej.
- Wartości pól przy zamknięciu. Status, powód, pola produktu lub kategorii oraz wszystkie pola niestandardowe wymagane w Państwa organizacji. To one sprawiają, że sprawa nadaje się do raportowania, więc w pełni uzasadnione jest traktowanie ich jako części jakości.
- Notatki i wpisy wewnętrzne. Jakość przekazania, przebieg analizy problemu, uzasadnienie eskalacji.
- Historia właścicieli. Kto miał sprawę i kiedy przeszła w inne ręce.
Często niedostępne, warto sprawdzić przed obiecaniem kryterium
- Rozmowy telefoniczne. To, czy do sprawy w ogóle dołączono połączenie i czy istnieje transkrypcja, a nie tylko nagranie lub notatka, zależy od tego, jak kanał głosowy skonfigurowano w Państwa organizacji. Prosimy to potwierdzić przed napisaniem kryterium, które zależy od treści rozmowy.
- Co widział konsultant. Zabezpieczenia na poziomie pól i reguły udostępniania sprawiają, że widok sprawy u recenzenta nie musi być taki sam jak u konsultanta. Jeśli kryterium zakłada, że konsultant miał daną informację pod ręką, trzeba sprawdzić, czy rzeczywiście ją miał.
- Stan bazy wiedzy w tamtym momencie. Jeśli artykuł zmienił się po zamknięciu sprawy, konsultant mógł mieć rację względem wersji, którą dysponował.
- Wszystko, co wydarzyło się poza rekordem. Oddzwonienie zapisane jako jednolinijkowa notatka, rozmowa w narzędziu do czatu, bezpośrednie przekazanie do innego zespołu. To prawdziwa praca, a kontrola jakości jej nie widzi.
Wynikająca z tego zasada jest krótka. Jeśli kryterium nie da się poprzeć czymś, co znajduje się w sprawie, to nie jest kryterium oceny jakości, tylko opinia. Trzeba albo znaleźć pole lub wiadomość, które je potwierdzają, albo usunąć je z karty oceny i przenieść do coachingu. Ogólny formularz monitoringu rozmów to dobry punkt wyjścia do takiego spisu, ale każda jego pozycja musi przejść ten test w zestawieniu z układem spraw w Państwa organizacji.
Jak dane sprawy przekładają się na kryteria kontroli jakości w Salesforce Service Cloud
To ćwiczenie z mapowania decyduje o powodzeniu albo porażce programu. Dla każdego kryterium trzeba nazwać dowód, sposób sprawdzenia i spodziewany błąd. Ostatnią kolumnę zespoły pomijają, a to właśnie ona przewiduje każdy spór, jaki Państwa czeka.
| Typ kryterium | Dowód w sprawie | Jak sprawdza to recenzent | Gdzie pojawia się błąd |
|---|---|---|---|
| Trafność rozwiązania | Ostatnia wiadomość konsultanta, czytana w zestawieniu z polami, z którymi sprawę zamknięto | Czy udzielona odpowiedź zgadza się z zapisanym wynikiem i czy była poprawna w tamtym momencie | Status ustawia automatyzacja lub makro, więc rekord mówi „rozwiązane”, choć nie ma na to żadnego dowodu |
| Zgodność z procesem | Pola obowiązkowe, notatki wewnętrzne oraz rekordy uprawnień lub poziomów usług skonfigurowane w organizacji | Porównanie tego, co zapisano w sprawie, z udokumentowanym procesem dla danego typu sprawy | Wymóg istnieje w wiki, a nie w polu, więc dwóch recenzentów stosuje dwie różne jego wersje |
| Jakość komunikacji | Wyłącznie wiadomości napisane przez konsultanta, nigdy cały kanał aktywności | Ocena tekstu, który klient faktycznie mógł przeczytać | Recenzenci przejmują ton z wpisów wewnętrznych i wpisów systemowych i przypisują go konsultantowi |
| Szybkość reakcji i nakład pracy | Znaczniki czasu wiadomości i zmian właściciela | Pomiar przerw między wiadomością klienta a kolejną odpowiedzią konsultanta | Czas w kolejce, godziny pracy i oczekiwanie na inny zespół obciążają tego, kto akurat jest właścicielem sprawy |
| Kategoryzacja i jakość danych | Źródło, powód, typ rekordu i Państwa własne pola raportowe | Czy wartości opisują to, co faktycznie wydarzyło się w rozmowie | Konsultanci wybierają wartość, która najszybciej przechodzi regułę walidacji, i do tej pory nikt tego nie oceniał |
| Kierowanie | Historia właścicieli, przynależność do kolejek, typ rekordu | Czy sprawa od razu trafiła do właściwego zespołu, a jeśli nie, to dlaczego | Błędne skierowanie spowodowane regułą kierowania jest oceniane jako błąd konsultanta |
Czym ocena sprawy różni się od oceny zgłoszenia w Zendesk
Wielu liderów operacji obsługi klienta prowadziło kontrolę jakości w Zendesk, a teraz ma ją prowadzić w Service Cloud albo w obu systemach naraz. Filozofia karty oceny się przenosi. Mechanika nie, a oto sześć różnic, które kosztują najwięcej czasu. Jeśli prowadzą Państwo także stronę Zendesk, mechanika właściwa dla tej platformy jest opisana osobno w tekście kontrola jakości w Zendesk.
| Wymiar | Zgłoszenie w Zendesk | Sprawa w Salesforce Service Cloud |
|---|---|---|
| Jednostka oceny | Zgłoszenie to wątek. Zgłaszający, osoba przypisana i komentarze czyta się jak jedną liniową rozmowę | Sprawa to rekord. Rozmowę składa się z powiązanych wiadomości, transkrypcji i elementów kanału aktywności |
| Kto wykonał pracę | Osoba przypisana oraz autorzy widocznych komentarzy | Pole właściciela mówi, kto ma sprawę teraz. Autorstwo trzeba odczytać z każdej wiadomości osobno |
| Kanał | Zwykle właściwość samego zgłoszenia | Kanały pojawiają się jako różne powiązane rekordy, a jedna sprawa może mieć ich kilka |
| Definiowanie populacji próbki | Widoki i filtry wyszukiwania | Raport lub widok listy zbudowany na polach spraw w Państwa organizacji |
| Ile jest standardowe | Zestaw pól jest w dużej mierze taki sam w różnych kontach | Typy rekordów, pola niestandardowe i wartości list wyboru są konfigurowane w każdej organizacji osobno, więc żadna karta oceny nie przenosi się bez zmian |
| Stan zamknięcia | Krótki, znany zestaw statusów | Wartości statusów i ich znaczenie operacyjne określa Państwa administrator |
Jak pobrać próbkę, której da się bronić
Najczęstszy zarzut wobec programu kontroli jakości brzmi: recenzent wybrał najgorsze sprawy. W Service Cloud łatwo go postawić, bo nie ma naturalnej kolejki ocen i naprawdę kusi, żeby pracować na widoku listy, który akurat jest otwarty.
Najpierw trzeba zdefiniować populację w raporcie i ten raport zapisać. Sprawdzony filtr to: data zamknięcia w okresie oceny, typ rekordu lub kolejka identyfikujące ocenianą pracę, kanał, jeśli kanały ocenia się osobno, oraz wykluczenie spraw bez żadnej wiadomości napisanej przez konsultanta. Duplikaty, sprawy zamknięte automatycznie i sprawy, które nigdy nie trafiły do człowieka, to szum, a pozostawienie ich w populacji po cichu zawyża lub zaniża każdą średnią publikowaną później.
Następnie próbkę losuje się z tej populacji, a nie z listy. Dwie zasady są ważniejsze niż wielkość próbki:
- Losowanie w warstwach, a nie z całego zbioru. Warstwy wyznacza się według konsultanta i typu sprawy, a następnie losuje w obrębie każdej z nich. Czysto losowy dobór z całego miesiąca daje najbardziej obciążonym konsultantom dwadzieścia spraw, a najnowszemu jedną, przez co wyniki indywidualne stają się nieporównywalne.
- Ustalenie próbki, zanim ktokolwiek przeczyta sprawę. Trzeba wylosować listę, zapisać ją i ocenić to, co wylosowano. Próbka wybrana po tym, jak recenzent przejrzał populację, nie jest próbką.
Warto uczciwie przyznać, co daje ręczna próbka. Ocena trzydziestu spraw na konsultanta miesięcznie to poważna ilość pracy, a mimo to mówi bardzo niewiele o konkretnych typach spraw, które zdarzają się rzadko, a szkodzą najbardziej. To ograniczenie wynika z arytmetyki, a nie z braku wysiłku, i jest to ten sam warunek, który podręcznik inżynierski NIST opisuje, pytając, czy próbkowa proporcja wadliwych egzemplarzy spełnia wymaganie: próbka musi być na tyle duża, by test był ważny, zanim odpowiedź cokolwiek znaczy. Dlatego wynik z próbki i internal quality score raportowany kierownictwu powinny podawać przedział ufności obok liczby, i dlatego warto wiedzieć, gdzie próbkowanie rozmów do oceny jakości przestaje odpowiadać na pytanie.
Kto napisał odpowiedź: przypisanie w sprawie, która zmieniła właściciela
Oto problem, na który nie przygotowuje żaden szablon, i ten, który najbardziej szkodzi zaufaniu konsultantów do programu kontroli jakości w Service Cloud.
Sprawy się przemieszczają. Są kierowane, eskalowane, przypisywane na nowo, pobierane z kolejki, przekazywane zespołowi specjalistów i zwracane. Pole właściciela zapisuje, kto ma sprawę w chwili, gdy Państwo na nią patrzą. Nie zapisuje, kto napisał odpowiedź, która zirytowała klienta, ani kto przeprowadził analizę, która rozwiązała problem. Jeśli proces kontroli jakości ocenia sprawę i przypisuje wynik właścicielowi, to w każdej przekazanej sprawie praca jednej osoby zostaje przypisana innej.
Praktyczne skutki są przewidywalne i konkretne. Konsultanci obsługujący eskalacje przejmują sprawy, które już idą źle, i zbierają wynikające z nich oceny. Zwykle są to Państwa najbardziej kompetentni ludzie. W ciągu kwartału uczą się, że przejęcie trudnej sprawy ich kosztuje, a zachowanie, które najbardziej chcieli Państwo wspierać, staje się zachowaniem karanym przez Państwa ranking.
Cztery zasady, które to naprawiają
- Oceniać wiadomość, a nie rekord. Każde odjęcie punktów powinno być powiązane z konkretną wiadomością napisaną przez konsultanta, ze znacznikiem czasu i autorem, a nie z całą sprawą.
- Przypisywać według autora. Autorstwo należy odczytywać z każdej wiadomości, a nie z pola właściciela. Jeśli Państwa raportowanie tego nie potrafi, to pierwsza rzecz do naprawienia, zanim zmieni się choćby jedną wagę.
- Jawnie obsługiwać sprawy z udziałem kilku konsultantów. Albo ocenia się osobno wkład każdego konsultanta, albo wyłącza sprawę z oceny indywidualnej i wykorzystuje ją do przeglądu procesu. Obu podejść da się bronić. Ciche ocenianie ostatniego właściciela już nie.
- Trzymać historię właścicieli obok wyniku. Gdy wynik jest kwestionowany, pierwsze pytanie zawsze brzmi: kto co zrobił. Jeśli odtworzenie odpowiedzi zajmuje dwadzieścia minut, spór jest już przegrany.
Przekazywane sprawy są też najbogatszym źródłem do pracy nad procesami, a nie nad indywidualnym coachingiem. Sprawa, która przed rozwiązaniem czterokrotnie zmieniała właściciela, mówi coś o kierowaniu, uprawnieniach lub granicach między zespołami, a to należy do analizy przyczyn źródłowych, a nie do czyjejś karty oceny.
Ocena każdej sprawy zamiast próbki
Gdy metoda ręczna jest już ustalona, oczywiste pytanie brzmi, czy można przestać pobierać próbki. Można, a w Service Cloud argument za tym jest mocniejszy niż w prostszym modelu zgłoszeń, bo najważniejsze typy spraw to często właśnie te rzadkie, do których próbka nigdy nie dociera. Istnieje realna różnica między pokryciem 100% (po angielsku), które ujawnia trendy, jakich próbkowanie 3% nigdy by nie pokazało, a comiesięczną oceną trzydziestu spraw na konsultanta.
Samo pokrycie nie jest jednak najciekawsze i nie jest już też czynnikiem wyróżniającym. Każdy dostawca w tej kategorii ocenia dziś wszystko. O tym, czy automatyczny wynik przetrwa zderzenie z Państwa zespołem, decyduje pytanie, czy da się pokazać, że system oceniający miał rację. W Service Cloud oznacza to konkretnie cztery rzeczy:
- Możliwość prześledzenia w sprawie. Odjęcie punktów musi wskazywać kryterium i konkretną wiadomość w sprawie, która je spowodowała. „Komunikacja: minus dziesięć” w sprawie z czterdziestoma elementami w kanale aktywności jest bezużyteczne.
- Ten sam materiał dowodowy, którego użył system oceniający. Recenzent sprawdzający wynik powinien widzieć zestaw wiadomości, z którego wynik obliczono, a nie jego streszczenie.
- Ścieżka odwoławcza. Konsultant musi móc zakwestionować wynik (po angielsku) i doprowadzić do tego, by ktoś sprawdził uzasadnienie. Jeśli nie może, wynik jest wyrokiem.
- Zmierzona zgodność, zanim wynik zacznie się liczyć. Przez kilka tygodni automatyczna ocena powinna działać równolegle z Państwa recenzentami na tych samych sprawach, a walidacja oceny (po angielsku) powinna nastąpić, zanim liczba zostanie powiązana z czymkolwiek, co ma konsekwencje.
Auto QA od Kaizo stosuje do spraw kryteria z Państwa własnej karty oceny i utrzymuje uzasadnienie przy rozmowie, dzięki czemu zakwestionowane odjęcie punktów można prześledzić do wymiany, która je spowodowała, zamiast spierać się z pamięci. Działa w Service Cloud dzięki integracji z Salesforce, opisanej szerzej na stronie Kaizo w Salesforce, obok takiej samej integracji z Zendesk, co ma znaczenie, jeśli prowadzą Państwo kontrolę jakości w obu systemach w trakcie migracji. Umów demo, aby zobaczyć to na własnych sprawach.
Wdrożenie, które przetrwa pierwszy spór
Programy kontroli jakości w Service Cloud upadają zawsze w tym samym momencie: gdy konsultant po raz pierwszy poważnie kwestionuje wynik, a program nie potrafi odpowiedzieć. Wdrożenie trzeba ułożyć tak, by odpowiedź istniała, zanim pojawi się zarzut.
| Etap | Co należy zrobić | Ukończony, gdy |
|---|---|---|
| 1. Zdefiniować jednostkę | Wybrać jedną z trzech definicji rozmowy i ją zapisać. Spisać, co faktycznie znajduje się w zamkniętej sprawie w Państwa organizacji | Recenzent potrafi bez wahania powiedzieć, które rekordy są objęte oceną |
| 2. Powiązać kryteria z polami | Dla każdego kryterium nazwać dowód, sposób sprawdzenia i spodziewany błąd. Usunąć wszystko, czego nie da się udowodnić | Każde kryterium wskazuje pole lub typ wiadomości, które istnieją |
| 3. Zbudować raport populacji | Jeden zapisany raport definiujący zbiór do oceny, z wykluczeniem spraw zamkniętych automatycznie i spraw bez konsultanta | Dwie osoby uruchamiające raport otrzymują tę samą liczbę spraw |
| 4. Ocena równoległa i kalibracja | Trzech recenzentów niezależnie ocenia te same piętnaście spraw, w tym co najmniej trzy, które zmieniły właściciela. Porównać wyniki i przedyskutować | Znają Państwo wskaźnik rozbieżności recenzentów i ten wskaźnik spada |
| 5. Ogłosić wraz ze ścieżką odwoławczą | Ogłosić razem kartę oceny, metodę doboru próbki i procedurę odwoławczą. Odwołanie bez ścieżki to tylko skarga | Konsultanci potrafią opisać procedurę bez zaglądania do dokumentów |
| 6. Raportować, a potem sprawdzić mapowanie | Raportować wyniki obok wyników operacyjnych, takich jak ponowne otwarcia i eskalacje. Co kwartał wracać do mapowania | Zmiany wyników wyjaśniają coś, czego menedżer już się domyślał |
Raportowanie wyniku sprawy tak, by ktoś podjął działanie
Wynik QA, który istnieje tylko w narzędziu do QA, czyta zespół QA. Żeby był wart wysiłku, musi stać obok liczb operacyjnych, na które kierownictwo obsługi klienta już patrzy, i musi być rozbity w sposób, który wskazuje działanie.
Większość pracy na danych z Service Cloud wykonują trzy przekroje:
- Według typu sprawy lub typu rekordu, a nie tylko według konsultanta. Jakość zależy znacznie bardziej od rodzaju pracy niż od osoby, która ją wykonuje. Niska średnia dla jednego typu rekordu to problem procesu, wiedzy lub kierowania i można go naprawić centralnie.
- Według kryterium, w całym zespole. Kryterium, które zawodzi powszechnie, prawie nigdy nie jest problemem coachingowym. To niejasna zasada, brakujący artykuł w bazie wiedzy albo źle napisane kryterium.
- Wynik w zestawieniu ze wskaźnikiem ponownych otwarć i eskalacji. To sprawdzian samej karty oceny. Jeśli sprawy z wysokim wynikiem są ponownie otwierane równie często jak te z niskim, karta mierzy coś innego niż jakość i trzeba zmienić jej wagi.
Ten trzeci przekrój warto chronić. To on sprawia, że program kontroli jakości nie zamienia się w rytuał zgodności, który wszyscy odprawiają i z którego nikt nie korzysta. Zestawienie wyników jakości z obrazem operacyjnym to dokładnie zadanie widoku analityki obsługi klienta, a zarazem najszybszy sposób, by pokazać sceptycznemu kierownictwu, że program kontroli jakości mierzy coś rzeczywistego.
Najczęściej zadawane pytania
Czy Salesforce Service Cloud ma wbudowaną ocenę QA?
Service Cloud dostarcza surowiec: rekord sprawy, powiązane z nim wiadomości i transkrypcje, historię pól i warstwę raportową nad tym wszystkim. Karta oceny z wagami, kolejka ocen, kalibracja między recenzentami i audytowalny ślad odwołań nie są częścią standardowego obiektu sprawy. Zespoły albo budują prostą wersję na polach niestandardowych i raportach, co działa, dopóki rozbieżności między recenzentami nie staną się wąskim gardłem, albo dodają narzędzie do QA, które odczytuje sprawy. Zanim przyjmą Państwo którekolwiek założenie, warto sprawdzić, co już skonfigurowano we własnej organizacji, bo stopień dostosowania jest bardzo różny.
Co oceniać w sprawie w Salesforce?
Tylko to, czego dowodzi sprawa. W praktyce są to wiadomości napisane przez konsultanta, znaczniki czasu tych wiadomości i zmian właściciela, wartości pól, z którymi sprawę zamknięto, oraz notatki wewnętrzne, jeśli Państwa definicja rozmowy je obejmuje. Wszystko, czego nie da się wskazać w rekordzie, na przykład to, co konsultant wiedział w danym momencie, albo oddzwonienie zapisane jako jednolinijkowa notatka, należy do coachingu, a nie do wyniku.
Czym kontrola jakości w Service Cloud różni się od kontroli jakości w Zendesk?
Filozofia karty oceny jest ta sama, mechanika nie. Zgłoszenie w Zendesk (po angielsku) to liniowy wątek z jasno przypisaną osobą, więc jednostka oceny jest oczywista. Sprawa w Salesforce to rekord z powiązanymi wiadomościami, transkrypcjami i elementami kanału aktywności, więc jednostkę trzeba zdefiniować samodzielnie. Autorstwo również trzeba odczytywać z poszczególnych wiadomości, a nie brać z pola właściciela, a ponieważ typy rekordów i pola niestandardowe konfiguruje się w każdej organizacji osobno, żadna karta oceny nie przenosi się bez zmian między dwiema organizacjami Salesforce.
Jak pobrać próbkę spraw z Salesforce do oceny jakości?
Należy zbudować zapisany raport definiujący populację, z filtrem na datę zamknięcia, typ rekordu lub kolejkę, kanał tam, gdzie ma to znaczenie, i z wykluczeniem spraw bez żadnej wiadomości napisanej przez konsultanta. Następnie losuje się w warstwach, według konsultanta i typu sprawy, a nie z całego miesiąca, tak by każdy konsultant miał porównywalną liczbę spraw. Próbkę trzeba ustalić, zanim ktokolwiek otworzy sprawę. Ocenianie listy, którą już się przejrzało, nie jest próbkowaniem.
Kto dostaje wynik QA, gdy sprawa zmienia właściciela?
Nie automatycznie obecny właściciel, choć to domyślne rozwiązanie, w które wpada większość programów, i to, które wyrządza najwięcej szkód. Każdą ocenianą wiadomość należy przypisać jej autorowi. W sprawie obsługiwanej przez kilka osób trzeba albo ocenić osobno wkład każdego konsultanta, albo wyłączyć sprawę z oceny indywidualnej i wykorzystać ją do przeglądu procesu. Obciążanie ostatniego właściciela wynikiem za pracę, którą przejął, uczy najlepszych konsultantów unikać eskalacji.
Czy można oceniać e-mail, czat i rozmowy telefoniczne w tej samej sprawie?
Można, ale podejście trzeba ustalić przed wdrożeniem, a nie w trakcie pierwszego sporu. Jeden łączny wynik dla sprawy zawierającej wątek e-mailowy i transkrypcję czatu trudno wykorzystać w coachingu, bo standardy dla tych dwóch kanałów naprawdę się różnią. Zwykle czytelniejsza jest osobna ocena i osobne raportowanie każdego fragmentu kanału. Jeśli w grę wchodzą rozmowy telefoniczne, najpierw trzeba potwierdzić, czy Państwa organizacja rzeczywiście ma dołączone transkrypcje, a nie tylko nagrania, bo kryterium zależnego od treści rozmowy nie da się bez nich egzekwować.