Zadávání požadavku skrze e-mail klientské podpory
Zadávání požadavku skrze klientskou podporu- strana zákazníka
Klient se proklikne skrze odkaz, který mu přijde e-mailem, na klientský portál, který vypadá následovně:
2. Následně si klient vybere, jaký typ požadavku potřebuje vyřešit (viz níže):
Request types (typy požadavků):
Potřebuji podporu - mám otázku ohledně Targita = Typ požadavku, který se volí pokud klient má problém/ dotaz, na který nenašel odpověď v dokumentaci ani v jiných materiálech (např. specifická podmínka, kterou chce klient přidat do šablony a neví, jak ji nastavit).
Něco mi nefunguje = Typ požadavku, který se volí, když nefunguje konkrétní funkce platformy Targito. Například, když si klient nastaví automatizaci a nechodí mu testovací rozesílka, přestože postupoval podle dokumentace (tzv. bugy = softwarové chyby)
Mám námět na novou funkci = Typ požadavku, který se volí, pokud klient chce přidat novou funkci do platformy Targito. Tento typ požadavku se řeší s IT oddělením, které zhodnotí, zda je požadavek možný splnit a s jakým časovým odhadem. IT oddělení dá též informaci, jestli se jedná o požadavek, který bude zpoplatněn.
3. Po rozkliknutí konkrétního požadavku se zobrazí formulář (viz obrázek níže):
Postoupení tohoto požadavku jménem: Automaticky se vloží, účet klienta, který požadavek zadává.
Předmět: Klient musí zadat předmět požadavku. Předmět by mě maximálně věrně vystihovat povahu požadavku. Např. Podmínka přepisování jména produktů v košíku do šablony v předmětu.
Popis: Následně klient popíše daný problém a kdy a jak nastal. Text požadavku by měl maximálně přesně popisovat danou situaci, např. mělo by být zmíněno, ve kterém originu je problém, dát odkaz na kampaň v Targito, ve které se problém vyskytl, přidat screenshoty, ID produktu, který je nefunkční atd.
Příloha: Je volitelná, ale může pomoci vyřešit daný problém, proto se doporučuje ji vždy vkládat, především u těžko popsatelných problémů (přílohou může být např. screenshot)
Priorita: Pole viditelné pouze u možnosti “Něco mi nefunguje”, zvolte si důležitost/prioritu problému (low, medium, high)
Sdílet s: Pokud je klient přihlášený pod nějakou společností automaticky, tak se jeho požadavek nasdílí dané společnosti
Pokud klient patří pod více společností (např. agentury) pak si vybere, se kterou společností zadaný požadavek nasdílí (tj. za kterou společnost problém hlásí)
4. Po odeslání se požadavek zobrazí v prostředí klientské podpory (viz níže):
V odeslaném požadavku lze vidět (viz obrázek výše):
Stav požadavku
otevřeno
v řešení
hotovo
5. Přehled všech klientem vytvořených požadavků lze najít v pravém horním rohu klientského portálu (viz screenshot níže):
V přehledu požadavků nalezneme:
Referenci (kód daného požadavku)
Souhrn (předmět požadavku)
Stav
Projekt služby
Žadatel (Jméno a Příjmení kontaktní osoba klienta)
Je možné filtrovat již i uzavřené žádosti v případě historického dohledávání požadavků, které třeba již někdy klient řešil a potřebuje se k nim vrátit (screenshot níže):
6. Upozornění - je možné měnit v prostředí klientské podpory, či v e-mailu, který klientovi přijde.
zapnuté - chodí upozornění do e-mailu při každé změně stavu požadavku
vypnuté - nechodí upozornění do e-mailu
zapnutí/vypnutí upozornění v prostředí klientské podpory lze provést kliknutím na ikonku zvonečku (viz obrázek níže).
zapnutí/vypnutí upozornění v e-mailu, který klientovi přijde při přijetí požadavku klientskou podportou, lze kliknutím na možnost “Vypnout oznámení o této žádosti”.
Otevře se okno klientské podpory, která uživatele zadávajícího žádost informuje o vypnutých notifikacích s možností prokliku na danou žádost (viz screenshot níže):
Typ žádosti - není možné měnit
Sdíleno s - za jakou organizaci je požadavek zadaný
Možnost přidat komentář - zde probíhá konverzace ze strany klienta (tj. pracovník klientské podpory komentuje v prostředí Jiry a klient komentuje skrze přidání komentáře, či skrze e-mail)
Odpovídání na dotazy skrze e-mail - skrze “Odpověď vložte nad tento řádek” (viz obrázek níže)
Workflow požadavku
Existuje více možností workflow požadavku viz obrázek níže
Open = požadavek je po zadání zadavatelem automaticky označen stavem open. V této fázi zadavatel požadavku nedostane ze strany supportu žádné upozornění e-mailem
Received = fáze přijetí požadavku stranou supportního oddělení tzn. požadavek byl přijat a začíná se na něm pracovat; v této fázi je zadavateli požadavku odesláno upozornění o přijetí požadavku e-mailem.
Waiting for customer = Pokud je potřeba dodání informací od zadavatele požadavku, pak je nutné požadavek přepnout do fáze “Waiting for customer”. Po přepnutí do této fáze si řešitel vyžádá informace/podklady, které je třeba dodat skrze tabulku, která se zobrazí při přepnutí do této fáze (viz obrázek níže). Zadavateli požadavku je následně odeslán automatizovaný e-mail, ve kterém je vysvětleno, jaké informace se po něm žádají.
Waiting for PM = Pokud pracovník supportu není schopen úkol vyřešit sám, pak se požadavek přesouvá na PM (blocker buď na Honzu / Michala), pokud je požadavek spojený s
Waiting for development = požadavek na vývoj produktu, bug - používá se např. pokud má klient námět na novou funkci- zde se napíše, jak by námět měl fungovat, odhad, termín realizace a poté se zadá task na IT a do kdy je nutné mít odpověď.
Waiting for support = Fáze čekání na znovu přijetí požadavku supportem, používání po vrácení požadavku z fází popsaných v bodech 3), 4) a 5).
Waiting for approval = Klientovi se pošle automatická zpráva s prosbou o schválení změny/vyřešení požadavku, opět má řešitel možnost vložit poznámku např. Dobrý den, upravila jsem to, už by to mělo být v pořádku. Je to za Vás takto ok? -> Klient požadavek může schválit / odmítnout přímo z e-mailu (viz obrázek níže).
V případě schválení je klient převeden do prostředí klientské podpory, ve které je stav požadavku označen jako “hotovo” - požadavek je označen jako hotový i pro stranu pracovníků klientské podpory.
V případě odmítnutí je klient převeden do prostředí klientské podpory, kam zadá komentář, ve kterém by měl popsat, proč zpracování požadavku odmítl. Ze strany pracovníka klientské podpory je pak nutné důvod revidovat. V případě, že pracovník klientské podpory zhodnotí, že požadavek opravdu není vyřešený, pak je třeba jej přepnout do stavu “re-open” a dále řešit v komentářích.
Pokud klient požadavek schválí, tak se automaticky vyhodnotí jako hotový v okně klientské podpory.
Pokud by klient odmítl požadavek, tak se přepne do “Waiting for Support” - zde je nutné, aby klient napsal, co je na řešení špatně, nebo co je ještě nutné změnit (SLA se počítá pouze pokud je požadavek ve stavu “Waiting for Support”)
Klient má svůj komentář možnost napsat do okénka klientské podpory, kde se mu zobrazí okno pro napsání textu / důvodu odmítnutí ukončení požadavku.
Požadavek se musí ručně přepnout do stavu re-open odkud se přepne automaticky do received.
Následně opět pokračuje celý cyklus znovu
Done = požadavek po schválení vyřešení zadavatelem požadavku.
Re-open = pokud by klient chtěl ještě něco změnit tak je možné požadavek znovu otevřít (nutnost přepnout → pomocí Re-open) a pokračuje se opět dle workflow (viz výše)