Jak sprawić, by wewnętrzne zgłoszenia trafiały do właściwej osoby

TL;DR

• Kontekst: Lead UX w scaleupie e-commerce B2B z opakowaniami.
• Problem: Zgłoszenia (zgubiona paczka, zwrot pieniędzy, korekta faktury) krążyły w wiadomościach. Zgłaszający pisał do kolejnych osób, aż ktoś się tym zajął.
• Co zrobiłem: Zaprojektowałem w platformie warstwę workflow, która kieruje zadanie do właściwego zespołu według typu problemu.
• Wynik: Ponad 10 workflowów na produkcji i ~300 zadań miesięcznie.

Diagnoza

Kiedy przejąłem projekt, w platformie był już zaczęty moduł zadań. Brakowało mu jednak najważniejszej części, czyli kierowania zgłoszeń do właściwych ludzi. Osoba, która zgłasza zgubioną paczkę, nie wie, kto się tym zajmie, i nie musi tego wiedzieć. Wystarczy, że powie, co się stało. Pisanie do ludzi po kolei działa słabo, bo im więcej zgłoszeń, tym więcej czasu na nie ucieka. Nie potrzebowaliśmy więc ładniejszej listy zadań. Potrzebowaliśmy warstwy, która przyjmuje zgłoszenie według typu problemu i przekazuje je zespołowi, który się nim zajmuje. Umieściłem ją w platformie, w której było już zamówienie, więc nikt nie musiał przełączać się do innego narzędzia.

flowchart TD
    subgraph Przed["Przed"]
        A1["Zgłaszający pisze do osoby 1"] --> A2{"Odpowiedź?"}
        A2 -->|"nie"| A3["Pisze do osoby 2, 3..."]
        A3 --> A2
        A2 -->|"tak"| A4["Ktoś w końcu się tym zajmuje"]
    end
    subgraph Po["Po"]
        B1["Zgłoszenie: typ problemu"] --> B2["Automatyczne przekazanie do zespołu"]
        B2 --> B3["Właściwy zespół bierze zadanie"]
    end

    classDef good    fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
    classDef bad     fill:#faeaea,stroke:none,color:#5f2626,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class A1,A2,A3,A4 bad
    class B1,B2 good
    class B3 accent
    style Przed fill:#fdf5f5,stroke:#e0c3c3,stroke-width:1px,color:#5f2626,rx:14,ry:14
    style Po fill:#f2f8f3,stroke:#c2dcc8,stroke-width:1px,color:#1f4d33,rx:14,ry:14
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

Co zrobiłem

• Rozbudowałem moduł zadań po designerze, który odszedł z firmy. Dodałem warstwę workflow, która kieruje zadania do zespołów.
• Zaprojektowałem tworzenie zadań z poziomu zamówienia albo konkretnej pozycji. Zadanie od razu ma kontekst i nie trzeba wypełniać pustego formularza.
• Zaprojektowałem widoki dla dwóch ról. Manager widzi zadania według osób i osobną grupę „nieprzypisane”. Pracownik widzi swoje zadania pogrupowane według workflowów. Inspirowałem się bazami w Notion i tablicami w Jirze i Asanie.
• Całość zmieściłem w istniejącej platformie, bez osobnego systemu zgłoszeń.

Wyniki

• Ponad 10 workflowów na produkcji (m.in. zgubiona paczka, korekta faktury, zwrot pieniędzy).

• ~300 zadań miesięcznie w pierwszych trzech miesiącach.
• Pomiar czasu obsługi dla każdego procesu. Przy wiadomościach nie dało się tego zmierzyć.
• Zespoły mówiły, że łatwo widzą otwarte sprawy i łatwo przekazują zadania, kiedy ktoś nagle idzie na zwolnienie. Zgłoszenie ma swój typ, więc nie utyka w czyjejś skrzynce.

Problem

Dlaczego wewnętrzne zgłoszenia szły tak wolno?

Firma robiła opakowania na zamówienie. Każde zamówienie przechodzi przez specyfikację, wycenę, produkcję, wysyłkę i rozliczenia, a na każdym etapie coś może pójść nie tak. Kiedy paczka się gubiła albo faktura miała błąd, osoba, która to zauważyła (często z obsługi klienta), pisała do kolejnych kolegów, aż ktoś się tym zajął. Nie wiedziała, do kogo iść, bo nie było żadnego systemu. Im więcej zgłoszeń, tym więcej czasu to zajmowało, a nikt nie widział, co jest otwarte i kto nad tym pracuje.

Dlaczego nie kupić gotowego systemu zgłoszeń?

