Ezen az oldalon
Egy írott kérés így szól: „Ha a rendelést kifizették, frissítsd a kapcsolatot.” Ebben a képzeletbeli munkafolyamatban az egyetlen mondatból kimarad a fizetés után törölt rendelés, a később fiókot létrehozó vendégvásárló és a marketinghez soha hozzá nem járuló vevő.
Az operátor ismeri ezeket az eseteket, mert már kezelte őket. A fejlesztő tökéletesen megvalósíthatja az egymondatos szabályt, az eredmény mégis rossz lehet.
Egy feldolgozott beszélgetés a munkahelyi ügynökök építéséről szerint az automatizálást a feladatot értő embereknek kell alakítaniuk. A nehézséget is megnevezi: a cselekvéshez nekik is megfelelő adatok és jogosultságok kellenek. Ez a feszültség az ötlet hasznos része.
A kivételekben él a szakértelem
A normál út ábrája könnyen megrajzolható. Esemény érkezik, mezőt leképezünk, rekordot frissítünk. A szakértő tudása gyakran akkor jelenik meg, amikor az ábra nem elég.
Mi van, ha két kapcsolat ugyanazt az e-mail-címet használja? Ha a küldeményt felosztják? Ha az újabb rendelési esemény előbb érkezik meg, mint a régebbi? Ha a célrendszer elfogad egy frissítést, de a forrás közben már megváltozott?
A szakértőnek nem kell tudnia a választ minden API-kérdésre. Azt viszont meg kell mondania, melyik üzleti állapot legyen érvényes. „A törölt rendelés nem teheti jogosulttá a kapcsolatot vásárlás utáni üzenetre” üzleti szabály. Ennek betartatása késő események között mérnöki feladat.
A feladat szakértője valós kivételeket és kívánt eredményt ad. A fejlesztés biztonságossá teszi a felülvizsgált szabályok végrehajtását a forrás- és célrekordokon.
Az integrációs útmutatónk azt javasolja, hogy minden objektumhoz nevezzünk meg mértékadó forrást. Ezt a rekordokért felelős embereknek kell eldönteniük. A kód ezután a döntéshez mérheti az esemény frissességét és a célállapotot.
A szakértő mutathassa meg, ne csak elmondhassa
Jogos ellenvetés: „Ha a felhasználók maguk építik az automatizációt, tucatnyi ellenőrizetlen szabály érhet vásárlói adatokhoz.” Ez valós kockázat. A válasz nem az, hogy elzárjuk tőlük a feladatot. Válasszuk szét a szabály szerzőségét a cselekvési jogtól.
A szakértő jelöljön meg néhány valódi rekordot: ezt frissíteni kell, ennek várnia kell, ezt ki kell zárni. Kérdezd meg, miért. A forrásverzió és a várt eredmény maradjon a példával. Ezek jobb specifikációk, mint egy mondat a „kivételek kezeléséről”.
Az engedélyezett művelet ezután legyen szűk. A javasolt leképezés szerkeszthető és előnézetben vizsgálható küldés nélkül. Az élő íráshoz megfelelő hitelesítő adatok, jóváhagyott mezők és kikényszeríthető hatókör kell. A promóciós művelethez érvényes hozzájárulási alap is. A kettős feliratkozásról szóló útmutatónk az e-mail-marketing engedélyének egyik rögzítési módját tárgyalja; a rendelés önmagában nem adja meg.
A Tajo leképezési eszközeiben egy sablont szintetikus adatokkal ellenőrizhetsz, mielőtt létrehoznád a szabály tervezetét. Az alábbi három mező egyszerű. Nehezebb kérdés, mi hiányzik a térképből: kinek a hozzájárulási meghatározása szabja meg a következő üzenetet? A sikeres előnézet erre a szabályzati kérdésre nem válaszol.
Ellenőrizd a szinkronizálást az indítás előtt
Szinkronizáld a vásárlói változásokat az e-mail-platformommal.
Vásárlók szinkronizálása
| Forrásmező | Célmező | Szabály |
|---|---|---|
email | EMAIL | Közvetlen |
first_name | FIRSTNAME | Közvetlen |
last_name | LASTNAME | Közvetlen |
A szintetikus előnézet sikeres
3 mező leképezve · Nincs írás a célrendszerbe
A szemléltető elrendezés a Tajo leképezési eszközein alapul. A szintetikus előnézet és a mentett tervezet nem aktiválja a szinkronizálást.
| Amit a szakértő ad | Amit a rendszer kikényszerít |
|---|---|
| Melyik rendelési állapot számít | Eseményfrissesség és állapotlekérés |
| Melyik vásárlói azonosság a cél | Stabil azonosítók és ütközések kezelése |
| Mely esetek várjanak | Sor, felülvizsgálati állapot és időkorlát |
| Milyen a helyes eredmény | Célrendszerbeli visszaolvasás vagy más utófeltétel |
| Melyik kommunikációs cél engedélyezett | Jogosultság és kizárás a végrehajtáskor |
A felosztás nem fal. A fejlesztőknek meg kell kérdőjelezniük a lehetetlen vagy veszélyes szabályt, a szakértőknek pedig valódi eredményeket kell vizsgálniuk. Így minden döntés annál az embernél vagy rendszernél marad, amely meg is tudja védeni.
Kezdj az utolsó tíz valós esettel
A tökéletes, elképzelt munkafolyamat gyenge teszt. Vegyél kis számú friss esetet a valós folyamatból, és a vásárlói adatokat a csapat hozzáférési szabályai szerint kezeld. Jelöld meg a normál és a kivételes eseteket. Ha a szabály nem tudja megmagyarázni ezt a tízet, az automatizáció nem kész dönteni a tizenegyedikről.
Az első szinkronizálásnál a szintetikus tesztrendelés megmutathatja a mechanikát. Az éles jogosultság és a valódi esetek mintája külön lépés. A Brevo és Shopify integrációs útmutató azt javasolja, hogy kampányok aktiválása előtt ellenőrizzünk tesztkapcsolatot és rendelést a célrendszerben.
Ennek a módszernek ára van. A szakértőnek időt kell szánnia a hallgatólagos szabályok kimondására. Valakinek át kell néznie azokat az eseteket, amelyekben a szakértők nem értenek egyet. A csapat megtudhatja, hogy a folyamat ma következetlen, ami kényelmetlen.
Néhány kivételre elsőre nincs állandó szabály. Egy vendég azonosságához kevés bizonyíték lehet az egyesítéshez, vagy a hozzájárulási rekord lehet kétértelmű. A specifikáció mondja azt, hogy „visszatartás felülvizsgálatra”, és nevezze meg, ki dönthet, ahelyett hogy hiányos adatból igent vagy nemet kényszerítene. Jegyezd fel a döntést és indokát. Idővel a sor megmutatja, hogy ugyanahhoz a bizonytalansághoz világosabb szabály, jobb forrásmező vagy továbbra is emberi megítélés kell-e. Az automatizáció akkor is hasznos munkát végez, ha helyes kimenete a körülhatárolt megállás.
Ez a lényeg is. Az ügynök csak akkor tud következetesen dönteni, ha a csapat előbb meghatározza, mit jelent a következetesség. Különben a leggyorsabb ember találgatását nagyítja fel.
A legrövidebb specifikáció gyakran egy valódi kivétel teljes magyarázata.
Gyakran Ismételt Kérdések
A feladat szakértője mérnök nélkül építsen automatizációt?
A feladat szakértője határozza meg a normál utat, a kivételeket és az elfogadható eredményeket. A fejlesztésnek továbbra is ki kell kényszerítenie az azonosságot, jogosultságokat, adatszerződéseket, újrapróbálkozásokat és teszteket ott, ahol a folyamat ügyfélrendszerekben cselekszik.
Miért maradnak ki fontos esetek a munkafolyamat leírásából?
A normál út összefoglalása gyakran kihagyja a tapasztalatból megoldott kivételeket. Nézz át a feladat szakértőjével közelmúltbeli valós eseteket, és az automatizálás előtt tedd egyértelművé a kezelésük szabályát.
Hol kezdődjön az első automatizáció?
Egy ismétlődő feladattal, egy mértékadó forrással, egy világos eredménnyel és néhány megfigyelt kivétellel. A bővítés előtt a szakértő hagyja jóvá a szabályt, és ellenőrizze a célállapotot.