在數(shù)字化轉(zhuǎn)型的浪潮中，電商售后作業(yè)的自動化成為提升客戶服務(wù)質(zhì)量和效率的關(guān)鍵。本文深入探討了售后作業(yè)自動化的現(xiàn)狀與挑戰(zhàn)，分析了咨詢類和售后作業(yè)處理類兩大類售后作業(yè)的特點，并提出了利用OCR、區(qū)塊鏈、AI等先進技術(shù)優(yōu)化售后流程的具體方案。

隨著數(shù)字化轉(zhuǎn)型的推進，“云移大物智”技術(shù)的迭代速度的加快，電商售后的場景更加的豐富，僅依靠傳統(tǒng)的“被動響應(yīng)”來解決售后問題已經(jīng)無法滿足企業(yè)對于客戶服務(wù)的需求，越來越多的企業(yè)正在尋求“主動預(yù)防”來提升售后作業(yè)的效率，確保電商售后場景的安全，提升用戶的體驗。

售后作業(yè)大體可定義為兩個方面：

1. 咨詢類
2. 售后作業(yè)處理類

下面，將對這兩類作業(yè)進行解析，并分析如何應(yīng)用新技術(shù)來提升作業(yè)效率，重塑企業(yè)面向消費者的服務(wù)體系。

咨詢類

簡單來說，就是消費者主動發(fā)起的咨詢動作，用來解決「產(chǎn)品如何使用？」、「售后/物流進度？」、「條款/政策是什么？」、「專業(yè)技術(shù)咨詢或答疑？」等的一些類咨詢服務(wù)。

這類作業(yè)必然的要求是快速響應(yīng)、可通過知識庫/FAQ來減少重復(fù)性的咨詢、對一些高頻問題可反哺產(chǎn)品功能或性能優(yōu)化

一款产品无到有，产品经理需要做些什么？

在一个产品从无到有的过程中，要做好产品经理这个角色实在是不容易，除了大家都知道的写需求、写需求、写需求，要做的事多着呢。产品经理不是你眼中的只会找你麻烦，提要求..

查看详情 >

在咨詢類作業(yè)中，常使用的電商的客服體系。傳統(tǒng)類的電商客服服務(wù)流程是智能客服+人工客服協(xié)同，通常采用的流程如下：

這種模式下，存在以下問題：

• 答非所問，對于一些復(fù)雜的多條件的問題，或者使用方言進行描述的問題，智能客服無法解決，需要反復(fù)轉(zhuǎn)人工，造成服務(wù)時間延長。
• 對于一些新的業(yè)務(wù)問題或者比較小眾的問題，智能客服可能會一直回復(fù)“我不明白”，或者循環(huán)的點擊菜單
• 當(dāng)在高峰期咨詢量激增時，用戶會一直在排隊中，或者等待的時間過長，從而直接影響了購物體驗
• 當(dāng)人機層協(xié)同斷層時，會出現(xiàn)問題重復(fù)提交，缺乏對上下文的理解，影響的用戶的售后體驗
• 除此之外，智能客服的數(shù)據(jù)與人工客服的數(shù)據(jù)存在數(shù)據(jù)孤島，導(dǎo)致人工無法提前預(yù)判當(dāng)前用戶的情緒或者歷史的問題。

……

等等。

隨著大模型的誕生，衍生除了諸多的AI客服系統(tǒng)，但是目前大部分的AI客服還停留在SOP模型或者Copilot協(xié)作模式，其中Copilot模型指的是，系統(tǒng)內(nèi)設(shè)定任務(wù)目標(biāo)，其中標(biāo)記某幾個任務(wù)由AI完成初稿，人類來進行修改并確認(rèn)調(diào)整的人類+AI協(xié)同工作模型。

但是也會出現(xiàn)，前后端沒有配置，就無法回答、只能機械式的完成單論的問答、使用一些幻覺問題來誤導(dǎo)用戶、答非所問情況依然存在。

為了讓AI客服更加的智能化，出現(xiàn)了很多新的解決方案，如可利用抖音的Coze 平臺、fastgpt等平臺創(chuàng)建客服Agents來構(gòu)建AI客服場景下的人機協(xié)作的新服務(wù)范式。這種范式是由人類設(shè)立目標(biāo)并提供相應(yīng)的資源，由AI全權(quán)代理。

在這種模式下

• AI智能客服可以直面面對用戶，未用戶提供服務(wù)。通過智能體，結(jié)合之前的規(guī)劃過程中累積的常見問題以及對應(yīng)的問題解決方案，不僅能夠更快的回答客戶，還能越“訓(xùn)練”越“準(zhǔn)確”，甚至有些一部分場景甚至可以完全的取代人工。
• 在回復(fù)內(nèi)容存在風(fēng)險的情況下，真人客服可以對AI回復(fù)的內(nèi)容進行人工監(jiān)管。同時通過評分標(biāo)準(zhǔn)，來有效的評估模型的能力以及評估坐席干預(yù)的合理性，即“AI回答的好不好”、“人工客戶糾正的對不對”。

