PROJECT 02

問卷 × CRM 跨系統串接:會員服務的閉環工程

問卷收得回來,服務跟不上去——因為填答是匿名的、流程是斷裂的。這一頁收錄兩個代表案:日系連鎖零售品牌的「問卷自動建 CRM 工單並綁定會員」,與國際電腦硬體品牌的「Zendesk × FedEx × OneDrive 保修流程」。這類客製整合我在 4 年間交付了 130+ 件,每件都由我完成訪談、規格與交付協調。

WebhookCRM APIZendeskFedEx API會員 mapping規格文件

角色:需求訪談・方案設計・規格撰寫(User Story/Flow/Infra)・交付協調

案例一:日系連鎖零售品牌——問卷自動建 CRM 工單、綁定會員

客服問卷回收後,客服人員看到的是一張張匿名表單,無法對回會員、也無法在 CRM 裡跟進。方案讓問卷送出後自動變成「掛在正確會員名下的 CRM 工單」:

整體流程(高階視角)
flowchart LR
  subgraph G1["顧客"]
    A["填寫客服問卷"]
  end
  subgraph G2["自動化系統"]
    B["自動認出
他是哪位會員"] C["自動建立 CRM 工單
掛在他的名下"] end subgraph G3["客服"] D["帶著完整脈絡
直接跟進"] end A --> B --> C --> D
這個案子的售前價值在需求收斂:客戶最初的需求只有一句「串接 CRM」。經訪談收斂成「後台自助註冊+兩支 API 呼叫順序+標籤對應約定」三條規格後,工程團隊據此精準估出 1.75 人天——收斂品質直接決定估時精度與報價說服力。
工程視角:技術時序圖(點開展開)
sequenceDiagram
  autonumber
  actor C as 顧客
  participant SC as 問卷平台
  participant BS as BS 後端(轉接層)
  participant CRM as 品牌 CRM 系統
  actor CS as 客服人員
  Note over BS: 前置:品牌於 BS 後台自助註冊問卷
(svid/hash key/IV key) C->>SC: 填寫並送出客服問卷 SC->>BS: Webhook 通知(svid+hash) BS->>BS: 以 hash key/IV key 還原加密填答 BS->>BS: 依標籤約定(如 crm_subject)
組裝 API 參數 BS->>CRM: 「搜尋客戶」API(以填答 email) CRM-->>BS: 回傳會員編號 alt 查得會員 BS->>CRM: 「建立工單」API(帶會員編號) Note over CRM: 工單自動掛在正確會員名下 else 查無會員 BS->>CRM: 「建立工單」API(不帶會員參數) end CRM-->>CS: 工單出現於客服佇列 CS->>CRM: 直接以會員完整脈絡跟進

案例二:國際電腦硬體品牌——保修申請的跨系統自動化

保修索賠流程原本需要人工在多套系統間搬運:客服開工單、確認寄件地址、歸檔證明文件。方案把它串成一條自動化流程——其中 FedEx API 的角色是在填答階段即時驗證寄件地址是否符合物流格式,把「地址寫錯、包裹寄丟」擋在源頭:

整體流程(高階視角)
flowchart LR
  subgraph H1["顧客"]
    A["填寫保修申請"]
    C["當場修正地址"]
    E["感謝頁上傳
購買證明"] end subgraph H2["自動化系統"] B{"寄件地址
符合物流格式?"} D["自動開立
客服工單"] F["證明文件
自動歸檔雲端"] end subgraph H3["客服"] G["接手處理
全程零人工搬運"] end A --> B B -- "不符" --> C --> A B -- "符合" --> D --> E --> F --> G

Demo 影片:問卷串接 Zendesk

實際操作錄影:問卷送出 → Zendesk 工單自動建立的完整流程。

本案的三張規格工單(問卷串接 Zendesk/感謝頁上傳 OneDrive/感謝頁驗證邏輯調整)與 Zendesk 串接技術文件均由我撰寫。
工程視角:技術時序圖(點開展開)
sequenceDiagram
  autonumber
  actor C as 顧客
  participant SC as 保修申請問卷
  participant BE as 整合後端
  participant FX as FedEx API
  participant ZD as Zendesk
  participant OD as OneDrive
  C->>SC: 填寫保修申請(含寄件地址)
  SC->>BE: 地址欄位驗證請求
  BE->>FX: 地址驗證 API
  FX-->>BE: 是否符合物流格式
  alt 地址格式不符
    BE-->>C: 即時提示修正後再送出
  else 格式正確
    C->>SC: 送出申請
    SC->>BE: Webhook 觸發
    BE->>ZD: 建立保修工單
    C->>SC: 感謝頁上傳購買證明/故障照片
    SC->>BE: 檔案接收
    BE->>OD: 自動歸檔(權限隔離)
    ZD-->>C: 客服於既有系統接手後續
  end

規模與方法論

130+ 件客製整合的方法論

  • 每件從訪談開始:把模糊需求收斂成 User Story、Flow、Infrastructure 需求與驗收條件
  • 規格工單格式統一:前情提要/User Story/Flow/Spec/時程——工程師可直接估時
  • 共通需求推動產品化:審核放行、Referral API——客製變標準功能
  • 其他代表案:跨國 FMCG(Salesforce 自動派工)、國際汽車品牌、半導體 IC 設計大廠、社福基金會

成果

  • 客服看到的從匿名表單變成會員完整脈絡——服務閉環真正跑起來
  • 地址錯誤在填答階段即被攔截,保修流程零人工搬運
  • 4 年 130+ 件客製規格全數交付