品牌導入自動化行銷之後，第一個真正的難關通常不是設計旅程。
流程圖畫得出來，條件也設得出來。卡住的地方是：你怎麼知道它會照你想的跑？
測試環境跟真實條件對不起來
舉一個很常見的例子：會員到期前七天發提醒。
這個旅程要怎麼測？
你需要一個「再七天就到期」的會員。但你手上的測試帳號可能剛續約完， 到期日在明年。於是你只有兩個選擇：等，或者請技術端進資料庫把測試帳號的到期日改掉。
多數品牌選第二個。而這代表每測一次，就要排一次技術支援，提前兩天預約。
一個旅程如果要調三輪，你的測試週期就是兩個禮拜。
於是很多旅程是「上線即測試」
因為測試太麻煩，實務上常發生的是：直接上線，用真實會員當試驗品。
出錯的時候你會知道，因為客訴會告訴你。
我看過的狀況包括：同一封生日祝賀在一天內發了三次、 條件寫反了所以發給了不該發的分群、 旅程卡在某個節點沒有往下走但沒有人發現，直到三週後有人問「為什麼都沒收到」。
最後一種最危險，因為它不會產生客訴，只會安靜地失效。
驗證機制要包含三件事
一、能夠模擬條件，而不是等條件發生。 測試機制的核心價值是讓你不用等。如果測一個「到期前七天」要真的等七天， 或要請人改資料，那這個測試機制等於不存在。
二、要能看到旅程走到哪一步。 一個卡住的旅程和一個還沒觸發的旅程，從外面看起來一模一樣。 沒有節點層級的狀態，你根本不知道問題在哪一段。
三、要能停止。 每個旅程都應該設上限：同一個人在多久之內最多收到幾次、 單日發送總量的天花板是多少。
停止不是為了正常情況，是為了條件寫錯的那一次。 條件寫錯遲早會發生，差別只在於它會影響三個人還是三萬人。
上線前的檢查清單
我通常會請品牌端在每個旅程上線前，先回答四個問題：
這個旅程的觸發條件，最短多久會發生一次？ 如果同一個人重複符合條件，他會不會重複收到？ 如果中間某個節點失敗，會停在那裡還是跳過？ 你打算多久之後回來看它有沒有在跑？
第四題最少人想過，但它決定了一個安靜失效的旅程會被發現， 還是會在三個月後才被發現。
自動化的真正成本
很多品牌買自動化工具時算的是省下多少人力。
但自動化真正的成本不在設定，在維護。 旅程會過期、條件會失效、商品會下架、活動會結束， 而一個沒有人在看的自動化旅程，不會自己停下來。
會自己跑的東西，也需要有人固定回來看它還在不在正確地跑。
所以導入自動化的時候，除了設定旅程，也要一起決定誰負責定期檢視、多久看一次。 這件事沒有指定人，三個月後就不會有人做。