Softwarová řešení soustředěná do cloudových prostředí a obzvlášť řešení typu SaaS (Software as a Service) si už svou podstatou sami říkají o minimalizaci zásahů zákaznické podpory. Zjednodušeně řečeno, ultimátním cílem každého poskytovatele takových řešení by měla být jejich kvalita, spolehlivost a transparentnost operovaného řešení na takové úrovni, aby požadavky uživatelů na zákaznickou podporu vůbec neměly šanci vzniknout. A když už přijmeme možnost, že se s požadavky koncových uživatelů na zákaznickou či technickou podporu můžeme setkat, budeme se patrně v této souvislosti chtít bavit nejčastěji o nástrojích jako knowledge base, diskusní fórum nebo komunitní support.
Co však v případě, že provozujeme řešení tzv. enterprise cloudu. Tedy cloudová řešení předurčená pro náročné zákazníky, kterým komfort zákaznické a technické podpory chceme nadále nabídnout, možná i prodat v rámci zakázky jako speciální benefit.
Přeskočme teď debatu o tom, co vlastně je servisní smlouva v případně cloudových řešení. Bylo by to jistě téma na další článek rozebrat výhody či nevýhody různých podob smluv se zákazníky, kde a případě i jakou formou chceme či nechceme definovat způsob poskytování zákaznické podpory koncovým uživatelům. Jako příklad nás v souvislosti s cloudovým prostředím může napadnout obsáhlý dokument typu EULA či Terms and Conditions. Ten na nás poskytovatel služby vrhne zpravidla okamžitě po registraci a jen málo z nás uživatelů dokáže na toto první čtení před jeho vynuceným potvrzením v tomto dokumentu rozklíčovat přesné parametry nabízené podpory a tím se i rozhodnout, zda s ní souhlasíme či nikoli. Předpokládejme nyní tedy, že postupujeme standardněji, a i o SaaS řešení zákazníkovi poskytujeme plnohodnotný servisní kontrakt k zhodnocení a podpisu.
Narozdíl od standardních "on-premise" instalací přebíráte jako provozovatel SaaS řešení odpovědnost nejen za produkt a jeho kvalitu, ale i za kvalitu a spolehlivost prostředí, ve kterém řešení operujete. Očekává se tedy naprosto přirozeně, máte-li pod kontrolou kvalitu produktu i prostředí, kde produkt je produktu operován, že i o tento stupeň dojde k zefektivnění (rozumějte ke zrychlení) řešení případného požadavku na zákaznickou podporu, a to především technického charakteru (opravu chyb či konfigurace). Existují-li definovaná KPI, která podchycují rychlost řešení support cases definovaná pro on-premise produkty, požadavkem provozovatele cloudové či SaaS služby by mělo být mít tato KPI například poloviční, nebo i kratší.
Zároveň prosím nezapomínejme, že se o takových KPI bavíme především interně, jako o cílech pro fungování vnitrofiremní mezitýmové komunikace. Ani cloudová realita zatím nepřinesla výraznou změnu v definici SLAs pro uživatelskou či technickou podporu do zákaznických smluv navenek. Tak jako tradiční výrobce on-premise softwaru se také málokterý provozovatel SaaS řešení i nadále chce zavazovat v zákaznických smlouvách (tím méně ve veřejně dostupných všeobecných podmínkách služby) k nějakým dalším konkrétnějším support SLAs mimo standardní rychlosti odpovědi na zákaznický požadavek, což zpravidla support organizace má pod svým přímým vlivem.
Vnímání uživatele cloudové služby, co se týče nabízeného supportu takto detailně procesní samozřejmě není. Když už má takový uživatel nějaký support k dispozici, a poskytovatel mu ho například v rámci smluvního vztahu nabízí a zpřístupňuje, je očekávání koncového uživatele zaměřené zpravidla primárně na rychlost reakce a sekundárně na kvalitu řešení vzniklého problému. Neohlíží se samozřejmě na to, kam všude bylo třeba jeho požadavek uvnitř firmy či organizace eskalovat, nebo které instalační či konfigurační aktivity bylo nutné provést. Veškeré výše popsané parametry měření a hodnocení support procesu by ale tyto dva aspekty měly maximálně podpořit. Je totiž naprosto přirozené, že tak jako je zkracování doby adopce cloudové služby vnímáno jako největší benefit oproti on-premise softwaru, je tomu tak i co se týče její technické a uživatelské podpory. Cloudová doba je dobou zkracování.