Jak proměnit Outlook v helpdesk, který skutečně funguje
Malou frontu podpory můžete spravovat v Outlooku pomocí sdílené schránky, pravidel, kategorií a šablon odpovědí. Když tým potřebuje formální vlastnictví požadavků, sledování úrovně služeb, automatizaci nebo reporting, propojte stávající schránku Microsoft 365 s helpdeskem namísto změny veřejné adresy podpory.
Promyšlené DIY nastavení začíná sdílenou schránkou. Dokud je fronta jednoduchá, může fungovat, ale Outlook nepřevádí zprávy na strukturované tikety ani neposkytuje reporting helpdesku a zásady SLA.
Hlavní závěry
Přeměna Outlooku na spolehlivý helpdesk vyžaduje buď disciplinovaný DIY proces se sdílenou schránkou pro týmy s malým objemem požadavků, nebo integrovaný helpdesk pro každý tým, který potřebuje vlastnictví tiketů, vynucování SLA a reporting.
| Hlavní bod | Podrobnosti |
|---|---|
| DIY má pevný strop | Sdílená schránka s pravidly může fungovat pro jednoduchou frontu, ale vlastnictví a stav závisí na týmových konvencích. |
| Na způsobu integrace záleží | Upřednostněte helpdesk s přímým připojením k Microsoft 365 a před spuštěním ověřte odchozí adresu v poli Od. |
| Přejděte na helpdesk, jakmile se objeví signály | O helpdesku uvažujte, jakmile se ruční přiřazování, předávání, servisní cíle nebo reporting stanou nespolehlivými. |
| Otestujte řešení na reálném provozu | Spusťte časově omezený pilot na kontrolované části skutečných požadavků, s jedním vlastníkem a předem definovanými metrikami. |
| Deskhero se pro tento případ hodí | Deskhero se připojí k Microsoft 365, přidá odpovědi navržené umělou inteligencí na základě znalostí pracovního prostoru a nabízí 30denní bezplatnou zkušební verzi bez nutnosti zadání platební karty. |
Obsah
- Proč je přeměna Outlooku na helpdesk složitější, než se zdá
- Dva praktické přístupy: DIY Outlook versus integrovaný helpdesk
- Jak se integrace Outlooku s helpdeskem skutečně připojují
- Nastavení obou přístupů krok za krokem
- Co integrovaný helpdesk nabízí a samotný Outlook nikoli
- Kdy je čas opustit proces založený pouze na Outlooku?
- Na co se zaměřit při výběru helpdesku integrovaného s Outlookem
- Jak Deskhero promění vaši schránku Microsoft 365 v plnohodnotný helpdesk
- Co skutečně rozhoduje o úspěchu či neúspěchu pilotního projektu
- Prvních 30 dní s Deskhero v číslech
- Zdroje
- Časté dotazy
Proč je přeměna Outlooku na helpdesk složitější, než se zdá
Outlook je e-mailový klient, nikoli tiketovací systém. Sdílená schránka podporuje týmovou práci s e-maily, ale týmy si musí vytvořit vlastní konvence pro vlastnictví, stav a předávání požadavků. Mezi běžná omezení patří:
- Ruční vlastnictví. Otevření nebo kategorizace zprávy nevytvoří formálně přiřazený tiket.
- Žádné zásady SLA helpdesku. Outlook nepočítá termíny první odpovědi a vyřešení vzhledem k rozvrhu podpory.
- Omezené směrování. Pravidla mohou třídit zprávy, ale přiřazení a aktualizace polí tiketu vyžadují konvence nebo další nástroje.
- Žádný přehled tiketů. Složky a kategorie mohou frontu přibližně simulovat, neposkytují však strukturovaný reporting tiketů.
- Historie závislá na procesu. Přesunutí, smazání nebo odpověď ze špatné schránky může ztížit sledování konverzace se zákazníkem.
- Chyby v adrese pro odpověď. Odpověď odeslaná z osobní schránky může zákazníka zmást a rozdělit sdílený proces.
Studie Microsoftu zjistila, že 40 % zaměstnanců kontroluje e-mail před šestou hodinou ranní. Toto číslo se netýká konkrétně zákaznické podpory, ale užitečně připomíná, že je třeba definovat pokrytí fronty a předávání požadavků, namísto spoléhání na to, že lidé budou e-mail nepřetržitě sledovat.
Na bezpečnosti a uchovávání dat stále záleží. V Microsoft 365 nakonfigurujte oprávnění sdílené schránky, nastavení auditu a uchovávání dat a poté posuďte rozsahy přístupu, umístění dat a možnosti exportu jednotlivých poskytovatelů helpdesku.
Dva praktické přístupy: DIY Outlook versus integrovaný helpdesk
Používání Outlooku pro podporu je vhodné, když je fronta jednoduchá a tým dodržuje strukturovaný proces. Helpdesk se stává užitečným, když tyto konvence již neposkytují spolehlivé vlastnictví, sledování úrovně služeb nebo reporting. Zde je porovnání obou cest.
DIY proces v Outlooku
Co to je: Sdílená schránka s pravidly Outlooku, barevnými kategoriemi, strukturou složek, konvencemi ručního vlastnictví a uloženými šablonami odpovědí (Quick Parts).
Výhody:
- Využívá nástroje, které jsou již dostupné v Microsoft 365
- Využívá přihlašovací údaje, které váš tým již má
- Nemusí vyžadovat samostatné předplatné softwaru pro podporu
Nevýhody:
- Vlastnictví je společenská konvence, nikoli systémově vynucované pravidlo
- Žádné sledování SLA, reporting ani historie tiketů
- S rostoucím objemem, složitostí nebo velikostí týmu se hůře spravuje
Integrovaný helpdesk
Co to je: Platforma SaaS nebo doplněk Outlooku, který se připojí k vaší schránce, převádí příchozí e-maily na tikety a přidává vlastnictví, SLA, automatizaci a reporting.
Výhody:
- Vlastnictví tiketů vynucované systémem
- Může zahrnovat časovače SLA, automatizaci a reporting
- Podporuje strukturovanější proces při růstu týmu
- Může poskytovat historii tiketů, exporty a další administrativní ovládací prvky
Nevýhody:
- Vyžaduje předplatné
- Vyžaduje konfiguraci a akceptační testování
- Uživatelé potřebují zaškolení do nového procesu
Který přístup se hodí pro váš tým?
| Funkce | DIY proces v Outlooku | Typický integrovaný helpdesk |
|---|---|---|
| Vlastnictví tiketu | Pouze ruční konvence | Přiřazení vynucované systémem |
| Sledování SLA | Žádné | Nastavitelné časovače a upozornění |
| Automatizace směrování | Základní pravidla složek | Podmíněná pravidla přiřazení |
| Reporting a dashboardy | Žádné | Vestavěná analytika |
| Auditní stopa | Částečná (protokoly schránky) | Historie tiketů a možnosti exportu specifické pro produkt |
| Příjem z více kanálů | Pouze e-mail | Liší se podle produktu |
| Doba nastavení | Obvykle rychlá, v závislosti na oprávněních | Liší se podle produktu a procesu |
DIY zvolte, pokud je fronta dostatečně jednoduchá na správu pomocí zdokumentovaných konvencí. O integrovaném helpdesku uvažujte, když potřebujete strukturované přiřazování, měřitelné servisní cíle, automatizaci nebo reporting.
Jak se integrace Outlooku s helpdeskem skutečně připojují
Porozumění způsobu připojení ještě před výběrem poskytovatele vám později ušetří bolestivou rekonfiguraci. Existují čtyři hlavní přístupy.
Konektor Microsoft 365. Mnoho helpdesků nabízí přímé připojení OAuth k Microsoft 365. V závislosti na produktu a oprávněních může připojení načítat poštu ze sdílené schránky a odesílat odpovědi ze stejné adresy, aniž by ukládalo heslo ke schránce.
IMAP, POP a SMTP. Některé produkty podporují standardní poštovní protokoly, často pro starší nebo lokální prostředí. Ověřte, zda připojení poskytuje průběžnou obousměrnou synchronizaci, nebo pouze importuje zprávy, a otestujte, jak se řeší změny ověřování.
Sdílená schránka s oprávněním Send As. Helpdesk se může připojit ke sdílené adrese, například support@yourcompany.com, a odesílat z ní odpovědi. Toto chování ověřte pomocí externího testovacího účtu.
Doplněk Outlooku nebo načítání na straně serveru. Doplňky obvykle umožňují uživateli pracovat s vybranými zprávami přímo v Outlooku. Načítání na straně serveru sleduje schránku a vytváří tikety, aniž by Outlook musel být otevřený. Přesné chování při vytváření tiketů a seskupování konverzací se liší podle poskytovatele.
Před výběrem produktu otestujte novou zprávu, odpověď na existující konverzaci, přeposlanou zprávu a zprávu odeslanou z aliasu. Ověřte, že každá z nich vytvoří nebo aktualizuje očekávaný tiket a zachová správnou adresu v poli Od.
Bezpečnostní aspekty. Projděte si oprávnění požadovaná konektorem a udělte pouze ta, která zdokumentovaná integrace potřebuje. Ověřte možnosti přihlášení poskytovatele, umístění dat, uchovávání, historii auditu a možnosti exportu v porovnání s vašimi požadavky.
Tip: Pro Microsoft 365 upřednostněte zdokumentované připojení OAuth před nastavením, které vyžaduje sdílení hesel ke schránce. Během pilotního projektu otestujte adresu pro odpovědi a proces opětovného ověření.
Nastavení obou přístupů krok za krokem
Vytvoření DIY procesu v Outlooku
- Vytvořte sdílenou schránku v centru pro správu Microsoft 365 (např. support@yourcompany.com). Podle průvodce Microsoft Learn pro sdílené schránky přidělte každému uživateli oprávnění Full Access a Send As.
- Publikujte adresu. Aktualizujte kontaktní stránku webu, e-mailové podpisy a všechny automatické odpovědi tak, aby dotazy zákazníků směřovaly na sdílenou adresu.
- Vytvořte strukturu složek. Vytvořte složky nejvyšší úrovně: Nové, Řeší se, Čeká se na zákazníka, Vyřešené. V případě potřeby přidejte podsložky podle kategorií (Fakturace, Technické, Vrácení zboží).
- Nastavte pravidla Outlooku. Vytvořte pravidla pro automatické přesouvání e-mailů podle domény odesílatele, klíčového slova v předmětu nebo kategorie do správné složky.
- Definujte barevné kategorie. Použijte kategorie Outlooku jako jednoduchý systém priorit: červená = urgentní, žlutá = běžné, zelená = vyřešené.
- Uložte šablony odpovědí. Pro běžné odpovědi použijte Quick Parts nebo My Templates. Pojmenujte je jasně, aby je uživatelé rychle našli.
- Zaveďte konvenci vlastnictví. Dohodněte se na písemném pravidle: uživatel, který e-mail otevře, jej vlastní, dokud jej nepředá nebo neoznačí jako vyřešený. Toto pravidlo zdokumentujte ve sdíleném OneNote nebo wiki v Teams.
- Vyřešená vlákna zpracovávejte jednotně. Přesuňte je do dohodnuté složky a uplatněte zásady uchovávání dat vaší organizace.
Spuštění rychlého pilotního projektu integrovaného helpdesku
- Vyberte poskytovatele se zdokumentovaným připojením k Microsoft 365, které odpovídá vaší schránce a bezpečnostním požadavkům.
- Připojte schránku Microsoft 365 pomocí podporovaného autorizačního procesu poskytovatele. Před schválením si projděte požadovaná oprávnění.
- Namapujte adresu Send As. Ověřte, že odchozí odpovědi zobrazují support@yourcompany.com, nikoli subdoménu poskytovatele. Otestujte to před pozváním uživatelů.
- Nastavte základní pravidla směrování. Pokud je produkt podporuje, směrujte podle odesílatele, předmětu nebo obsahu zprávy. Příklady plánování najdete v průvodci převodem e-mailu na tiket.
- Pozvěte uživatele. Přidělte odpovídající role a skupiny a poté nakonfigurujte oznámení.
- Otestujte seskupování vláken. Ověřte, že následné zprávy zákazníka se připojí ke správnému tiketu, aniž byste se spoléhali na předpoklady o tom, jak poskytovatel identifikuje konverzaci.
- Proveďte akceptační testy od začátku do konce. Odešlete testovací e-mail na sdílenou adresu, ověřte vytvoření tiketu, odpovězte z helpdesku a zkontrolujte, že zákazník obdrží odpověď z adresy vaší společnosti.
Kontrolní seznam před spuštěním
- Adresa pro odpověď zobrazuje doménu vaší společnosti, nikoli doménu poskytovatele
- Následná odpověď zákazníka se připojí ke stejnému tiketu (nikoli k novému)
- Všichni uživatelé mohou současně vidět stejnou frontu tiketů
- Vzorový termín SLA se vypočítá správně, pokud je nakonfigurován
- Historie tiketu a dostupné auditní záznamy zachycují očekávané akce
Tip: Před spuštěním otestujte odchozí poštu pomocí externího účtu. Z pohledu zákazníka zkontrolujte adresu v poli Od, seskupování odpovědí, podpisy a přílohy.
Co integrovaný helpdesk nabízí a samotný Outlook nikoli
Rozdíl mezi DIY procesem v Outlooku a integrovaným helpdeskem není jen otázkou funkcí. Jde o to, co můžete skutečně měřit a zlepšovat.
Funkce, které je třeba hledat:
- Vlastnictví tiketu s uvedeným řešitelem u každého požadavku
- Termíny SLA, filtry a upozornění
- Podmíněná pravidla přiřazení (dotazy k fakturaci směrujte fakturačnímu týmu, technické problémy na 2. úroveň)
- Prohledávatelná databáze tiketů s kompletní historií konverzací
- Znalostní báze, do které mohou uživatelé nahlížet při odpovídání
- Další vstupní kanály, například formuláře nebo chat, pokud jsou potřeba
- Analytické dashboardy zobrazující objem, dobu odpovědi a míru vyřešení
- Historie tiketů a možnosti exportu odpovídající vašim požadavkům
Metriky sledované během pilotního projektu:
- Doba první odpovědi v porovnání s vaším vlastním servisním cílem
- Doba vyřešení podle kategorie
- Míra znovuotevřených tiketů (indikátor kvality odpovědí)
- Počet tiketů vyřízených jedním uživatelem za den
- Procento plnění SLA
| Potřeba podpory | DIY Outlook | Typický integrovaný helpdesk |
|---|---|---|
| Přiřadit tiket jednomu uživateli | Ruční příznak u e-mailu | Přiřazení vynucované systémem |
| Sledovat plnění SLA | Není možné | Časovače a upozornění specifické pro produkt |
| Vyhledat historii minulých tiketů | Pouze vyhledávání ve schránce | Strukturovaná databáze tiketů |
| Reportovat výkon týmu | Není možné | Vestavěné dashboardy |
| Zpracovávat odeslání webových formulářů | Není možné | Dostupné u některých produktů |
| Automaticky navrhovat odpovědi ze znalostní báze | Není možné | Dostupné u některých produktů |
Smyslem helpdesku není přidávat procesy samoúčelně. Měl by zviditelnit vlastnictví, upozornit na požadavky vyžadující pozornost a poskytnout týmu spolehlivá data pro zlepšování procesu.
Kdy je čas opustit proces založený pouze na Outlooku?
Správný okamžik ke změně nástrojů závisí na složitosti fronty, nikoli na univerzálním počtu e-mailů. Sledujte tyto signály.
- Uživatelé přehlížejí vlákna nebo odesílají duplicitní odpovědi
- Vlastnictví a předávání závisí na tom, zda si lidé pamatují neformální konvence
- Zákazník si stěžoval, že neobdržel odpověď, a vy jste nemohli najít původní e-mail
- Na otázku „Jaká je naše průměrná doba první odpovědi?“ nedokážete odpovědět bez ručního počítání
- Nesplnili jste závazek úrovně služeb a před jeho porušením jste neměli žádné upozornění
- Uživatelé sledují schránku mimo své směny, protože neexistuje jasný proces předávání
- Nemůžete konzistentně rozdělovat práci ani reportovat vytížení
Tyto příznaky použijte k definování pilotního projektu. Před testem a během něj například měřte počet duplicitních odpovědí, nepřiřazených požadavků, dobu první odpovědi a nesplněné servisní cíle.
Při přechodu ponechte veřejnou adresu podpory beze změny. Pokud to váš proces umožňuje, začněte s kontrolovanou kategorií nebo schránkou, ověřte její fungování a rozšiřte řešení, až si uživatelé zvyknou.
Na co se zaměřit při výběru helpdesku integrovaného s Outlookem
Ne všechny helpdesky se s Outlookem integrují stejně dobře. Před zahájením zkušební verze položte tyto otázky.
Otázky pro každého poskytovatele:
- Jaké způsoby připojení podporujete: Microsoft 365 OAuth, Exchange on-premises, IMAP/POP?
- Jak řešíte mapování adres Send As a Od?
- Funguje seskupování tiketů bez nutnosti, aby zákazníci zachovali řádek předmětu?
- Jaké nástroje SLA jsou součástí řešení: časovače, pravidla eskalace, upozornění na porušení?
- Mohu exportovat všechna data tiketů ve standardním formátu (CSV, JSON)?
- Kde jsou uložena zákaznická data a máte certifikaci SOC 2 Type II?
- Podporujete Microsoft SSO (Azure AD)?
- Jaká automatizační pravidla jsou dostupná a existuje API?
- Jaké jsou podmínky zkušební verze: jak dlouho trvá, je vyžadována platební karta, mažou se data po skončení zkoušky?
Otázky, které je třeba vyřešit před zkušební verzí:
- Poskytovatel nedokáže vysvětlit, zda si můžete ponechat svou adresu podpory
- Historie tiketů a možnosti exportu nesplňují vaše požadavky
- Podmínky zkušební verze neposkytují dostatek času nebo reprezentativního provozu pro užitečné vyhodnocení
- Umístění dat je nejasné nebo mimo jurisdikci, v níž platí vaše požadavky na soulad
- Chybí požadované možnosti API, integrace nebo exportu
- Podpora během pilotního projektu není jasně definována
Plánování pilotního projektu: Použijte reprezentativní provoz a definujte kritéria úspěchu ještě před prvním dnem. Zahrňte cílovou dobu první odpovědi, metriku SLA, pokud je relevantní, a limit nepřiřazených tiketů na konci dne. Zaznamenejte výchozí stav, abyste mohli nový proces spravedlivě porovnat.
Jak Deskhero promění vaši schránku Microsoft 365 v plnohodnotný helpdesk
Deskhero je helpdesk pro malé a středně velké týmy zákaznické podpory. Připojte schránku Microsoft 365 prostřednictvím OAuth, včetně podporované sdílené schránky, a nadále používejte stávající adresu podpory. Připojení schránky nevyžaduje novou veřejnou adresu ani změny DNS.
Co Deskhero přidá k vašemu procesu v Outlooku:
- Obousměrnou synchronizaci e-mailů, takže odpovědi odcházejí z adresy vaší společnosti
- Automatické vytváření tiketů, přičemž odpovědi ve stejné konverzaci se připojí k existujícímu tiketu
- Návrhy odpovědí vytvořené umělou inteligencí a založené na znalostech pracovního prostoru, včetně vyřešených tiketů, interních znalostí, schválených položek FAQ a načtených stránek webu
- Automatizační pravidla pro nové tikety týkající se přiřazení, skupin, stavu, priority, štítků a podporovaných vlastních polí
- Interní znalostní bázi s přístupem na úrovni skupin
- Navrhované veřejné položky FAQ, které uživatel před zveřejněním zkontroluje
- Statistiky objemů, dob odpovědí, výsledků SLA, uživatelů, kanálů a funkcí umělé inteligence plus samostatný přehled tematických skupin
- Vícejazyčnou podporu ve 14 jazycích
- Microsoft SSO a plnohodnotné REST API
- Zákaznický panel Shopify pro týmy podpory v e-commerce
Kroky onboardingu pilotního projektu s Deskhero:
- Zaregistrujte se na Deskhero (30denní zkušební verze nevyžaduje platební kartu).
- Připojte schránku Microsoft 365 prostřednictvím OAuth v administrátorském panelu.
- Potvrďte mapování Send As, aby odchozí odpovědi zobrazovaly adresu vaší společnosti.
- Pozvěte uživatele a nastavte role.
- Nakonfigurujte malou sadu automatizačních pravidel pro nové tikety a v případě potřeby zásady SLA s cíli pro první odpověď a vyřešení.
- Proveďte akceptační testy: odešlete testovací e-mail, ověřte vytvoření tiketu, odpovězte a zkontrolujte adresu odpovědi z pohledu zákazníka.
Čím se Deskhero liší od obecného doplňku: Návrhy odpovědí umělou inteligencí využívají fond znalostí pracovního prostoru, zatímco chat s umělou inteligencí a automatické odpovědi směrem k zákazníkům používají pouze schválené veřejné FAQ. Uživatelé navrhované odpovědi před odesláním kontrolují. Automatické odpovědi jsou volitelné, označené a zaznamenané na časové ose tiketu.
Metriky, které je třeba v Deskhero během pilotního projektu sledovat:
- Doba první odpovědi (výchozí hodnota v 1. týdnu, cílové zlepšení do 4. týdne)
- Procento plnění SLA
- Přiřazené a nepřiřazené tikety na konci každého dne
- Kontrolovaný vzorek návrhů AI z hlediska přesnosti a náročnosti úprav
Tip: Během pilotního projektu kontrolujte reprezentativní vzorek návrhů AI. Pokud je návrh neúplný nebo nepřesný, vylepšete podkladové znalosti pracovního prostoru a zachovejte lidskou kontrolu v procesu odesílání.
Co skutečně rozhoduje o úspěchu či neúspěchu pilotního projektu
Technicky úspěšné připojení je pouze jednou částí užitečného pilotního projektu. Tým potřebuje také jasné vlastnictví zavedení, zdokumentované konvence pro práci s frontou a metriky navázané na problémy, které má nový systém řešit.
Pověřte jednoho vlastníka pilotního projektu údržbou pravidel směrování, zodpovídáním dotazů k procesu a vyhodnocováním výsledků. Tato osoba nemusí rozhodovat o všem sama, ale tým by měl vědět, kde se koordinují změny konfigurace a zpětná vazba.
Pokud je to praktické, začněte s kontrolovanou částí provozu, například jednou kategorií požadavků nebo jednou schránkou. Rozšiřte řešení až poté, co uživatelé dokončí testy od začátku do konce a směrování, oznámení, adresa pro odpovědi i servisní cíle se budou chovat očekávaným způsobem.
Do akceptačního testování zahrňte reprezentativní scénáře vytíženého dne. Otestujte běžné typy požadavků, neobvyklé přílohy, následné zprávy zákazníků i kombinace pravidel, které by mohly tiket směrovat jinak.
Proškolte uživatele v každodenních úkonech: hledání a převzetí práce, odpověď nebo přidání soukromé poznámky, změna stavu a předání tiketu. Krátkého průvodce mějte v běžném týmovém prostoru pro spolupráci.
Před zahájením pilotního projektu vysvětlete, jak budou využívány metriky a návrhy AI. Uživatelé by měli rozumět tomu, že navrhované odpovědi jsou koncepty ke kontrole, nikoli pokyny, které musí přijmout.
Prvních 30 dní s Deskhero v číslech
Deskhero převádí zprávy z připojené schránky Microsoft 365 na tikety a zároveň zachovává adresu podpory společnosti. Uživatelé pracují ve sdílené frontě tiketů a návrhy odpovědí AI se zobrazují jako koncepty ke kontrole.
30denní bezplatná zkušební verze nevyžaduje platební kartu. Připojte schránku Microsoft 365, pozvěte uživatele, nakonfigurujte pouze pravidla a zásady SLA potřebné pro pilotní projekt a porovnejte tyto metriky s výchozím stavem v Outlooku:
- Doba první odpovědi
- Plnění SLA, pokud jsou nastaveny servisní cíle
- Přiřazené a nepřiřazené tikety na konci dne
- Zpětná vazba uživatelů k procesu
- Přesnost a náročnost úprav u vzorku návrhů odpovědí AI
Výsledky zkušební verze použijte k rozhodnutí, zda proces řeší problémy identifikované na začátku. Porovnání vždy vztahujte k vlastnímu výchozímu stavu a servisním cílům.
Zdroje
- Vytvoření sdílené schránky – Microsoft Learn
- Nová studie Microsoftu odhaluje rozmach nekonečného pracovního dne – Microsoft News
Časté dotazy
Má Outlook vestavěný helpdesk?
Ne. Outlook nemá nativní pole tiketů, vynucování SLA ani reporting. Helpdesk lze přibližně simulovat pomocí sdílené schránky, pravidel a šablon, ale vlastnictví a odpovědnost zůstávají ručními konvencemi, nikoli systémově vynucovaným chováním.
Jak používat Outlook jako tiketovací systém?
Vytvořte sdílenou schránku v centru pro správu Microsoft 365, vytvořte pravidla Outlooku pro třídění e-mailů do složek, používejte kategorie pro stav nebo prioritu a ukládejte běžné odpovědi jako šablony. Zdokumentujte, jak uživatelé požadavky přebírají, předávají a uzavírají.
Mohu e-mail z Outlooku automaticky změnit na úkol nebo tiket?
Ano, pomocí doplňku nebo serverové integrace helpdesku. Přesné chování se liší podle produktu. Připojení schránky Deskhero převádí příchozí zprávy na tikety a odpovědi ze stejné konverzace připojuje k existujícímu tiketu.
Jak poslat e-mail na helpdesk?
Adresujte jej na sdílenou adresu podpory týmu, uveďte jasný předmět a přiložte všechny relevantní soubory. U následných zpráv odpovídejte v existující konverzaci, pokud vás tým podpory nepožádá o jiný postup.
Kdy bych měl přestat používat Outlook pro zákaznickou podporu?
O integrovaném helpdesku uvažujte, když tým přehlíží nebo duplikuje požadavky, vlastnictví a předávání jsou nejasné, servisní cíle nelze sledovat nebo reporting vyžaduje ruční počítání. Tyto příznaky jsou důležitější než univerzální limit počtu zpráv nebo uživatelů.