O czym jest ten film
- Zespół autora spędzał około czterech godzin tygodniowo na ręcznej analityce rozsianej po Stripe, HubSpocie i MySQL — doszło do punktu, w którym poważnie rozważali kolejną osobę na etacie operacyjnym.
- Problemem nie była trudność pojedynczych zadań, tylko ciągłe przeskakiwanie między systemami i składanie tego samego zestawienia od nowa.
- Victor to „pracownik AI” działający w Slacku i Microsoft Teams, z dostępem do ponad 3 200 narzędzi — wykonuje pracę między systemami, a nie tylko doradza i zostawia dokończenie człowiekowi.
- Wdrożenie przebiega dwutorowo: Victor pojawia się w przestrzeni jak zwykły członek zespołu, a panel administracyjny służy do integracji, zarządzania uprawnieniami i harmonogramem.
- Kontrola jest dwuwarstwowa: uprawnienia można zawęzić do potrzeb konkretnego zadania, a czynności wrażliwe (wysyłka czegokolwiek, zmiana danych) wymagają zgody człowieka.
- Pierwsze zadanie — poranny przegląd operacyjny łączący Stripe i HubSpot — z pięciu minut pracy człowieka spadło do trzydziestu sekund sprawdzania gotowego wyniku.
- Drugie zadanie — analiza wolnych zapytań MySQL — Victor wykonuje we własnym środowisku chmurowym; dziesięć minut dochodzenia zamieniło się w półtorej minuty ludzkiego przeglądu.
- Trzecie, najważniejsze zadanie — kompletny raport operacyjny z trzech systemów — przestało wymagać dodatkowego etatu: piętnaście minut dziennie zamieniło się w dwie, a obowiązek wreszcie zyskał stałego wykonawcę.
- Po pierwszych sukcesach pozostałe działy zaczęły delegować własne obowiązki temu samemu asystentowi: operacje przeglądają lejek sprzedażowy, finanse uzgadniają rozliczenia Stripe’a, inżynieria pilnuje bazy.
- Wniosek autora: ChatGPT i Claude to narzędzia dla pojedynczego użytkownika, a różnicę podsumowuje formuła „czatbot odpowiada, kopilot pomaga, pracownik odpowiada za rezultat” — plus praktyczna metoda „audytu delegowania”.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wspólna przestrzeń zamiast osobnych czatów z AI
Na czym polega: Wartość nie płynie z samego modelu, tylko z faktu, że cały zespół pracuje z tym samym asystentem w Slacku lub Teams — historia zadań i kontekst zostają w jednym miejscu, a nie rozsypują się po prywatnych rozmowach.
Jak stosować: Wdrażaj AI jak pełnoprawnego członka przestrzeni roboczej: dodawaj do kanałów, pozwalaj oznaczać go w wątkach, zamiast żeby każdy prowadził własne, odseparowane okno rozmowy.
Na co uważać: Gdy każdy rozmawia z AI osobno, wiedza o procesach ucieka z zespołu — pilnuj, żeby kluczowe zadania lądowały we wspólnym kanale.
2.Daj AI dostęp raz, zamiast co tydzień eksportować dane
Na czym polega: Victor pracuje bezpośrednio w połączonych systemach, więc odpada wydobywanie danych, wgranie plików i tłumaczenie ich struktury — cała robota dzieje się tam, gdzie żyją źródła.
Jak stosować: Podłącz narzędzia w panelu administracyjnym i formułuj zadania tak, by obejmowały cały ciąg: od pobrania danych po gotowy wynik w wątku.
Na co uważać: Każde połączenie to decyzja o bezpieczeństwie — integruj wyłącznie systemy, których asystent naprawdę potrzebuje.
3.Zawężaj uprawnienia do minimum, jakiego wymaga zadanie
Na czym polega: Ponad 3 200 integracji nie oznacza 3 200 udostępnień; autor nadaje Victorowi dokładnie te uprawnienia, których wymaga dana czynność — na przykład sam odczyt danych lejka w HubSpocie, bez władzy nad resztą konta.
Jak stosować: Przy każdym nowym zadaniu wypisz, jakie akcje AI musi wykonać, i nadaj tylko je.
Na co uważać: Szeroki dostęp „na zapas” to najczęstszy błąd — minimalizuje szkody przy błędzie i ułatwia późniejszy audyt.
4.Czułe akcje tylko za zgodą człowieka
Na czym polega: Gdy zadanie sięga operacji wrażliwych — wysłania czegoś na zewnątrz albo zmiany danych — Victor się zatrzymuje i prosi o zatwierdzenie. Analizę przygotowuje, decyzję podejmuje zespół.
Jak stosować: Ustaw progi zgód dla akcji wychodzących i modyfikujących dane; swobodnie przepuszczaj analizy oparte na samym odczycie.
Na co uważać: Nadmiar obowiązkowych aprobat zabija sens automatyzacji — blokuj wyłącznie to, co realnie ryzykowne.
5.Najpierw ręcznie, dopiero potem harmonogram
Na czym polega: Sprawdzony ręcznie proces można zamienić w cykliczne zadanie (cron), które Victor uruchamia automatycznie — np. co rano przed startem zespołu — i sam zamieszcza wynik na Slacku.
Jak stosować: Przetestuj zadanie ręcznie, upewnij się co do jakości wyników, a dopiero wtedy wrzuć je na harmonogram.
Na co uważać: Zautomatyzowany niedziałający proces mnoży błędy w powtarzalnej skali; ustal też, kto regularnie przegląda wypluwane raporty.
6.Deleguj całe zadanie, a nie pojedyncze pytania
Na czym polega: Przełom przyszedł, gdy autor przestał poprosić o fragmenty, a oddał cały łańcuch: przychody ze Stripe’a, zmiany w lejku HubSpota, dane techniczne z MySQL, wykrycie anomalii i złożenie jednego raportu. Piętnaście minut dziennie spadło do około dwóch.
Jak stosować: Formułuj polecenia jak zakres obowiązków: „weź dane z A, B i C, uzgodnij je, zaznacz nietypowe, zwróć jeden raport”.
Na co uważać: Bez precyzyjnego określenia efektu końcowego dostaniesz odpowiedź, a nie gotową pracę.
7.Obliczenia w chmurze odciążają inżynierów
Na czym polega: Zadania wymagające kodu Victor wykonuje we własnym środowisku w chmurze — analiza wolnych zapytań MySQL biegnie bez angażowania komputera ani uwagi inżyniera, a dziesięć minut dochodzenia zamienia się w półtorej minuty przeglądu.
Jak stosować: Przekazuj AI pierwszą fazę dochodzeń technicznych: zebranie, odfiltrowanie i wstęczną ocenę danych.
Na co uważać: Dostęp do baz ogranicz do odczytu (albo absolutnego minimum) i sprawdź, gdzie fizycznie przetwarzane są dane.
8.Po pierwszym sukcesie rozszerzaj na kolejne działy
Na czym polega: Gdy jeden proces działa niezawodnie, pozostali naturalnie zaczynają delegować własne obowiązki temu samemu asystentowi — operacje przeglądają lejek (z trzech minut do trzydziestu sekund plus minuta sprawdzenia), finanse uzgadniają Stripe’a, inżynieria pilnuje bazy.
Jak stosować: Pokaż wyniki pierwszego wdrożenia reszcie firmy i zachęć każdą osobę do przekazania jednego „swojego” powtarzalnego obowiązku.
Na co uważać: Wspólny pracownik wymaga wspólnego zarządzania — integracjami i dostępami powinien sterować jeden administrator.
9.Audyt delegowania: „dlaczego to nadal robi człowiek?”
Na czym polega: Prosty sposób selekcji zadań: przejrzyj powtarzalne obowiązki w firmie i pytaj o powód, dla którego wymagają człowieka. Jeśli odpowiedź brzmi „bo ktoś musi skakać między narzędziami i co tydzień składać ten sam raport” — to kandydat numer jeden dla AI.
Jak stosować: Zrób listę cyklicznych raportów i sprawdzeń, zacznij od jednego, najmniej ryzykownego.
Na co uważać: Nie wszystko nadaje się do oddelegowania — decyzje strategiczne i robotę jednorazową zostaw ludziom.
10.Mierz „właściciela obowiązku”, nie tylko zaoszczędzone minuty
Na czym polega: Największa zmiana nie polegała na skróceniu raportu z piętnastu minut do dwóch, lecz na tym, że powtarzalny obowiązek — wiecznie spadający na te same osoby — wreszcie miał stałego wykonawcę. Stąd formuła: czatbot odpowiada, kopilot pomaga, pracownik odpowiada za rezultat.
Jak stosować: Oceniając AI w zespole, pytaj nie „o ile szybciej”, ale „czy ten obowiązek ma właściciela i czy zespół przestał być wąskim gardłem”.
Na co uważać: To materiał sponsorowany — podane liczby pochodzą z jednego zespołu, więc zweryfikuj je własnym pilotażem.
Redakcyjne tłumaczenie
Cztery godziny tygodniowo zjadane przez analitykę
Nasz zespół spędzał około czterech godzin tygodniowo na pracy analitycznej rozsypanej po Stripe, HubSpocie i MySQL. Dochodziliśmy do momentu, w którym wydawało się, że bez kolejnej osoby w dziale operacji to wszystko po prostu przestanie się wyrabiać. Problem nie polegał na tym, że któreś z tych zadań było szczególnie trudne. Chodziło o ciągłe przeskakiwanie między systemami. Ktoś musiał sprawdzić przychody, przejrzeć lejek sprzedażowy, zerknąć na wydajność bazy, uzgodnić liczby, a na końcu złożyć z tego raport, z którego reszta zespołu faktycznie coś wyniesie. I ta robota nieustannie odrywała inżynierów od produktu.
Zamiast więc zatrudniać kolejną osobę wyłącznie po to, żeby udźwignęła ten ciężar operacyjny, sprowadziliśmy do Slacka Victora. Victor to pracownik AI działający wewnątrz Slacka i Microsoft Teams, łączący się z ponad 3 200 narzędzi — i wykonujący pracę w systemach, których zespół już używa, zamiast udzielić odpowiedzi i zostawić człowiekowi dokańczanie reszty.
W tym materiale pokażę cztery zadania, które przekazaliśmy Victorowi: jak go skonfigurowaliśmy, jak kontrolujemy to, do czego ma dostęp, i co się zmieniło, gdy te powtarzalne procesy przestały zależeć od kogoś, kto musiał je ręcznie posuwać dalej.
(Informacja dodatkowa: film jest materiałem sponsorowanym przez Victora — autor zastrzega jednak, że wszystkie pokazane operacje wykonuje na prawdziwej, bieżącej pracy własnego zespołu.)
Wdrożenie: Victor pojawia się w Slacku
Pierwszym krokiem jest wprowadzenie Victora do przestrzeni roboczej. Da się to zrobić na dwa sposoby: bezpośrednio z poziomu rozmowy albo przez panel administracyjny. Zacznę od Slacka, bo to tam zespół będzie pracować z nim na co dzień — stronę administracyjną pokażę zaraz potem.
Po dodaniu Victor widnieje w przestrzeni jak zwyczajny członek zespołu. Można napisać do niego bezpośrednio, dodać go do kanału albo oznaczyć w istniejącym wątku, gdy pojawia się coś do zrobienia. To istotne, bo sedno pomysłu polega na tym, że wszyscy pracują z tym samym Victorem w tej samej przestrzeni — a nie na tym, że każdy otwiera własne, odizolowane okno czatu z AI.
Panel administracyjny: integracje, uprawnienia, cykliczne zadania
Panel administracyjny to miejsce, skąd zarządza się wszystkim, co dzieje się „za” Victorem: podłącza się integracje, decyduje o tym, do czego ma dostęp, przegląda zaplanowane obowiązki i resztę konfiguracji współpracy z zespołem.
Victor łączy się z ponad 3 200 narzędzi, ale oczywiście nie oznacza to, że chcę udostępnić mu wszystko. Podłączając na przykład HubSpota, Stripe’a czy GitHuba, mogę zawęzić uprawnienia do tego, czego dane zadanie naprawdę wymaga. Jeśli Victor ma wyłącznie przeglądać dane lejka sprzedażowego, dostaje uprawnienia potrzebne do tej jednej czynności — bez zbędnej władzy nad resztą konta. A gdy proces dochodzi do czegoś wrażliwego, na przykład wysłania czegokolwiek na zewnątrz albo zmiany danych, Victor potrafi się zatrzymać i poprosić o zgodę. Analizę przygotuje, ale ostatnie słowo należy do zespołu.
Widoczne są tu również crony — cykliczne zadania, które Victor uruchamia według harmonogramu. Skorzystamy z nich później, gdy przetestujemy procesy ręcznie i upewnimy się, że robią dokładnie to, czego chcemy. Jest tu też dostęp do wsparcia i społeczności: pomoc prowadzą realni ludzie, a społeczność przydaje się, gdy chce się podejrzeć konfiguracje, na których pracują inne zespoły. Na razie jednak trzymam się prostoty i podłączam narzędzia potrzebne do pierwszego zadania.
Zadanie pierwsze: poranny przegląd operacyjny
Zaczynamy od analityki, która pochłaniała nam najwięcej czasu — od roboty, która wciąż nas przerywała. Potrzebowaliśmy szybkiego przeglądu operacyjnego, ale informacje były porozrzucane po systemach: przychody siedziały w Stripe, aktywność w lejku — w HubSpocie, a czasem trzeba było jeszcze kontekstu technicznego z bazy danych, żeby w ogóle zrozumieć, co się dzieje. Standardowo ktoś otwierał każdy system po kolei, przeglądał dane, ręcznie je zestawiał, a potem składał z tego coś użytecznego dla pozostałych.
Tym razem oddaliśmy całą robotę Victorowi. Piszę do niego bezpośrednio na Slacku: przejrzyj najnowsze dane przychodowe w Stripe, przeanalizuj aktywny lejek w HubSpocie, uzgodnij jedno z drugim i zaznacz wszystko, co wygląda podejrzanie. Po wysłaniu prośby Victor przechodzi przez połączone systemy w tle — zamiast tłumaczyć mi, jak samemu zrobić tę analizę.
I właśnie tutaj zaczyna widać różnicę względem zwykłego czatbota. Gdybym o pomoc poprosił ChatGPT, i tak musiałbym wyeksportować dane, wgrać je, opisać strukturę, a na końcu sam przenieść wynik do systemu, w którym pracuje zespół. Tu Victor ma już zaakceptowany dostęp, więc zadanie wykonuje się w całym łańcuchu narzędzi, prosto ze Slacka. Widać, jak prowadzi analizę, porównuje systemy, szuka rozbieżności, a gotowy przegląd wraca do wątku. Zamiast skakania po dashboardach i ręcznego uzgadniania mamy jeden zbiorczy obraz operacyjny.
Co ważniejsze, takie zadanie da się zaplanować. Jeśli przegląd jest potrzebny każdego ranka, nie muszę wracać i odpalać tego samego za każdym razem — zamieniamy proces w crona i Victor wykonuje go automatycznie, zanim zespół zasiada do pracy. Kiedyś takie zestawienie zabierało komuś pięć minut dziennie. Dziś ludzka część to około trzydzieści sekund sprawdzenia gotowego wyniku. Ta sama widoczność operacyjna przy znacznie mniejszym nakładzie koordynacji — i nikt z inżynierii nie musi przerywać pracy, żeby od nowa składać ten sam raport.
To był prosty proces. Teraz coś bardziej technicznego.
Zadanie drugie: kontrola wydajności MySQL
Pierwsze zadanie było głównie operacyjne; to drugie pokazuje, gdzie Victor staje się użyteczny dla strony inżynierskiej. Jedną z nawracających czynności jest kontrola wydajności bazy danych. Gdy coś zaczyna zwalniać, prędzej czy później ktoś musi odłożyć swoje zajęcia, otworzyć narzędzia bazodanowe, obejrzeć wolne zapytania, ustalić, co się zmieniło, i zdecydować, czy w ogóle jest co zgłębiać. Nic w tym szczególnie trudnego — ale to właśnie taki rodzaj przerwania, który wyrywa inżyniera z pracy nad produktem.
Oddajemy więc i tę robotę Victorowi: przejrzyj dane wydajnościowe MySQL, wyłap wolno działające zapytania, poszukaj anomalii i streść, które problemy naprawdę wymagają uwagi. Gdy wyślę polecenie na Slacku, Victor zajmuje się zadaniem, nie uruchamiając niczego na moim komputerze. Jeżeli praca wymaga kodu albo dodatkowego przetwarzania, korzysta z własnego środowiska w chmurze: uruchamia skrypty, obrabia dane i wraca z gotową analizą do wątku. Mogę więc przekazać mu dochodzenie i dalej pracować, podczas gdy on robi pierwsze podejście.
Po chwili mamy wynik. Zamiast ręcznego przekopywania się przez obszerny log zapytań Victor zawęził sprawę do pozycji faktycznie podejrzanych — wraz z kontekstem wydajnościowym i podsumowaniem prawdopodobnych przyczyn spowolnienia. Inżynier zaczyna więc od użytecznej części śledztwa, a nie od wydawania pierwszych minut na zbieranie i filtrowanie surowca. I jak poprzednio — można z tego zrobić cykl. Jeśli sprawdzanie ma przebiegać co rano albo w innym sensownym rytmie, zamieniamy zadanie w crona i Victor powtarza przegląd automatycznie.
Kiedyś taki przegląd bazy zabierał nam około dziesięciu minut, zanim w ogóle wiedzieliśmy, co jest warte uwagi. Dziś ludzkie sprawdzenie trwa około minuty i pół. Wygrana nie polega na tym, że Victor wygenerował kolejny raport techniczny — tylko na tym, że zespół inżynierski znacznie szybciej dochodzi do decyzji, bo nikt nie musi ciągle przerywać pracy, żeby robić pierwsze podejście do analizy. Sprawdzanie pojedynczego systemu to wciąż stosunkowo prosta sprawa.
Zadanie trzecie: pełny raport operacyjny, czyli etat, który stał się zbędny
Zanim przejdziemy do największego procesu — jeśli chcecie „zatrudnić” Victora u siebie, link i kod rabatowy znajdziecie w opisie filmu.
Teraz coś najbliższego temu, pod kogo faktycznie rozważaliśmy zatrudnienie człowieka. To tu w pełni objawiło się nasze wąskie gardło analityczne. Jeden raport mógł wymagać danych przychodowych ze Stripe’a, informacji o lejku z HubSpota i kontekstu technicznego z MySQL, zanim ktokolwiek pojął, co się dzieje. Najbardziej frustrujące nie były poszczególne kroki, tylko to, że za każdym razem ktoś z zespołu musiał wziąć na klatę cały proces.
Dlatego w tym zadaniu przekazuję Victorowi całość, a nie pojedynczą prośbę. Prosze: przejrzyj najnowsze przychody w Stripe, sprawdź, co zmieniło się w lejku HubSpota, zajrzyj w odpowiednie dane wydajnościowe MySQL, zaznacz nietypowe zjawiska i złóż z tego jeden raport operacyjny dla zespołu. Po wysłaniu Victor zabiera się do pracy po wszystkich połączonych systemach. Jeśli zadanie wymaga dodatkowego przetwarzania, uruchamia kod we własnym środowisku chmurowym i wraca z gotową analizą do tego samego wątku, w którym zaczęła się prośba. Nie muszę trzymać procesu otwartego na komputerze ani karmić go krok po kroku.
Raport gotowy. Zamiast trzech dashboardów i arkusza mamy jedno podsumowanie: obraz przychodów, zmiany w lejku, stan techniczny oraz lista pozycji wymagających czyjejś uwagi. I tu wynik znaczy więcej niż sam raport. Kiedyś ten proces zabierał komuś około piętnastu minut dziennie. Dziś Victor kończy całość w około dwie minuty, a człowiek jedynie sprawdza gotowy materiał.
To właśnie ta robota operacyjna pchała nas w stronę dodatkowego etatu. Zamiast tego przekazaliśmy powtarzalny obowiązek Victorowi, a inżynieria mogła zostać przy produkcie. A ponieważ potrzebujemy tych danych regularnie, zadanie również dało się zaplanować: zamiast pilnowania, by ktoś co rano odtwarzał raport, Victor wykonuje go z crona i wstawia gotowy wynik na Slacka, zanim zespół zdąży go potrzebować. W tym momencie proces nie jest już tylko szybszy — ma właściciela. I to zrobiło największą różnicę. Nie chodziło o skrócenie jednego raportu z piętnastu minut do dwóch. Przenieśliśmy powtarzalny obowiązek, który ciągle spadał na te same osoby, na kogoś, kto potrafi go wykonywać w kółko — bez kolejnego pełnego etatu w operacjach. A gdy to zaczęło działać, pozostali członkowie zespołu także zaczęli oddawać Victorowi swoje cykliczne obowiązki.
Jeden Victor dla inżynierii, operacji i finansów
Dotąd większość pokazanych zadań pochodziła z inżynierii i operacji. Ale gdy Victor już siedzi w Slacku, jest połączony ze stosem narzędzi i niezawodnie ogarnia jeden powtarzalny proces, naturalnym kolejnym krokiem jest to, że pozostali również zaczynają mu oddawać własną robotę. Ktoś z operacji może poprosić go o przegląd lejka HubSpota przed spotkaniem tygodniowym: zaznacz transakcje, które się nie ruszyły, i streść te wymagające uwagi. Ktoś z finansów może zlecić cykliczne uzgadnianie rozliczeń Stripe’a i kazać gotowemu raportowi wylądować na kanale do sprawdzenia. A inżynieria nadal korzysta z tego samego Victora do kontroli bazy, raportów technicznych i innych powtarzalnych analiz. Zamiast żeby każdy budował własną, odrębną automatyzację, trzy działy delegują różne zadania temu samemu pracownikowi AI w jednej wspólniej przestrzeni.
Pokażmy to w praktyce. Proszę osobę z operacji, żeby oznaczyła Victora w wątku i zleciła przegląd lejka. Gdy prośba przejdzie, Victor pracuje na połączonych systemach i wraca z analizą na kanał. Operacje mają swoje zestawienie bez proszenia inżynierów o przerwę w pracy. Kiedyś przygotowanie zajmowało około trzech minut; Victor pierwsze podejście robi w niecałe pół minuty, a ludzkie sprawdzenie — około minutę. Finanse mogą postąpić tak samo ze swoim raportem, a inżynieria dalej delegować procesy techniczne pokazane wcześniej.
To właśnie ta część zmieniła nasze myślenie o Victorze. Sprowadziliśmy go z powodu jednego wąskiego gardła analitycznego, ale wartość zaczęła się rozlewać, gdy kilka osób naraz zdołało przekazać mu cykliczne zadania bez budowania wszystkiego od zera. To nie jest jedna automatyzacja oszczędzająca komuś chwilę — to jeden wspólny pracownik AI biorący powtarzalną robotę od inżynierii, operacji i finansów, przy czym każdy startuje od gotowego materiału, a nie od ręcznego składania pierwszej wersji. I to chyba najprostszy sposób wyjaśnienia, czemu to czuje się inaczej niż otwarcie kolejnego okna czatu z AI.
Dlaczego nie po prostu ChatGPT albo Claude?
W tym miejscu nasuwa się oczywiste pytanie: czemu nie zrobić tego wszystkiego ChatGPT albo Claude? Dla mnie największa różnica jest taka, że tamte narzędzia pozostają głównie jednoosobowe. Otwieram ChatGPT czy Claude, podaję kontekst, pracuję z nim nad problemem, a potem biorę wynik i sam przenoszę go w dalszy ciąg procesu. To działa znakomicie, gdy to ja aktywnie prowadzę zadanie. Victor jest inny, bo cały zespół pracuje z tym samym pracownikiem AI wewnątrz Slacka. Inżynieria oddaje mu kontrolę bazy, operacje — przegląd lejka, finanse — cykliczny raport, i wszystko to dzieje się w tej samej wspólnej przestrzeni. Kontekst nie rozprasza się więc po mnóstwie osobnych rozmów, z których każda należy do kogoś innego — zespół deleguje pracę temu samemu Victorowi.
A to ma znaczenie właśnie przy takim wąskim gardle, jakie mieliśmy, bo problemem nie był brak lepszych odpowiedzi. Potrzebowaliśmy, żeby praca między wszystkimi tymi systemami toczyła się dalej bez jednej osoby, która nieustannie ją koordynuje. Najprościej ująłbym to tak: ChatGPT i Claude to narzędzia, przy których siedzę. Victor to ktoś, komu zespół może oddać robotę.
Czatbot odpowiada, kopilot pomaga, pracownik odpowiada za rezultat
Po przejściu całej tej drogi najprościej opisałbym Victora jednym zdaniem: czatbot odpowiada, kopilot pomaga, pracownik odpowiada za rezultat. I o tę zmianę tu chodzi. Zaczęliśmy od dość prostego problemu: zbyt dużo pracy operacyjnej wisiało między inżynierią, finansami i operacjami, i zawsze ktoś musiał być osobą, która przegląda dane, sprawdza systemy, uzgadnia zmiany i składa z tego coś użytecznego dla reszty. Victor dał nam sposób na oddanie tych cyklicznych obowiązków jednemu wspólnemu pracownikowi AI w Slacku — przy zachowaniu przez zespół kontroli nad tym, do czego ma dostęp i co wymaga zatwierdzenia.
Jeśli chcecie ocenić, czy coś takiego ma sens u was, zacznijcie od audytu delegowania. Przejdźcie przez powtarzalne obowiązki w firmie i zadajcie jedno pytanie: dlaczego ta robota wciąż należy do człowieka? Jeśli odpowiedź brzmi mniej więcej: „bo ktoś musi cały czas przeskakiwać między narzędziami, przeglądać te same informacje, sprawdzać te same systemy albo co tydzień odtwarzać te same raporty” — to jest właśnie zadanie warte przetestowania w pierwszej kolejności.
Na koniec sprawy porządkowe: link i kod rabatowy („Eric Tech 100” — sto dolarów z pierwszej faktury, bez podawania karty kredytowej, uruchomienie w kilka minut) autor zostawił w opisie filmu. Jego rada jest konkretna: daj Victorowi raport, którego zespół nie znosi, i zobacz, ile z niego faktycznie przejmie.