Agent obsługi klienta w Copilot Studio: plan wdrożenia

Agent obsługi klienta w Microsoft Copilot Studio powinien rozwiązywać wybrany rodzaj spraw i przekazywać pozostałe do właściwej osoby. Jego wartość nie wynika z liczby odpowiedzi ani z samej dostępności czatu. Liczy się to, czy klient otrzymał poprawną informację, wykonał potrzebny krok i nie musi powtarzać całej historii konsultantowi.

Dla kierownika obsługi oznacza to zmianę kolejności wdrożenia. Najpierw trzeba ustalić zakres, źródła wiedzy oraz sposób przekazania sprawy. Te kryteria są wspólne dla różnych platform; szerzej opisuje je plan chatbota AI w firmie. Dopiero potem warto projektować rozmowę i podłączać narzędzia. Agent obsługujący jeden dobrze opisany proces może być bardziej przydatny niż rozbudowany chatbot, który odpowiada na wszystko, ale nie potrafi zakończyć zgłoszenia.

Wybierz sprawy, które mają jasny warunek zakończenia

Zacznij od przeglądu rzeczywistych kontaktów z ostatniego okresu. Pogrupuj je według intencji klienta, a nie wyłącznie produktu. Pytanie o instrukcję, sprawdzenie statusu i zgłoszenie niezgodności mogą dotyczyć tego samego zamówienia, lecz wymagają innych danych oraz uprawnień.

Dla każdej grupy zapisz częstotliwość, obecny czas obsługi, typowe wyjątki i źródło poprawnej odpowiedzi. W pierwszej wersji wybierz sprawy częste, dobrze udokumentowane i możliwe do sprawdzenia. Wysoka liczba kontaktów nie wystarcza, jeśli każdy wymaga indywidualnych ustaleń lub decyzji przełożonego.

Przykładowy zakres może brzmieć: agent objaśnia publiczne instrukcje instalacji, sprawdza status zgłoszenia po uwierzytelnieniu oraz przekazuje awarie wymagające diagnostyki do serwisu. Poza zakresem pozostają negocjacje warunków umowy, ustalanie rekompensaty i potwierdzanie terminu naprawy bez informacji z systemu.

Nie zapisuj celu jako „redukcja kontaktów z człowiekiem za wszelką cenę”. Taki miernik może premiować utrudnianie eskalacji. Lepszym celem jest poprawne zakończenie określonej klasy spraw przy utrzymaniu jakości i dostępności konsultanta tam, gdzie jest potrzebny.

Oddziel informację publiczną od sprawy konkretnego klienta

Odpowiedź na pytanie o godziny pracy nie wymaga tego samego dostępu co odczyt historii zamówienia. Podział powinien być widoczny zarówno w projekcie rozmowy, jak i w integracji z systemem. Sam numer sprawy podany przez rozmówcę nie jest dowodem, że wolno mu ją zobaczyć.

Rodzaj kontaktu	Źródło odpowiedzi	Wymagana kontrola
Instrukcja użycia produktu	Zatwierdzona dokumentacja publiczna	Wersja produktu i aktualność instrukcji
Status indywidualnej sprawy	System obsługi zgłoszeń	Uwierzytelnienie i dostęp do konkretnego rekordu
Zmiana danych zgłoszenia	Operacja w systemie źródłowym	Walidacja, potwierdzenie i wynik zapisu
Nietypowa awaria	Opis klienta i dostępne informacje techniczne	Przekazanie do właściwego zespołu
Spór o warunki obsługi	Dokumenty sprawy	Decyzja uprawnionego pracownika

Copilot Studio umożliwia konfigurowanie uwierzytelniania, ale trzeba dobrać je do kanału i odbiorcy. Dokumentacja logowania użytkowników rozróżnia między innymi brak uwierzytelniania oraz warianty z logowaniem. Publiczny agent nie powinien otrzymać narzędzia, które na podstawie dowolnie wpisanego identyfikatora oddaje dane klienta.

Uprawnienia muszą być egzekwowane przez system lub usługę realizującą odczyt. Polecenie w instrukcji agenta, aby nie ujawniał cudzych spraw, nie zastępuje tej kontroli. Test powinien obejmować próbę odczytu własnego rekordu, cudzego rekordu i nieistniejącego identyfikatora.

Przygotuj małą, utrzymywaną bazę wiedzy

Do pierwszej wersji nie trzeba podłączać całego archiwum firmy. Wybierz aktualne instrukcje dotyczące uzgodnionego zakresu. Każda powinna mieć właściciela, datę obowiązywania i informację o produktach lub wariantach usługi, których dotyczy. Usuń z tego zbioru robocze propozycje i zastąpione wersje.

