Většina malých firem nepotřebuje fronty, směny a satisfaction skóre. Potřebuje, aby požadavek nezapadl. Čtyři kategorie nástrojů, co v každé dostanete, kde narazí a od kolika požadavků se ticketing vyplatí.
Požadavek přišel v pátek odpoledne na obecnou adresu. Odpověděl na něj kolega, který měl zrovna volno mezi schůzkami, a o hodinu později odpověděl ještě jeden, jinak. V pondělí se zákazník ptá, co tedy platí, a ve firmě nikdo neví, kdo to má na starosti. Tohle je problém, který malé firmy skutečně mají - ne chybějící fronty, směny a měření spokojenosti.
Zendesk řeší jiný problém, než máte
Velké helpdesk nástroje vznikly pro týmy, kde podporu dělá deset a víc lidí na směny, tickety se musí rozdělovat podle jazyka a produktu a vedoucí potřebuje týdně vidět, kdo kolik zvládl. Tomu odpovídá i cena a náročnost nastavení. Firma, kde na požadavky odpovídají dva lidé mezi ostatní prací, řeší něco jiného: aby se na nic nezapomnělo a aby si ten druhý dohledal, co už bylo řečeno.
První otázka proto nezní „který helpdesk", ale „kolik požadavků nám měsíčně přijde a kolik lidí na ně odpovídá". Podle těch dvou čísel vypadne kategorie sama a výběr konkrétního nástroje je až druhý krok. Jak se z e-mailové schránky stane provozní systém a proč to firmy odkládají, rozebírá text o obchodu v e-mailech a tabulkách.
Z e-mailu se stane záznam, který má stav a majitele
Zpráva na obecnou adresu založí požadavek, přiřadí ho člověku a naváže na zákazníka. Vlákno nezmizí, jen přestane být jediným místem, kde požadavek žije.
Spočítejte si dvě čísla, než otevřete první ceník
Hranice, kdy se ticketing vyplatí, se dá popsat docela přesně, a objem je jen jedna její část.
Do zhruba 40 požadavků měsíčně a jeden až dva lidé, kteří odpovídají. Sdílená schránka stačí. Nastavení ticketingu vás bude stát víc času, než kolik ušetří, a lidé se stejně vrátí do Outlooku.
Zhruba 40 až 150 požadavků měsíčně a dva až čtyři lidé. Tady se rozhoduje. Objem sám o sobě ještě ticketing nevyžaduje, rozhoduje jiné číslo: kolikrát za měsíc někdo urguje, protože se mu nikdo neozval. Když se to stane víc než dvakrát, schránka už neplní svou roli.
Nad 150 požadavků měsíčně, nebo tři a víc lidí ve směnách, nebo reakční doba ve smlouvě. Klasický ticketing se vyplatí, protože potřebujete stavy, eskalaci a čísla, která doložíte zákazníkovi.
Třetí číslo rozhoduje o kategorii víc než objem: kolik procent požadavků nevyřešíte, aniž byste se podívali jinam - do zakázky, do dodacího listu, do faktury, do historie servisu. Pokud je to víc než třetina, důležitější než fronty a makra je kontext. A ten samostatný helpdesk nemá, protože vaše zakázky nezná.
Sdílená schránka drží déle, než se čeká, a pak spadne najednou
Nejlevnější start je sdílená schránka v Google Workspace nebo Microsoftu 365. Nástroje jako Front, Hiver nebo Missive k ní přidají přiřazení konkrétnímu člověku, interní poznámky mimo zákazníka, štítky a šablony odpovědí. Nikdo se nic neučí, protože pořád píše e-mail.
Kde narazí: chybí stav mezi „přečteno" a „vyřízeno". Požadavek, který čeká na dodavatele nebo na doplnění od zákazníka, nemá kde ležet, takže leží v hlavě toho, kdo ho vzal. Druhá věc je měření - po roce neřeknete, kolik požadavků přišlo, jak dlouho trvala první odpověď ani kterých pět problémů se opakuje. Složka „Vyřízeno" není evidence, protože se nedá filtrovat podle typu problému ani spočítat. A třetí věc je předání: když člověk odejde nebo onemocní, kontext odchází s ním.
Komu sedí: firmám pod uvedenou hranicí, bez smluvní reakční doby, kde požadavky chodí jedním kanálem.
Klasický ticketing dá fronty a čísla, chce ale správce
Sem patří Zendesk, Freshdesk, Zoho Desk, Help Scout, z tuzemských LiveAgent nebo Daktela s napojením na telefonii. Dostanete frontu s jasným vlastníkem a stavem, SLA s automatickou eskalací, makra a šablony, znalostní bázi, zákaznický portál a statistiky, které jdou poslat klientovi jako přílohu ke smlouvě. Sloučení duplicit, měření spokojenosti po vyřešení nebo chat a telefon jako další kanál jsou hotové, ne k dodělání.
Kde narazí: účtuje se za agenta a měsíc, což tlačí firmu k tomu, aby dovnitř pustila jen podporu. Jenže na požadavek často potřebuje odpovědět technik nebo obchodník, který tam licenci nemá - a kontext se vrátí do e-mailu, tentokrát mimo systém. Druhá věc je zavedení: fronty, stavy, SLA a automatiky jsou projekt na dny, u tříčlenné firmy se ta investice nevrátí. A třetí je izolace. Ticket zná zákazníka a jeho tickety, ale nezná vaši zakázku, termín dodání ani fakturu, takže propojení řešíte konektorem nebo přepínáním oken. Co to dělá s komunikací, když kanálů přibude, popisuje článek o komunikaci se zákazníky napříč kanály.
Komu sedí: firmám, kde je podpora samostatná funkce s vlastními lidmi, směnami a smluvní reakční dobou.
Helpdesk v CRM vymění hloubku za kontext zákazníka
Třetí kategorie je modul uvnitř CRM - HubSpot Service Hub, Zoho Desk v rámci Zoho, Salesforce Service Cloud, u menších nástrojů to bývá záložka „požadavky" nebo „servis". Ticket sedí vedle karty zákazníka, takže při odpovědi vidíte obchodní historii, poslední nabídku i to, kdo ho má na starosti. Jedno přihlášení, jedna smlouva, jeden reporting nad obchodem i podporou.
Kde narazí: hloubkou. Fronty, směny, makra a měření spokojenosti bývají chudší než u specializovaného nástroje, a když je opravdu potřebujete, dřív nebo později stejně přijde druhý systém. Druhá potíž je datový model - modul obvykle váže požadavek na kontakt a firmu, ale ne na zařízení, pobočku nebo konkrétní dodávku, takže se to opisuje do textového pole. A třetí je cena: helpdesk bývá ve vyšším tarifu nebo jako doplněk, takže zdraží celé CRM, ne jen podporu.
Komu sedí: firmám, kde požadavky chodí od zákazníků, které už v CRM máte, a kde obchod i podporu dělají stejní lidé.
Vlastní databáze požadavků: model si určíte, prázdný start zaplatíte
Čtvrtá možnost není hotová aplikace, ale platforma, ve které si evidenci postavíte - Airtable, Notion, z českých Tabidoo nebo Apexloop. Určíte si, co je požadavek a na co se váže: zákazník, zařízení, zakázka, faktura. Stavy pojmenujete svými slovy, ne slovníkem dodavatele. Pohledy typu „moje otevřené", „čeká na zákazníka" nebo „po reakční době" jsou uložený filtr, ne funkce navíc. Formulář na webu zakládá záznam rovnou a automatizace pošle potvrzení, přiřadí podle typu a eskaluje, když se blíží konec reakční doby - princip je stejný jako u hlídání termínů obecně. Jak takový helpdesk postavit krok za krokem, ukazuje článek Helpdesk bez zvláštního softwaru.
Kde narazí: prázdným startem. Hotový nástroj má čtyři rozumné stavy v ceně, tady je někdo musí vymyslet - a osm stavů, které nikdo nepoužívá, je horší než čtyři výchozí. Věci, které specializovaný nástroj má hotové, si buď dodělíte, nebo oželíte: sloučení duplicitních požadavků, dotazník spokojenosti po vyřešení, plnohodnotný portál se znalostní bází, telefon jako plnohodnotný kanál. A model musí někdo vlastnit, jinak si za půl roku každý založí vlastní pohled.
Komu sedí: firmám, kde požadavek nevisí na abstraktním ticketu, ale na zařízení, zakázce nebo dodávce - typicky servis, montáž, výroba. Jak to vypadá u výjezdů a protokolů, rozebírá CRM pro servisní a montážní firmu.
Čtyři kategorie vedle sebe
| Kategorie | Co dostanete | Kde narazí |
|---|---|---|
| Sdílená schránka (Google, Microsoft, Front, Hiver) | Nulové zaškolení, přiřazení a interní poznámky, historie jako e-mailové vlákno | Chybí stav mezi přečteno a vyřízeno, nejde měřit ani předat, po roce nevíte, co se opakuje |
| Klasický ticketing (Zendesk, Freshdesk, Zoho Desk, LiveAgent, Daktela) | Fronty, SLA s eskalací, makra, znalostní báze, portál, statistiky, víc kanálů | Cena za agenta drží lidi mimo systém, zavedení je projekt na dny, nezná vaše zakázky a faktury |
| Helpdesk v CRM (HubSpot, Zoho, Salesforce) | Ticket u karty zákazníka, obchodní historie při odpovědi, jedno přihlášení a jeden reporting | Mělčí fronty a měření, požadavek se váže na kontakt, ne na zařízení nebo dodávku, vyšší tarif celého CRM |
| Vlastní databáze požadavků (Airtable, Notion, Tabidoo, Apexloop) | Vlastní entity a vazby, vlastní stavy a pohledy, formulář a automatizace, požadavek vedle zakázky | Prázdný start, chybí hotové duplicity, dotazník spokojenosti a portál, model musí někdo vlastnit |
Než začnete vybírat, měsíc počítejte
Do jednoduché tabulky si měsíc zapisujte tři věci: kolik požadavků přišlo, u kolika z nich jste se museli podívat do jiného systému a kolikrát někdo urgoval. Tři čísla po jednom měsíci rozhodnou o kategorii líp než tři dema.
Co všechno musí helpdesk nad vlastní databází umět, aby nebyl jen seznamem, shrnuje stránka Helpdesk a podpora. Než podepíšete u specializovaného nástroje, projděte si, jak se z něj dostávají data ven i s vazbami na zákazníky - to je téma článku o vendor lock-inu ve firemním softwaru. A jestli vás při srovnání zajímá hlavně cena, orientaci v tuzemských cenících dává přehled cen.
Časté otázky k helpdesk systémům
Jaký helpdesk je nejlepší pro malou firmu?
Žádná kategorie nevyhrává univerzálně. Do zhruba 40 požadavků měsíčně a dvou lidí stačí sdílená schránka, nad 150 požadavků nebo při smluvní reakční době se vyplatí klasický ticketing. Mezi tím rozhoduje, jestli požadavek potřebuje kontext ze zakázek a faktur.
Od kolika požadavků měsíčně se vyplatí ticketing?
Prakticky od chvíle, kdy na požadavky odpovídají tři a víc lidí, nebo když jich měsíčně přijde přes sto padesát. Pod touhle hranicí bývá dražší položkou zavedení a údržba než samotné licence.
Stačí na helpdesk sdílená e-mailová schránka?
Stačí, dokud vám jde jen o to, aby všichni viděli všechno. Přestane stačit ve chvíli, kdy potřebujete stav „čeká na zákazníka", doložit reakční dobu nebo po roce zjistit, které problémy se opakují.
Kolik stojí helpdesk software?
Specializované nástroje se účtují za agenta a měsíc, takže cena roste s počtem lidí, kteří do systému musí, ne s počtem požadavků. U helpdesku postaveného nad vlastní databází platíte za uživatele platformy a přidání dalšího typu evidence už cenu nemění.