自建漏斗同上線與維運遇到嘅難題
名單同跟進電郵，攞返喺自己手度
目標好直接：訪客喺網頁填表，資料跟住落你自己嘅庫，再按預先排好嘅時間，一封一封寄出跟進電郵。聽落唔複雜，但當你想唔再依賴單一大型平台包住成條由收集到寄信嘅鏈，就要同時照顧網頁、託管後台、寄信同防濫用幾條線，中途好多個決定位，都要揀邊一種做法先最啱你而家團隊規模同預算。
本案實作對應係 Cloudflare Pages + Workers + D1 + Postmark + Turnstile 嘅組合。
邊度最易「以為壞咗」？
表單一撳提交，訪客畫面見到冇紅字，但你負責嗰邊「好似完全無反應」。好多時唔係程式邏輯寫錯，而係瀏覽器同你租嗰個託管後台，本質係兩個世界：可能一邊擋咗連線，另一邊根本未收到任何請求。查呢類問題要習慣先用訪客手上嗰部機睇網絡同畫面，再轉去託管後台嘅紀錄，唔好只係睇其中一邊就落結論。
方便同安全，邊條線畫喺邊？
表單喺公開網頁，想流程順暢，就要俾瀏覽器帶一啲「通行用」嘅設定；換言之，唔可以當成銀行戶口嗰種「得你一個人知」嘅秘密。實務上要同團隊講清楚：邊一類設定只用嚟擋噪音、拉高濫用成本，邊一類至係真係要收收埋埋喺託管後台、唔經網頁流出。之後若要加真人驗證、或者限制重複提交嘅頻率，都可以按同一套原則慢慢加上去。
寄信、退訂、網域：最易「細位搞死大戲」
電郵寄唔出、退訂掣撳唔開，好多時唔係信入面內容寫得唔好，而係寄件人身份、寄件網域、退訊連結去錯網址之類設定未對齊。換另一間寄件服務，又要由頭核對一輪。同埋對外講過嘅承諾（例如退信之後點處理）要同你實際做得到嘅一致，唔好用誇大咗嘅講法應付過關。
「即刻」其實多數有緩衝
跟進電郵係按時間表一批一批寄出，唔會做到好似即時通訊咁一秒內就到對方信箱。若果你對外講「一提交就即刻收到第一封」，就要同訪客講清楚實際要等幾耐；日後若想按訪客行為再密啲發信，就要另外設計流程。
網頁同後台分開上線
主站網頁改咗字、改咗表單，但託管後台未跟住更新（或者倒轉，後台先改而網頁未改），就會出現一邊新、一邊舊、兩邊唔對齊、易誤會嘅情況。要習慣用一張上線清單寫清楚：邊幾樣改動要同一日上、邊啲可以獨立之後再補。
同現有習慣並行
例如表單一邊仍然用團隊慣用嘅試算表收集流程，另一邊再加多一層你自己嘅名單庫，可以減少一次過搬晒所有流程嘅壓力；長遠如果想收窄會經網頁傳出去嘅資料種類，再按階段逐步收緊就得。
想談名單、跟進電郵或者表單點接最啱你？
我可以按你而家團隊規模同行業，拆成一步一步、盡量減少來回修改同重複執手尾嘅做法。
預約 30 分鐘診斷：幫你定邊啲值得自建、邊啲可以遲啲先換。