Automatyczna transkrypcja rozmów firmowych – jak stworzyć usługę zamieniającą nagrania w notatki, zadania i dane w CRM

Największy błąd przy automatycznej transkrypcji rozmów firmowych polega na potraktowaniu jej jak zamiany pliku audio na tekst. Sam tekst ma ograniczoną wartość. Sprzedawca nadal musi przeczytać kilkanaście stron rozmowy, znaleźć ustalenia, przepisać je do CRM i ręcznie utworzyć zadania. Dobra usługa powinna wykonywać cały ten ciąg: nagranie → transkrypcja → identyfikacja rozmówców → notatka → decyzje → zadania → aktualizacja CRM.

Technicznie nie jest to już projekt wymagający trenowania własnego modelu rozpoznawania mowy. Gotowe API potrafi transkrybować godzinę nagrania za kilka złotych, a przy niektórych modelach nawet za około złotówkę. Trudniejsza część zaczyna się później: rozpoznanie, kto co powiedział, odróżnienie deklaracji od luźnej sugestii, prawidłowe przypisanie terminu zadania oraz niedopuszczenie do sytuacji, w której model wpisuje do CRM coś, czego klient wcale nie ustalił.

Jeżeli system ma działać w sprzedaży, obsłudze klienta albo rekrutacji, trzeba więc projektować go jak proces przetwarzania danych biznesowych, a nie jak prostą funkcję „transcribe”.

Od pliku audio do zadania w CRM – jak powinien wyglądać cały proces

Najbezpieczniejsza architektura składa się z kilku oddzielnych etapów. Łączenie wszystkiego w jedno wywołanie modelu wygląda atrakcyjnie w prototypie, ale później utrudnia poprawianie błędów i kontrolowanie kosztów.

Pierwszy etap to pozyskanie nagrania. Źródłem może być centrala VoIP, Microsoft Teams, Zoom, Google Meet, aplikacja mobilna handlowca albo plik dodany ręcznie. W produkcyjnym systemie razem z nagraniem trzeba przejąć także metadane:

• identyfikator rozmowy,
• datę i godzinę,
• czas trwania,
• numer telefonu albo identyfikator uczestnika,
• użytkownika prowadzącego rozmowę,
• identyfikator firmy, kontaktu lub szansy sprzedażowej w CRM,
• informację o źródle nagrania.

To właśnie identyfikator rozmowy jest później jednym z najważniejszych pól. Bez niego ponowne uruchomienie zadania po błędzie może utworzyć drugą notatkę, drugie zadanie i drugą aktywność w CRM. Operacje zapisu powinny być idempotentne: ponowne przetworzenie tej samej rozmowy aktualizuje istniejący rekord zamiast tworzyć następny.

Drugim etapem jest przygotowanie audio. Dla systemu większym problemem niż długość nagrania bywa jego jakość. Rozmowy telefoniczne często mają znacznie gorsze pasmo niż nagrania z Teams lub Meet. Do tego dochodzą głośnomówiące zestawy samochodowe, echo, szum ulicy, nakładające się głosy i nazwy produktów, których model wcześniej nie widział.

Jeżeli centrala telefoniczna zapisuje klienta i konsultanta na osobnych kanałach, nie należy ich przed transkrypcją miksować do jednego kanału. Rozdzielenie stron rozmowy na poziomie źródła jest pewniejsze niż późniejsze zgadywanie, który fragment wypowiedział który rozmówca.

Przy typowym bitrate 64–128 kb/s godzina skompresowanego nagrania zajmuje mniej więcej 29–58 MB. Dziesięć tysięcy minut rozmów miesięcznie to około 167 godzin, czyli zaledwie około 5–10 GB surowych nagrań. Sam storage nie jest więc zwykle problemem kosztowym. Problemem jest ustalenie, czy rzeczywiście trzeba przechowywać nagrania przez pół roku, skoro do dalszej pracy wystarcza transkrypcja i notatka.

Dopiero trzeci etap to speech-to-text. Dla rozmów biznesowych wynik powinien zawierać co najmniej tekst oraz znaczniki czasu. Jeżeli rozmowa ma kilku uczestników, potrzebna jest również diarization, czyli przypisanie fragmentów do poszczególnych mówców.

