← Back to articles

Jak zachovat e-mailová vlákna, když se z e-mailů stanou tikety

Jak zachovat e-mailová vlákna, když se z e-mailů stanou tikety

Udržení e-mailové konverzace pohromadě poté, co se z ní stane ticket, závisí na pravidlech vláken používaných helpdeskem. Mezi běžné signály patří hlavičky Message-ID, In-Reply-To a References. Některé platformy také používají ID ticketu nebo jiný identifikátor v těle zprávy či na přijímací adrese.

Předtím, než se spolehnete na nový e-mailový kanál, použijte tento kontrolní seznam:

  • Připojte adresu podpory pomocí metody, kterou helpdesk oficiálně podporuje.
  • Odešlete testovací ticket a odpovězte přes stejnou trasu, jakou budou používat zákazníci.
  • Porovnejte hlavičky původní zprávy a odpovědi a poté ověřte, že se odpověď zobrazuje v existujícím ticketu.

Pokud test vytvoří nový ticket, před změnou směrování pošty si projděte zdokumentovaná pravidla vláken daného helpdesku. Každá platforma může hlavičky, identifikátory ticketů a kontroly odesílatele kombinovat odlišně.

Hlavní závěry

Vytváření e-mailových vláken není založeno pouze na předmětech zpráv. Helpdesky běžně kontrolují standardní hlavičky odpovědí a jako další signály pro přiřazení mohou používat vlastní identifikátory ticketů.

Body Podrobnosti
Hlavičky propojují odpovědi In-Reply-To a References odkazují na ID zpráv z existující konverzace.
Pravidla se podle platformy liší Helpdesk může také kontrolovat ID ticketu, skrytý identifikátor, přijímací adresu nebo odesílatele.
Používejte podporovaná připojení Postupujte podle nastavení schránky zdokumentovaného vaším helpdeskem a poskytovatelem e-mailu.
Otestujte skutečnou trasu Odpovězte jako zákazník a ověřte, že se zpráva připojí k původnímu ticketu.
Možnosti schránek v Deskhero Deskhero podporuje obousměrná připojení schránek Google a Microsoft a také přeposílání z vlastní domény s autentizovaným odesíláním.

Obsah

Které hlavičky skutečně zachovávají e-mailová vlákna

E-mail obvykle obsahuje Message-ID. Odpověď může obsahovat hodnotu In-Reply-To odkazující na zprávu, na kterou se odpovídá, a hodnotu References uvádějící ID dřívějších zpráv. Helpdesk může tyto vztahy využít k přiřazení zpráv ke konverzaci. Dokumentace Amazon Connect popisuje chronologická vlákna i stromové vzory vznikající v případě, že někdo odpoví na starší zprávu.

Platformy mohou přidávat vlastní metody přiřazování. Zendesk dokumentuje tři kontroly: prvky hlaviček, zakódované ID v těle zprávy a zakódované ID na přijímací adrese Zendesk. Jde o pravidla specifická pro Zendesk, nikoli o šablonu, kterou lze zkopírovat do každého helpdesku.

Vlákna jsou důležitá, protože oddělení odpovědi od předchozích zpráv ztěžuje orientaci v historii podpory:

  • Uživatelé možná budou muset hledat dřívější přílohy nebo rozhodnutí v jiném ticketu.
  • Příjemci a předchozí odpovědi mohou být odděleni od nejnovější otázky.
  • Dva uživatelé mohou odpovídat na související zprávy, aniž by si uvědomili, že patří do jedné konverzace.

Dokumentace e-mailů Freshdesk ukazuje další přístup specifický pro danou platformu. Kontroluje ID ticketu, ID zprávy nebo jedinečný identifikátor a následně ověřuje odesílatele. Praktickým závěrem je zjistit, které signály používá váš vlastní helpdesk, a zachovat tyto signály během skutečné trasy pošty.

Nastavení poštovních serverů pro zachování celistvosti vláken

