Własny system zgłoszeń dla sieci serwisowej

Jedno zgłoszenie, różne potrzeby

Załóżmy, że klient zgłasza usterkę instalatorowi. Instalator zapisuje problem i dodaje zdjęcie, ale naprawę ma wykonać inna firma z sieci. Koordynator przekazuje jej sprawę. Od tej chwili każda ze stron potrzebuje trochę innego widoku tej samej pracy.

Instalator chce wiedzieć, czy ktoś zajął się jego zgłoszeniem. Powinien móc wrócić do własnego opisu i zdjęcia oraz sprawdzić, komu przekazano sprawę i na jakim jest etapie. Dzięki temu odpowie klientowi bez telefonu do centrali. Nie potrzebuje przy tym dostępu do późniejszych notatek serwisanta ani wewnętrznych ustaleń koordynatora.

Firma wykonująca naprawę potrzebuje kontaktu do klienta, opisu usterki i zdjęcia, żeby przygotować wizytę. Dopisuje przebieg swojej pracy i może później do niego wrócić. Nie ma powodu, by przy okazji otrzymała dostęp do pozostałych zgłoszeń instalatora. Centrala z kolei musi widzieć całość: co wpłynęło, komu przekazano sprawę i co wydarzyło się podczas naprawy. Jej wewnętrzne notatki pozostają dostępne tylko dla uprawnionych pracowników.

To jeden możliwy podział dostępu. W twojej sieci instalator może potrzebować innych informacji. Warto ustalić to na konkretnym zgłoszeniu, bo ogólne polecenie „przekaż sprawę partnerowi” nie mówi, co ma zostać widoczne dla poprzedniego uczestnika. Gdy system tego nie rozróżnia, koordynator musi ręcznie wybierać pliki i kopiować fragmenty historii.

Czy obecny system już to potrafi?

Zanim zamówisz aplikację, poproś administratora o pokazanie takiego przekazania w używanym narzędziu. Obejrzyj sprawę z kont obu partnerów. Czy serwisant otworzy zdjęcie? Czy instalator nadal zobaczy status, ale nie otrzyma maila z wewnętrznymi uwagami do naprawy? Czy centrala odtworzy przebieg sprawy bez szukania w skrzynkach pocztowych? Sprawdzenie powinno objąć również moment przed przekazaniem, kiedy przyszły wykonawca jeszcze nie ma dostępu do zgłoszenia.

Sama zmiana osoby lub firmy przypisanej do sprawy nie daje odpowiedzi na te pytania. Uprawnienia mogą wynikać także z ustawień organizacji, do której należy użytkownik. Na przykład Zendesk Support osobno ocenia widoczność zgłoszeń na poziomie organizacji i profilu użytkownika końcowego. Gdy te ustawienia są sprzeczne, obowiązuje to, które daje szerszy dostęp. Tak działa ten konkretny zakres uprawnień w Zendesk; nie jest to wspólna reguła wszystkich systemów (dokumentacja Zendesk).

Jeśli pokaz ujawni problem, ustal z dostawcą, czy wynika on z konfiguracji, ograniczeń planu czy braku funkcji. Zapytaj o konta dla zewnętrznych partnerów i role z ograniczonym dostępem. Partner, który tylko przyjmuje wybrane zlecenia, może potrzebować znacznie mniej funkcji niż pracownik centrali. Dostępne opcje i ich warunki trzeba sprawdzić dla konkretnego produktu.

Konfiguracja, rozszerzenie czy własna aplikacja

Gdy gotowy system obsługuje potrzebny podział informacji, zacznij od konfiguracji. Koszt zmiany obejmie wtedy również uporządkowanie istniejących kont i pokazanie partnerom, jak mają pracować. Przed odnowieniem umowy warto porównać dostępne plany oraz inne produkty SaaS. Wysoki rachunek za rzadko używane konta jest powodem do takiego porównania, ale sam nie przesądza o opłacalności budowy.

Rozszerzenie ma sens, gdy obecny system dobrze prowadzi zgłoszenia, a brakuje jednego fragmentu pracy. Może to być prosty widok dla partnera lub zapis powodu przekazania sprawy. Wtedy zgłoszenia i ich historia mogą pozostać w dotychczasowym narzędziu. Trzeba jednak sprawdzić, czy wspierany sposób połączenia pozwala udostępnić partnerowi właściwe dane i zapisać jego działania. Jeśli koordynator nadal musi kopiować wynik naprawy do głównego systemu, część problemu pozostaje.