Bo cała praca działa już w platformie do obsługi zamówień. Osobne narzędzie to kolejne logowanie, kolejne miejsce do sprawdzania i kolejne dane, które trzeba synchronizować. System musiał być prosty i działać tam, gdzie jest zamówienie.

Moja rola / zakres

• Byłem Lead UX i odpowiadałem za projekt systemu zadań i warstwy workflow.
• Podstawowy moduł zadań naszkicował inny designer, zanim odszedł, ale bez workflowów. To ja dodałem kierowanie zgłoszeń do zespołów, bo uznałem, że tam jest największa wartość.
• Odszedłem z firmy przed kolejną zaplanowaną fazą (paleta komend i automatyczne przypisywanie).

Proces

• Zacząłem od prostego założenia: zgłaszającego nie obchodzi, kto zajmie się sprawą. Obchodzi go tylko, co się stało. Na tym oparłem cały model workflowów.
• Spisałem typy zgłoszeń, które się powtarzają: zgubiona paczka, korekta faktury, zwrot pieniędzy, status wysyłki. Każdy dostał własny workflow z listą potrzebnych informacji.
• Projektowałem tworzenie zadań z zamówienia, widoki dla ról i powiadomienia. Na bieżąco sprawdzałem je z zespołami, które miały z nich korzystać.

Kluczowe decyzje i trade-offy

• Zgłoszenie według typu problemu. Zgłaszający wybiera „zgubiona paczka” i nie musi szukać nikogo w logistyce. Nie musi znać ludzi, żeby coś zgłosić, a to działa niezależnie od liczby zgłoszeń. Według mnie dopiero to sprawiło, że moduł zadań zaczął mieć sens.
• System w platformie. Zrezygnowałem z zewnętrznego narzędzia. Musieliśmy go sami zbudować i utrzymywać, ale działa tam, gdzie zamówienie. Nikt nie przełącza się między narzędziami i nic się nie rozjeżdża.

flowchart LR
    O["Widok zamówienia<br/>istniejąca platforma"] --> T["System zadań<br/>wbudowany"]
    Alt["Osobny system zgłoszeń"] -->|"kolejne logowanie, przełączanie narzędzi"| O

    classDef good    fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
    classDef bad     fill:#faeaea,stroke:none,color:#5f2626,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class O good
    class T accent
    class Alt bad
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

• Zadanie tworzone z zamówienia. Zadanie powstaje tam, gdzie jest problem, i od razu ma dane zamówienia. Nie trzeba ich przepisywać.
• Osobne widoki dla managera i pracownika. Manager rozdziela pracę i ma grupę „nieprzypisane” na górze. Pracownik widzi swoje zadania pogrupowane według workflowów. Filtry i gęsty układ są dla osób, które pracują w tym systemie cały dzień.
• Proste MVP z polami w opisie. Żeby nie przepalić budżetu na starcie, informacje wymagane w każdym workflow (kwota, numer konta itp.) wklejało się jako tekst w opis zadania. Muszę przyznać, że to nie jest eleganckie rozwiązanie. Na pierwszą wersję wystarczyło. Uznałem, że osobne pola warto dodać dopiero wtedy, kiedy zobaczymy, czego ludzie naprawdę potrzebują.

Odtworzony szkic. Ta sama pula zadań w dwóch widokach, dla managera i dla pracownika (inspiracja: bazy w Notion, tablice w Jirze i Asanie).

Jak to się skończyło

System wdrożyliśmy szybko i zespoły szybko zaczęły z niego korzystać. W pierwszych trzech miesiącach działało ponad 10 workflowów i ~300 zadań miesięcznie. Po raz pierwszy dało się też zmierzyć czas obsługi każdego procesu. Odszedłem przed wdrożeniem palety komend i automatycznego przypisywania, więc piszę tylko o tym, co wdrożyliśmy za mojej obecności.

Co z tego wyniosłem

• Lista zadań to za mało. Moduł stał się przydatny dopiero wtedy, gdy zgłoszenia zaczęły same trafiać do zespołów, bez człowieka, który je rozdziela.
• Zgłaszanie nie powinno wymagać znajomości ludzi. Pytanie „co się stało?” działa przy każdej liczbie zgłoszeń. Pytanie „do kogo mam napisać?” przestaje działać bardzo szybko.
• Narzędzie warto budować tam, gdzie ludzie już pracują. Według mnie wewnętrzne narzędzie, które wymaga przełączania się do innego systemu, z czasem przestaje być używane.
• Pierwsza wersja może być prosta. Pola wklejane jako tekst wystarczyły, żeby zobaczyć, czego ludzie naprawdę potrzebują, a dopiero potem budować więcej.