首页
/
每日頭條
/
生活
/
工單管理開源
工單管理開源
更新时间:2024-09-28 22:19:13

編輯導語:在售後業務、快遞業務和社區團購等業務場景,利益糾紛問題極易出現。産品經理遇到利益糾紛問題時應該怎麼解決?這篇文章提供了一套完整的“申訴-審核工單流”,以及具體介紹了設計搭建工單流需要解決的五個問題。一起來看看吧!

工單管理開源(申訴-審核工單流)1

作為一名B端産品經理,當你負責的業務涉及多個角色參與方之間利益的時候,是否會陷到入很多實物或者虛拟交接環節“公說公有理,婆說婆有理”的尴尬境地。由于這個“誰也說不清”的灰色地帶存在,業務場景反饋出來的信息以及數據會極度失真,導緻産品負責人對該場景業務的利益錯付,甚至産品長期存在經濟或者業務指标上的嚴重損失。

“利益糾紛”問題存在比較典型的業務場景主要有售後業務、快遞業務以及現在風頭正盛的社區團購。為了大家更好地了解現在電商風口,下面會使用社區團購中的真實case來給大家輔助解釋産品設計方法。社區團購現在的利益方以及交接過程如下,先不做過多介紹,大家一眼便可看明白:

工單管理開源(申訴-審核工單流)2

言歸正傳,當産品遇到“利益糾紛”問題,且所在業務的多個利益角色之間滿足以下關系的時候,就需要涉及一套完整的“申訴-審核工單流”,來可靠地解決這個“誰也說不清”的灰色地帶:

  1. 多角色之間有業務環節承接關系:隻有兩個角色之間同時參與某一個環節的運作,其中一方的利益才會對另外一方産生影響。
  2. 多角色之間存在利益沖突:隻有存在利益沖突,才會促使各角色為了保全自己的利益,站在自己的立場上可以曲解事情發生的經過。
  3. 多角色之間有參與方和決策方:對應業務的運作,大部分角色都是業務的參與方,但是也一定需要一個對糾紛場景能起到最終決策作用的角色,這個角色一般是業務平台運營,甚至是業務産品本身。

在明确了哪些場景需要“申訴-審核工單流”來串聯各個角色之後,下面的重點是如果要搭建完整的“申訴-審核工單流”,你的PRD中到底需要給開發或者其他産品解釋清楚哪些東西。

為了搭建完整的“申訴-審核工單流”,需要妥善制定策略解決以下幾個問題:

  1. “申訴-審核工單流”的參與方以及參與作用
  2. 申訴方、審核方的申訴和審核标準
  3. “申訴-審核工單流”的流向制定
  4. “申訴-審核工單流”的時效限定
  5. “申訴-審核工單流”的狀态流轉
一、“申訴-審核工單流”的參與方以及參與作用

“申訴-審核工單流”中,主要的角色有兩個,分别是申訴方、審核方。

申訴方是指需要在此工單流中按照要求提供憑證進行申訴的一方;審核方是指根據申訴方所提供的憑證以及判斷标準進行審核并給出審核結果的一方。申訴方處在工單流的流程上遊,審核方處在流程下遊。隻有在申訴方提供了憑證之後,審核方才能進行審核操作。

在明确具體的申訴方和審核方之前,首先要知道你需要解決的業務場景參與方到底有哪些。根據這些參與方在業務流程中所起到的作用,以及相互的利益關系,來決定在審核流中所應該擔負的角色。

審核方需要一個中立的角色,需要站在天平中央來對憑證判斷并對結果負責,所以一般是平台的管理者或者運營者。申訴方一般是利益受損方,需要從自身角度,結合審核方要求,提供一些客觀憑證。

在社區團購中,主要環節包括供應商與倉庫的交付,倉庫與與服務站的交付,服務站與團點的交付。在這些交接流程中,每個環節都存在誰也說不清的灰色地帶,所以各個環節的貨物損失也是相當大。

就社區團購最後一環“服務站與團點”交付過程而言,可能存在一件商品,團點沒有收到的時候,團長和服務站站長都會站在自身的立場維護自己的利益,甚至不惜曲解事實。此時團長和服務站都是利益受損方,都應該作為申訴者,而隻有平台相關運營能作為決策者把握這個天平的平衡。

二、申訴方、審核方的申訴和審核标準

在線上進行的 “申訴-審核工單流”中,為了節省各環節操作成本,以及提升各環節操作有效性,需要制定标準的SOP來規定好申訴方舉證、備注的規範性,以及審核方根據憑證判斷的客觀性和公正性。

申訴憑證需要滿足一些基本特征,如:易采集、易辨别、高可信。

  • “易采集”保證了申訴方的低操作成本,不需要花費大量的時間和精力在憑證采集上。
  • “易辨别”可以保證憑證的有效性,即提升審核方的審核效率以及審核準确性。
  • “高可信”意味着提供的憑證必須剔除申訴方個人情感,避免出現為個人利益處罰,提供的一些失真的憑證。

在社區團購“服務站與團點”的交接中,團長通過售後動作表達了有商品缺貨之後,需要服務站從申訴者的角度來提供一些貨物是否送達團點的證據。證據可以是送達團長時團長簽字的交接單、事後跟團長電話确認的錄音、司機送貨到團點的圖片證據等等。但不是以上所有證據都很合适,都能滿足以上三個特征。

