На тази страница
Писмена заявка гласи: „Когато поръчката е платена, актуализирайте контакта“. В този илюстративен процес едно изречение пропуска поръчката, анулирана след плащане, госта, който по-късно създава акаунт, и купувача, който никога не е дал разрешение за маркетинг.
Операторът познава тези случаи, защото ги е обработвал. Разработчикът може да приложи правилото от едното изречение безупречно и пак да създаде грешен резултат.
Разговор от включените източници за агенти в работата защитава идеята хората, които разбират задачата, да оформят автоматизацията ѝ. Посочва и уловката: те все пак се нуждаят от правилните данни и разрешения за действие. Именно напрежението между двете е полезната част от идеята.
Експертното знание живее в изключенията
Диаграмата на нормалния път се рисува лесно. Събитие пристига, поле се съпоставя, запис се актуализира. Знанието на експерта често се появява, когато диаграмата се провали.
Ако два контакта споделят имейл? Ако доставка е разделена? Ако последното събитие за поръчка пристигне преди по-старо? Ако целевата система приеме актуализация, но източникът вече се е променил?
Експертът не е длъжен да знае отговора на всеки API въпрос. Трябва да каже кое бизнес състояние има предимство. „Анулирана поръчка не трябва да прави контакта подходящ за съобщение след покупка“ е бизнес правило. Как да бъде наложено при закъснели събития е инженерен проблем.
Експертът по задачата предоставя реални случаи на изключения и желания резултат. Инженерният екип прави прегледаните правила безопасни за изпълнение върху изходни и целеви записи.
Нашето ръководство за интеграция казва на читателите да посочат източник на истината за всеки обект. Този избор трябва да идва от хората, отговорни за записите. После кодът може да проверява актуалността на събитията и състоянието в целевата система спрямо него.
Дайте на експерта начин да показва, не само да разказва
Възражението е справедливо: „Ако потребителите сами строят автоматизациите си, ще получим десетки непрегледани правила върху клиентски данни“. Това е реален риск. Отговорът не е да скрием задачата от тях. Той е да отделим авторството от правомощието.
Нека експертът отбележи няколко действителни записа: този трябва да се актуализира, този да изчака, този да бъде изключен. Попитайте защо. Запазете версията на източника и очаквания резултат към всеки пример. Това са по-добри спецификации от изречение за „обработка на изключения“.
После ограничете разрешеното действие. Предложено съпоставяне може да се редактира и прегледа, без да изпраща нищо. Реалният запис изисква правилните удостоверения, одобрени полета и наложим обхват. Промоционално действие се нуждае и от валидно основание за съгласие. Нашето ръководство за двойно потвърждение описва един начин разрешението за имейл маркетинг да бъде записано; самата поръчка не го дава.
В инструментите на Tajo за съпоставяне шаблон може да бъде проверен със синтетични данни, преди да се създаде чернова на правило. Трите полета по-долу са ясни. По-трудният въпрос е какво липсва в картата: чие определение за съгласие определя следващото съобщение? Успешната предварителна проверка не може да реши този въпрос на политика.
Прегледайте синхронизацията преди изпълнение
Синхронизирайте промените по клиентите с моята имейл платформа.
Синхронизация на клиенти
| Поле източник | Поле цел | Правило |
|---|---|---|
email | EMAIL | Директно |
first_name | FIRSTNAME | Директно |
last_name | LASTNAME | Директно |
Синтетичната предварителна проверка премина успешно
Съпоставени са 3 полета · Няма запис в целевата система
Илюстративен изглед, основан на инструментите на Tajo за съпоставяне. Синтетичната проверка и запазената чернова не активират синхронизация.
| Експертът определя | Системата налага |
|---|---|
| Кое състояние на поръчка се брои | Актуалност на събитието и справка за състоянието |
| Коя клиентска идентичност се има предвид | Стабилни идентификатори и обработка на конфликти |
| Кои случаи трябва да изчакат | Опашка, състояние на преглед и правила при изтичане на времето за изчакване |
| Как изглежда правилен резултат | Прочитане от целевата система или друго крайно условие |
| Коя цел на комуникацията е разрешена | Разрешение и спиране при изпълнение |
Разделението не е стена. Инженерите трябва да оспорват невъзможно или опасно правило, а експертите да разглеждат реалните резултати. То държи всяко решение при човека или системата, която може да го защити.
Започнете с последните десет реални случая
Въображаемият идеален процес е слаб тест. Вземете малък набор от скорошни случаи от действителната работа, като обработвате клиентските данни според правилата за достъп на екипа. Отбележете нормалните случаи и изключенията. Ако правилата не могат да обяснят десетте, автоматизацията не е готова да решава единадесетия.
За първа синхронизация синтетична тестова поръчка може да демонстрира механизма. Разрешението за реална работа и извадката от действителни случаи са отделни стъпки. Ръководството за интеграция на Brevo с Shopify препоръчва да се проверят тестов контакт и поръчка в целевата система преди активиране на кампании.
Този метод има цена. Експертът трябва да отдели време, за да изрази неявните правила. Някой трябва да разгледа случаите, по които експертите не са съгласни. Екипът може да научи, че днешният процес е непоследователен, което е неудобно.
Някои изключения не могат да се решат с постоянно правило от първия опит. За сливане на идентичността на гост може да липсват доказателства или записът за съгласие да е неясен. Спецификацията трябва да казва „задръж за преглед“ и да назовава кой може да реши, вместо да налага „да“ или „не“ при непълни данни. Записвайте решението и причината. С времето опашката показва дали същата неизвестност изисква по-ясно правило, по-добро поле в източника или продължаваща човешка преценка. Автоматизацията върши полезна работа и когато правилният ѝ резултат е ограничена пауза.
Точно това е и смисълът. Агент може да взема последователно решение едва след като екипът определи какво означава последователност. Иначе той мащабира догадката на най-бързия човек.
Най-кратката спецификация често е едно реално изключение, обяснено докрай.
Често Задавани Въпроси
Трябва ли експертът по задачата да строи автоматизацията без инженер?
Експертът трябва да определи нормалния път, изключенията и приемливите резултати. Инженерният екип все пак трябва да налага идентичността, разрешенията, договорите за данни, повторните опити и тестовете навсякъде, където процесът действа върху клиентски системи.
Защо описанията на процеси пропускат важни случаи?
Резюмето на нормалния път често изпуска изключенията, които хората решават от опит. Прегледайте скорошни реални случаи с експерта и направете правилото за обработка изрично преди автоматизиране.
Откъде трябва да започне първата автоматизация?
Започнете с една повтаряща се задача, един източник на истината, един ясен резултат и няколко наблюдавани изключения. Нека експертът одобри правилото и провери състоянието в целевата система преди разширяване.