E-mail zůstává výchozím kanálem pro transakční zprávy. Obnovení hesla, potvrzení objednávky, připomínky schůzek, upozornění na fakturu, týdenní přehledy — drobné každodenní signály, na kterých stojí provoz firmy. Většina z nich chodí e-mailem a příjemci je tam očekávají bez ohledu na to, jaké další kanály existují. Kdyby platforma neměla vlastní odesílání e-mailů, museli by implementátoři skládat dohromady SDK jednotlivých poskytovatelů, vymýšlet vlastní systém šablon, hlídat doručitelnost a to všechno pak dlouhodobě udržovat. Na tak samozřejmou potřebu je to spousta práce. Jetstack ji řeší nativně.
Napojení na více poskytovatelů odesílání skrývá jednotné rozhraní. Implementace není vázaná na jediného dodavatele doručování — provozovatelé prostředí si zvolí backend, který odpovídá jejich požadavkům na doručitelnost i pravidlům, a zbytek platformy s e-mailem komunikuje pořád stejnou akcí, ať je pod ní cokoli. V praxi je to důležité: e-mail může jít ruku v ruce s tím, jak si zákazník staví zbytek své infrastruktury, místo aby zůstal u toho, co platforma zvolila první den.
Každé prostředí odesílá z vlastní adresy a pod vlastním jménem odesílatele, se správným nastavením domény. E-mail o obnově hesla z aplikace daného zákazníka tak přijde pod jeho vlastní identitou, ne z neosobní adresy platformy. To je základ vnímané profesionality i doručitelnosti — pošta, která dorazí od očekávaného odesílatele, je ta, co skutečně skončí ve schránce. Stejně tak systémové e-maily, které spouští sama platforma, a ne automatizace zákazníka, odcházejí pod identitou daného prostředí, takže je koncový uživatel od ostatních nerozezná.
Přílohy se přidávají přirozeně. Souborovou vlastnost ze záznamu lze připojit přímo k odchozí zprávě. PDF vygenerované platformou (viz článek o generování PDF) můžete přiložit k potvrzovacímu e-mailu, který ho doprovází. Podporované jsou i výslovně zadané přílohy z úložiště souborů. Právě díky tomu je běžný postup — vygenerovat PDF, přiložit ho a odeslat — jedním krokem, a ne třemi vratkými.
Skryté kopie (BCC), kopie (CC) i Reply-to nejsou žádný dodatečný nápad, ale běžná součást zprávy. Zvlášť Reply-to má ve firemních procesech velký smysl: potvrzení, které doprovází nový požadavek na podporu, by ve většině nastavení mělo mít reply-to nastavené tak, aby se odpovědi vracely zpět do ticketovacího systému. V akci pro odeslání e-mailu v tvůrci automatizací nastavíte reply-to i výrazem, takže různé e-maily z jedné automatizace mohou odpovědi podle kontextu směrovat na různá místa.
Pro testovací a přípravná prostředí existuje přepínač odesílání, který vypne odchozí poštu, aniž byste ji museli z implementace odebírat. Přípravné prostředí se kvůli testům chová dál jako to produkční, ale jeho automatizace reálně nikomu e-mail nepošlou. Je to drobná, ale důležitá pojistka, aby zkušební běh na testovacím prostředí nezaplavil schránku zákazníka testovacími zprávami.
Samotné šablony bydlí ve vyhrazeném modulu e-mailových šablon. Šablona je spravovaná entita s vlastním rozhraním: má název, obsah těla zprávy, volbu rozvržení (layoutu) a příznak aktivní/neaktivní, díky kterému lze šablonu vyřadit z používání, aniž byste ji mazali. Když šablonu vyřadíte, automatizace, které ji používaly, mají dál nedotčenou historii a snadno je přesměrujete na náhradu. Příznak zároveň drží staré šablony mimo výběr při zakládání e-mailu a přitom zachovává auditní stopu.
Šablony nesou proměnné postavené na jazyce vložených výrazů. Záznam, který automatizaci spustil, přihlášený uživatel, aktuální datum, vlastnosti souvisejících záznamů — to vše je v těle šablony dostupné stejnou syntaxí výrazů jako všude jinde. Uvítací šablona pro nového zákazníka může obsahovat jeho jméno, jméno jeho account manažera, datum zahájení i personalizovaný odkaz; šablona je jeden kus obsahu a každý odeslaný e-mail vznikne vyhodnocením té šablony nad konkrétním záznamem. A právě tahle jednotnost napříč platformou — stejný jazyk výrazů ve formulářích, v pohledech, v automatizacích i v šablonách — dělá platformu snadno naučitelnou. Neudržujete tři různé druhy šablonování, ale jeden.
Přímé zadání těla zprávy pokryje jednorázové případy. Když chce konkrétní automatizace poslat zprávu bez vyhrazené šablony — protože je opravdu jednorázová, nebo se obsah skládá dynamicky — přijme akce pro odeslání e-mailu tělo přímo. Katalog šablon tak zůstává zaměřený na znovupoužitelný obsah a nezaplňují ho zprávy na jedno použití.
Branding jednotlivých prostředí se do šablon promítá přirozeně. Záhlaví, zápatí, barvy i loga se řídí nastavením daného zákazníka, takže stejný základ — rozvržení, blok s podpisem, jednotné zápatí — je k dispozici napříč šablonami, aniž by si ho každá musela definovat znovu. Právě to udržuje rostoucí katalog šablon vizuálně konzistentní bez ruční práce.
Vykreslování šablon probíhá v izolovaném prostředí (sandboxu). Proměnné se vyhodnotí, libovolný kód ne. Tím odpadá celá kategorie bezpečnostních starostí, které trápí méně promyšlené systémy šablon, a správci mohou nechat skládat šablony i nevývojáře, aniž by se báli, co by mohl chytrácký výraz provést.
Odeslání e-mailu z automatizace jsou v praxi čtyři vstupy: příjemce (výraz, nebo pevná adresa), šablona (nebo přímo tělo zprávy), případné přílohy a kontext, nad kterým se má šablona vykreslit. O zbytek se postará automatizace. Pro týmy, jejichž každodenní práce stojí na spoustě transakčních zpráv — potvrzeních, aktualizacích, upozorněních, připomínkách — bývá právě tohle ta funkce, po které má člověk pocit, že za něj platforma opravdu pracuje, místo aby u každého nového procesu musel znovu integrovat samostatnou poštovní službu.