對于“送達團長時團長簽字的交接單”而言,具備易采集、易辨别的特征,但是不具備高可信。司機可能為了自身利益,随便仿造團長簽字。

對于“事後跟團長電話确認的錄音”也一樣,具備易采集、易辨别的特征,但是不具備高可信。因為通過音色,我們隻能大概率辨别是幾個人的聲音,但是不能判斷是否是團長和司機雙方各自的聲音。

對于“司機送貨到團點的圖片證據”,完美的具備以上三個特征,作為這個場景下的申訴材料再合适不過。

但是“易采集、易辨别、高可信”隻是挑選憑證的方式,決定了憑證之後,需要規定好其中必備的元素。比如對于服務站的舉證,随便拿一張貨物圖片肯定是不行的,需要這張照片上有一些基本元素:時間、地點、交付商品(且能看到有幾件)。服務站需要按照這個标準來準備憑證并上傳,才能最大限度地說明問題。

三、“申訴-審核工單流”的流向制定

“申訴-審核工單流”說到底是個流程,流程是個持續的過程,因此需要明确在每個節點,每個環節,數據的流向。“申訴-審核工單流”至少需要兩方參與,一個充當申訴方,一個充當審核方,當然也可能存在多個申訴方或者多個審核方。

對于多個申訴方,如果利益關系一緻,共同對損失負責,則需要互相感知數據和對方的操作,此時審核方也隻需要感知多個申訴方最終确認的結果;如果多個申訴方的利益關系相反,各自維護各自的損失,且互相對立,則不能感知對方的數據和操作,以免導緻申訴帶有對抗性。

這個情況下,審核方需要綜合兩個對立申訴方的憑證來作出判斷。

比如社區團購“服務站-團點”交接過程中,對于缺貨問題的舉證。本質上站長不直接跟團長交接,而站長雇傭的負責送貨的司機才是跟團長交接的實際角色。司機和站長完全是一根繩上的螞蚱,所以各自的申訴材料、申訴結果以及其他操作都應該互相可見。而這些細節并不需要全部都同步給審核方,隻要把他們最終達成一緻的憑證提交即可。但是對于團長和站長的舉證則不同,他們的憑證必須互相不可見,而且兩方的憑證必須都同步給審核方。

四、“申訴-審核工單流”的時效限定

“申訴-審核工單流”是為了制定一個線上流程,提供給各個角色以滿足申訴和審核的需求。隻有明确制定好各個環節的操作時效,才能有效收集證據,讓各個角色在合适的時間參與到流程中,完成角色在申訴-審核流中的義務。

為了細分各個角色的操作時效,首先應該根據這個工單流整體從開始到輸出結果所能占有的時間資源。時間資源需要根據業務所在的場景來做判斷。對于一些需要緊急得出結果,并有下遊使用方來緊急消費這個結果的,整體時效應該限制在某個時間範圍内。

但是整體時效也不是越短越好,還需要充分考慮各個角色操作所需要的最少時間。比如某個角色搜集憑證需要至少兩天,那麼整體審核時效就應該高于這個阈值。

對于社區團購中“服務站-團點”的交接流程而言,判斷是否缺貨的結果會影響是否給用戶退款(如果最終判斷缺貨,則給用戶退款;如果最終判斷非缺貨,則駁回用戶的退款要求)。而對于售後而言,售後時間是個重要考核指标,希望縮短用戶售後時長,提升用戶體驗,所以整體申訴審核流的時長上限可以定位為1天、2天等。

但這個過程中,有司機和站長同時參與申訴流程,平台運營參與審核流程。考慮到司機、站長和運營的工作和作息時間,雙方共同平分這整體的時間。此外,還需要對夜間的工單進行特殊操作,避免這段時間内,大家都在休息,無人申訴和審核的情況。

五、“申訴-審核工單流”的狀态流轉

狀态流轉是工單流中的靈魂,在以上幾個環節的設計結束之後,就應該根據以上規則,指定一套貼合的狀态流轉。隻有制定了一套完美的狀态流轉,才能讓流程參與者明确所在環節、所需操作和所面臨的問題。

狀态的定義需要充分體現三個方面:

  1. 明确現階段的操作角色:能一眼得出現在的環節停留在誰
  2. 明确現在所處審核流的環節:能一眼看出現在的環節需要怎麼操作
  3. 明确标記各異常場景:能一眼看出哪個環節出現了問題

對于社區團購中“服務站-團點”的交接流程而言,狀态可能會有:待服務站申訴、待運營審核、服務站申訴超時等。

六、結語

“申訴-審核工單流”是解決“誰也說不清”的灰色地帶的必背方案。為了更好地設計一套“申訴-審核工單流”,需要充分設計以上各個環節。在此基礎之上,需要再補充一些細節内容,比如說展示的方式、字段等等,才能更好地實現目标和解決問題。

本文由 @膜法獅 原創發布于人人都是産品經理。未經許可,禁止轉載。

題圖來自 pexels,基于 CC0 協議

,
Comments
Welcome to tft每日頭條 comments! Please keep conversations courteous and on-topic. To fosterproductive and respectful conversations, you may see comments from our Community Managers.
Sign up to post
Sort by
Show More Comments
Copyright 2023-2024 - www.tftnews.com All Rights Reserved