Przykład produktu serwisowego
Załóżmy, że software house rozwija aplikację do obsługi urządzeń. Klient chce przyjmować zgłoszenia telefoniczne również wtedy, gdy dyspozytor jest zajęty. Agent ma zebrać identyfikator urządzenia, objawy i kontakt, a następnie utworzyć sprawę w aplikacji.
Zespół produktu pozostaje właścicielem zasad dostępu, walidacji danych oraz przydzielania zleceń. My przygotowujemy przebieg rozmowy, odczyt uzgodnionych informacji, wywołanie operacji i reakcję na jej rezultat. Nie trzeba udostępniać agentowi funkcji, które nie są częścią tej obsługi.
Uzgodnienie wymiany danych
Poniższa tabela jest przykładem umowy technicznej między zespołami, nie opisem istniejącego API.
Przewiń tabelę w bok, aby zobaczyć wszystkie kolumny.
| Operacja | Co przekazuje część głosowa | Co zwraca produkt |
|---|---|---|
| Sprawdź urządzenie | Identyfikator i wymagany kontekst dostępu | Właściwe urządzenie albo brak pewnego dopasowania |
| Utwórz zgłoszenie | Identyfikator sprawy, opis i kontakt | Potwierdzenie zapisu z numerem zgłoszenia |
| Sprawdź wcześniejszy zapis | Ten sam identyfikator sprawy | Utworzona sprawa albo informacja o braku zapisu |
| Przekaż do dyspozytora | Powód i zebrane ustalenia | Potwierdzenie przekazania albo potrzeba innego sposobu kontaktu |
Identyfikator sprawy pomaga rozstrzygnąć sytuację, gdy odpowiedź z produktu nie dotrze. Ponowienie operacji nie powinno tworzyć kolejnego zlecenia. Sposób zapewnienia tego warunku uzgadnia się z zespołem produktu; nie wystarczy dopisać instrukcji do rozmowy.
Co otrzyma dyspozytor
Przykładowy wynik może brzmieć: „Urządzenie DEMO-12. Zgłoszenie: wyciek przy przyłączu. Kontakt wskazany przez rozmówcę. Potrzebna odpowiedź dyspozytora w sprawie terminu. Nie potwierdzono wyjazdu technika”. Numery i sytuacja są fikcyjne.
W próbie odbioru sprawdzamy ten zapis w produkcie oraz komunikat dla rozmówcy. Jeżeli agent powiedział o wysłaniu technika, a aplikacja utworzyła jedynie zgłoszenie, proces nie spełnia uzgodnionego zakresu. Odpowiedź głosowa musi odpowiadać rzeczywistemu wynikowi operacji.
Podział utrzymania
Wspólna oferta powinna określać, kto poprawia rozmowę, kto utrzymuje API i kto przyjmuje zgłoszenie od klienta. Po zmianie pól lub odpowiedzi produktu potrzebna może być aktualizacja połączenia oraz wspólna próba. Można ją objąć opieką albo uzgodnić jako dodatkową pracę zależnie od skali zmiany.
Dostawę części głosowej, dostęp do środowiska testowego, kryteria odbioru i opiekę ustalamy dla konkretnego projektu. Kod, dokumentacja i prawo do ich dalszego użycia powinny mieć jednoznaczne ustalenia w zamówieniu.
Materiał do wyceny
Przekaż opis jednego procesu i przykładową odpowiedź aplikacji. Na początku wystarczą dane demonstracyjne. Po ustaleniu granicy pracy przygotujemy wycenę obejmującą rozmowę, połączenie, wspólny odbiór oraz opiekę. Sposób dostarczenia wdrożenia.
Jeżeli aplikacja nie ma jeszcze potrzebnej operacji, ustalimy osobno, który zespół ją tworzy. Tego kosztu nie wolno pomijać w ofercie dla końcowego klienta. Do wspólnego zestawienia można użyć arkusza kosztorysu projektu.
Zakres materiału
Przykładową wymianę danych opracowano na potrzeby tego tekstu. Nie potwierdza ona wykonania połączenia z konkretnym produktem. Integracje odbierze.ai Model podwykonawstwa części głosowej