Spolehlivé nastavení začíná metodou připojení podporovanou helpdeskem. Nepředpokládejte, že SMTP relay, pravidlo přeposílání nebo synchronizace schránky fungují napříč produkty stejně.

  1. Vyberte zdokumentované připojení schránky. Pokud helpdesk nabízí přímé připojení Google nebo Microsoft, postupujte podle autorizačního procesu. Pokud vyžaduje přeposílání, použijte přesné cílové údaje a DNS záznamy dodané produktem.
  2. Nastavte přeposílání pro zamýšlenou adresu. Návod Deskhero k přeposílání v Google Workspace vysvětluje, jak vytvořit skupinu a přidat cílovou adresu Deskhero jako člena. Microsoft 365 a další poskytovatelé mají odlišné postupy nastavení.
  3. Zachovejte identifikátory platformy. Pokud helpdesk přidává do odchozího oznámení značku ticketu, neodstraňujte ji ze šablony, pokud dokumentace produktu neuvádí, že je volitelná. Freshdesk doporučuje zahrnout formát svého ID ticketu, zatímco Zendesk ve výchozím nastavení přidává do odchozích oznámení zakódované ID.
  4. Prověřte systémy, které poštu upravují. Směrovací pravidla, e-mailové konference a brány mohou zprávu před přijetím helpdeskem změnit. Porovnejte nezpracovaný zdroj v každé dostupné fázi, místo abyste odhadovali, kde se hodnota změnila.
  5. Proveďte opakovatelný ověřovací test. Vytvořte ticket, odešlete odpověď a prohlédněte si nezpracovaný zdroj. Zkontrolujte, zda In-Reply-To odkazuje na dřívější Message-ID, zda References obsahuje očekávaný řetězec a zda byla odpověď připojena k existujícímu ticketu.

Tip pro pokročilé: Testujte prostřednictvím stejné adresy, stejné cesty přeposílání a stejného e-mailového klienta, které budou používat vaši zákazníci. Přímá zpráva na interní testovací adresu neověří celou produkční trasu.

Proč se vlákna přerušují a jak napravit jednotlivé příčiny

Odpověď se může z několika důvodů stát novým ticketem. Přesná příčina závisí na pravidlech přiřazování dané platformy.

  • Chybějící hlavičky odpovědi. Zpráva vytvořená jako nový e-mail nemusí obsahovat hodnoty In-Reply-To nebo References, které se očekávají u odpovědi. Požádejte odesílatele, aby použil funkci Odpovědět, a poté porovnejte nezpracovaný zdroj.
  • Změněné směrování nebo příjemci. Zpráva odeslaná na jinou adresu podpory může vytvořit další ticket. Freshdesk například dokumentuje zvláštní chování v případě, že je zahrnuto více než jedna nakonfigurovaná adresa helpdesku.
  • Odstraněný identifikátor platformy. Úprava šablony oznámení může odstranit ID ticketu nebo skrytý identifikátor, který helpdesk používá jako záložní údaj.
  • Vypršení párování zpráv. Freshdesk uvádí, že jeho ID zprávy obvykle vyprší sedm dní po poslední odpovědi. Poté vyhledává ID ticketu nebo identifikátor ticketu. Toto načasování je specifické pro Freshdesk a nelze je předpokládat u jiných produktů.

Diagnostiku začněte původní odchozí zprávou a odpovědí zákazníka. Porovnejte jejich nezpracované hlavičky vedle sebe a poté zkontrolujte vlastní dokumentaci helpdesku a časovou osu ticketu. Pokud jsou hlavičky odpovědi přítomné, prověřte další požadavky platformy, například značky ticketů, přijímací adresu nebo povoleného odesílatele. Pokud hlavičky chybí, sledujte trasu přes poskytovatele e-mailu a případnou službu přeposílání, abyste zjistili, kde se zpráva změnila.

Jak Deskhero zachovává historii konverzace v nezměněné podobě

Deskhero promění existující schránku Gmail, Google Workspace nebo Microsoft 365 v helpdesk. Podporuje také schránky na jiných vlastních doménách prostřednictvím autentizace DNS a příchozího přeposílání.

  • Připojení Google a Microsoft poskytují obousměrnou synchronizaci, takže Deskhero může číst příchozí poštu a odesílat odpovědi jako připojená adresa.
  • Schránka DNS používá záznamy DKIM pro autentizované odesílání a jedinečnou adresu Deskhero pro příchozí přeposílání.
  • Odpovědi ve stejné e-mailové konverzaci se připojí k existujícímu ticketu v Deskhero.
  • Odpovědi navržené umělou inteligencí využívají znalosti pracovního prostoru a zůstávají pod kontrolou uživatelů. Automatické odpovědi jsou samostatnou funkcí, kterou je nutné povolit pro každou skupinu, a odpovídají pouze na základě schválených veřejných často kladených dotazů.

Další informace najdete v článcích Deskhero o obousměrné synchronizaci e-mailů helpdesku, použití existující schránky jako helpdesku a přeměně příchozího e-mailu na ticket.

