Copilot Studio – automatyzacja obsługi pracowników i klientów za pomocą agentów AI
Jak zbudować w Copilot Studio agenta AI dla HR, IT lub obsługi klientów? Poznaj zasady projektowania dialogów, integracji z systemami i przekazywania spraw konsultantom. Sprawdź, jak zadbać o bezpieczeństwo danych i mierzyć efekty automatyzacji.
Po co budować agentów AI w Copilot Studio dla HR, IT i obsługi klienta?
Pracownik pyta, gdzie znaleźć zasady pracy zdalnej. Klient chce sprawdzić status zamówienia. Do działu IT trafia kolejne zgłoszenie dotyczące problemu z dostępem do aplikacji. Każda z tych spraw jest ważna dla zgłaszającego, ale nie każda wymaga od początku zaangażowania specjalisty. Agent AI może przejąć pierwszy etap obsługi: zrozumieć potrzebę, udzielić odpowiedzi na podstawie udostępnionej wiedzy lub pomóc wykonać określoną czynność. Dzięki temu użytkownik nie musi wiedzieć, w którym dokumencie szukać informacji ani do jakiego zespołu skierować pytanie.
Microsoft Copilot Studio to platforma do tworzenia i zarządzania agentami AI w podejściu low-code, czyli z ograniczoną potrzebą pisania kodu. Pozwala budować rozwiązania dopasowane do konkretnych procesów organizacji, zamiast ograniczać się do ogólnego asystenta. Nie oznacza to jednak automatyzacji bez przygotowania: agent potrzebuje jasno określonego zadania, wiarygodnych materiałów i ustalonego zakresu działania.
Od odpowiadania na pytania do pomocy w załatwieniu sprawy
Klasyczny bot oparty na sztywnym scenariuszu zwykle prowadzi użytkownika przez zdefiniowane pytania i odpowiedzi. Agent AI może dodatkowo interpretować pytania zadane własnymi słowami, uwzględniać kontekst rozmowy i korzystać z wiedzy organizacji. Jeśli zostanie odpowiednio przygotowany, może również wykonywać dozwolone działania, a nie tylko wskazywać instrukcję. Istotą tej zmiany jest przejście od „gdzie znajdę informację?” do „pomóż mi rozwiązać problem”. Nie każda potrzeba wymaga jednak agenta — przy prostym, niezmiennym procesie formularz lub tradycyjna automatyzacja mogą wystarczyć.
Wspólna technologia, różne potrzeby użytkowników
W HR i IT agent wspiera przede wszystkim pracowników, natomiast w obsłudze klienta pomaga odbiorcom produktów lub usług. Te zastosowania łączy potrzeba szybkiego dostępu do właściwej informacji, ale różni je kontekst:
- HR: wyjaśnianie zasad obowiązujących w organizacji, wskazywanie dokumentów i pomoc w odnalezieniu się w procedurach, szczególnie podczas wdrażania nowych pracowników.
- IT: wsparcie w typowych problemach technicznych i prowadzenie przez podstawowe kroki rozwiązania, zanim sprawa trafi do specjalisty.
- Obsługa klienta: odpowiadanie na pytania o ofertę, zamówienia czy zasady zwrotów oraz ułatwianie załatwienia rutynowych spraw.
Najlepszym punktem wyjścia są powtarzalne potrzeby, dla których istnieje sprawdzona odpowiedź lub jasno opisany sposób postępowania. W takich obszarach agent może ograniczyć ręczne wyszukiwanie informacji i odciążyć zespoły od podobnych zapytań. Celem nie jest zastąpienie każdej rozmowy z człowiekiem, lecz zapewnienie sprawniejszej obsługi tam, gdzie automatyzacja rzeczywiście pomaga — i pozostawienie specjalistom spraw wymagających oceny, empatii lub indywidualnej decyzji.
Projektowanie agenta: intencje, tematy (topics), dialogi, dane i ton komunikacji
Projektowanie agenta w Copilot Studio warto zacząć od rzeczywistych pytań pracowników i klientów, a nie od listy funkcji platformy. „Ile zostało mi urlopu?”, „Nie mogę się zalogować” i „Chcę zmienić adres dostawy” to trzy różne potrzeby: uzyskanie informacji, rozwiązanie problemu oraz wykonanie konkretnej operacji. Każda wymaga innego przebiegu rozmowy i innej definicji poprawnego zakończenia sprawy. W Cognity często słyszymy pytania, jak praktycznie przełożyć te potrzeby na projekt agenta — odpowiadamy na nie także na blogu.
Intencja określa cel, a temat organizuje obsługę
Intencja to cel użytkownika, niezależnie od słów, którymi go opisuje. Komunikaty „VPN nie działa” i „Nie mogę połączyć się z siecią firmową z domu” mogą dotyczyć tej samej potrzeby. Na etapie projektowania należy zebrać typowe sformułowania z dostępnych zgłoszeń i pytań oraz wskazać przypadki niejednoznaczne. Samo hasło „urlop” nie rozstrzyga przecież, czy pracownik chce poznać zasady, sprawdzić saldo, czy złożyć wniosek.
Temat, czyli topic, jest w Copilot Studio elementem definiującym przebieg obsługi określonego zagadnienia. Może zawierać pytania, warunki, komunikaty i wywołania działań. Nie musi odpowiadać pojedynczemu sformułowaniu ani całemu obszarowi, takiemu jak HR. Lepszym punktem odniesienia jest konkretna sprawa, np. pomoc przy problemie z logowaniem. W zależności od konfiguracji agenta dobór tematu może opierać się m.in. na frazach wyzwalających lub jego opisie wykorzystywanym przez orkiestrację generatywną.
Dialog powinien prowadzić do rozwiązania, nie do kolejnych pytań
Dobry dialog zbiera tylko informacje potrzebne do następnego kroku. Jeśli użytkownik podał już nazwę aplikacji i treść błędu, agent nie powinien pytać o nie ponownie. Trzeba więc zaplanować, jakie dane będą przechowywane w zmiennych, które są obowiązkowe i jak sprawdzać ich poprawność. Warto również uwzględnić zmianę odpowiedzi, rezygnację oraz powrót do wcześniejszego kroku.
Swobodna odpowiedź generatywna i kontrolowany dialog służą różnym zadaniom. Pierwsza dobrze sprawdza się przy wyjaśnianiu procedur na podstawie wiedzy. Drugi jest przydatny tam, gdzie trzeba zebrać ustalony zestaw informacji lub uzyskać potwierdzenie przed wykonaniem operacji. Przykładowo pytanie o zasady zmiany adresu dostawy wymaga objaśnienia, natomiast prośba o samą zmianę — uporządkowanego przebiegu. Gdy wypowiedź jest niejasna, lepiej zadać jedno precyzyjne pytanie doprecyzowujące niż zgadywać.
Dane i wiedza muszą odpowiadać zakresowi agenta
Należy odróżnić wiedzę opisową, taką jak instrukcje i regulaminy, od bieżących danych dotyczących konkretnej sprawy. Dokument opisujący politykę urlopową nie pozwoli ustalić aktualnego salda urlopu pracownika. Dla każdej intencji warto zatem określić, czego agent potrzebuje: treści źródłowej, informacji od rozmówcy czy aktualnego stanu w systemie.
Materiały wiedzy powinny być aktualne, jednoznaczne i pozbawione sprzecznych wersji. Ważna jest też czytelna struktura dokumentów oraz wskazanie, kogo dotyczą poszczególne zasady. W projekcie należy przewidzieć odpowiedź na brak informacji: agent powinien jasno komunikować ograniczenie, zamiast uzupełniać lukę prawdopodobnie brzmiącą treścią.
Ton komunikacji dopasowany do sytuacji
Instrukcje agenta powinny określać język, długość odpowiedzi, sposób wyjaśniania terminów i zadawania pytań. W IT liczą się krótkie, wykonalne kroki; w HR — neutralność i takt; w obsłudze klienta — zrozumiałe przedstawienie dostępnych możliwości. Ton może dostosowywać się do sytuacji, ale musi pozostawać spójny. Agent nie powinien deklarować wykonania czynności, jeśli jedynie opisał procedurę, ani obiecywać rezultatu, którego nie może potwierdzić.
Integracje i automatyzacje: system zgłoszeń, CRM, bazy wiedzy, API i Power Automate
Agent, który wyjaśnia procedurę zgłoszenia awarii, pomaga znaleźć informację. Agent połączony z systemem ITSM może dodatkowo zebrać opis problemu, utworzyć zgłoszenie i zwrócić jego numer. Integracje pozwalają przejść od udzielania odpowiedzi do realizacji spraw — bez konieczności ręcznego przenoszenia danych z rozmowy do kolejnych aplikacji.
W Copilot Studio warto rozróżnić dwa zastosowania połączeń z systemami: dostarczanie wiedzy potrzebnej do odpowiedzi oraz wykonywanie operacji na danych. Dokumentacja może wyjaśnić zasady reklamacji, ale aktualny status konkretnej sprawy trzeba pobrać z systemu, który ją obsługuje.
System zgłoszeń — tworzenie spraw i sprawdzanie ich statusu
Połączenie z systemem zgłoszeniowym przydaje się zarówno w wewnętrznym wsparciu HR/IT, jak i w obsłudze klientów. Agent może utworzyć zgłoszenie na podstawie informacji z rozmowy, odczytać jego status lub uzupełnić istniejącą sprawę. Zakres dostępnych operacji zależy od możliwości konektora lub API danego systemu.
Kluczowe jest poprawne odwzorowanie danych. System docelowy może wymagać kategorii, identyfikatora użytkownika, opisu problemu czy wskazania usługi. Integracja musi przekazać te wartości w odpowiednim formacie, a następnie odebrać wynik operacji. Potwierdzenie utworzenia zgłoszenia powinno wynikać z odpowiedzi systemu, nie z samego rozpoczęcia procesu.
CRM — kontekst klienta i aktualizacja danych
CRM dostarcza innego rodzaju informacji niż system zgłoszeń: danych o relacji z klientem, powiązanych kontaktach, produktach czy wcześniejszych interakcjach. Dzięki integracji agent może pobrać informacje potrzebne do konkretnej sprawy, zapisać ustalenia lub zaktualizować wybrane pola rekordu.
Nie warto jednak pobierać całej historii klienta przy każdym pytaniu. Lepszym rozwiązaniem są precyzyjne operacje, takie jak „pobierz dane wskazanej sprawy” albo „zapisz preferowany termin kontaktu”. Ułatwia to kontrolowanie przepływu danych i ogranicza ryzyko pracy na niewłaściwym rekordzie. Jeśli sprawa obejmuje CRM oraz system zgłoszeniowy, ich rekordy należy powiązać jednoznacznymi identyfikatorami.
Bazy wiedzy — odpowiedzi oparte na dokumentach
Źródła wiedzy, takie jak SharePoint, Dataverse czy wskazane witryny internetowe, pomagają agentowi odpowiadać na pytania o procedury, produkty i zasady obsługi. Ich rolą jest dostarczenie treści do odpowiedzi, a nie automatyczne wykonywanie opisanych w nich czynności.
W praktyce oba mechanizmy mogą się uzupełniać: agent wyjaśnia zasady wymiany sprzętu na podstawie dokumentacji, a następnie uruchamia operację utworzenia wniosku. Informacje zmienne, takie jak bieżący status wniosku lub dostępność urządzenia, najlepiej odczytywać bezpośrednio z właściwego systemu, zamiast opierać je na okresowo aktualizowanym dokumencie.
Konektory, API i Power Automate — wybór sposobu połączenia
Sposób integracji powinien wynikać z dostępności gotowych połączeń oraz złożoności zadania. Te rozwiązania nie wykluczają się — przepływ Power Automate może korzystać zarówno ze standardowych konektorów, jak i z własnego konektora udostępniającego API.
- Gotowe konektory — dobry punkt wyjścia, gdy udostępniają potrzebne operacje w używanej aplikacji. Przed wdrożeniem należy sprawdzić ich zakres, ograniczenia i wymagania licencyjne.
- API i konektory niestandardowe — przydatne w integracji z systemami wewnętrznymi lub wtedy, gdy gotowe połączenie nie obsługuje wymaganej funkcji.
- Power Automate — pozwala połączyć kilka kroków w jeden proces, np. sprawdzić dane w CRM, utworzyć zgłoszenie i wysłać powiadomienie.
Automatyzacja musi zwracać jednoznaczny wynik
Każda operacja powinna mieć określone dane wejściowe, oczekiwany rezultat oraz sposób obsługi błędu. Jeśli proces trwa dłużej, agent powinien odróżnić przyjęcie zlecenia od jego zakończenia. Warto również zabezpieczyć operacje przed tworzeniem duplikatów przy ponowieniu żądania po utracie połączenia.
Na początek najlepiej wybrać jeden zamknięty scenariusz, np. utworzenie zgłoszenia i odczyt jego statusu. Taka integracja daje użytkownikowi konkretny rezultat, a zespołowi pozwala sprawdzić cały przepływ: od danych z rozmowy po potwierdzenie wykonania operacji w systemie docelowym.
4. Eskalacja do człowieka: handoff, kontekst rozmowy, SLA i routing
Agent AI nie powinien za wszelką cenę utrzymywać rozmowy. Gdy nie potrafi rozwiązać problemu, nie ma uprawnień do wykonania operacji lub sprawa wymaga indywidualnej decyzji, powinien przekazać obsługę człowiekowi. Dobrze zaprojektowana eskalacja pozwala użytkownikowi kontynuować sprawę bez ponownego opisywania problemu i jasno określa, co wydarzy się dalej.
Kiedy uruchamiać eskalację?
W Copilot Studio warto przewidzieć zarówno przekazanie na wyraźną prośbę użytkownika, jak i eskalację wynikającą z przebiegu rozmowy. Powtarzanie tej samej odpowiedzi lub kolejnych pytań doprecyzowujących nie zastępuje pomocy. Jeśli agent wyczerpał dostępne możliwości, powinien to zakomunikować i zaproponować właściwą ścieżkę kontaktu.
- HR: sprawy wymagające interpretacji indywidualnej sytuacji pracownika, rozpatrzenia skargi lub decyzji kadrowej.
- IT: nieskuteczne kroki diagnostyczne, incydenty o szerokim wpływie albo działania wymagające uprawnień administratora.
- Obsługa klienta: sporne reklamacje, wyjątki od standardowych warunków lub prośba o kontakt z konsultantem.
Nie każda trudniejsza sprawa wymaga natychmiastowej rozmowy na żywo. Sposób przekazania powinien odpowiadać pilności problemu, dostępności zespołu oraz kanałowi, w którym działa agent.
Handoff na żywo a zgłoszenie do późniejszej obsługi
Handoff oznacza przekazanie trwającej rozmowy konsultantowi w obsługiwanym środowisku kontaktowym. W Copilot Studio wymaga odpowiednio skonfigurowanej integracji, na przykład z Dynamics 365 Customer Service, oraz obsługi takiego przekazania w danym kanale. Samo dodanie komunikatu „łączę z konsultantem” nie uruchamia transferu.
Eskalacja asynchroniczna polega natomiast na utworzeniu zgłoszenia lub skierowaniu sprawy do zespołu, który odpowie później. To właściwa ścieżka między innymi poza godzinami pracy lub wtedy, gdy rozwiązanie wymaga analizy. Użytkownik powinien otrzymać potwierdzenie przyjęcia sprawy, numer zgłoszenia, jeśli został nadany, oraz informację o sposobie dalszego kontaktu.
W Cognity omawiamy projektowanie eskalacji zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników.
Kontekst, który pozwala kontynuować sprawę
Przekazanie do człowieka powinno obejmować nie tylko samą prośbę o pomoc, lecz także zwięzły opis problemu i dotychczasowych działań. Warto uwzględnić cel użytkownika, ustalone fakty, kroki wykonane przez agenta, ich wyniki oraz przyczynę eskalacji. Zależnie od konfiguracji konsultant może otrzymać również historię rozmowy i identyfikatory powiązanych spraw.
Na przykład informacja „użytkownik nadal nie może zalogować się po wykonaniu wskazanej procedury; błąd występuje po uwierzytelnieniu” jest bardziej przydatna niż ogólna etykieta „problem z logowaniem”. Podsumowanie powinno odróżniać potwierdzone informacje od przypuszczeń. Zakres przekazywanego kontekstu trzeba sprawdzić dla konkretnej integracji — nie należy zakładać, że pełna historia automatycznie trafi do konsultanta.
Routing i SLA: kto przejmuje sprawę i kiedy odpowie?
Routing określa odbiorcę sprawy, a SLA — obowiązujące zobowiązania czasowe. Agent może zebrać informacje potrzebne do wyboru kolejki, takie jak obszar problemu, język, lokalizacja czy wpływ awarii na pracę. Przypisanie do odpowiedniego zespołu i obsługa priorytetów zależą jednak od reguł skonfigurowanych w systemie docelowym.
W komunikacji należy rozróżniać czas oczekiwania na konsultanta, termin pierwszej odpowiedzi i termin rozwiązania. Copilot Studio nie gwarantuje ich dotrzymania przez sam fakt eskalacji. Agent powinien podawać wyłącznie terminy wynikające z dostępnych danych i obowiązujących zasad, z uwzględnieniem godzin pracy zespołu.
Potrzebna jest także ścieżka awaryjna: gdy kolejka jest zamknięta, transfer się nie powiedzie lub nikt nie jest dostępny, użytkownik powinien otrzymać alternatywę, na przykład możliwość pozostawienia zgłoszenia. Nie należy potwierdzać przekazania ani utworzenia sprawy, dopóki system nie potwierdzi wykonania tej operacji.
Logowanie, analityka i optymalizacja: jak doskonalić agenta w Copilot Studio
Agent może udzielić poprawnej językowo odpowiedzi, a mimo to nie rozwiązać problemu użytkownika. Może też prawidłowo rozpoznać prośbę, ale utknąć podczas wykonywania akcji. Dlatego po wdrożeniu trzeba obserwować nie tylko przebieg rozmów, lecz także działanie narzędzi i jakość odpowiedzi. W Copilot Studio logowanie, analityka i testowanie pełnią różne, uzupełniające się funkcje: logi pomagają odtworzyć zdarzenia, raporty ujawniają powtarzalne problemy, a testy pozwalają sprawdzić poprawki przed ich publikacją.
Monitorowanie: od rozmowy do przyczyny błędu
Podstawą analizy są dane o sesjach i transkrypcje rozmów, dostępne zależnie od konfiguracji środowiska. Pokazują, o co pytał użytkownik, jak odpowiedział agent i w którym momencie rozmowa przestała prowadzić do rozwiązania. Warto szukać zwłaszcza powtarzających się pytań, niezrozumiałych odpowiedzi, zapętleń oraz sytuacji, w których użytkownik musi kilkukrotnie wyjaśniać tę samą potrzebę.
Sam zapis rozmowy nie zawsze wyjaśnia jednak awarię. Jeżeli agent miał sprawdzić status zgłoszenia, trzeba ustalić, czy poprawnie zebrał jego numer, uruchomił właściwą akcję i otrzymał wynik. Przy bardziej złożonych wdrożeniach diagnostykę można rozszerzyć o telemetrię w Azure Application Insights oraz historię uruchomień przepływów Power Automate. To pomaga odróżnić problem dialogu od błędu wykonania lub opóźnienia usługi zewnętrznej.
Raporty: szukanie wzorców zamiast pojedynczych potknięć
Wbudowana analityka Copilot Studio umożliwia obserwowanie wykorzystania agenta i wyników sesji. Zakres dostępnych danych zależy między innymi od konfiguracji i używanych funkcji. Raport warto traktować jako punkt wyjścia do diagnozy, a nie gotową ocenę jakości. Zakończenie sesji nie musi oznaczać, że użytkownik załatwił sprawę — mógł zrezygnować, przenieść się do innego kanału albo otrzymać odpowiedź, której nie potrafił zastosować.
Analizę najlepiej prowadzić według obszarów obsługi, takich jak urlopy, dostęp do aplikacji czy status zamówienia. Zbiorczy obraz może ukrywać sytuację, w której agent dobrze obsługuje proste pytania, lecz regularnie zawodzi przy jednym ważnym procesie. Porównywanie okresów przed zmianą i po niej pomaga wychwycić pogorszenie działania, ale wymaga uwzględnienia kontekstu: większej liczby zgłoszeń, sezonowości lub aktualizacji procedur.
Testy: poprawna odpowiedź to tylko część kontroli
Panel testowy w Copilot Studio pozwala sprawdzać zachowanie agenta podczas edycji. Przed publikacją zmian warto dodatkowo zweryfikować pełny scenariusz w warunkach zbliżonych do docelowego kanału. Test samej odpowiedzi nie potwierdzi, że cała sprawa zostanie obsłużona prawidłowo.
Praktyczny zestaw testów powinien obejmować:
- Typowe sprawy — użytkownik jasno opisuje potrzebę i podaje wymagane informacje.
- Warianty językowe — to samo pytanie zawiera skróty, literówki lub potoczne określenia.
- Niepełny kontekst — brakuje danych, użytkownik zmienia zdanie albo odwołuje się do wcześniejszej wypowiedzi.
- Sytuacje niepowodzenia — źródło nie zawiera odpowiedzi, akcja zwraca błąd lub usługa jest niedostępna.
Dla każdego przypadku należy określić oczekiwany rezultat, niekoniecznie identyczne brzmienie odpowiedzi. Przy odpowiedziach generatywnych liczą się przede wszystkim zgodność ze źródłem, kompletność instrukcji i właściwe zachowanie w razie braku informacji.
Ciągłe doskonalenie: małe zmiany, sprawdzalny efekt
Najskuteczniejszy cykl pracy to: wykrycie problemu, ustalenie przyczyny, poprawka, test regresji i ponowna obserwacja po publikacji. Jeżeli agent podaje nieaktualną procedurę HR, najpierw trzeba sprawdzić źródło wiedzy, zamiast od razu przebudowywać dialog. Jeśli błędnie interpretuje skrót używany przez pracowników IT, poprawa powinna dotyczyć rozpoznawania tej potrzeby.
Warto prowadzić rejestr zmian i uzupełniać zestaw testów o przypadki znalezione w rzeczywistych rozmowach. Dzięki temu każda wykryta usterka staje się także zabezpieczeniem przed jej powrotem przy kolejnej aktualizacji agenta.
Bezpieczeństwo i zgodność: uprawnienia, ochrona danych, audyt i governance
Agent obsługujący HR, IT lub klientów może korzystać z informacji, których ujawnienie niewłaściwej osobie miałoby poważne konsekwencje: danych kadrowych, historii zgłoszeń czy dokumentów klienta. W Copilot Studio bezpieczeństwo wymaga więc kontroli nie tylko nad tym, co agent odpowiada, lecz także do jakich danych sięga i w czyim imieniu wykonuje operacje. Samo polecenie zapisane w instrukcjach agenta, aby nie ujawniał poufnych informacji, nie zastępuje zabezpieczeń dostępu.
Uprawnienia: oddziel dostęp twórcy od dostępu użytkownika
Należy rozróżnić trzy obszary: uprawnienia osób budujących i publikujących agenta, dostęp użytkowników do rozmowy oraz uprawnienia połączeń wykorzystywanych przez agenta. Są to odrębne warstwy kontroli. Możliwość uruchomienia rozmowy nie powinna automatycznie oznaczać dostępu do wszystkich podłączonych zasobów.
Dla scenariuszy wewnętrznych podstawą jest odpowiednio skonfigurowane uwierzytelnianie, na przykład z użyciem Microsoft Entra ID. Następnie trzeba sprawdzić, czy konkretne źródło wiedzy lub narzędzie działa w kontekście zalogowanego użytkownika, czy korzysta z poświadczeń skonfigurowanego połączenia. Nie należy zakładać, że każde połączenie automatycznie dziedziczy uprawnienia rozmówcy. Przykładowo pracownik pytający o własną sprawę kadrową nie może otrzymać danych innych osób tylko dlatego, że konto używane przez połączenie ma do nich dostęp.
Obowiązuje zasada najmniejszych uprawnień: agentowi udostępnia się wyłącznie zasoby i operacje niezbędne do realizacji jego zadania. Dostęp tylko do odczytu jest właściwszy niż możliwość modyfikacji danych, jeżeli agent ma jedynie udzielać informacji. Ograniczenia należy egzekwować również w systemie źródłowym lub warstwie API, a nie wyłącznie w logice rozmowy.
Ochrona danych: minimalizacja i kontrola przepływu informacji
Zakres danych powinien wynikać z konkretnego celu obsługi. Do odpowiedzi na pytanie o zasady urlopowe wystarczy zatwierdzony regulamin — nie jest potrzebny dostęp do całej dokumentacji kadrowej. Ta sama zasada dotyczy informacji zbieranych podczas rozmowy: agent nie powinien prosić o hasła, kody uwierzytelniające ani dane osobowe, które nie są potrzebne do załatwienia sprawy.
Polityki danych w Power Platform, określane także jako DLP, pozwalają ograniczać użycie konektorów oraz łączenie ich w określonych konfiguracjach. Pomagają zapobiegać niepożądanemu przepływowi danych między usługami, ale nie są uniwersalnym filtrem wykrywającym każdą poufną treść w odpowiedzi agenta. Wymagają uzupełnienia o właściwe uprawnienia, dobór źródeł i kontrolę danych przekazywanych do usług zewnętrznych.
Ochroną trzeba objąć również zapisy rozmów. Należy określić, czy są przechowywane, kto może je odczytywać i po jakim czasie powinny zostać usunięte. Przy ocenie zgodności z RODO trzeba uwzględnić cel i podstawę przetwarzania, obowiązki informacyjne oraz realizację praw osób. Lokalizację przetwarzania i warunki przechowywania należy sprawdzić dla wybranej konfiguracji oraz podłączonych usług — samo użycie Copilot Studio nie przesądza o zgodności całego rozwiązania.
Audyt: możliwość odtworzenia istotnych zdarzeń
Audyt służy rozliczalności, a nie ocenie jakości odpowiedzi. Powinien umożliwiać ustalenie, kto zmienił konfigurację, nadał dostęp lub opublikował nową wersję agenta. Zakres dostępnych zdarzeń i okres ich przechowywania zależą od użytych usług, konfiguracji oraz licencji; trzeba zweryfikować je przed uruchomieniem produkcyjnym. Dostęp do danych audytowych również wymaga ograniczenia, ponieważ mogą zawierać informacje wrażliwe.
Governance: odpowiedzialność za cały cykl życia agenta
Governance oznacza ustalenie, kto odpowiada za agenta i na jakich zasadach może go zmieniać. Każdy agent powinien mieć właściciela biznesowego i technicznego, zatwierdzony zakres działania oraz procedurę publikowania zmian. Warto rozdzielić środowiska deweloperskie, testowe i produkcyjne, aby eksperymenty nie wpływały na rzeczywistą obsługę ani nie wymagały kopiowania danych produkcyjnych.
Przegląd bezpieczeństwa jest potrzebny także po wdrożeniu, szczególnie przy dodawaniu źródeł wiedzy, narzędzi lub nowych grup użytkowników. Organizacja powinna również określić sposób reagowania na incydent, odebrania uprawnień i szybkiego wyłączenia agenta. Dzięki temu odpowiedzialność nie kończy się w momencie publikacji, lecz obejmuje cały okres jego działania.
KPI i mierzenie efektów: jak ocenić skuteczność agenta AI w Copilot Studio
Duża liczba rozmów z agentem nie oznacza jeszcze, że obsługa działa lepiej. O wartości wdrożenia świadczy to, czy pracownik lub klient rozwiązuje sprawę szybciej, bez zbędnych kontaktów i przy uzasadnionym koszcie. Dlatego skuteczność agenta w Copilot Studio należy oceniać łącznie przez samodzielność obsługi, jakość rozwiązania i wynik ekonomiczny. Żaden z tych wymiarów nie wystarcza osobno.
Samodzielna obsługa, szybkość i rozwiązanie sprawy
Deflection rate pokazuje, w jakim stopniu agent ogranicza potrzebę kontaktu z konsultantem. W praktyce można go mierzyć jako udział spraw rozwiązanych przez agenta bez udziału człowieka wśród spraw objętych pomiarem. Trzeba jednak jasno określić kryterium rozwiązania i zakres analizowanych kontaktów. Sam brak przekazania rozmowy do konsultanta nie potwierdza sukcesu: użytkownik mógł zrezygnować albo zgłosić ten sam problem innym kanałem. Wysoki wynik ma wartość dopiero wtedy, gdy towarzyszy mu potwierdzone załatwienie sprawy.
Czas odpowiedzi opisuje szybkość reakcji agenta, ale nie należy utożsamiać go z czasem rozwiązania problemu. Natychmiastowe powitanie niewiele zmienia, jeśli użytkownik długo czeka na użyteczną informację lub wykonanie działania. Warto więc rozdzielić czas do pierwszej merytorycznej odpowiedzi i czas do zakończenia sprawy. Mediana oraz 90. percentyl pomagają zobaczyć zarówno typowe doświadczenie, jak i sytuacje, w których oczekiwanie jest szczególnie długie.
FCR, czyli First Contact Resolution, określa odsetek spraw rozwiązanych przy pierwszym kontakcie, bez konieczności ponownego zgłoszenia tego samego problemu. W odróżnieniu od deflection rate nie musi oznaczać obsługi wyłącznie przez AI: sprawa przekazana konsultantowi może nadal zakończyć się podczas pierwszego kontaktu. Dla wiarygodnego pomiaru trzeba ustalić okres obserwacji ponownych zgłoszeń oraz sposób rozpoznawania tej samej sprawy.
Satysfakcja użytkownika i koszt obsługi
CSAT służy do oceny satysfakcji z konkretnego kontaktu, dlatego dobrze nadaje się do badania doświadczeń bezpośrednio po rozmowie z agentem. Wynik należy interpretować wraz z liczbą odpowiedzi i odsetkiem osób, które wypełniły ankietę. NPS mierzy skłonność do rekomendacji i zwykle odzwierciedla szerszą relację z organizacją lub usługą. Może uzupełniać ocenę wdrożenia, ale jego zmian nie należy automatycznie przypisywać agentowi — wpływają na nie również inne doświadczenia klienta.
Koszt obsługi najlepiej odnosić do rozwiązanej sprawy, a nie tylko do pojedynczej rozmowy. W kalkulacji należy uwzględnić koszty korzystania z platformy, utrzymania rozwiązania oraz pracy ludzi, w tym obsługi eskalacji i ponownych kontaktów. Koszt wdrożenia warto rozliczyć w przyjętym horyzoncie oceny. Tania rozmowa, po której użytkownik ponownie szuka pomocy, nie musi oznaczać oszczędności.
Jak porównywać wyniki, żeby nie przeceniać efektów
Punktem odniesienia powinny być wyniki obsługi przed uruchomieniem agenta, mierzone według tych samych definicji. Porównania warto prowadzić osobno dla HR, IT i wsparcia klientów, a także dla podobnych kategorii oraz poziomów trudności spraw. Inaczej wzrost udziału prostych pytań może stworzyć pozór poprawy skuteczności całego rozwiązania.
Cel biznesowy powinien łączyć poprawę efektywności z utrzymaniem jakości: krótszy czas rozwiązania i niższy koszt mają znaczenie, jeśli nie rośnie liczba ponownych zgłoszeń ani nie spada satysfakcja. Taki zestaw KPI pozwala odróżnić rzeczywiste odciążenie zespołu od przeniesienia wysiłku na użytkownika.
Scenariusze end-to-end: agent HR dla pracowników i agent helpdesk dla klientów
Pracownik pytający o urlop i klient zgłaszający problem z usługą oczekują podobnego rezultatu: chcą załatwić sprawę bez szukania właściwego formularza, działu i instrukcji. Scenariusz end-to-end obejmuje całą drogę od zgłoszenia potrzeby do uzyskania wyniku — odpowiedzi, wykonanej operacji albo przekazania sprawy osobie, która może ją rozstrzygnąć. Agent zbudowany w Copilot Studio może wspierać taki przebieg, jeśli ma dostęp do odpowiednich informacji i skonfigurowanych działań. Sama rozmowa nie zastępuje procesu, który musi działać w tle.
Agent HR: od pytania o urlop do złożenia wniosku
Przykładowa rozmowa zaczyna się od pytania: „Chcę wziąć wolne w przyszłym tygodniu. Jak złożyć wniosek?”. Agent pomaga ustalić rodzaj nieobecności i wyjaśnia obowiązującą procedurę na podstawie firmowych materiałów. Jeśli rozwiązanie udostępnia mu dane kadrowe zalogowanego pracownika, może również pomóc sprawdzić dostępny wymiar urlopu. Bez takiego dostępu powinien wskazać, gdzie pracownik znajdzie tę informację, zamiast sugerować, że zna jego indywidualną sytuację.
W wariancie obejmującym obsługę wniosku agent zbiera potrzebne dane, przedstawia je do sprawdzenia i po potwierdzeniu przez pracownika uruchamia skonfigurowane działanie. Rozmowę kończy jednoznaczną informacją o rezultacie: wniosek został złożony i oczekuje na decyzję albo nie udało się go przekazać i potrzebny jest inny sposób zgłoszenia. Złożenie wniosku nie oznacza przyznania urlopu — agent nie powinien zacierać tej różnicy.
Podobny model sprawdza się przy zamawianiu zaświadczeń, wyjaśnianiu zasad korzystania z benefitów czy prowadzeniu nowej osoby przez zadania onboardingowe. Jego wartość polega na połączeniu informacji z konkretnym następnym krokiem, a nie na samym odsyłaniu do regulaminu.
Agent helpdesk: od zgłoszenia problemu do rozwiązania lub dalszej obsługi
Klient zgłasza, że nie może korzystać z zakupionej usługi. Agent doprecyzowuje objawy i zakres problemu, a następnie prowadzi przez adekwatne czynności opisane w zatwierdzonej bazie wiedzy. Nie musi od razu tworzyć zgłoszenia: przy prostych trudnościach wystarczy krótka instrukcja i sprawdzenie, czy usługa znów działa.
Jeśli problem pozostaje nierozwiązany, rozmowa przechodzi w obsługę sprawy. Po zebraniu niezbędnych informacji i wykonaniu wymaganej weryfikacji agent może utworzyć zgłoszenie, o ile takie działanie zostało udostępnione w rozwiązaniu. Klient otrzymuje potwierdzenie, numer sprawy oraz informację, co nastąpi dalej. Zakończeniem tego wariantu nie jest deklaracja usunięcia usterki, lecz skuteczne przekazanie problemu do dalszej obsługi bez konieczności ponownego opisywania go od początku.
Różne potrzeby, wspólna zasada: wyraźny wynik rozmowy
Agent HR wspiera przede wszystkim wewnętrzne procedury i sprawy związane z zatrudnieniem. Agent helpdesk pomaga klientom korzystać z produktu lub usługi oraz rozwiązywać problemy po zakupie. Różnią się więc odbiorcą, zakresem informacji i możliwymi działaniami. W obu przypadkach dobrze zaprojektowany scenariusz pozwala użytkownikowi jasno odróżnić uzyskanie instrukcji, wykonanie czynności i rozpoczęcie dalszej obsługi. Dzięki temu rozmowa kończy się realnym postępem w sprawie, a nie tylko uprzejmą odpowiedzią.
Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy temat automatyzacji obsługi za pomocą agentów AI w praktyce.
Najczęściej zadawane pytania i odpowiedzi odnośnie Copilot Studio – automatyzacja obsługi pracowników i klientów za pomocą agentów AI
Copilot Studio pozwala tworzyć agentów AI w podejściu low-code, czyli z ograniczoną potrzebą pisania kodu. Trzeba jednak zaprojektować przebieg rozmowy, określić zadania agenta i przygotować wiarygodne źródła wiedzy. Bardziej złożone połączenia z systemami mogą wymagać wykorzystania API lub konektorów niestandardowych. Łatwość budowania dialogu nie eliminuje więc potrzeby wiedzy o procesach, integracjach i bezpieczeństwie danych.
Najlepiej zacząć od jednej powtarzalnej sprawy, która ma jasno opisany przebieg i sprawdzalny rezultat. Dobrym przykładem jest utworzenie zgłoszenia IT oraz odczyt jego statusu. Przed rozpoczęciem prac ustal:
- jaką potrzebę użytkownika agent ma obsługiwać;
- jakich danych i działań wymaga realizacja zadania;
- co będzie potwierdzeniem poprawnego zakończenia sprawy.
Wąski zakres ułatwia ocenę pilotażu i wykrycie problemów przed rozszerzeniem automatyzacji.
Firmowe dokumenty wystarczą do wyjaśniania opisanych w nich zasad, ale nie do ustalania aktualnych danych konkretnego pracownika. Regulamin urlopowy pozwoli objaśnić procedurę, lecz nie pokaże bieżącego salda urlopu. Takie informacje wymagają dostępu do właściwego systemu. Materiały udostępnione agentowi powinny być aktualne, jednoznaczne i pozbawione sprzecznych wersji. Gdy brakuje odpowiedzi w źródłach, agent powinien jasno o tym poinformować.
Agenta w Copilot Studio można połączyć z CRM lub systemem zgłoszeń przez dostępne konektory, API oraz przepływy Power Automate. Wybór rozwiązania powinien wynikać z wymaganych operacji i możliwości systemu docelowego. Integracja musi przekazywać poprawne dane, obsługiwać błędy i zwracać jednoznaczny wynik. Agent powinien potwierdzić zapis lub utworzenie sprawy dopiero po otrzymaniu potwierdzenia z systemu, a nie po samym uruchomieniu działania.
Agent AI powinien przekazać sprawę człowiekowi, gdy użytkownik o to prosi, dostępne działania nie pomagają lub potrzebna jest indywidualna decyzja. Przekazanie rozmowy na żywo wymaga odpowiedniej integracji i obsługi tej funkcji w danym kanale. Poza godzinami pracy alternatywą może być zgłoszenie do późniejszej obsługi. Konsultant powinien otrzymać opis problemu, wykonane kroki i ich wyniki, aby użytkownik nie musiał ponownie wyjaśniać sprawy.
Dane należy chronić przez uwierzytelnianie, ograniczone uprawnienia i kontrolę dostępu w systemach źródłowych lub API. Same instrukcje agenta nie stanowią wystarczającego zabezpieczenia. Przed publikacją sprawdź:
- czy połączenie działa z uprawnieniami rozmówcy, czy skonfigurowanego konta;
- czy użytkownik może odczytać cudzą sprawę, podając jej identyfikator;
- kto ma dostęp do zapisów rozmów i jak długo są przechowywane.
Testy przeprowadzaj na kontach zwykłych użytkowników o różnych rolach.
Agenta należy testować na pełnych scenariuszach obsługi, a nie tylko na pojedynczych odpowiedziach. Oprócz typowych pytań sprawdź literówki, niepełne dane, zmianę decyzji użytkownika, brak informacji w źródłach oraz awarie integracji. Dla każdego przypadku określ oczekiwany rezultat. Panel testowy pomaga podczas edycji, ale przed publikacją potrzebna jest również weryfikacja w warunkach zbliżonych do docelowego kanału. Po zmianach powtarzaj testy wcześniej poprawnie działających scenariuszy.
Skuteczność agenta AI należy oceniać przez rozwiązane sprawy, czas obsługi, satysfakcję użytkowników i koszt uzyskania rezultatu. Sama liczba rozmów ani brak przekazania do konsultanta nie dowodzą sukcesu. Warto śledzić FCR, czyli odsetek spraw rozwiązanych przy pierwszym kontakcie, oraz CSAT, czyli satysfakcję z obsługi. Wyniki porównuj z okresem przed wdrożeniem, osobno dla podobnych kategorii spraw, uwzględniając ponowne zgłoszenia tego samego problemu.