
Kiedy system może czytać pliki, a kiedy musi zapytać
Przed dostępem do plików trzeba ustalić, co system może tylko odczytać i przy czym potrzebna jest zgoda.

Michał Gorgolewski · MG Bits
Zamiast dużego wdrożenia wybieram jeden powtarzający się temat: mail od klienta, folder z dokumentami albo raport składany ręcznie.
Sprawdzam, gdzie trzeba szukać informacji, co trzeba przepisać ręcznie i czego brakuje przed odpowiedzią. Z tego robię mały test, a czasem pierwszą wersję automatyzacji. Na blogu piszę też o AI, kosztach, zatwierdzaniu i o tym, kiedy taka zmiana ma sens w małej firmie.
Piszę o AI na przykładach: mailach, plikach, brakach, zatwierdzaniu, kosztach i sensie automatyzacji.
Możemy przejść jeden taki temat i sprawdzić, czy warto go automatyzować.
Dla małych firm, które odpowiadają na podobne zapytania i szukają informacji w mailach, plikach albo tabelach.
Jaki materiał wystarczy na start i czego nie ruszam bez osobnej zgody.
Gdzie system ma pokazać brak i poczekać, zamiast iść dalej.
Czy wynik pomaga, co trzeba poprawić i czy jest sens robić kolejną wersję.
Blog

Przed dostępem do plików trzeba ustalić, co system może tylko odczytać i przy czym potrzebna jest zgoda.

Jak sprawdzić zapytanie i załączniki, żeby brak pliku nie wyszedł dopiero przy odpowiedzi.

Bez porównania z ręczną pracą pokaz może wyglądać dobrze, ale nie mówić, czy jest mniej pracy.
Nie każda sprawa nadaje się do automatyzacji. Najpierw patrzę, czy podobny temat pojawia się regularnie.
Interesuje mnie moment, w którym ktoś szuka, przepisuje, porównuje albo musi dopytać drugą osobę.
Dobry przykład nie jest idealny: ma brak, starą wersję pliku, niejasną prośbę albo decyzję do potwierdzenia.
Jeśli wynik ma trafić do klienta albo zmienić dane, musi go zatwierdzić osoba odpowiedzialna.
Jak pracuję
Na początek wybieram powtarzalny temat: zapytanie ofertowe, folder z dokumentami albo mail z prośbą o wycenę. Opisuję, jak ta praca wygląda dziś.
Mail, folder albo plik do testu.
Co ma być gotowe po teście.
Czego pierwsza wersja nie robi.
Jeśli system wskazuje, że czegoś brakuje, obok wyniku musi być źródło: plik, fragment maila albo notatka.
Nazwa pliku albo link.
Fragment do sprawdzenia.
Informacja, której nadal nie ma.
System może przygotować odpowiedź albo podsumowanie. Mail do klienta, zmiana statusu i zapis w tabeli czekają na zatwierdzenie.
Tekst do sprawdzenia.
Kto zatwierdza.
Co jest wyłączone w pierwszej wersji.
Biorę jedno zapytanie i przechodzę je krok po kroku: gdzie jest mail, gdzie leży załącznik i kto odpisuje klientowi.
Od czego zaczyna się praca.
Gdzie leży materiał.
Kto ją wysyła.
Do testu trafia niepełny mail, brakujący załącznik albo niejasna prośba. Na takim materiale widać, czy system zatrzyma się przed wysyłką.
Materiał z pracy, po anonimizacji.
Jak wygląda wynik ręczny.
Co ma się stać przy braku danych.
Jeżeli test nie skraca pracy albo nie poprawia odpowiedzi, zapisuję to wprost. Nie dokładam funkcji, żeby ratować pomysł.
Jak wyglądała praca przed testem.
Co faktycznie ubyło.
Dalej, zmiana zakresu albo stop.
Na start wystarcza paczka przykładów albo dostęp tylko do czytania. Zapis w tabeli, CRM i integracje przychodzą później.
Tylko potrzebny materiał.
Jak zatrzymać test.
Czego nie wolno wkładać do testu.
Osoba odbierająca wynik ma zobaczyć, co system przeczytał, co pominął i skąd wzięła się propozycja.
Co się wydarzyło.
Skąd pochodzi informacja.
Jak poprawić zły wynik.
Widok ma pokazać braki, źródła i przyciski: zatwierdź albo odrzuć. Ładny ekran bez tego nie pomaga w pracy.
Czego nie wiemy.
Co można otworzyć.
Co można zatwierdzić albo odrzucić.
Jeżeli pierwszy wynik jest przydatny, kolejny krok wybieram po miejscu, które najbardziej blokuje pracę: kolejne typy wiadomości, statusy albo integracje.
Po czym poznać, że warto iść dalej.
Co sprawdzić jako następne.
Kiedy nie ciągnąć tematu dalej.
Przy uruchomieniach szybko widać, czy decyzję da się później sprawdzić.
Dlatego w MG Bits patrzę, czy wynik ma źródło, zanim ktoś go wyśle albo zapisze.

System może znaleźć brakujący załącznik albo niejasną prośbę. Odpowiedź do klienta ma zatwierdzić osoba, która za nią odpowiada.
Opis wyniku ma pokazać źródło, brak i moment, w którym praca wraca do człowieka.

Dobry wynik pokazuje brak, źródło i osobę, która może zatwierdzić odpowiedź.
Wtedy łatwiej rozmawiać o następnym kroku, zamiast zgadywać zakres większego projektu.

Krótko o ofercie
Napisz, gdzie zaczyna się sprawa, kto dziś ją prowadzi i co najczęściej blokuje kolejny krok.
Po krótkim rozpoznaniu będzie wiadomo, czy jest z czego zrobić mały test, czy temat trzeba najpierw uporządkować po stronie procesu.