以抖音的Coze平臺創(chuàng)建智能客服為例，對應(yīng)的系統(tǒng)架構(gòu)如下。

在以上架構(gòu)下，如何將傳統(tǒng)的客服的工作智能，抽象為可以數(shù)據(jù)化和智能化的服務(wù)主體，一般可以采取如下步驟

步驟1：解構(gòu)客服的服務(wù)流程

步驟2：工作流架構(gòu)的抽離設(shè)計

2.1 主流程來串聯(lián)完整的服務(wù)鏈路，判斷繪畫的基本面并通過路由，流轉(zhuǎn)到響應(yīng)的Agent；

2.2 在Agent節(jié)點上，由于該節(jié)點是可以承接處理的智能的，故進行階段設(shè)置的時候，需要包含寒暄、收尾、問題澄清、場景路由、判斷解決方案、協(xié)商方案、執(zhí)行方案等。

2.3 配置節(jié)點，如配置知識庫節(jié)點、判斷條件配置、LLM模型參數(shù)配置等

2.4 代碼節(jié)點，如IM通信、特征解析、實驗參數(shù)的獲取等。

售后作業(yè)處理類

簡單來說，就是需要公司主動介入的來解決的實質(zhì)性售后問題，一般情況可能會涉及到工單系統(tǒng)或者線下操作。常見的售后作業(yè)場景有：

1. 維修服務(wù)類，比如對硬件的檢測及部件的更換、軟件BUG的修復(fù)等等
2. 退換貨服務(wù)類，比如僅退款、退款退貨、補貨、換貨、售后物流的咨詢、售后工單的審核咨詢等等
3. 投訴處理類，比如問題需要升級投訴、投訴的賠償協(xié)商、投訴引發(fā)的情緒的安撫
4. 現(xiàn)場服務(wù)類，比如家電的送貨上門并安裝服務(wù)、設(shè)備的檢修和巡檢等

等等，這些售后作業(yè)都需要依賴標(biāo)準(zhǔn)的流程的，比如退換貨服務(wù)中的質(zhì)檢環(huán)節(jié)等；是會依賴工單系統(tǒng)的，通過工單系統(tǒng)來協(xié)調(diào)技術(shù)人員等；重視業(yè)務(wù)的閉環(huán)反饋，如滿意度調(diào)查等。

通過對當(dāng)前主流的電商平臺的售后作業(yè)自動化進行調(diào)研，其中調(diào)研內(nèi)容如下：

在調(diào)研中發(fā)現(xiàn)，目前主流的電商廠商已經(jīng)在售后作業(yè)流程中一個或者多個節(jié)點應(yīng)用了先進的“云移大物智”技術(shù)重塑了作業(yè)流程，使其實現(xiàn)了自動化，做到了“預(yù)防為主，響應(yīng)為輔”。

所謂“功欲利其器，必先利其器”，下面舉例說明如何利用這些先進的工具改進售后業(yè)務(wù)。

場景1：利用OCR技術(shù)來識別退貨商品的信息，來提升退貨質(zhì)檢流程。

在OCR識別過程中

Step1，做圖像采集，常用的拍攝工具有手機、RF槍、掃描儀、工業(yè)相機等；拍攝掃碼的內(nèi)容有<商品標(biāo)簽>、<商品條形碼>、<發(fā)票>、<退貨單>等。拍攝時要求盡量保持背景簡單、確保拍攝的內(nèi)容能夠足夠的清晰，內(nèi)容確保完整，避免出現(xiàn)反光或者光線不足造成無法識別的情況；

Step2，圖像預(yù)處理這步，主要是用來優(yōu)化圖像的質(zhì)量，來進一步提升OCR識別的準(zhǔn)確率。預(yù)處理常用的工具有OpenCV、PIL，預(yù)處理的關(guān)鍵步驟有：圖像灰度化，來減少計算的復(fù)雜度；二值化，通過閾值的處理，將圖像轉(zhuǎn)為黑白色，來進一步突出文字的區(qū)域；降噪，主要是用來去除噪點；傾斜校正，如果圖像傾斜，則使用霍夫變換或者邊緣檢測來矯正圖像的傾斜度；銳化，這步主要是增強文字的邊緣的清晰度；區(qū)域剪裁，這步就是僅保留包含退貨信息的區(qū)域。

Step3，OCR文本識別這步，是從Step2這步處理后的圖像中處理相關(guān)的文字信息，通過通用的OCR引擎或者定制化的OCR模型來輸出結(jié)構(gòu)化或者半結(jié)構(gòu)化的文本數(shù)據(jù)，輸出類型為JSON或者CSV格式。

Step4，信息解析與提取這步，是根據(jù)Step3輸出的文本數(shù)據(jù)，使用正則表達式或自然語言處理或者企業(yè)內(nèi)置的模板來匹配并提取出關(guān)鍵的字段，一般退貨的關(guān)鍵字段有<訂單號>、<商品SKU>、<退貨數(shù)量>、<退貨原因>、<客戶ID>、<退貨日期>等。

