Automatizace neodpověděla. Kdy ji lze zopakovat bez dalšího úkolu v CRM?

Automatizace kampaně skončila chybou a v historii vidíte červený stav. Máte ji spustit znovu? Rozhodující není barva záznamu, ale to, co se stalo v CRM nebo v nástroji pro rozesílání. Nový technický pokus nemusí znamenat nový obchodní úkon. S dodavatelem proto předem dohodněte, jak systém jednotlivé úkony pozná a odkud získá důkaz o jejich výsledku.

Časový limit znamená, že volající systém přestal čekat na odpověď. Neprokazuje, že cílový systém přestal pracovat. Samostatně posuzujte také webhook, tedy automatické oznámení události: jeho další doručení nemusí představovat další zákaznickou akci. Lepší zadání pro AI samo o sobě opakovanému zápisu do jiného systému nezabrání.

Nejprve rozlište tři možné výsledky

Chyba před zahájením akce umožňuje další pokus podle dohodnutých pravidel. U prokazatelně dokončené akce automatizace převezme uložený výsledek a pokračuje. Nejistý výsledek vyžaduje porovnání s údaji v cílovém systému. Dokud chybí důkaz, nesmí se nejistota automaticky změnit na povolení k opakování.

Konkrétní příklad nabízí vlastní akce v Shopify Flow: jejich koncový bod má na odpověď až deset sekund, potom Flow spojení uzavře a požadavek později pošle znovu. Identifikátor action_run_id pomůže rozpoznat tentýž běh, ale příjemce musí ochranu proti opakovanému provedení zajistit sám. Desetisekundové pravidlo neplatí obecně pro webhooky, CRM ani AI.

Každý úkon potřebuje stálou identitu a uložený průběh

Přidělte zamýšlenému úkonu jedinečný technický identifikátor operace, který neobsahuje osobní údaje. Při opakování zůstává stejný; každý technický pokus dostane vlastní identifikátor pokusu. Záměrně nový úkol či nová zpráva naopak potřebují vlastní identitu i schválení. Tím se ochrana proti duplicitám nestane překážkou legitimních dalších akcí.

Identita doručeného oznámení není vždy identitou obchodního úkonu. Shopify upozorňuje, že webhook může přijít opakovaně. Zároveň mohou dva různé odběry oznámení o téže události používat různé identifikátory webhooku a sdílet identifikátor události. Dodavatel musí vysvětlit, z čeho odvodí identitu vaší operace a které samostatné akce musí zachovat.

Uložte identifikátor operace, zdroj a událost, zamýšlenou akci, schválený obsah a jeho verzi, stav, počet pokusů, odkaz na výsledek v cílovém systému a časové údaje. Záznam má obsahovat také odpovědnou osobu a další rozhodnutí. Pro návrh takové evidence nepotřebujete skutečné citlivé údaje zákazníků.

Co musí zaručovat místní evidence a co cílový systém

Idempotence znamená, že opakování stejné zamýšlené operace nepřidá další účinek, pokud jsou splněny zdokumentované podmínky systému. Samotná kontrola „už hotovo?“ nestačí: dva souběžné procesy mohou oba přečíst zápornou odpověď. Akce se také může dokončit v CRM dříve, než automatizace stihne uložit úspěch.

Požadujte proto atomické převzetí operace nebo omezení, které v místní evidenci vynutí jedinečnost záznamu. Atomické zde znamená jedinou nedělitelnou rezervaci, kterou nemohou současně získat dva pracovní procesy. K tomu je potřeba ochrana v cílovém systému nebo ověření skutečného výsledku. Pouhý zápis identifikátoru či pozdější zápis úspěchu tuto mezeru neřeší.

