表單資料怎麼對進 CRM？逐欄寫出格式、空值與同步方向

從來源鍵、CRM 目標欄位到格式轉換、空值策略與同步方向，整理一份可交給設定者的逐欄映射規格，並用邊界樣本驗證去重與更新結果。

表單資料要穩定進到 CRM，關鍵不是把欄位照名稱搬過去，而是先訂出雙方對同一筆資料的共同定義：來源欄位代表什麼、目標欄位存什麼、格式怎麼轉、空值代表什麼，以及哪一方可以更新。若未定義，電話可能被當成數字而失去開頭零，空白也可能覆蓋既有內容，或同一個人因此成為重複聯絡人。以下以一份假設的詢問表單與一般 CRM 聯絡人資料為例，建立可交付給設定者的映射規格；實際目標欄位名稱仍須依所選 CRM 的資料模型確認。先列出來源欄位，再逐項填上格式、空值政策與同步責任，才有一致的檢查基準。

列出來源目標欄位

先把表單與 CRM 的一筆資料拆成可比較清單，不要只抄畫面標籤；「聯絡方式」可能包含電話、Email 與偏好時段。每列記錄來源鍵、題目、目標物件與欄位、型別、必填、空值政策、轉換方式、同步方向與排錯責任人。來源鍵比標籤穩定，表單改字不應讓映射失效；沒有固定鍵就先請維護者補上，不依欄位順序猜。目標端要分清聯絡人、公司及自訂欄位，不期待 CRM 自動把姓名和公司拆開。以下純屬假設範例：

映射還要標明目標紀錄的查找鍵，以及欄位是在建立時寫入、每次更新都覆寫，還是只在目標空白時填入；這會改變同一筆提交再次到達時的結果。若目標尚無欄位，記下待新增欄位的名稱與型別，不把備註欄當萬用收納區。欄位表是表單、CRM 管理者與維護者共用的資料契約。正式設定前確認目標物件關係、可空性、選項值與欄位主控權。若同一來源欄要寫入兩處，分列並說明原因；若無對應欄，標記待新增或刻意不傳，不讓設定者自行挑相似欄位。記錄版本與變更日期，才能在欄位改動時知道要檢查哪些規則。

定義格式與空值

每個目標欄位都要指定儲存型別與正規格式，因為畫面看似相同的值可能有不同意義。姓名、公司、電話、郵遞區號與識別碼應以文字處理，避免前導零被刪或符號被轉成數值；日期要明訂時區與格式，金額要明訂幣別與小數位，布林值則規定可接受的輸入，例如是／否如何轉成 true／false。不要用「照原樣」帶過格式，至少寫出允許字元、大小寫、分隔符、長度或選項集合；若無法在來源端限制，就指定同步前的驗證與錯誤回報方式。

空值政策需區分欄位缺席、空字串、只有空白字元、使用者明確選擇「不提供」，以及來源送來 null。它們不能一律當成可清除 CRM 舊值的指令。建議先定三種結果：忽略代表不更新目標；清空代表有明確授權才刪除既有值；預設值代表只在建立新資料時補值，不能在每次同步時覆寫人工修正。必填資料缺漏時，選擇阻擋整筆、暫存待補或略過該欄，並寫明由誰處理。若 CRM 需要姓名而表單只有 Email，也需明確決定以 Email 建立識別、標記待補，或停止建立；不能讓串接工具自行填入「未知」。

處理空值前先做標準化：去除首尾空白後若長度為零，即視為空；不可任意刪除文字中間空格，地址或姓名可能因此失真。新增與更新也要分開定義：新聯絡人可採設定的預設狀態，既有聯絡人的空值通常代表保留原值。把政策寫成真值表，列出來源狀態、目標原值、建立時結果與更新時結果，才能看出一個空欄到底是沒有資料，還是使用者真的要求清除。若業務需要清除，另設明確勾選或管理流程，並保留操作紀錄；一般空白提交不應默默承擔這個意思。

處理欄位拆併情境

欄位拆分與合併最容易把可讀資料變成難以搜尋的資料。若表單只有 full_name，而 CRM 分成姓與名，先判斷來源語言與命名方式是否可靠；中文姓名不宜用固定切字數拆分，英文複姓或中間名也可能被錯放。較穩妥的選擇是保留完整姓名在完整姓名欄，若目標必須拆欄，就調整表單分開收集，或把拆分結果限制為可人工確認的候選值。不要悄悄丟掉原始內容；需要轉換時，保留原始欄位或來源快照，以便追查錯誤。

反過來，若來源把姓與名分開，目標只有一個姓名欄，先決定組合順序、分隔符及缺一欄時的結果，例如兩者都有才以單一空格連接，只有一欄就保留該欄，不額外輸出分隔符。電話的國碼與號碼若分欄，明訂是否組合成一欄；地址若由縣市、區、街道組成，是否維持結構欄位或建立完整地址，也要依搜尋、寄送與匯出用途決定，不能只為了映射方便而併欄。

一個來源欄也可能拆到多個目標欄，例如單一地址拆成行政區與街道；這需要解析規則和失敗時的回退欄位，否則格式變動就會漏字。多個來源欄寫到一個目標欄時，則要規定來源優先順序、缺值處理與衝突處理，避免最後寫入的空欄覆蓋先前有效資料。若 CRM 的資料模型無法無損承接來源資訊，應保留原文於備註或來源欄位，並標示其用途。判斷拆併是否合適，可問兩件事：日後會不會單獨搜尋或排序？是否需要回寫表單？答案不同，就可能需要保留結構化欄位而不是合成一段文字。

