Day5-人機協作找答案 – AI引導下的系統量化之路(上)

昨天分享了訪談階段理想與現實的差距,以及我們決定轉向量化的重要決策。今天要接續這個故事,深入聊聊我們如何與AI協作,從眾多變數中找到量化的核心焦點,並最終決定自主開發追蹤系統的完整過程。

量化範圍的關鍵決策:為什麼只專注「訂單建立」?

在決定進行量化後,我們面臨的第一個問題是:要量化哪個部分?

從訪談中發現的不可控因素

回顧之前的訪談和觀察,我們發現整個銷售流程中充滿了太多變數:

客戶諮詢階段的變數:

  • 有些客戶很明確知道要買什麼,決定快速,流程簡單
  • 有些客戶需要搭配多樣商品,諮詢時間長,比較複雜
  • 客戶的決策風格差異很大:有人當場決定,有人需要回家考慮

系統架構的限制:

  • 目前詢價功能在不同系統中
  • 庫存查詢也是獨立的系統
  • 這些外部查詢的時間很難精準追蹤

環境因素的影響:

  • 門市忙碌程度不同
  • 其他客戶的干擾

與AI討論量化範圍的確立

面對這麼多變數,我帶著困惑向Claude請教:

我的 Prompt:

“我們想要量化銷售流程,但發現前段的客戶諮詢時間變數太多,包括客戶決策風格、商品複雜度、外部系統查詢等。請協助我們思考,應該聚焦在哪個環節進行量化會比較有意義?”

Claude的分析建議:

  • 建議聚焦在「可控制」且「標準化」的流程環節
  • 客戶確定購買後的訂單建立流程相對穩定
  • 這個環節的時間長短更能反映系統效率問題
  • 可以排除客戶決策因素的干擾

這個建議讓我們有了明確的方向:專注量化「客戶確定下單後,業務建立訂單的完整過程」。

訂單建立流程的核心價值

我們之所以選擇這個範圍,是因為它能揭露幾個關鍵問題:

流程卡點的識別:

  • 是否在輸入客戶地址時卡很久?需要確認電梯、樓層等配送資訊
  • 商品加入訂單的步驟是否耗時?可能需要重複查找商品編號
  • 促銷計算是否造成延遲?複雜的折扣規則可能讓系統變慢

操作習慣的觀察:

  • 業務是否習慣先建立客戶資料,還是先加入商品?
  • 在訂單建立過程中,是否經常需要中途修改?
  • 付款資訊的填寫是否順暢?

系統問題的暴露:

  • 哪些頁面載入速度較慢?
  • 哪些操作容易導致系統錯誤?
  • 流程中是否有不必要的重複步驟?

發現關鍵問題:反覆編輯的時間成本

真實場景的觀察

在實地觀察中,我們發現了一個特別有趣的現象:

典型的「反覆編輯」情境:

  1. 業務開始建立訂單,加入客戶指定的商品
  2. 進行到付款資訊填寫時,客戶突然說:「等等,我想再加一個抱枕」
  3. 業務需要回到商品選擇頁面,重新搜尋和加入商品
  4. 商品加入後,發現促銷規則改變了,需要重新計算價格
  5. 回到付款頁面,才發現客戶又想要修改配送地址

這個現象背後的意義

對業務人員的影響:

  • 增加不必要的操作時間
  • 容易產生操作錯誤
  • 影響服務其他客戶的效率

對客戶體驗的影響:

  • 等待時間變長,客戶不耐煩
  • 頻繁的系統操作讓客戶懷疑專業度
  • 可能影響最終的購買決策

對系統設計的啟發:

  • 流程設計是否過於線性?
  • 是否缺少「暫存」和「預覽」功能?
  • 能否在不同步驟間更靈活地切換?

與AI協作:確立技術解決方案

既有工具的評估

有了明確的量化目標後,我們開始評估實作方案。第一個想法當然是:有沒有現成的工具可以使用? 於是再次向 Claude 請教:

我的 Prompt:

“目前市面上的工具可以量化銷售流程嗎?如果有,請列出幾個我們可以測試的工具,並簡易說明原因嗎?”

Claude提供的市面上選擇有很多:

  • Google Analytics:最常見的網站分析工具
  • Hotjar:使用者行為分析和熱力圖
  • Mixpanel:事件追蹤分析
  • LogRocket:使用者會話錄製
  • Crazy Egg:點擊熱力圖分析

根據AI建議進行實際測試

拿到Claude的工具清單後,我們逐一測試和評估各種工具是否符合我們的需求。 經過一輪工具測試,我們發現標準化工具都無法完美滿足需求。於是我再次向Claude請教:

AI建議的自製方案

向Claude詳細說明我們的需求後,得到了具體的技術建議:

我的完整 Prompt:

“我們想追蹤訂單建立流程中每個步驟的時間,特別關注:1)客戶資料輸入耗時 2)商品加入訂單耗時 3)反覆編輯的頻率和時間成本 4)付款資訊填寫耗時。現有的GA和Hotjar都無法滿足這些精細化需求,請建議技術實作方案。基於我們的系統架構,我目前比較傾向使用 Google Sheets、Google Apps Script 和 GTM 來做記錄,你覺得這個方式可行嗎?”