Nie należy zakładać, że model poprawnie rozpozna nazwę „Comarch ERP Optima”, nazwisko „Grzegorz Brzęczyszczykiewicz” czy wewnętrzny skrót produktu tylko dlatego, że dobrze radzi sobie ze zwykłym językiem polskim. W systemach obsługujących konkretną branżę przydaje się słownik nazw własnych i terminów, przekazywany jako kontekst lub lista słów kluczowych, jeśli dany silnik to obsługuje.

Po transkrypcji zaczyna się etap, który daje firmie największą wartość: ekstrakcja ustrukturyzowanych danych.

Zamiast pytać model:

„Podsumuj rozmowę i znajdź zadania”

lepiej wymagać zwrotu konkretnego schematu, na przykład:

• summary – notatka z rozmowy,
• decisions – podjęte decyzje,
• tasks – lista zadań,
• task_owner – osoba odpowiedzialna,
• due_date – termin,
• customer_needs – potrzeby klienta,
• objections – zastrzeżenia,
• products – omawiane produkty,
• next_contact_date – data następnego kontaktu,
• crm_fields – pola przeznaczone do aktualizacji,
• confidence – poziom pewności,
• evidence – fragment transkrypcji będący podstawą wpisu.

Ostatnie dwa pola są szczególnie ważne. Jeśli model stwierdzi, że klient zaakceptował ofertę, system powinien umieć wskazać fragment rozmowy, na podstawie którego doszedł do tego wniosku.

Nie każda informacja powinna też automatycznie trafiać do CRM. Reguła, która dobrze sprawdza się w praktyce, jest prosta: fakty można automatyzować agresywniej niż interpretacje.

Bez większego ryzyka można automatycznie zapisywać:

• czas rozmowy,
• uczestników,
• notatkę,
• jawnie wskazany termin kolejnego kontaktu,
• zadanie typu „wyślij ofertę do piątku”, jeśli zostało jasno wypowiedziane.

Znacznie ostrożniej należy traktować:

• zmianę etapu szansy sprzedażowej,
• przewidywany budżet klienta,
• prawdopodobieństwo zakupu,
• ocenę jakości rozmowy,
• klasyfikację klienta jako „zainteresowanego” albo „niezainteresowanego”.

Jeżeli system interpretuje zdanie „muszę jeszcze porozmawiać z zarządem” jako zamknięcie sprzedaży, problemem nie jest model językowy. Problemem jest źle zaprojektowana automatyzacja, która pozwala modelowi wykonać operację biznesową bez odpowiednio mocnego dowodu.

Ile kosztuje automatyczna transkrypcja i gdzie naprawdę pojawiają się problemy

Koszt samego speech-to-text jest obecnie niewielki w porównaniu z kosztem pracy człowieka. Przy kursie 1 USD = 3,7209 zł z końca sierpnia 2026 r. przykładowe ceny wyglądają następująco:

• OpenAI GPT Transcribe – 0,0045 USD za minutę, czyli około 0,27 USD lub 1,00 zł za godzinę nagrania,
• Deepgram Nova-3 Multilingual dla nagrań – 0,0052 USD za minutę, czyli około 1,16 zł za godzinę,
• Google Cloud Speech-to-Text V2 Standard – 0,016 USD za minutę przy pierwszych 500 tys. minut miesięcznie, czyli około 3,57 zł za godzinę.

Przy 10 000 minut miesięcznie daje to orientacyjnie około:

• 167 zł dla GPT Transcribe,
• 193 zł dla Deepgram Nova-3 Multilingual,
• 595 zł dla Google Speech-to-Text V2 Standard.

To wartości dla samej transkrypcji, bez kosztów podatkowych, przewalutowania, przechowywania, modeli generujących notatki, monitoringu i infrastruktury.

W Google koszt jednostkowy zaczyna wyraźnie spadać dopiero przy bardzo dużej skali: po przekroczeniu 500 tys. minut miesięcznie standardowa stawka schodzi z 0,016 do 0,01 USD za minutę, przy 1–2 mln minut wynosi 0,008 USD, a powyżej 2 mln minut 0,004 USD. Dla przeciętnej polskiej firmy są to jednak wolumeny znacznie większe niż potrzebne.

Koszt wygenerowania notatki i pól CRM jest zwykle mniejszy niż koszt samego rozpoznania mowy, szczególnie jeśli używa się małego modelu i wymusza krótki, ustrukturyzowany wynik. Nie oznacza to jednak, że najtańszy model należy stosować wszędzie. Streszczenie rozmowy i ekstrakcja daty to dwa różne problemy. Model może dobrze skracać tekst, a jednocześnie mylić „w przyszły czwartek” z nieprawidłową datą kalendarzową.