Podmínky se liší podle rozhraní. U podporovaných požadavků POST Stripe vrací při stejném idempotentním klíči první uložený stav a odpověď, včetně chyb. Změněné parametry se stejným klíčem odmítne. Klíče může odstranit po nejméně 24 hodinách; jejich pozdější použití pak vytváří nový požadavek. Výsledek ukládá až po zahájení provádění, takže chyby validace a souběžné konflikty mají jiná pravidla. Jde o příklad podmínek rozhraní, nikoli návrh platební automatizace. U vašeho CRM ověřte podporované akce, dobu uchování, parametry a chování při chybě. Ověření může proběhnout i opakováním s týmž klíčem a parametry, pokud dokumentace cíle pro danou akci a platnou dobu výslovně zajišťuje idempotentní zpracování; není vždy nutné samostatné ruční hledání.

Ztracená odpověď při vytvoření úkolu

Následující situace je smyšlená a nebyla spuštěna. Požadavek na kampaň má vytvořit jeden navazující úkol v CRM a poté poslat e-mail. CRM úkol uloží, ale odpověď se cestou ztratí. Opakování celého postupu by mohlo vytvořit druhý úkol.

Rozumný další krok je dohledat existující úkol podle průkazné reference. Pokud je potvrzený, uložte do evidence jeho identifikátor přidělený CRM a pokračujte jen dosud nevyřešenou fází. Stav úkolu a stav e-mailu ověřujte odděleně; přijetí e-mailu odesílací službou ještě nedokládá doručení příjemci. Jestliže cíl neumí výsledek potvrdit ani zabránit duplicitě, operaci pozastavte a předejte konkrétnímu člověku; automatické odeslání naslepo nepovolujte.

Schválení obsahu musí přežít další pokus

AI může připravovat návrhy nebo třídit chyby. O akcích s dopadem však rozhodují jednoznačná pravidla automatizace a určený člověk. Další generování může změnit text, proto opakování schválené akce používá původní schválený obsah. Změna obsahu vyžaduje nové posouzení. Před schválením náhradní operace nejprve dořešte původní operaci s nejistým výsledkem.

Ani lidské schválení samo nezabrání duplicitě. V LangGraph se při pokračování po pozastavení voláním interrupt() příslušný uzel, tedy krok postupu, provádí znovu od začátku; změna v externím systému provedená před touto pauzou se může zopakovat. Oddělení schvalování od zápisu do systému pomáhá, ale neřeší všechny pozdější chyby. Ochranu potřebuje každá fáze samostatně.

Přejímací zkoušky, které si sjednejte před pilotem

Tento seznam je návrhem přejímacích kritérií, nikoli výsledkem provedených testů či zárukou. U každého případu si vyžádejte viditelný stav, důkaz z cílového systému a určení dalšího kroku.

1. Běžný úspěšný průchod: vznikne požadovaná akce a uloží se její reference.
2. Opakované doručení stejné události: v chráněném scénáři vznikne jen jedna zamýšlená externí akce a další pokus využije existující důkaz.
3. Časový limit po úspěchu v cíli: systém dohledá výsledek, případně ponechá nejistý stav ke kontrole.
4. Dva souběžné pokusy: převzetí operace a ochrana cíle zabrání druhému účinku v dohodnutém chráněném scénáři.
5. Pokračování po schválení: zachová se schválený obsah a dokončené fáze se neopakují.
6. Pozdní opakování po skončení uchování klíče: systém nepočítá se zaniklou ochranou; výsledek ověří, nebo vyžádá kontrolu.

Počet opakování a prodlužování prodlev nastavte podle dokumentace cílového systému. Nekonečné opakování ani jeden univerzální počet pokusů nejsou vhodná pravidla. Sledujte odděleně události, pokusy, potvrzené externí účinky, nevyřešené položky a čas obsluhy potřebný k nápravě. Samotný počet úspěšných běhů neukáže, zda zákazník dostal dvě zprávy.

Pilot s jasně vymezenou odpovědností

MindVerve při návrhu automatizace mapuje spouštěče, vstupy, výstupy a odpovědné osoby, pravidla pro chybějící údaje i selhání, testovací případy a provozní pokyny. AI Workflow Launch zahrnuje jeden dohodnutý postup: výběr nástrojů, reprezentativní i chybové testy, opakovaně použitelné podklady a zadání pro AI, dokumentaci, školení a předání. Licence, spotřeba API a další integrace nejsou součástí; průběžná údržba se řeší zvlášť.