Przejdź do treści

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

TL;DR

Diagnoza

Odziedziczony koncept już miał „zadania”. Czego mu brakowało, to część, która się liczyła: routing. Osoba zgłaszająca zgubioną paczkę nie wie — i nie musi wiedzieć — który team lub człowiek się tym zajmie; musi tylko powiedzieć, co jest nie tak. Bezpośrednia komunikacja skaluje się źle: piszesz do ludzi po kolei, aż ktoś to zgarnie, a czas, który to pożera, rośnie wykładniczo. Wygraną więc nie była bardziej ozdobna lista zadań — tylko warstwa workflow, która pozwalała skierować problem po typie i pozwalała właściwemu teamowi go podjąć. I siedziała wewnątrz platformy, gdzie zamówienie już było, więc nikt nie musiał przełączać narzędzi.

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 to zgarnia"]
    end
    subgraph Po["Po"]
        B1["Zgłoszenie: typ problemu"] --> B2["Automatyczny routing do teamu"]
        B2 --> B3["Właściwy team podejmuje 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:transparent,stroke:#a1a1aa,stroke-width:1px,rx:14,ry:14
    style Po fill:transparent,stroke:#a1a1aa,stroke-width:1px,rx:14,ry:14
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

Co zrobiłem

Wyniki

#WorkflowStatus
1Zgubiona paczkana żywo
2Korekta fakturyna żywo
3Refundna żywo
4Status wysyłkina żywo
5–10+inne typy zgłoszeńna żywo

Problem

Dlaczego wewnętrzne zgłoszenia były tak wolne?

Biznes oparty na customowych zamówieniach działa jak łańcuch — specyfikacja, wycena, produkcja, wysyłka, rozliczenia — a każde ogniwo może pęknąć. Gdy coś szło nie tak (zgubiona paczka, błędna faktura), osoba, która to zauważyła — często obsługa klienta — musiała pisać do kolegów po kolei, aż ktoś to podjął. Nie wiedziała, kto się tym zajmie; nie było systemu. Taka bezpośrednia komunikacja nie skaluje się — pożerany czas rośnie wykładniczo, a widoczności w to, co otwarte i kto nad tym pracuje, jest zero.

Dlaczego po prostu nie kupić systemu zgłoszeń?

Bo praca już żyje w platformie do obsługi zamówień. Wysyłanie ludzi do osobnego narzędzia to przełączanie kontekstu — kolejny login, kolejne miejsce do sprawdzenia, kolejna rzecz, która rozjeżdża się w synchronizacji. System musiał być minimalistyczny i żyć tam, gdzie było zamówienie.

Moja rola / zakres

Proces

Kluczowe decyzje i trade-offy

flowchart LR
    O["Widok zamówienia<br/>istniejąca platforma"] --> T["System zadań + routing<br/>wbudowany"]
    Alt["Osobny system zgłoszeń"] -->|"kolejny login, przełączanie kontekstu"| 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

Jak to się skończyło

System wdrożono szybko i szybko zdobył adopcję — ~10+ workflowów i ~300 zadań/mies. w pierwszych trzech miesiącach — i odblokował monitorowanie czasu obsługi per proces, czego bezpośrednia komunikacja nigdy nie mogła. Najjaśniejszy sygnał od teamów: otwarte sprawy było łatwo monitorować, a delegacja przy nieplanowanych nieobecnościach (zwolnienie lekarskie) stała się trywialna, bo zadanie kierowane po typie nie było już zakładnikiem czyjejś skrzynki. Odszedłem przed planowaną paletą komend i auto-przypisaniem — więc mówię o wdrożonym core i jego adopcji, nie o featurach, które przyszły potem.

Co z tego wyniosłem