Požadavek Možnost v Deskhero
Připojení Gmailu nebo Google Workspace Připojení OAuth s obousměrnou synchronizací
Připojení Microsoft 365 nebo Outlooku Připojení OAuth s obousměrnou synchronizací včetně sdílených schránek
Použití jiné vlastní domény Autentizace DNS pro odesílání a přeposílání příchozí pošty
Kontrola odpovědí umělé inteligence Uživatelé kontrolují navržené odpovědi; automatické odpovědi vyžadují samostatné aktivní přihlášení

V čem se většina návodů k nastavení mýlí

Je lákavé zredukovat vytváření vláken na jediné pravidlo, například na zachování Message-ID. Dokumentace dodavatelů ukazuje, proč je to neúplné. Zendesk kombinuje kontroly hlaviček a zakódovaných ID. Freshdesk kombinuje několik e-mailových značek s kontrolou odesílatele. Amazon Connect propojuje kontakty pomocí údajů o souvisejících kontaktech a běžných e-mailových hlaviček.

V čem se většina návodů k nastavení mýlí, přehledový diagram

Lepším přístupem je chápat vytváření vláken jako chování od začátku do konce. Používejte podporované připojení schránky, zachovejte identifikátory generované produktem a testujte pomocí skutečné odpovědi zákazníka. Pokud je výsledek nesprávný, porovnejte nezpracované zprávy a postupujte podle zdokumentovaného pořadí přiřazování vašeho helpdesku.

Tím se také vyhnete zbytečným změnám poštovního serveru. Nový relay nebo přepsaná šablona mohou přidat další proměnnou, aniž by vyřešily skutečný nesoulad.

Spusťte helpdesk s vlákny, aniž byste přišli o jedinou odpověď

Deskhero může připojit existující schránku Gmail, Google Workspace nebo Microsoft 365 prostřednictvím obousměrné synchronizace. U jiné vlastní domény podporuje autentizované odesílání prostřednictvím konfigurace DNS a příchozí přeposílání na jedinečnou adresu Deskhero.

Deskhero

Vaši uživatelé pracují ze sdílené schránky, zatímco odpovědi se odesílají z připojené firemní adresy. Pokud vaše podpora používá Shopify, integrace Shopify přidá do postranního panelu ticketu kontext zákazníka a objednávky.

Deskhero nabízí 30denní bezplatnou zkušební verzi, která nevyžaduje platební kartu. Můžete připojit existující adresu, místo abyste zákazníky žádali, aby se učili používat novou.

Zdroje

Časté dotazy

Jaký je rozdíl mezi obousměrnou synchronizací a přeposíláním?

Obousměrná synchronizace umožňuje helpdesku číst z připojené schránky a odesílat přes ni zprávy. Přeposílání odesílá příchozí zprávy na jiné místo a pro odchozí poštu může vyžadovat samostatnou autentizaci. Dostupné metody a pravidla vytváření vláken závisí na helpdesku a poskytovateli e-mailu.

Proč odpověď zákazníka vytvořila nový ticket místo připojení do vlákna?

Odpovědi mohou chybět očekávané hlavičky, mohou používat jinou adresu podpory, pocházet od odesílatele, kterého platforma nespojuje s ticketem, nebo jim může chybět identifikátor ticketu specifický pro daný produkt. Zkontrolujte nezpracovaný zdroj e-mailu a zdokumentovaná pravidla vašeho helpdesku.

Jak ověřím, zda vytváření vláken fungovalo správně?

Ověřte, že se odpověď zobrazuje v existujícím ticketu. Pokud tomu tak není, porovnejte hodnoty In-Reply-To a References v odpovědi s hodnotami Message-ID dřívějších zpráv a poté zkontrolujte případné identifikátory ticketu používané platformou.

Potřebuji autentizovaný SMTP relay, pokud již používám obousměrnou synchronizaci?

Obvykle ne jako samostatnou opravu vytváření vláken. Postupujte podle konfigurace odesílání vyžadované vaším helpdeskem. Přímé připojení schránky již může odchozí poštu řešit, zatímco nastavení založené na přeposílání nebo DNS může používat jinou metodu autentizovaného odesílání.

Podporuje Deskhero Gmail i Microsoft 365?

Ano. Deskhero podporuje obousměrná připojení pro Gmail, Google Workspace, Microsoft 365 a Outlook. Podporovány jsou také sdílené schránky Microsoft.