Dlatego test przed wdrożeniem powinien obejmować co najmniej 50–100 rzeczywistych rozmów, a nie przygotowane wcześniej nagrania demonstracyjne. W zbiorze powinny znaleźć się rozmowy:

• krótkie i długie,
• z dobrą i słabą jakością audio,
• prowadzone po polsku i z wtrąceniami angielskimi,
• z dwoma i większą liczbą uczestników,
• zawierające daty, kwoty, adresy e-mail, nazwy produktów oraz nazwiska,
• w których rozmówcy sobie przerywają.

Nie ma większego sensu mierzyć wyłącznie procentu poprawnie rozpoznanych słów. Dla firmy istotniejsze są błędy biznesowe. Jeśli model pomyli „piętnaście tysięcy” z „pięćdziesiąt tysięcy”, pojedynczy błąd może być ważniejszy niż sto brakujących „yyy” i „no właśnie”.

W praktyce warto więc mierzyć oddzielnie:

• poprawność kwot,
• poprawność dat,
• przypisanie wypowiedzi do rozmówców,
• wykrycie wszystkich zadań,
• liczbę zadań wymyślonych przez model,
• poprawność przypisania właściciela zadania,
• liczbę nieprawidłowych zmian danych CRM.

Najbardziej niebezpieczna metryka to false positive, czyli utworzenie czegoś, czego w rozmowie nie było. Brak jednego zadania jest irytujący. Automatyczne ustawienie w CRM informacji „klient zaakceptował ofertę za 120 tys. zł”, gdy klient tego nie powiedział, może wpłynąć na prognozę sprzedaży, raport zarządu i późniejszą komunikację handlowca.

Drugi obszar, którego nie można zostawić na koniec projektu, to RODO.

Nagranie głosu, transkrypcja, numer telefonu, nazwisko czy informacje przekazane podczas rozmowy mogą być danymi osobowymi. Firma musi określić między innymi cel przetwarzania, podstawę prawną, odbiorców danych, okres przechowywania i zasady realizacji praw osoby, której dane dotyczą. Sam komunikat „rozmowa jest nagrywana” nie zastępuje pełnego obowiązku informacyjnego.

Nie należy też automatycznie przyjmować, że podstawą każdego nagrania musi być zgoda. W zależności od procesu podstawą może być inna przesłanka z art. 6 RODO. To trzeba ustalić przed uruchomieniem systemu dla konkretnego przypadku biznesowego, a nie dopiero wtedy, gdy pierwsza osoba zażąda usunięcia nagrania.

Kolejny problem to retencja. Nie istnieje jedna uniwersalna zasada mówiąca, że każdą nagraną rozmowę wolno przechowywać przez 30, 90 czy 365 dni. Okres powinien wynikać z celu. Jeśli nagranie służy wyłącznie do sporządzenia notatki i po kilku dniach przestaje być potrzebne, trudno uzasadniać jego bezterminowe trzymanie „na wszelki wypadek”.

Dobry projekt rozdziela retencję:

• nagranie audio – np. krótki okres operacyjny,
• pełna transkrypcja – zgodnie z rzeczywistą potrzebą,
• notatka i ustalenia biznesowe – zgodnie z okresem obowiązującym dla danych w CRM,
• log techniczny – tylko w zakresie potrzebnym do diagnostyki.

Trzeba też sprawdzić miejsce przetwarzania danych i umowę z dostawcą. Nie wystarczy fakt, że dostawca „jest zgodny z RODO”. Google udostępnia europejski endpoint Speech-to-Text, Deepgram ma osobny endpoint UE, a OpenAI oferuje europejskie przetwarzanie dla kwalifikujących się projektów API wraz z opcją zero data retention. Konfiguracja regionu powinna jednak rzeczywiście znaleźć się w projekcie i umowie – logo „GDPR compliant” na stronie dostawcy niczego samo nie ustawia.

