1. Co má reklamační proces u zakázkového softwaru řešit
U softwaru vyvíjeného na zakázku není reklamace totéž co běžná technická podpora. Reklamace by měla řešit nesoulad mezi dodaným řešením a odsouhlaseným zadáním, zatímco support pokrývá provozní dotazy, změny a incidenty způsobené užíváním nebo prostředím klienta. Pokud tyto oblasti nesepíšete přesně, velmi rychle vznikne spor o to, zda je chyba „v záruce“, nebo je to už placený zásah.
V praxi doporučuji rozdělit požadavky minimálně do čtyř kategorií:
- Reklamace vady – funkcionalita neodpovídá smlouvě, zadání nebo akceptačním kritériím.
- Incident – systém je nedostupný, padá, vrací chyby nebo je v konfliktu s prostředím.
- Uživatelský dotaz – klient potřebuje vysvětlení práce s funkcí.
- Change request – klient chce novou funkcionalitu nebo úpravu chování.
Toto rozlišení je zásadní i finančně. U většiny B2B zakázek bývá dobré mít v SLA definované, že reklamace se řeší bezplatně po dobu záruky, zatímco změnové požadavky a provozní podpora běží z hodinové sazby nebo z paušálu. Bez tohoto rámce se snadno dostanete do situace, kdy tým pálí desítky hodin na nejasných požadavcích, které klient považuje za „opravu v rámci dodávky“.
2. Reklamaci musí definovat smlouva, ne dojem
Největší chybou je spoléhat na to, že „to nějak vyřešíme po e-mailu“. U zakázkového vývoje musí být reklamační proces součástí smlouvy o dílo, případně obchodních podmínek a přílohy se SLA. V ideálním případě má smlouva přesně definovat, co je vadou, jak se hlásí, kdo ji posuzuje, v jaké lhůtě se reaguje a co je výstupem řešení.
Praktická struktura smluvního nastavení může vypadat takto:
- Definice vady – například „funkce neplní akceptační kritéria uvedená v zadání“.
- Způsob nahlášení – ticketingový systém, e-mail na support, formulář v klientské zóně.
- Lhůta pro první reakci – například 4 pracovní hodiny pro kritické chyby, 1 pracovní den pro běžné.
- Lhůta pro posouzení – typicky 2 až 5 pracovních dnů podle složitosti.
- Režim odstranění vady – oprava, workaround, plánovaná release, nebo odmítnutí reklamace s odůvodněním.
- Výluky – zásah třetí strany, změna API, nekompatibilní prostředí, neoprávněné zásahy do kódu nebo konfigurace.
Velmi důležitá je také akceptace díla. Pokud klient převezme software bez připomínek, je mnohem snazší rozlišit, co byla skutečná vada při dodání a co vzniklo až později. U větších projektů se osvědčuje předávací protokol s testovacími scénáři a seznamem otevřených bodů. Převzetí bez této dokumentace je v praxi častý zdroj sporů.
Pro inspiraci lze využít i jednoduché pravidlo: všechno, co je měřitelné v akceptačních kritériích, je reklamovatelné; všechno, co v nich není, je změna nebo nová zakázka. Tím se proces výrazně zpřehlední.
3. Jak nastavit workflow, aby reklamace nezůstávaly v e-mailech
Reklamační proces selhává nejčastěji ne na smlouvě, ale na operativě. Požadavek přijatý do e-mailu se ztratí, někdo si myslí, že už to řeší vývojář, a klient mezitím eskaluje nespokojenost. Proto je zásadní mít jeden oficiální kanál a jasný workflow.
Nejlépe funguje ticketingový systém jako Jira Service Management, Zendesk, Freshdesk, Linear nebo Help Scout. U menších týmů může stačit i sdílený formulář a tabulka, ale i tam musí být každá reklamace evidovaná jako samostatný ticket s číslem, stavem a vlastní historií.
Doporučený workflow:
- Přijetí reklamace – systém automaticky potvrdí přijetí a přiřadí číslo ticketu.
- Triage – support nebo analytik ověří, zda jde o reklamaci, incident, nebo změnový požadavek.
- Reprodukce – tým se pokusí chybu nasimulovat v testovacím prostředí.
- Klasifikace závažnosti – kritická, vysoká, střední, nízká.
- Rozhodnutí – uznaná reklamace, zamítnutá reklamace, nebo požadavek na změnu.
- Implementace a nasazení opravy – ideálně včetně testu regresí.
- Uzavření ticketu – potvrzení klientem nebo automatické uzavření po době bez reakce.
Dobrou praxí je mít předem nastavené priority a SLA. Například kritická chyba v produkci, která blokuje objednávky, má reakční dobu do 2 hodin a řešení do 24 hodin. Naopak kosmetická odchylka v administraci může mít reakci do 2 pracovních dnů. Čísla se liší podle byznysu, ale princip je stejný: čím větší dopad na příjem nebo provoz, tím rychlejší reakce.
Pro řízení práce je vhodné doplnit ticketing o nástroje jako Slack nebo Microsoft Teams pro interní eskalace, GitHub/GitLab pro vazbu na commit a release a Datadog, Sentry nebo New Relic pro technické logy a monitoring. U reklamací je velmi užitečné, když každý incident má dohledatelnou stopu od hlášení přes opravu až po nasazení.
4. Jak reklamaci posuzovat férově a bez emocí
Posouzení reklamace má být technické a dokumentované, ne pocitové. Nestačí napsat „u nás to funguje“ nebo „klient to špatně používá“. Každé rozhodnutí by mělo vycházet z podkladů: zadání, uživatelských scénářů, logů, screenshotů, videozáznamu, verze aplikace a prostředí, ve kterém se problém objevil.
V praxi se osvědčuje mít checklist pro posouzení:
- Je chyba reprodukovatelná?
- Odpovídá chování zadání, nebo je zadání nejednoznačné?
- Došlo ke změně prostředí, API, prohlížeče nebo infrastruktury?
- Je problém v kódu, konfiguraci, datech, nebo v integraci třetí strany?
- Byl proveden zásah do systému mimo autorizovaný proces?
Pro snížení sporů je vhodné mít u větších projektů i reklamační protokol s těmito poli: datum nahlášení, popis vady, dopad na provoz, důkazní materiál, vyjádření dodavatele, rozhodnutí, termín nápravy a potvrzení uzavření. Tato dokumentace je cenná nejen právně, ale i pro interní zlepšování.
Pokud se reklamace opakují na stejné oblasti, znamená to často problém v analytice nebo testování. Například když se během tří měsíců vrací 12 podobných ticketů k jedné části formuláře, je to signál, že selhává návrh UX, validace nebo test coverage. U zakázkového softwaru se vyplatí sledovat metriky jako počet reklamací na release, průměrný čas do prvního vyjádření, průměrný čas do uzavření a podíl uznaných reklamací. Už při 20–30 ticketech měsíčně se bez těchto čísel proces řídí velmi těžko.
5. Co si pohlídat po uzavření reklamace
Uzavření ticketu by nemělo být konec práce, ale začátek prevence. Každá uznaná reklamace by měla projít krátkou retrospektivou: proč vznikla, proč ji neodhalilo testování a co změnit, aby se neopakovala. U větších týmů se osvědčuje měsíční review reklamací, kde se vyhodnotí trend a navrhnou konkrétní opatření.
Nejčastější preventivní kroky bývají:
- úprava akceptačních kritérií a zadávací dokumentace,
- doplnění automatizovaných testů v Playwrightu, Cypressi nebo PHPUnit,
- zavedení povinného code review pro rizikové části aplikace,
- monitoring chyb přes Sentry a alerting do Slacku,
- upřesnění provozního prostředí a verzí komponent.
U klientů s vyšším provozem se vyplatí i jednoduchý knowledge base nebo interní FAQ. Část „reklamací“ je totiž ve skutečnosti opakovaný dotaz na chování systému. Když má klient k dispozici návod, video nebo krátké vysvětlení, počet zbytečných ticketů může klesnout klidně o 15 až 25 % během několika týdnů.
Správně nastavený reklamační proces tedy není jen právní ochrana. Je to provozní mechanismus, který zlepšuje kvalitu dodávek, zrychluje komunikaci a dává oběma stranám jasná pravidla. Čím přesněji definujete hranici mezi vadou, incidentem a změnou, tím méně času strávíte hádkami a tím více ho zůstane na skutečné zlepšování produktu.