Piotr MuchaPrincipal Software Engineer FairyDeck EN / PL Porozmawiajmy o systemie
Menu

Case produkcyjny · Shoper

Opublikowane doświadczenie produkcyjne

Eliminacja ręcznego wyszukiwania klienta podczas rozmów supportu na platformie obsługującej ponad 20 tys. sklepów.

Rozwiązanie połączyło telefonię, wewnętrzną administrację i historię supportu wokół rzeczywistego procesu konsultanta.

20 tys.+
sklepów na platformie w tamtym okresie
~400 / dzień
rozmów supportu dziennie

01

Kontekst przygotowany przed rozpoczęciem rozmowy.

Dzwoniący często nie znali nazwy konta ani danych rejestracyjnych. Konsultant musiał rozpoznać klienta, znaleźć sklep i odtworzyć wcześniejszą korespondencję przed zajęciem się właściwym problemem.

Identyfikacja zaczynała się podczas oczekiwania na konsultanta. W chwili odebrania rozmowy dane klienta, sklepy i historia supportu były już dostępne.

02

Proces supportu tracący czas na znalezienie właściciela problemu.

Stan początkowy

Ręczna identyfikacja w rozproszonym kontekście

Telefon, administracja klienta i wcześniejsze kontakty z supportem nie tworzyły jednego kontekstu roboczego. Wyszukiwanie mogło pochłonąć większość czasu obsługi przed rozpoczęciem diagnozy.

Ograniczenia

Integracja musiała działać wewnątrz dojrzałej platformy e-commerce

  • Platforma obsługiwała w tamtym okresie ponad 20 tys. sklepów.
  • Dział supportu prowadził około 400 rozmów dziennie.
  • Dane dzwoniącego mogły być niepełne lub różnić się od danych konta.
  • Proces musiał połączyć telefonię z istniejącymi systemami klienta i supportu.

Decyzja produktowa

Usunięcie wyszukiwania zamiast nieznacznego przyspieszania searcha

Wykorzystanie czasu oczekiwania do identyfikacji zmieniło granicę procesu. Konsultant zaczynał od gotowego kontekstu, zamiast obsługiwać kolejny interfejs wyszukiwania podczas rozmowy.

Mój wkład

Proces produktowy oparty na bezpośrednim doświadczeniu supportu.

Połączyłem wcześniejsze doświadczenie w obsłudze klienta z implementacją, rozwiązując problem operacyjny u źródła.

Projekt procesu supportu
Zmapowałem kontekst potrzebny przy odebraniu telefonu i przeniosłem identyfikację dzwoniącego do czasu oczekiwania.
Integracja telefonii i kontekstu
Dostarczyłem połączenie przychodzącej rozmowy z danymi klienta, sklepami i wcześniejszą historią supportu.
Aplikacja migracyjna PrestaShop
Osobno zbudowałem aplikację przenoszącą sklepy z PrestaShop do Shopera.

Zmierzony rezultat dotyczy etapu wyszukiwania kontekstu klienta. Nie przedstawiam go jako skrócenia całkowitego czasu rozmowy.

Kluczowe decyzje

Projekt wokół momentu, w którym konsultant musi działać.

Rozwiązanie potraktowało kontekst klienta jako część zestawiania rozmowy, a nie osobne zadanie administracyjne.

  1. 01

    Identyfikacja podczas oczekiwania

    Dopasowanie dzwoniącego zaczyna się przed odebraniem, wykorzystując czas bez wcześniejszej wartości dla supportu.

  2. 02

    Połączony kontekst operacyjny

    Dane klienta, sklepy i historia supportu trafiają razem, zamiast wymagać osobnych wyszukiwań.

  3. 03

    Optymalizacja pierwszej użytecznej czynności

    Konsultant może rozpocząć diagnozę bezpośrednio po odebraniu rozmowy.

Model dostarczania

Proces przebudowany wokół połączenia przychodzącego.

  1. 01

    Mapowanie kontekstu supportu

    Ustalenie danych klienta, sklepu i historii potrzebnych konsultantowi przed pierwszym pytaniem.

  2. 02

    Połączenie numeru z danymi wewnętrznymi

    Rozpoznanie prawdopodobnych kont i zebranie dostępnego kontekstu podczas oczekiwania.

  3. 03

    Jeden widok roboczy

    Udostępnienie przygotowanego kontekstu przy odebraniu i weryfikacja w codziennej pracy supportu.

Zweryfikowany rezultat produkcyjny

Rozmowa mogła zacząć się od zidentyfikowanego klienta.

~400 / dzień
obsługiwanych dziennie przez proces
Do 60% → praktycznie zero
etap wyszukiwania został praktycznie wyeliminowany po wdrożeniu

Skala platformy i liczba rozmów opisują okres realizacji projektu. Nie sugerują aktualnej skali Shopera ani endorsementu.

Czego to dowodzi

Product engineering zaczynający się od realnego procesu operacyjnego.

Case łączy insight użytkownika, projekt integracji i bezpośrednie wykonanie z mierzalną poprawą dla wewnętrznego zespołu pracującego w dużej skali.

Modernizacja platformy marketing automation przetwarzającej do około 45 tys. zdarzeń na minutę.

Przy około 1000 zintegrowanych sklepów przetwarzanie eventów na dysku i skalowanie przez dokładanie serwerów osiągały granice niezawodności i kosztów. Platforma przeszła na kolejki oraz skalowalne workery, a krytyczne komponenty PHP i Java były modernizowane etapami.

Modernizacja krytycznego ERP bez zatrzymywania sprzedaży, zakupów i pracy magazynów.

Wielokanałowa hurtownia części samochodowych opierała krytyczne procesy na kilku nieudokumentowanych, silnie powiązanych systemach legacy. Zamiast przepisywać wszystko naraz, przenosiłem kompletne procesy do audytowalnych domen, utrzymując ciągłość sprzedaży, zakupów i pracy magazynów.

Twój proces wewnętrzny

Które powtarzalne wyszukiwanie lub przekazanie blokuje użyteczną pracę?

Możemy zmapować rzeczywistą ścieżkę decyzji i zaprojektować najmniejszą zmianę systemową usuwającą wąskie gardło.

Porozmawiajmy o usprawnieniu procesu operacyjnego

Wróć do realizacji