Szczególną ostrożność trzeba zachować przy analizowaniu pracowników. AI Act zakazuje stosowania systemów AI do wnioskowania o emocjach osób w miejscu pracy, poza wyjątkami dotyczącymi względów medycznych lub bezpieczeństwa. Pomysł, aby każdemu handlowcowi automatycznie wyliczać „poziom stresu”, „entuzjazm” czy „frustrację” na podstawie głosu, jest więc nie tylko metodologicznie wątpliwy. W środowisku pracy może wejść w obszar zakazanych zastosowań AI.

Jak połączyć transkrypcję z CRM, żeby automatyzacja nie zaczęła psuć danych

Najbardziej użyteczna wersja systemu nie próbuje od pierwszego dnia automatyzować całej firmy. Lepiej zacząć od jednego rodzaju rozmowy i jednego obiektu CRM.

Przykład dla zespołu sprzedaży korzystającego z HubSpot, Pipedrive albo Salesforce:

1. Rozmowa się kończy.
2. Nagranie trafia do kolejki.
3. System wykonuje transkrypcję.
4. Model zwraca ustrukturyzowany JSON.
5. Backend sprawdza wymagane pola oraz poziom pewności.
6. Do CRM trafia notatka z rozmowy.
7. Jeśli rozmówca jasno ustalił następny krok, system tworzy zadanie.
8. Pola wymagające interpretacji trafiają do akceptacji handlowca.
9. Po określonym czasie źródłowe audio jest automatycznie usuwane.

Pierwsza wersja nie potrzebuje skomplikowanego panelu. Znacznie ważniejszy jest mechanizm korekty. Handlowiec powinien móc jednym kliknięciem oznaczyć:

• notatka poprawna,
• błędny termin,
• brakujące zadanie,
• zadanie utworzone błędnie,
• niewłaściwy rozmówca,
• błędna kwota.

Bez tych danych po dwóch miesiącach nadal wiadomo tylko, że „AI czasami się myli”. Z mechanizmem korekty można policzyć konkretnie, że na przykład 97% terminów jest poprawnych, ale tylko 84% kwot zostaje zapisanych bez błędu.

Dobrą praktyką jest zapisanie wraz z każdą automatyczną wartością pochodzenia informacji. Jeżeli CRM pokazuje:

„Budżet klienta: 80 000 zł”

system powinien przechować również coś w rodzaju:

„00:18:42 – klient: na pierwszy etap mamy mniej więcej osiemdziesiąt tysięcy”.

Dzięki temu człowiek może sprawdzić wartość w kilka sekund bez odsłuchiwania całej rozmowy.

Najgorszym pomysłem jest natomiast oddanie modelowi pełnej swobody w API CRM. Model nie powinien sam decydować, jaki endpoint wywoła i jakie dane nadpisze. Warstwa aplikacyjna powinna udostępniać mu ściśle ograniczony zestaw operacji, np.:

• create_note,
• create_followup_task,
• suggest_deal_stage,
• update_next_contact_date.

Zwraca uwagę słowo suggest. Zmiana etapu transakcji z „Oferta” na „Wygrana” powinna mieć znacznie wyższy próg niż dodanie notatki. To klasyczny przykład operacji, która wygląda niewinnie podczas demonstracji, a po wdrożeniu potrafi zniszczyć jakość raportów sprzedażowych.

Trzeba też przewidzieć awarie. Przy integracji produkcyjnej wystąpią: timeouty API, uszkodzone pliki, brak nagrania, podwójne webhooki, limity zapytań CRM i chwilowe problemy dostawcy modelu. Kolejka z retry oraz dead-letter queue nie są więc dodatkiem dla dużych przedsiębiorstw. Są podstawowym zabezpieczeniem przed cichym gubieniem rozmów.

Dla niewielkiej firmy pierwsze proof of concept można zwykle zbudować w ciągu około 3–7 dni roboczych, jeśli nagrania są już dostępne i CRM ma dobrze opisane API. Wersja produkcyjna z autoryzacją użytkowników, obsługą błędów, audytem, retencją, monitoringiem i sensownym mechanizmem zatwierdzania zmian to raczej 2–6 tygodni pracy. W środowisku korporacyjnym, gdzie dochodzą SSO, procedury bezpieczeństwa, DPIA, zamówienia, testy penetracyjne i kilka systemów źródłowych, projekt może zająć 6–12 tygodni lub więcej.