Według opisu źródeł wiedzy Copilot Studio sposób uwierzytelnienia zależy od rodzaju źródła. Przykładowo źródła SharePoint wykorzystujące tożsamość użytkownika różnią się od dokumentów przesłanych do agenta. Nie należy zakładać, że każda kopia pliku zachowuje kontrolę dostępu z miejsca, z którego pochodziła.

Zaprojektuj odpowiedź tak, aby klient mógł sprawdzić istotną instrukcję. Odsyłacz powinien prowadzić do dostępnego dla niego materiału. Link do wewnętrznej biblioteki, której nie może otworzyć, nie jest użytecznym potwierdzeniem odpowiedzi.

Sprawdź też pytania uzupełniające. Klient może najpierw zapytać o instalację jednego modelu, a następnie przejść do innego. Agent powinien zauważyć zmianę kontekstu. Nie wystarczy test jednej poprawnej odpowiedzi w nowej rozmowie, jeśli rzeczywiste kontakty obejmują kilka tematów.

Zaprojektuj rozmowę wokół następnego kroku

Pytaj tylko o informacje potrzebne do rozwiązania sprawy lub jej przekazania. Jeśli do wskazania instrukcji wystarczy model urządzenia, nie zbieraj od razu adresu, numeru zamówienia i numeru telefonu. Skraca to rozmowę i ogranicza ilość informacji, które zespół musi później chronić oraz przeglądać.

Po rozpoznaniu problemu agent powinien wskazać konkretny krok i warunek sprawdzenia rezultatu. „Uruchom ponownie i sprawdź” jest zbyt ogólne. Lepsza instrukcja podaje, co zrobić zgodnie z dokumentacją produktu oraz po czym poznać, że problem ustąpił. Działania mogące przerwać pracę klienta wymagają odpowiedniej procedury, a nie improwizowanej porady.

Gdy brakuje potrzebnych danych, agent powinien je doprecyzować. Gdy źródła nie dają odpowiedzi, powinien powiedzieć, czego nie udało się ustalić. Nie powinien generować prawdopodobnej daty realizacji tylko dlatego, że klient oczekuje terminu.

Rozdziel język potwierdzenia od języka propozycji. „Przygotowałem zgłoszenie do wysłania” i „zgłoszenie zostało przyjęte pod numerem…” opisują inne stany. Drugi komunikat powinien pojawić się dopiero po potwierdzeniu operacji przez system obsługi.

Przekazanie do konsultanta musi działać poza demonstracją

Microsoft opisuje przekazanie rozmowy do konsultanta dla agentów działających w wariancie standardowym. Pełne przekazanie wymaga skonfigurowanego połączenia z systemem obsługi konsultantów. Sam temat Escalate może jedynie wyświetlać komunikat lub instrukcję kontaktu; nie oznacza automatycznie działającego transferu rozmowy.

Zaprojektuj trzy sytuacje: konsultant jest dostępny, wszyscy są zajęci oraz zespół nie pracuje. Klient powinien wiedzieć, czy czeka w kolejce, czy powstało zgłoszenie do późniejszej obsługi. Nie wyświetlaj obietnicy natychmiastowego połączenia, jeśli integracja nie potrafi jej spełnić.

Do przekazania przygotuj zwięzłe podsumowanie: intencję klienta, potwierdzone dane, wykonane kroki i problem, który pozostał. Ustal, jaka część historii jest potrzebna konsultantowi. Nie kopiuj bez zastanowienia danych, które rozmówca podał przypadkiem i które nie służą rozwiązaniu sprawy.

Przetestuj również prośbę o człowieka na początku i w środku rozmowy. Klient nie powinien wielokrotnie przechodzić przez te same pytania, żeby dotrzeć do wsparcia. Jeśli sprawa wymaga pracownika z określonego zespołu, sprawdź przypisanie kolejki, a nie tylko fakt uruchomienia transferu.

Narzędzia dodawaj po sprawdzeniu podstawowej obsługi

Odczyt statusu jest zwykle prostszy do oceny niż operacja zmieniająca dane. Dlatego warto zacząć od informacji, następnie dodać kontrolowany odczyt, a dopiero później wybrane zapisy. Każdy krok powinien mieć własne testy i możliwość wyłączenia bez zamykania całego kanału pomocy.

Przy tworzeniu zgłoszenia określ wymagane pola, dozwolone wartości i sposób obsługi ponowienia. Jeśli system przyjął zgłoszenie, ale odpowiedź nie dotarła do agenta, kolejna próba nie powinna bez kontroli tworzyć duplikatu. W projekcie integracji potrzebny jest identyfikator operacji lub inny mechanizm wykrycia wcześniejszego wykonania.

Ustal także, co agent pokazuje podczas awarii. Nie może zamieniać błędu odczytu w komunikat „nie masz żadnych zgłoszeń”. Brak dostępu, brak danych i niedostępność usługi to różne sytuacje, z różnymi dalszymi krokami dla klienta.

Zbuduj zestaw odbioru przed publikacją

