Servisní smlouva má přesně uvádět spravované weby, zahrnuté činnosti, výluky, priority incidentů, měření reakce, schvalování změn, reporty, vlastnictví účtů a úplný postup předání při ukončení.
Servisní smlouva pro WordPress mění obecný příslib péče na konkrétní rozsah, odpovědnosti a komunikační pravidla. Majitel webu potřebuje vědět, které aktualizace, zálohy, testy, monitoring a zásahy jsou zahrnuty, kdo schvaluje změnu a jak se řeší incident mimo pracovní dobu. Dodavatel zase potřebuje hranice, aby urgentní podpora nebyla zaměňována s neomezeným vývojem nových funkcí.
SLA, tedy dohoda o úrovni služeb, má používat měřitelné pojmy a rozlišovat potvrzení požadavku, zahájení práce, dočasné obnovení a úplné vyřešení. Konkrétní časy a sankce nelze určit univerzálně; závisí na významu webu, dostupnosti týmu a ceně služby. Smluvní a právní znění by měl prověřit kvalifikovaný odborník, zatímco tento článek pomáhá připravit věcný obchodní brief.
Přesný předmět služby a seznam spravovaných aktiv
V příloze nebo inventáři uveďte každou doménu, instalaci WordPressu, produkční a stagingové prostředí, hosting, šablonu, klíčové doplňky a externí integrace. U každé položky označte vlastníka účtu a úroveň odpovědnosti dodavatele. Správa WordPressu nemusí automaticky zahrnovat DNS, poštovní server, reklamní skripty nebo zásahy do CRM, přestože se jejich chyba projeví na webu.
Rozsah rozdělte na preventivní úkony, incidentní podporu, obsahové práce a rozvoj. Uveďte interval aktualizací, způsob testování, kontrolu záloh a obnovy, monitoring a funkční testy. Výluky pojmenujte stejně jasně: licence třetích stran, rozsáhlá oprava po útoku, migrace hostingu nebo nová funkcionalita mohou vyžadovat samostatné schválení. Nejasná formulace „kompletní správa“ vytváří na obou stranách odlišná očekávání.
Priority incidentů a smysluplné SLA
Definujte úrovně podle dopadu na uživatele a na byznys. Kritický incident může znamenat nedostupný web, podezření na aktivní napadení nebo nefunkční hlavní prodejní proces; nižší prioritou může být kosmetická chyba, která neblokuje úkol. Ke každé úrovni doplňte příklady, kanál pro nahlášení a osobu oprávněnou prioritu potvrdit. Samotné slovo urgentní bez definice při rozhodování nepomáhá.
SLA musí uvádět provozní hodiny, začátek měření, reakční dobu a způsob eskalace. Reakce znamená potvrzení a prvotní posouzení, ne nutně úplnou opravu. Doba vyřešení může záviset na výrobci doplňku, hostingu nebo chybějících přístupech. Dohodněte proto i pravidlo pro pravidelné aktualizace stavu a dočasné řešení. Dostupnost mimo pracovní dobu musí být výslovně dohodnuta, personálně zajištěna a zohledněna v obchodních podmínkách.
- priorita odvozená od skutečného dopadu
- samostatně definovaná reakce a vyřešení
- jasné servisní hodiny a eskalace
- pravidelné informování během otevřeného incidentu
Schvalování změn, rozpočtu a licencí
Dohodněte, které nízkorizikové aktualizace může správce provést v rámci paušálu a které zásahy vyžadují písemné schválení. Žádost o schválení má uvádět důvod, rozsah, očekávaný dopad, cenu nebo čerpání dohodnutého balíčku a plán návratu. U bezpečnostní opravy může být čas na rozhodnutí kratší, smlouva však má určit, kdo může jednat, pokud kontaktní osoba není dostupná.
Vlastnictví licencí a způsob jejich obnovy musí být transparentní. Firma má vědět, které licence vlastní přímo, které poskytuje dodavatel po dobu smlouvy a co po jejím ukončení přestane fungovat. Automatické prodloužení, změna ceny či omezení podpory nemají být překvapením. Rozvojové požadavky evidujte odděleně od provozní údržby, aby report a fakturace jasně ukázaly, na co byla kapacita využita.
Komunikační kanál a servisní report
Určete jeden evidovaný kanál pro běžné požadavky a zvláštní způsob nahlášení kritického incidentu. Zpráva má obsahovat URL, čas, pozorované chování, zařízení a dostupný obrazový záznam bez citlivých údajů. Telefonát může spustit reakci, ale výsledek je třeba zapsat do společného systému. Na straně klienta i dodavatele určete hlavní a náhradní kontakt a pravidla, komu lze oznámit bezpečnostní událost.
Pravidelný report má uvádět aktualizace, testy, dostupnost, stav záloh, incidenty, otevřená rizika, spotřebovanou rozvojovou kapacitu a doporučená rozhodnutí. Číslo bez kontextu nestačí: neúspěšná záloha potřebuje dopad a nápravný krok, nikoli jen červenou ikonu. Dohodněte frekvenci a formát reportu a začněte další období kontrolou neuzavřených úkolů. Citlivé logy ani osobní údaje do běžného reportu nekopírujte.
Vlastnictví účtů, přístupy a bezpečnostní odpovědnost
Doménu, hlavní hostingový účet, analytiku a firemní profily má kontrolovat firma, nebo musí mít smluvně i technicky proveditelný převod. Dodavatel používá vlastní identitu s nejnižšími potřebnými oprávněními a vícefaktorovým ověřením. Hesla se neposílají běžným e-mailem ani nevkládají do servisního reportu. Smlouva má určit, kdo schvaluje nový účet, jak se vede evidence přístupů a kdy se stará identita ruší.
Rozdělte odpovědnost za aplikaci, server, DNS, certifikát, zálohy, bezpečnostní upozornění a dodavatele třetích stran. Pokud incident vznikne mimo přímou správu dodavatele, musí být jasné, zda koordinuje komunikaci, nebo pouze poskytne technické podklady. U osobních údajů uveďte role a zpracovatelské vztahy podle odborného právního posouzení. Servisní smlouva nenahrazuje bezpečnostní politiku, ale má s ní být v souladu.
Ukončení smlouvy a kontrolované předání webu
Dohoda má obsahovat výpovědní lhůtu, rozsah součinnosti, formát exportu a pravidla vyúčtování otevřených prací. Předávací balíček obvykle zahrnuje inventář, aktuální kód, databázi a média, dokumentaci nasazení, stav licencí, přesměrování, zálohy, otevřené incidenty a datum posledních testů. Neurčité „předáme vše“ vytváří spor; konkrétní seznam umožní oběma stranám potvrdit splnění.
Nový správce má bezpečně převzít účty a provést test nasazení, formulářů, monitoringu a obnovy. Poté se zruší identity, API klíče a vzdálené přístupy původního dodavatele bez narušení automatizací. Hesla neposílejte v seznamu; použijte bezpečný kanál a následnou rotaci. Uveďte, jak dlouho se u původního dodavatele uchovávají pracovní kopie a kdy se odstraní podle smluvních a odborně posouzených povinností.
- konkrétní předávací balíček a termín
- test převzetí novým správcem
- rotace tajemství a zrušení identit
- dohodnuté odstranění pracovních kopií
Časté dotazy
Jaký je rozdíl mezi dobou reakce a dobou vyřešení?
Reakční doba určuje, do kdy dodavatel požadavek potvrdí a začne jej posuzovat. Úplné vyřešení může záviset na příčině nebo třetí straně, proto vyžaduje samostatnou definici, aktualizace stavu a případné dočasné řešení.
Má servisní smlouva zahrnovat neomezené úpravy webu?
Nemusí. Preventivní údržbu, incidenty, obsahové zásahy a nový vývoj je vhodné oddělit. Smlouva má uvádět zahrnutou kapacitu, způsob schválení práce navíc a komerční dopad bez skrytých očekávání.
Kdo má vlastnit doménu a hostingový účet?
Hlavní kontrolu má mít firma, případně musí existovat jasný a proveditelný převod. Dodavatel má používat vlastní přiměřený přístup, který se při ukončení zruší bez ztráty firemních dat.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