Claude的解決方案:

  1. 使用GTM管理追蹤代碼

    • 不需修改現有系統核心程式
    • 可以靈活調整追蹤邏輯
    • 支援自定義事件和變數
  2. Action Scripting記錄關鍵節點

    • 在每個重要操作點植入時間戳記錄
    • 可以追蹤「進入」和「離開」每個步驟的時間
    • 記錄操作類型(新增、編輯、刪除)
  3. Google Sheets作為資料倉庫

    • 即時同步,方便多人查看
    • 內建圖表功能,快速產生分析報表
    • 成本低,不需額外的資料庫投資

你預想的方式是可行的,需要我協助你設計追蹤節點嗎?

與Claude協作設計追蹤節點

這時我意識到一個重要點:Claude並不知道我們的系統實際長什麼樣子。如果只是簡單回答「好的」,他可能會基於想像設計出一套與我們真實系統不符的追蹤節點。

於是我詳細向Claude說明了我們的實際操作流程:

我的完整 Prompt:

“好,請幫我設計追蹤節點。我建立訂單的流程是:訂單管理頁 → 點選創建訂單 → 點選創建新客戶 → 客戶email填寫 → 配送資料填寫 → 新增產品 → 其他欄位填寫 → 建立訂單。這裡都還不要寫程式喔,我們都單純規劃就好。”

注意: 這裡不是單純地告訴他 yes 或 no,而是要詳細說明你的系統操作流程,才能夠讓他設計出正確的追蹤節點,否則他會想像一套流程設計給你,那麼就脫離了我們目前系統的操作流程了。

我也特別告訴他「這裡都還不要寫程式喔,我們都單純規劃就好。」,這樣他就知道我們目前只會先規劃,不會真的寫程式,他也知道我們目前的進度和需求,這樣才會設計出正確的追蹤節點。

Claude提供的詳細追蹤節點設計

T1 – 進入訂單管理頁

  • 觸發時機:使用者進入訂單管理頁面
  • 記錄目的:標記訂單流程的起始點
  • 重要性:建立整個流程的基準時間

T2 – 點選創建訂單

  • 觸發時機:點擊「創建訂單」按鈕
  • 記錄目的:真正開始訂單建立流程
  • 重要性:區分「瀏覽」和「實際操作」的時間

T3 – 點選創建新客戶

  • 觸發時機:選擇「創建新客戶」選項
  • 記錄目的:進入客戶建立流程
  • 重要性:追蹤決策時間(新客戶vs既有客戶)

T4 – 客戶email填寫完成

  • 觸發時機:完成email欄位填寫並移至下一步
  • 記錄目的:追蹤客戶基本資料輸入耗時
  • 重要性:電子郵件格式驗證可能造成延遲

T5 – 配送資料填寫完成

  • 觸發時機:完成配送地址等資料填寫
  • 記錄目的:追蹤配送資訊處理時間
  • 重要性:這個步驟容易卡關(電梯、樓層確認)

T6 – 產品新增完成

  • 觸發時機:完成所有產品的新增
  • 記錄目的:追蹤商品選擇和加入的總耗時
  • 重要性:最容易發生反覆編輯的環節

T7 – 其他欄位填寫完成

  • 觸發時機:完成訂單的其他必要欄位填寫
  • 記錄目的:追蹤最終資料完整性確認時間
  • 重要性:付款方式、備註等資訊的處理時間

T8 – 訂單建立完成

  • 觸發時機:成功建立訂單
  • 記錄目的:標記整個流程的結束點
  • 重要性:系統處理和儲存訂單的時間

下一步:量化數據的系統實作

根據以上 Claude 設計的追蹤節點,我們就可以開始進行實際的實作了。

明天我們將分享與AI協作建立實際追蹤系統的過程,讓我們期待明天的分享吧!

這個從「理論規劃」到「實際實作」的轉變,將展現AI如何在技術實作層面提供具體的協助,以及人機協作在解決真實業務問題上的實際價值。

與AI協作的價值反思

AI在決策過程中的關鍵貢獻

問題聚焦: Claude幫助我們從眾多變數中找到最有價值的量化焦點,避免了「什麼都想測量」的陷阱。

技術指引: 提供了具體可行的技術解決方案,讓我們不用從零摸索GTM和Action Scripting的實作細節。

風險提醒: 指出了實作過程中可能遇到的技術和營運挑戰,讓我們提前準備應對策略。

人機協作的最佳實踐

人類的價值:

  • 深度理解業務場景和實際需求
  • 判斷哪些數據對業務決策真正有意義

AI的價值:

  • 提供技術實作的具體建議
  • 分析不同方案的優缺點
  • 預測可能的實作風險和解決方案

協作的關鍵:

  • 向AI提供足夠詳細的上下文資訊
  • 不斷迭代和優化提問的方式
  • 將AI建議與實際情況結合判斷