Najpierw warto więc policzyć efekt na jednym procesie. Jeżeli 10 handlowców prowadzi po 5 rozmów dziennie i każdy poświęca średnio 6 minut na wpisanie notatki i ustawienie następnego zadania, firma zużywa około 300 minut pracy dziennie, czyli 5 godzin. Przy 20 dniach roboczych daje to około 100 godzin miesięcznie. W takim przypadku opłaty za samą transkrypcję są marginalne wobec wartości czasu odzyskanego przez zespół.

Nie znaczy to jednak, że każda firma potrzebuje własnej platformy. Jeżeli zespół wykonuje 30 rozmów miesięcznie, gotowa funkcja w używanym CRM, systemie VoIP czy narzędziu do spotkań może być rozsądniejsza niż budowanie własnego backendu. Własna usługa zaczyna mieć przewagę wtedy, gdy trzeba kontrolować logikę ekstrakcji, retencję danych, kilka źródeł nagrań, niestandardowe pola CRM albo sposób zatwierdzania informacji.

FAQ – najczęstsze pytania o automatyczną transkrypcję rozmów firmowych

Czy do stworzenia takiego systemu trzeba trenować własny model AI?
Nie. W większości wdrożeń lepiej zacząć od gotowego API speech-to-text i modelu językowego generującego dane w ustalonym schemacie. Własny model ma sens dopiero wtedy, gdy testy na rzeczywistych nagraniach pokażą konkretny, powtarzalny problem, którego nie da się rozwiązać słownikiem terminów, zmianą modelu albo poprawą jakości audio.

Czy można automatycznie wpisywać wszystkie ustalenia do CRM?
Technicznie tak, ale nie należy tego robić. Automatycznie warto zapisywać informacje jednoznaczne: notatkę, datę rozmowy czy jasno ustalone zadanie. Zmiana etapu sprzedaży, budżetu albo oceny klienta powinna mieć dodatkową walidację lub akceptację człowieka.

Czy klient musi wyrazić zgodę na nagrywanie rozmowy?
System wymaga określenia prawidłowej podstawy przetwarzania i spełnienia obowiązku informacyjnego, ale zgoda nie jest automatycznie jedyną możliwą podstawą z RODO. Właściwa podstawa zależy od celu i charakteru procesu. Samo zdanie „rozmowa jest nagrywana” nie realizuje pełnego obowiązku informacyjnego.

Jak długo przechowywać nagrania?
Nie powinno się ustalać okresu retencji metodą „wszyscy trzymają rok”. Nagranie należy przechowywać tak długo, jak wymaga tego konkretny cel. Często rozsądne jest usuwanie audio wcześniej niż transkrypcji i notatki w CRM.

Czy polski język jest problemem dla współczesnych modeli?
Sam język polski nie jest największym problemem. Więcej błędów powodują słabe nagrania telefoniczne, nakładanie się głosów, specjalistyczne nazewnictwo, nazwiska, skróty oraz mieszanie polskiego z angielskim. Dlatego dostawcę trzeba wybierać na podstawie testu własnych rozmów, a nie dema przygotowanego przez producenta.

Czy warto robić transkrypcję w czasie rzeczywistym?
Tylko wtedy, gdy wynik ma być używany jeszcze podczas rozmowy, np. do podpowiedzi konsultantowi. Jeżeli celem jest notatka i aktualizacja CRM po zakończeniu połączenia, przetwarzanie nagrania po rozmowie jest prostsze, tańsze w utrzymaniu i łatwiejsze do ponawiania po błędach.

Ile rozmów trzeba przetestować przed uruchomieniem systemu?
Minimum sensownego testu to około 50–100 prawdziwych rozmów reprezentujących różne warunki. Przy dużej zmienności – kilka języków, różne centrale, rozmowy terenowe i wiele produktów – próbka powinna być większa.

Co powinno być pierwszym krokiem wdrożenia?
Nie zaczynaj od wyboru modelu ani budowania integracji. Weź 50 rzeczywistych nagrań z jednego procesu, ręcznie zapisz oczekiwane notatki, zadania, daty, kwoty i pola CRM, a następnie przepuść dokładnie ten sam zestaw przez 2–3 silniki transkrypcji. Najpierw usuń błędy dotyczące kwot, terminów i fałszywie utworzonych zadań. Dopiero gdy te trzy elementy osiągną akceptowalną jakość, podłącz automatyczny zapis do CRM. To właśnie jest granica między ciekawym demem AI a usługą, której można powierzyć dane sprzedażowe firmy. Więcej informacji na: https://hd-biznes.com/blog