記錄轉換規則

轉換規則要能由另一位維護者照著重現。以 Email 為例，規格可以是移除首尾空白、將英文字母轉小寫、檢查只有一個合理的 @ 分隔並保留原始輸入供錯誤追查；格式不合時進入錯誤佇列，不要猜測或自動補網域。電話只去除規定的空格或括號，是否保留加號、分機如何存放，都需明訂；不可把它轉成數值。選項欄位要列出來源值到目標值的完整對照，未知選項採拒收、保留原文或送人工確認三者擇一，不能默認轉成最接近的選項。

文字標準化也要克制。大小寫、全半形、換行和特殊符號可以依目標限制處理，但姓名、公司名和地址不應因「看起來整齊」就改寫；去除首尾空白與改變內容是兩回事。日期需選定來源時區、目標時區和無時區輸入的解讀方式，否則同一日期在轉換後可能落到前一天。若來源型別轉換失敗，錯誤應指出欄位、原始值類型與預期格式，並保留可安全追查的識別資訊；不要只回報「同步失敗」，讓排錯者無法定位原因。

規則文件宜採「來源條件 → 轉換 → 目標值 → 失敗處理」格式，並列出一筆正例與反例。例如需求類型的來源值若為「產品諮詢」，只有在映射表列有完全對應的目標選項時才寫入；新的來源值先回報待維護，而不是由相似文字自動歸類。另需分清資料驗證與資料修補：驗證指出不符合規格，修補則改動原值，後者應有明確依據與留痕。每次修改規則都記錄版本、負責人與影響欄位，並先對測試樣本比較轉換前後，避免看似小改動改變既有資料含義。

指定同步方向與觸發

同步方向要逐欄指定，不能只寫「表單與 CRM 雙向同步」。新詢問資料通常由表單流向 CRM；CRM 補充的公司分類、負責人或後續狀態，是否回到表單端則需分別決定。把欄位分成來源主控、CRM 主控、只新增不更新、雙向但有衝突規則四類，並指出哪個系統是每欄的權威來源。若兩邊都能編輯同一欄，必須寫明何者優先、何時比較版本或由誰裁定；否則同步循環可能讓舊值來回覆寫。本文的假設表單欄位可由表單主控，CRM 的業務註記則留在 CRM，不把整筆記錄互相複製。

觸發條件需說明何時送出、何時略過、失敗如何重試。可將成功送出表單作為建立事件，但要定義必填檢查在送出前或送出後進行；資料更新則應指出哪些欄位變更才觸發，避免每次編輯都重送相同內容。每筆提交應有穩定的來源識別碼，重試時用它辨認同一事件，避免網路中斷後建立重複聯絡人。若無法找到目標紀錄，是建立新資料、暫停等待人工，還是依另一個明確鍵值查找，也要在映射規格中決定。

實務文件還需記錄成功、部分成功與失敗的處理責任。部分欄位拒收時，是整筆停止還是只跳過該欄？重試是否可能重複新增？錯誤由誰查看、如何辨識已處理事件？這些決策影響資料完整性，不能留給排程或串接工具的預設行為。建議先從單向、單一觸發開始，確認映射與去重正確後，再逐欄擴大；若需雙向，至少用欄位主控權與更新時間或版本規則處理衝突，並在每次同步紀錄事件識別碼、方向、結果及錯誤欄位。這使團隊能重播單一事件、定位責任，而不是整批覆蓋資料。

用邊界樣本驗證

上線前準備一組刻意涵蓋邊界的測試資料，逐筆比對來源值、轉換結果、目標欄位與同步紀錄。不要只拿每欄都有值的理想樣本；最容易暴露映射問題的是空值、格式邊界、未知選項、重送和目標端已有舊資料。測試環境若不可用，可先在不送出寫入的預覽模式檢查轉換結果；若沒有預覽能力，就用不會影響正式資料的隔離測試紀錄。確認每個測試案例都能對應到欄位表中的一條規則，否則新增的特例要先補回規格。

可用以下假設樣本檢查決策是否一致：姓名前後帶空白時，目標是否只去除首尾空白；電話以 0 開頭時，儲存後是否仍保留；Email 全大寫時，是否依規則正規化；空字串、純空白與 null 是否都採同一空值政策；未知需求選項是停止、保留或送人工；同一 form_id 重送時是否辨識為同一筆；既有 CRM 欄位已有人工值而表單送空時，是否保留。這些案例不代表特定 CRM 的實際能力，而是用來驗證你選定的規格。

驗證時為每個案例記錄預期結果、實際結果、差異與修正責任人；修正後重新跑受影響案例，也回歸檢查原本通過的欄位。特別檢查拆併欄位能否還原原始資訊、未知值是否留下可處理的錯誤、重試是否產生重複資料，以及更新事件有沒有覆蓋 CRM 主控欄位。驗收條件應可觀察，例如指定來源鍵寫入指定物件、空值依建立／更新規則處理、拒收案例有欄位級錯誤、重送沿用既有識別，而非只說「資料看起來正常」。下一步可先拿一筆測試提交，把每欄映射、空值結果和同步方向填入表格，再到 ZhenheAI 官網 查看品牌目前的流程相關資訊。