AI a weby

Web postavený AI ztrácí poptávky ve složce spam

Formulář odešle, návštěvník vidí potvrzení a čeká na vaši odpověď. Zatímco zpráva leží ve složce, kterou nikdo neotevře, nebo server vůbec neopustí — a stránka nikde nehlásí, že se něco pokazilo.

Formulář je ta jednodušší polovina

Když si u AI nástroje necháte udělat kontaktní formulář, dostanete ho na první pokus. Popisky, dvě validační pravidla, rozbalovací nabídka, souhlas se zpracováním údajů, potvrzovací hláška — to jsou standardní vzory a modely je spolehlivě zopakují. V ukázce formulář funguje: odešlete ho, objeví se hláška, stránka vám poděkuje.

Co ukázka ukázat nemůže, je to, co se děje po stisku tlačítka. Práce stránky končí úspěšným požadavkem; zpráva pak putuje přes nastavení pošty vašeho hostingového poskytovatele, DNS záznamy vaší domény a filtrační pravidla přijímajícího poštovního serveru. Tři oddělené systémy, žádný z nich není součástí stránky, a každý zprávu může tiše zahodit. Stránka přitom vidí jen to, že požadavek proběhl — co se děje dál, je mimo její dosah.

To selhání je tiché z principu. Návštěvník si přečte „děkujeme, ozveme se do 24 hodin“ a jde dál. Na vaší straně nikdo nic nedostane. Prvním signálem bývá až zákazník, který se ptá, proč jste na jeho poptávku neodpověděli — dní poté, co ji poslal.

Co rozhoduje o tom, jestli se poptávka dostane k vám

Zásadní jsou tři DNS záznamy: SPF, DKIM a DMARC. SPF vyjmenovává servery, které smějí posílat poštu vaší doménou. DKIM zprávu podepíše, aby ji příjemce mohl ověřit a zjistit, že se cestou nezměnila. DMARC oba záznamy spojuje: porovná viditelnou doménu v poli From s doménou podpisu a příjemci řekne, co má dělat, když si nesedí. Když tyto záznamy chybí nebo jsou špatně — což je běžný stav webu nasazeného nástrojem, který se vašeho DNS nikdy nedotkne — nemá přijímající server důvod zprávě věřit a její filtrování je výchozí řešení.

Druhá past je adresa odesílatele. Formulář, který posílá z no-reply@vasedomeni přes sdílený server hostingového poskytovatele, si o filtrování říká sám: ten server není uvedený ve vašem SPF záznamu, doména nemá DKIM klíč a schránka pro odpovědi je taková, kterou nikdo nečte. Přijímající služby navíc zvažují pověst odesílatele, takže doména, která dosud nikdy neposílala poštu, začíná bez jakékoli důvěryhodné historie. Příjemce se přitom neptá, jestli jste poctiví — rozhoduje podle záznamů, které vidí.

A někdy pošta vůbec neodejde. Některé sdílené hostingy blokují odchozí poštu úplně, aby udržely pod kontrolou spam, a plugin, který pro odeslání používá poštovní funkci serveru, vyhodnotí blokované odeslání jako úspěšné. V takovém případě neleží žádná zpráva ve složce, kterou byste našli — zpráva nikdy nevznikla.

Proč váš vlastní test vždycky projde

Test z vaší vlastní schránky prakticky nic nedokazuje. Vaši poštu si každý den otevíráte, takže si na vašich zprávách váš poskytovatel vybudoval dobrou pověst a zprávy mezi adresami stejné domény sdílejí stejnou historii. Test navíc dorazí vteřiny poté, co jste web použili, a to z prostředí i ze sítě, které běžně používáte. Zajímavé je, jak vypadá odesílatel, kterého příjemce dosud nikdy neviděl — a na to vaše vlastní adresa odpověď nedá.

Stejně zkresluje i test z kancelářské sítě. Interní směrování, přihlášené relace a adresy, na které už píšete, zprávu tlačí do hlavní schránky. Jediný poctivý test je složka spamu na adrese mimo vaši firmu — a přesně tu nikdo z týmu neotevírá.

To je průvodní znak většiny hlášení o „rozbitém formuláři“: týden úspěšných vnitřních testů a pak reálné poptávky, které se v žádné schránce neobjeví. Formulář nikdy nebyl rozbitý — nefungovala cesta za ním a žádný vnitřní test ji nemohl odhalit.

Kontrolní seznam na patnáct minut

Pošlete jednu poptávku z adresy, která vám dosud nikdy nepsala. Osobní Gmail, pokud firma běží na Microsoft 365, nebo naopak. Tento jeden test řekne víc než týdny vnitřních kontrol.

Otevřete přijatou zprávu a přečtěte si hlavičku. Většina poštovních klientů ji skrývá pod „zobrazit originál“ nebo „zobrazit zdroj“. Najděte řádek Authentication-Results: chcete na něm SPF pass, DKIM pass a DMARC pass. Chyba nebo chybějící výsledek tam vysvětlí většinu tichých ztrát.

Zkontrolujte DNS záznamy. SPF záznam, který obsahuje server nebo službu, která za vás skutečně posílá, publikovaný DKIM záznam a DMARC záznam — i benevolentní s p=none a adresou pro reporty, aby chyby chodily jako hlášení místo mlčení.

Posílejte přes ověřenou cestu. Nastavte formulář na přihlašovací údaje k SMTP vašeho poštovního poskytovatele nebo na transakční poštovní službu místo vlastní pošty serveru a adresu pro odpovědi nastavte na sledovanou schránku. Vyžádejte si u správce webu logování chyb odeslání: odeslání, které nelze doručit, má někoho upozornit, ne zmizet.

Test po několika hodinách zopakujte z jiné služby. Jedna úspěšná cesta znamená, že existuje; dvě z různých sítí znamenají, že drží. Celá kontrola zabere patnáct minut a nevyžaduje přístup na server — potřebujete prohlížeč a přístup k DNS záznamům domény.

Doručení je součástí stavby webu

Kontaktní formulář není hotový ve chvíli, kdy odešle — je hotový ve chvíli, kdy se poptávka dostane k člověku. Tím se doručování stává záležitostí stavby: DNS záznamy, cesta odeslání a jeden externí test patří do stejného seznamu jako rozvržení a zobrazení na mobilu. AI umí formulář vygenerovat skvěle a je jí jedno, co se děje potom, takže požádat o stránku a požádat o ověřené doručení jsou dva různé požadavky.

Patnáctiminutovou kontrolu udělejte dřív, než web spustíte, ne až po první ztracené poptávce. Nestojí nic a promění nejdražší tiché selhání webu malé firmy — zákazníka, který vám napsal a usoudil, že jste ho ignorovali — v problém, který vyřešíte za odpoledne. O ztracené poptávce se totiž nikdo nedozví: na rozdíl od výpadku webu ji nikdo nehlásí a vy o ní nevíte, dokud se nezeptá zákazník sám.


Související služba: Weby, formuláře a automatizace poptávek

Chcete podobný problém řešit prakticky? Napište nám.