Własny obieg warto rozważyć, gdy partnerzy stale przekazują sobie sprawy, a potrzebnego dostępu i historii nie da się obsłużyć konfiguracją ani rozszerzeniem. Zakres może ograniczać się do współpracy z partnerami i połączenia z obecnym CRM. Pełną wymianę systemu zostaw na sytuację, w której utrzymanie dotychczasowego narzędzia rzeczywiście uniemożliwia potrzebną zmianę.

AI nie jest konieczne do takiego obiegu. Może pomóc skrócić długi opis usterki, jeśli zespół tego potrzebuje. Przydział sprawy i dostęp do danych nadal powinny wynikać z ustalonych zasad.

Co będzie kosztować czas po uruchomieniu

Porównując oferty, uwzględnij pracę koordynatora przy jednym przekazaniu. Jeśli musi osobno wysłać zdjęcia, założyć konto i później przepisać odpowiedź, zapisz te czynności oraz to, jak często się powtarzają. Obok abonamentu pojawi się wtedy rzeczywista praca, którą zmiana ma uprościć. Podobnie oceń czas potrzebny na zaproszenie nowego partnera, odebranie mu dostępu i pomoc, gdy nie potrafi znaleźć zlecenia.

Przy własnej aplikacji część obowiązków dostawcy SaaS przechodzi na firmę i jej wykonawcę. Ktoś musi utrzymywać połączenia z CRM, reagować na błędy i aktualizować aplikację. Ustal, kto pomoże koordynatorowi, jeśli zgłoszenie nie dotrze do partnera, oraz kto przeszkoli osoby dołączające do sieci. Te obowiązki powinny mieć właściciela i miejsce w ofercie utrzymania.

Zmiana systemu wymaga też decyzji o otwartych sprawach. Opis zgłoszenia bez zdjęć albo historii napraw może nie wystarczyć do dalszej pracy. Przed migracją sprawdź więc, co uda się przenieść i jak zachowasz przypisanie do partnerów. Dla zamkniętych spraw ustal sposób korzystania z archiwum oraz eksportu danych po zakończeniu umowy.

Przy zamawianiu aplikacji uzgodnij również możliwość przekazania jej innemu wykonawcy. Potrzebne będą zasady dostępu do kodu i kont hostingowych, dokumentacja oraz zapis zmian i prac utrzymaniowych. To pozwoli ocenić, ile pracy będzie wymagało przejęcie opieki nad systemem, zanim zależność od dostawcy stanie się problemem.

Od czego zacząć rozmowę z Syntalith

Gdy partner potrzebuje również historii konkretnego urządzenia, pomocny jest zakres przygotowania informacji serwisowych z AI. Dostęp partnerów i przekazywanie zleceń wymagają osobnych ustaleń w projekcie sieci serwisowej.

Syntalith tworzy aplikacje na zamówienie. W sieci serwisowej użytecznym punktem wyjścia jest jedno przekazanie, przy którym koordynator musi dziś wyręczać system. Na tej podstawie można określić zakres widoku dla partnera i połączenia z obecnym narzędziem, a następnie porównać taki projekt z możliwościami gotowego produktu. Celem jest usunięcie konkretnych czynności, takich jak ponowne wpisywanie wyniku naprawy, przy zachowaniu pełnej historii w centrali.

Do pierwszej rozmowy wystarczy nazwa systemu, używany plan i zanonimizowane zgłoszenie, które pokazuje problem. Opowiedz, co koordynator robi poza systemem i czego partner nie może sam sprawdzić. Nie musisz wcześniej rozpisywać wszystkich uprawnień. Aplikacja na zamówienie w Syntalith zaczyna się od 12 500 zł netto (cennik). Jeśli potrzebujesz także miejsca do szerszej obsługi klientów, przeczytaj porównanie własnego portalu klienta z dodatkiem do CRM.

Ile to kosztuje

Od czego zacząć

Na bezpłatnej analizie wybieramy jeden proces i liczymy wolumen oraz czas pracy zespołu, a w 2 dni robocze dostajesz pisemne podsumowanie z ceną. Budowę prowadzimy w ramach aplikacji AI, a utrzymanie wyceniamy osobno.