Przejdź do treści
DevUzDevUz Studio

// chatbot dla zgłoszeń i call center

Specyfikacja techniczna chatbota dla call center: co zwykle pomijają

Chatbot do obsługi zgłoszeń to jeden z najczęstszych zakupów ostatnich lat: urzędy i duże firmy chcą odciążyć call center, przejąć botem typowe pytania na Telegramie i na stronie, zostawiając konsultantom tylko trudne przypadki. Na papierze zadanie wygląda prosto: bot odpowiada na częste pytania i przyjmuje zgłoszenia. W praktyce to system z bazą wiedzy, logiką przekazywania rozmowy do człowieka, przechowywaniem korespondencji i wymaganiami co do jakości odpowiedzi — i właśnie te elementy typowa specyfikacja techniczna opisuje najsłabiej.

Zamawiającym zwykle jest urząd lub firma z działającym już call center, która chce zmniejszyć obciążenie konsultantów, a nie zbudować coś zupełnie nowego. Stąd pułapka: specyfikację pisze się przy założeniu, że „bot i tak wszystko wie”, zapominając, że wiedzę do bota ktoś musi wprowadzić i aktualizować.

O jakości gotowego bota decyduje nie to, jak ładnie prezentuje się na demo, lecz to, jak dokładnie specyfikacja opisała źródło odpowiedzi, scenariusz eskalacji do konsultanta i kryteria, według których odbiór stwierdzi „bot działa”. Jeśli tego brakuje w dokumencie, spór przy odbiorze jest niemal nieunikniony — a rozwiązywać go trzeba już po zapłacie.

Co zwykle pomija się w specyfikacji

Bot „odpowiada na częste pytania”, ale baza wiedzy nie jest załączona

Czym to grozi. Wykonawca na własne ryzyko formułuje odpowiedzi w imieniu zamawiającego, a przy odbiorze okazuje się, że część z nich jest nieprecyzyjna lub nieaktualna — spór o winę ciągnie się dłużej niż sama realizacja.

Jak napisać to dobrze. Do specyfikacji powinna być załączona baza wiedzy: lista tematów, gotowe sformułowania odpowiedzi lub przynajmniej dokumenty źródłowe, na podstawie których wykonawca je opracuje. Jeśli bazy nie ma, trzeba jasno zapisać, kto i w jakim terminie ją przygotuje, oraz wydzielić to jako osobny etap z osobnym odbiorem.

Nie opisano przekazania rozmowy do żywego konsultanta

Czym to grozi. Bot albo zapętla użytkownika na nietrafionych odpowiedziach, albo po prostu urywa dialog bez przekazania — zgłoszenie ginie, a call center nawet o tym nie wie.

Jak napisać to dobrze. Potrzebna jest osobna sekcja ze scenariuszem eskalacji: jakie wyzwalacze powodują przekazanie rozmowy konsultantowi, dokąd trafia przekazanie (konkretna kolejka, kanał, system call center), co konsultant widzi z historii korespondencji i co się dzieje, gdy konsultant jest niedostępny.

Nie określono, gdzie i jak długo przechowywana jest korespondencja

Czym to grozi. Bez tego wymagania dane zgłoszeń mogą być przechowywane gdziekolwiek i dowolnie długo — od korespondencji w chmurze wykonawcy po brak logów w ogóle, co rodzi ryzyko przy kontrolach i sporach z użytkownikami.

Jak napisać to dobrze. Specyfikacja powinna określać miejsce przechowywania korespondencji (na czyjej infrastrukturze), okres przechowywania, kto ma dostęp do logów i w jakim formacie zamawiający może je wyeksportować.

Nie ma sposobu, by sprawdzić jakość odpowiedzi przy odbiorze

Czym to grozi. Odbiór zamienia się w dowolne testowanie: każda strona zadaje botowi własne pytania i interpretuje wynik po swojemu, co opóźnia podpisanie protokołu.

Jak napisać to dobrze. W specyfikacji potrzebna jest lista pytań kontrolnych z wzorcowymi odpowiedziami — checklista, według której obie strony testują bota przy odbiorze i zapisują wynik punkt po punkcie.

Nie wymieniono języków komunikacji

Czym to grozi. Bot startuje tylko w jednym języku, a gdy okazuje się, że potrzebny jest kolejny, traktuje się to jako prace dodatkowe wykraczające poza kontrakt — z dodatkową opłatą i terminem.

Jak napisać to dobrze. Jasno wskazać w specyfikacji, w jakich językach bot ma rozumieć pytania i odpowiadać, oraz uwzględnić sprawdzenie tych języków w pytaniach kontrolnych przy odbiorze.

Co daje dobra specyfikacja

Zamawiającemu specyfikacja z gotową bazą wiedzy, scenariuszem eskalacji i pytaniami kontrolnymi daje przewidywalny odbiór bez sporów o to, co uznać za „działającego bota”.

Wykonawcy taka specyfikacja pozwala realnie ocenić zakres pracy, a nie domyślać się treści odpowiedzi i języków komunikacji na własną rękę.

Jasny opis przechowywania korespondencji eliminuje pytania przy przyszłych kontrolach i uwalnia obie strony od prac nieprzewidzianych w kontrakcie.

W efekcie bot przejmuje realną część zgłoszeń call center, zamiast stać się systemem, który uruchomiono i zapomniano.

Cena i czas realizacji

Specyfikacja techniczna: od $400, 1-4 tygodnie; cena zależy od złożoności systemu, architektury, stosu technologicznego i integracji. Realizacja w podwykonawstwie: wycena według zakresu kontraktu, przed złożeniem oferty.

Specyfikacja do przetargu lub podwykonawstwo: szczegóły →

Nie podajemy zamawiających ani przetargów: analizujemy typową specyfikację, a nie czyjeś zamówienie.

Przygotowujesz zamówienie albo już wygrałeś przetarg?

Omów przetarg

Więcej analiz przetargowych