Zavedení zákaznické podpory v B2B integrační firmě

O klientovi

Výchozí situace

Klient dodával svým zákazníkům specializovaná integrační řešení, která po úspěšné implementaci přecházela do dlouhodobé aplikační podpory. Podpora probíhala ve stejné firmě, ale neproběhl potřebný posun v přístupu — podpora běžela v podobném režimu jako konstrukce, často se stejným nebo překrývajícím se týmem. Neproběhl žádný formální handover, žádné „uzavřené” předání mezi fázemi projektu, žádná dedikovaná organizační jednotka, která by držela podporu jako plnohodnotnou disciplínu.

Na papíře to vypadalo, že podpora funguje — zákazníci volali na dedikovaný kontakt, psali na mail nebo zakládali tikety přes svoje service desky. V realitě ale chyběl proces za tím. Nebylo formální kapacitní plánování, priority se řídily intuitivně, kontrakty s jednotlivými zákazníky byly roztříštěné. Překročení SLA se stávala pravidelně a přinášela sankce, které dále zhoršovaly finanční výsledek divize.

Vedení si uvědomilo, že si firma připravuje problém, který poroste s počtem klientů. Při stávající trajektorii by sankce dál narůstaly a každé nové výběrové řízení by bylo nejen o ceně, ale i o tom, jaké kompenzace budou při porušení SLA.

Jaký byl problém

• Chyběl handover/takeover proces mezi konstrukčními a podpůrnými fázemi projektu
• Nebyla dedikovaná role support managera ani jeho výstupy
• Kapacitní plánování podpory se neřídilo sebranými daty, ale intuicí vedoucích
• Prioritizace tiketů byla „kdo je nejhlasitější”
• Kontrakty o aplikační podpoře se lišily zákazník od zákazníka bez zjevného důvodu
• Katalog služeb podpory nebyl jednotný — jeden zákazník dostal službu A, druhý podobně nazvanou službu B s odlišnou definicí
• Reporting směrem k vedení vycházel z metrik vývoje, ne z provozních ukazatelů podpory
• Sankce za porušení SLA narůstaly a stávaly se finančně významné

Co jsem udělal

Spolupráce trvala 2–3 měsíce od analýzy po ustálený provoz a obsahovala několik souběžných pracovních proudů.

Analýza procesu a rolí

Prošel jsem skutečný průběh zakázek z obou stran — konstrukční i podpůrné. Rozhovory s vedoucími konstrukce a podpory, operátory, account managery a klíčovými lidmi, kteří nosili celou disciplínu v hlavě.

Z analýzy vzešly tři klíčová zjištění:

• Firma nerozlišovala mezi projektovým režimem a režimem podpory — přestože to jsou fundamentálně jiné provozní disciplíny s jinými metrikami, jinou kulturou a jinou organizací práce.
• Role support managera formálně existovala, ale neměla definované výstupy ani mandát.
• Kontraktová základna byla výsledkem historického vývoje, ne vědomého návrhu — každý zákazník měl jiný support SLA a jiný katalog služeb.

Nastavení handover/takeover procesu

Navrhl jsem formální předávací proces mezi konstrukcí a podporou s jasnými kontrolními body:

• Checklist technické připravenosti — dokumentace, runbooky, známé incidenty, závislosti
• Předávací prezentace — konstrukční tým představí řešení podpůrnému týmu
• Validace a kontrola — podpůrný tým potvrdí, že má vše potřebné k převzetí
• Formální předání — zápis s podpisem obou stran, datum ostrého přechodu
• Post-handover podpora — konstrukce má tikety z prvních 30 dní ještě v eskalaci

Narovnání kontraktů a katalogu služeb

Prošel jsem všechny platné kontrakty o aplikační podpoře a vytvořil:

• Jednotný katalog služeb podpory — pět typů služeb s jasnou definicí rozsahu, reakční doby a procesu
• Standardizované SLA úrovně (Bronze / Silver / Gold / Platinum)
• Plán revize kontraktů — při příští obnově každého zákazníka narovnat na nový rámec
• Přechodová pravidla — jak zákazníky přenést ze starého modelu na nový bez eskalace

Dedikace support managera a jeho výstupů

Support manager dostal definovanou roli s konkrétními odpovědnostmi:

• Kapacitní plánování a alokaci týmů
• Prioritizaci backlogu
• Reporting směrem k vedení (nové metriky — viz níže)
• Komunikaci s account managery a eskalacemi
• Správu systému servisních zpráv vůči zákazníkům

Nové metriky a KPI pro reporting vedení

Reporting směrem k vedení jsem kompletně přepracoval. Místo metrik z vývoje jsme zavedli provozní ukazatele:

• SLA plnění podle úrovně a zákazníka
• Volume tiketů (nově otevřených, vyřešených, čekajících)
• Typologie tiketů (bug / change / konzultace / incident)
• Míru vyřešení bez eskalace a míru eskalací
• Finanční metriky — náklady podpory, sankce, upsell příležitosti

Co klient dostal

• Dokument „Jak u nás funguje podpora” — proces, role, SLA, handover, eskalace
• Jednotný katalog služeb podpory s definicí rozsahu a SLA úrovní
• Handover/takeover checklist a procesní dokumentaci
• Popis role support managera s odpovědnostmi a výstupy
• Šablony reportingu pro vedení s novými provozními metrikami
• Systém servisních zpráv vůči zákazníkům — struktura, četnost, zodpovědnosti
• Plán revize kontraktů s přechodovými pravidly
• Průběžný koučink vedoucího podpory a support managera v průběhu implementace

Jaký to mělo přínos

Sankce za překročení SLA klesly na nulu do konce kvartálu po zavedení. Během 2–3 měsíců od startu klesla míra překročení SLA limitů o 90 %. Jakmile podpora začala fungovat jako samostatná disciplína, otevřely se navazující možnosti.

Upsell u stávajících klientů — support manager s přehledem o tiketech dokázal identifikovat příležitosti pro změnové požadavky a rozšíření řešení. Proaktivní zásahy — sledování trendů v incidentech umožnilo předcházet výpadkům místo jejich opravy. Release management — plánované nasazování změn v koordinaci se zákazníkem místo ad hoc oprav. Lepší distribuce práce — mezi podporou a konstrukčními týmy přestalo docházet k nechtěnému překrývání.

Firma získala funkční podpůrnou divizi s vlastním procesem a metrikami. Vedení mělo poprvé data, podle kterých mohlo podporu řídit — kapacitně i obchodně.

Poznámka z praxe

Nejtěžší částí této spolupráce nebyla technická stránka, ale posun kultury a paradigmatu. V B2B integračních firmách jsou konstrukční týmy často považovány za „hlavní” — vytvářejí hodnotu, dodávají. Podpora je vnímána jako „druhořadá disciplína”, která se má smluvně doplnit. Tato perspektiva se projevuje v rolích, kariérním růstu, odměňování i mentální mapě vedení. Pokud tuto kulturní vrstvu nezměníme, technické změny procesu samy o sobě neudrží. Proto byla značná část mé práce v té spolupráci o komunikaci se support managerem, vedoucími konstrukce a vedením firmy — aby support začal být vnímán jako plnohodnotná disciplína, nejen jako „servis po dodávce”.

O kterou službu šlo

Spolupráce byla klasickým případem mostu mezi byznysem a IT — nastavení organizace, procesů, kontraktové stránky a komunikace tak, aby podpora fungovala jako plnohodnotná disciplína a ne jako pokračování konstrukční fáze.