退貨申請怎麼核？先對訂單、政策和缺失證據

客戶寫“沒用過”，附件是一張包裝照片。運營要判斷退貨申請，還得查訂單、送達記錄、申請時刻和適用政策。這幾份材料回答的是不同問題。

可以用 Buda 搭建電商退貨分診工作流，根據訂單與獲批政策準備退貨處理建議。先提供授權匯出和明確稽核人，產物停在建議佇列；退款執行、訂單修改和客戶承諾另由負責人決定。

先固定規則，再算天數

下面採用虛構政策 P-R1：適用的普通商品在送達後 14 個經過日內、且未使用，可進入退貨稽核。演示假設稽核人已確認按連續經過時間計算、恰好第 14 天計入，所有時間均為 Asia/Shanghai；活動套裝須另審例外。這只是教學規則，實際操作須確認適用政策及消費者法定權利。

儲存政策批准記錄、生效區間、商品範圍和章節位置。檔案修改日期較新，不能單獨決定舊訂單適用哪版政策。發生適用爭議時，把候選版本與訂單依據一起交給政策負責人。

四份申請，不要落入一個“透過或拒絕”框

以下訂單、申請和證據均為虛構，沒有執行客戶處理。

R02 的空日期保持未知，不用任務執行時間替代申請時間。R03 的照片只證明畫面可見內容，包裝完整並不能自行補上“未使用”的事實。R04 即使申請及時，也還要確認套裝規則。缺證進入補問佇列，不直接寫成拒絕。

讓建議能被逐條複核

return-triage.csv 每行保留穩定申請 ID、訂單 ID、品類、來原始檔與行號、政策版本及章節、帶時區的送達與申請時間、狀態證據、例外項、建議佇列、待補問題和稽核人。已證實、缺失、衝突分列，避免一個空值承擔多種含義。

return-review.md 按條件解釋。R03 可以寫：“訂單第 3 行與申請記錄支援相隔 10 天；已收到包裝照片；未使用狀態仍待核；請客服按獲批流程詢問可提供哪些狀態證據。”客服得到下一步，不會誤把材料整理當成已批准退貨。

重複附件引用同一來源，不增加證據條數；同名客戶、同金額訂單不自動合案。新匯出糾正了舊時間時，保留舊稽核包，為受影響申請生成新版本。

把執行任務交清楚

只讀取授權訂單、申請記錄與獲批 P-R1 政策，生成 return-triage.csv 和 return-review.md。每個條件給來源位置。未知保持未知，標明版本衝突與套裝例外。不修改訂單、不退款、不聯絡客戶，只交運營負責人稽核的建議佇列。

在 Agent Workspace集中提供資料與輸出，另行配置任務實際獲准的資料和工具許可權。指令描述任務，不能代替系統許可權。先複核一份規則匹配、一份缺證、一份例外樣本，再沉澱輸入清單與輸出格式為可複用 Skill；需要現成 Skill 時，可在 Buda AI 的 Marketplace 搜尋安裝。

稽核時常見的三個問題

兩個系統時區不同怎麼辦？ 同時保留原時間和偏移，換算到約定時區後按政策口徑計算。只有日期、沒有時刻的邊界申請，交人確認。

贈品和套裝怎麼算？ 保留購買組合及贈品關係，先讓負責人確認退貨與金額分攤規則，再準備建議。

證據衝突或不滿足規則怎麼辦？ 並列保留來源與未滿足條件，轉交例外或售後負責人決定處理方式。不要為了消除衝突而選最寬鬆的政策。

先用四份歷史授權案例試跑，逐項複核建議是否有出處，再擴大批次。