Step5，數(shù)據(jù)驗證與糾錯這步，是確保提取出的信息與系統(tǒng)中的數(shù)據(jù)進行匹配，確定存在的。通過系統(tǒng)內(nèi)置邏輯來檢驗是否正確，比如退貨數(shù)量是否為數(shù)字、退貨原因是否為系統(tǒng)預(yù)設(shè)的原因，如“破損”等。識別通過后，如果存在置信度低的識別結(jié)果，則需要轉(zhuǎn)人工進行審核，并且需要標(biāo)注該條數(shù)據(jù)人工參與了審核以及審核的原因等。

通過這一些列的操作，可以顯著的減少人工錯誤率，但這并不能一勞永逸，也需要不斷的結(jié)合實際的業(yè)務(wù)場景對涉及的模型進行持續(xù)的優(yōu)化，需要特殊說明，消費者個人的敏感信息需要嚴(yán)格保密。

場景2：利用區(qū)塊鏈+AI技術(shù)，通過記錄碳足跡來優(yōu)化逆向物流路徑

在數(shù)據(jù)輸入過程中

Step1,物流環(huán)節(jié)數(shù)據(jù)指的是：在運輸工具上（汽車、卡車、船舶等）、倉庫中，部署傳感器，傳感器用來實時的采集運輸工具的<燃料消耗>、<運輸里程>、<路線>、<載重>、<速度>；倉庫的<溫度>、<耗電>等、貨品的包材、貨品的數(shù)量等等數(shù)據(jù)，并安裝GPS，使用GPS來跟蹤運輸工具的運輸路徑。外部數(shù)據(jù)指的是：第三方的碳排放因子數(shù)據(jù)庫或者能源供應(yīng)商的綠色能源認(rèn)證數(shù)據(jù)。

Step2,獲取到Step1的數(shù)據(jù)后，對數(shù)據(jù)進行清洗，清洗出異常值。對碳排放進行計算，公式為：碳排放量=活動數(shù)據(jù)×排放因子

Step3,計算到碳排放量后，開始將相關(guān)的數(shù)據(jù)上鏈，可以選擇聯(lián)盟鏈（Hyperledger Fabric）或者公鏈（以太坊）都行，依據(jù)需求而定。利用智能合約技術(shù)，校驗數(shù)據(jù)格式并上鏈，確保數(shù)據(jù)不可被修改。常見的可上鏈的格式如下

{

“timestamp”: “2025-03-27T14:30:00Z”,

“transport_id”: “TRUCK-001”,

“route”: “從北京倉庫到天津分揀中心”,

“distance_km”: 166,

“fuel_used_l”: 34,

“co2_kg”: 121,

“block_hash”: “0x3a7b…d41c”

}

并采用PBFT實用拜占庭容錯技術(shù)或者PoA權(quán)威證明技術(shù)來驗證數(shù)據(jù)在多參與方的數(shù)據(jù)都是一致的。

在輸入數(shù)據(jù)中，我們需要考慮運輸工具的容量、倉庫的處理能力、碳排放的上限、交通的情況、天氣的情況等，基于這些條件下，秉承成本最優(yōu)的原則，計算出最優(yōu)的路線。

在構(gòu)建模型的時候，將路徑的規(guī)劃轉(zhuǎn)化為多目標(biāo)的優(yōu)化問題，支持VRP變種?？赏ㄟ^使用強化學(xué)習(xí)算法RL訓(xùn)練智能體在動態(tài)的環(huán)境中如何快速的做決策；通過遺傳算法GA生成路徑，并持續(xù)迭代的優(yōu)化路徑；通過圖神經(jīng)網(wǎng)絡(luò)GNN算法處理復(fù)雜節(jié)點的關(guān)系，比如與倉庫的關(guān)系、與客戶的關(guān)系等關(guān)系拓撲圖。

分配路徑，調(diào)度資源后，車輛在實際的運輸?shù)倪^程中，可以根據(jù)交通的擁堵情況、天氣情況、訂單的狀態(tài)等各種因素來實時的調(diào)整實際的運輸路線，之后，實際的運輸路線以及實際的碳排放量都會被寫入?yún)^(qū)塊鏈，形成驗證閉環(huán)。

等等，除這兩個場景外，還有諸多的場景中都運用了先進的科技技術(shù)，但是需要技術(shù)帶來的風(fēng)險和挑戰(zhàn)。比如AI風(fēng)控模型可能會誤判低信用用戶，所以在AI風(fēng)控的場景下需要持續(xù)的對模型進行校準(zhǔn)和優(yōu)化。消費者行為數(shù)據(jù)的上鏈或者運輸數(shù)據(jù)的上鏈的時候，需要確保行為是符合GDPR等相關(guān)的法律法規(guī)的，也確保消費者的隱私協(xié)議必須符合平臺的規(guī)則的。