Testy powinny wynikać z zakresu obsługi i obejmować również zachowania, których oczekujesz przy braku odpowiedzi. Automatyczne metryki są pomocą, lecz próbka rozmów oceniona przez zespół obsługi pokaże, czy rozwiązanie rzeczywiście odpowiada standardom firmy.

Próba	Oczekiwany wynik	Dowód do zapisania
Typowe pytanie o instrukcję	Poprawna odpowiedź dla właściwego produktu	Źródło i ocena konsultanta
Niepełny opis problemu	Jedno potrzebne doprecyzowanie	Przebieg rozmowy
Cudza sprawa	Brak ujawnienia danych	Wynik kontroli uprawnień
Niedostępny system	Jasny komunikat i droga zastępcza	Zachowanie kanału produkcyjnego
Ponowione wysłanie	Jedno prawidłowe zgłoszenie	Identyfikator rekordu
Prośba o konsultanta	Działające przekazanie lub realna alternatywa	Odbiór po stronie zespołu

Przeprowadź odbiór w kanale, którego użyją klienci. Okno testowe projektanta nie potwierdza poprawności logowania, osadzenia na stronie ani działania kolejki konsultantów. Sprawdź również urządzenie mobilne i możliwość odczytania komunikatów bez polegania wyłącznie na kolorze.

Sprawdź zmianę procedury po uruchomieniu

Odbiór pierwszej wersji nie kończy pracy nad agentem. Przećwicz zmianę instrukcji produktu: właściciel zatwierdza nową wersję, osoba utrzymująca wiedzę aktualizuje źródło, a tester ponawia pytania dotyczące zmienionego fragmentu. Zapisz moment, od którego nowa odpowiedź powinna być dostępna. Nie zakładaj natychmiastowego odświeżenia każdego rodzaju źródła.

Dodaj do tej próby pytanie wykorzystujące wcześniejsze warunki. Agent powinien rozróżnić aktualną procedurę i sytuację klienta obsługiwanego według wcześniejszych ustaleń. Jeśli nie ma danych pozwalających rozstrzygnąć różnicę, powinien przekazać sprawę, zamiast łączyć obie wersje w jedną odpowiedź.

Przygotuj także sposób wycofania błędnej zmiany. Zespół musi wiedzieć, kto może ograniczyć temat, podmienić źródło albo czasowo skierować wszystkie takie kontakty do konsultanta. Taka próba pokazuje, czy firma umie utrzymać rozwiązanie podczas normalnych zmian oferty, a nie tylko uruchomić udaną demonstrację.

Policz wynik bez ukrywania eskalacji

Rozważmy przykład modelowy: na 200 kontaktów agent samodzielnie rozwiązał 110, poprawnie przekazał 60, a w 30 przypadkach udzielił błędnej odpowiedzi albo klient przerwał rozmowę bez rozwiązania. Samodzielne rozwiązanie wynosi 55%. Poprawny przebieg, obejmujący także uzasadnioną eskalację, wynosi 85%. Te liczby opisują różne rzeczy i nie powinny być zamieniane w prezentacji wyniku.

Załóżmy dodatkowo, że 110 rozwiązanych spraw oszczędziło średnio 4 minuty pracy konsultanta. Daje to 440 minut. Jeśli kontrola rozmów, poprawa wiedzy i obsługa błędów zajęły 180 minut, pozostaje 260 minut przed uwzględnieniem pozostałych kosztów. To ilustracja rachunku, nie prognoza osiągów Copilot Studio.

Osobno obserwuj powtórne kontakty. Klient, który wraca następnego dnia z tym samym problemem, może ujawnić pozorne rozwiązanie. Ustal okres i sposób przypisania takich powrotów do pierwotnej sprawy, żeby wynik nie zależał wyłącznie od zamknięcia sesji czatu.

Ustal właściciela i warunek rozszerzenia zakresu

Przed uruchomieniem wskaż osobę odpowiedzialną za wiedzę, integracje i ocenę rozmów. Te role mogą należeć do różnych zespołów, ale muszą mieć uzgodniony sposób zgłaszania błędów. Krytyczna nieprawidłowa odpowiedź powinna prowadzić do szybkiego ograniczenia odpowiedniego scenariusza.

Po pilotażu rozszerzaj zakres dopiero wtedy, gdy istnieją dowody jakości i korzyści operacyjnej. Jeśli brakuje źródeł lub sprawnej eskalacji, najpierw usuń tę przyczynę. Kolejne intencje zwiększą złożoność, ale same nie poprawią obsługi.

Przeczytaj kiedy budować własnego agenta w Copilot Studio, aby dobrać zakres rozwiązania. Następnie powiąż go z systemem obsługi i odpowiedzialnością w firmie. Dobry pierwszy rezultat to jedna klasa spraw, którą klient potrafi zakończyć, a zespół potrafi utrzymać.