B端產品經理接到客戶需求時,可能會踩哪些坑
本文講述了B端產品經理接到客戶需求時可能會踩的5個坑以及相應的解決辦法。
作為一名剛入門的支付產品經理,面對B端客戶的需求,需要產出對應的解決方案并確保順利上線,在這個過程中可能會踩哪些坑又應當如何繞開這些坑呢?
一、得不到完整準確的需求
對于2B支付業務的產品經理,除了開發測試同事,最經常溝通的應該就是公司內的銷售了,有時還需直接和客戶對話。
在這個兩個過程中,可能會遇到下面的問題:
1. 銷售傳達的客戶需求不明確
銷售向產品經理傳達的客戶需求不明確,一般體現在業務場景、功能需求、特殊要求這三個部分上。
業務場景不明確會影響我們制定方案時對現有產品的選擇與組合;功能需求不明確,我們就無法判斷是否需要對現有產品做改造;客戶的特殊要求將會影響我們采取哪種產品方案。
所以在銷售向我們傳達客戶需求時,要著重關注客戶的業務場景、功能需求和特殊要求。若存在不明確的部分,應當要求銷售和客戶確認后,再次與我們溝通。另外,產品經理可以參與到與客戶的交流中,全面了解客戶的需求,便于接下來的工作。
2. 與客戶間的理解偏差
產品經理在和客戶相關人員溝通需求時,由于雙方職業屬性的差異,又或是由于缺乏與對方的溝通經驗,會沿用各自行業內通用的詞匯或表達方式,這就會導致雙方理解偏差的出現。
理解偏差會導致客戶對功能的預期與產品方案最終實現的效果不一致,最終引起返工。
為了盡可能避免在溝通中出現理解偏差,可以邀請中間方參與溝通。比如客戶內部的開發團隊和對接客戶的銷售,他們的參與可以在一定程度上幫助雙方理解對方的話語。
若是沒有中間方可以參與溝通,則需要產品經理站在客戶的角度與對方進行對話。
另外,在平常的工作中,我們也應該多積累與客戶的溝通經驗,或者多和銷售同事交流來熟悉與客戶的對話方式,盡量減少在溝通中產生的理解偏差。
二、把客戶需求定位為產品方案
1. 直接從需求推導出的產品方案極有可能不合規
剛入門的支付產品經理有一個常犯的錯誤:就是習慣從需求直接推導出產品方案,
這樣的產品方案有兩個特點,
- 根據需求點對應到產品,再將產品進行簡單的組合;
- 無法幫助支付公司規避客戶需求可能會給我們的業務帶來的監管風險。
當我們拿著這樣的產品方案向合規部門報備的時候,很可能會被判定為不合規,那就不得不把方案推翻重新設計。另外,合規部門可能還會要求我們在方案中設計相關功能,要求客戶向我們提供資料或異步傳輸信息來為我們自身規避監管風險。
所以當我們經驗不足時,在產品方案設計完成后,可以將方案合規評審前置;需求評審后置,避免工作量的浪費。
在平時的工作中也要加強監管政策的學習,補充這方面的知識,在設計產品方案時自己就可以進行合規性的預判。
2. 產品業務邏輯比需求邏輯更復雜
大多數需求的實現,都不是簡單的業務邏輯就可以支撐的。
需求邏輯是在描述某個場景下通過某個功能來實現特定的效果;而業務邏輯則涵蓋了業務場景、底層基礎產品調用邏輯、清算記賬相關邏輯、逆向流程邏輯、失敗流程處理機制、對線上產品的影響范圍等部分,各個部分還需要前后貫通。
若簡單地將業務邏輯等同于需求邏輯,則會導致產品方案出現漏洞,在后續的開發過程中不斷填補漏洞,耽誤工期。更嚴重一點,還會因為一些改動而影響線上產品。
所以當我們接到需求時,上述業務邏輯的部分都需要納入我們的思考范圍。有些細節對我們的業務能力要求比較高,可以多向開發和測試同事尋求幫助,一同尋找解決方案。
三、只關心正向流程
從支付產品大的分類上看,無非是收單和代付兩類。
對于發展代付業務的客戶,幾乎不會出現退款的場景。而對于發展收單業務的客戶,從客戶的業務發展角度看,他們更關心把錢收進來的過程。
從支付公司的銷售來說,先把客戶接進來,客戶有了走量即可;后面有什么特殊情況銷售,可以再進行溝通處理。
客戶和銷售對逆向流程不那么關心是可以理解的,但是產品經理在需求溝通和方案確定的過程中,應該避免出現這樣的問題。
1. 逆向流程與正向流程是對等的
正向流程是滿足客戶正向交易目的的流程,逆向流程是在正向流程完成的前提下, 對交易結果的逆向操作。
雖說逆向流程并不會在每次交易中出現,但它和正向流程 一樣,是完整的交易場景中必須包含的兩部分。在支付業務中,逆向流程通常指收單后的退款流程。
如果在設計產品方案的時候忽略了對逆向流程的設計,對客戶來說,常規的逆向流程可能在復雜交易場景下并不適用;對第三方支付公司來說,后續為了滿足客戶在復雜場景下的退款需求,會需要進行人工調賬。這是非常復雜的清算對賬工作,人工維護成本很高。
舉個例子,受疫情影響,近幾個月各個旅游平臺的退款率相較去年同期異常高。旅游平臺作為平臺商戶,收單交易往往涉及多個分賬方。例如機票購買的交易場景中,分賬方至少是旅游平臺、機票出售方、保險公司三方。若是用戶的退款流程出現問題,受干擾的不止旅游平臺一方。
當然,各家支付公司肯定都已經有非常嚴密的退款邏輯了,但是客戶的需求是千變萬化的,逆向流程要提前和客戶確認,并且需要和相關的開發同事一起制定逆向流程方案。
2. 對賬的需求根據交易場景千差萬別
客戶的對賬需求基本體現在對賬文件的功能需求,大致包含三類內容:
- 對賬文件的獲取方式;
- 對賬文件包含的內容;
- 交易中各方的定制化需求。
對賬文件的獲取方式可以分為三種,
- 通過接口;
- 通過 FTP/SFTP 傳輸;
- 客戶通過客戶管理系統自行下載。
交易場景雖然并不能直接決定客戶對于對賬文件的獲取方式,但是可以從側面幫我們推測商戶更傾向于通過哪種方式獲得。比如對于交易場景比較復雜的客戶,往往具有開發團隊進行技術支持,他們更傾向于通過接口的途徑獲得。
對賬文件中包含的內容會受交易場景直接影響,對賬文件中各個字段以及每一行記錄,需要能夠還原出完整的交易資金流向。簡單的收單或退款交易,可能只需要對 賬文件中包含基礎交易字段。但是對于有分賬方參與的交易,對賬文件中需增加特殊字段來還原交易。
還是舉上文旅游平臺的例子,旅游平臺作為平臺商戶,收單交易涉及多個分賬方,那么我們給旅游平臺生成的對賬文件中,每條記錄中不僅要展示交易發起方產生的數據記錄,還要根據實際的資金流向,來記錄其他交易參與方對應的記錄。
復雜的交易場景中,參與交易的各方原則上都是支付公司的入網客戶,那么一旦有其參與的交易發生,我們就需要向其提供對賬文件。
交易發起方和交易參與方雖會共享同一筆交易訂單,但由于角色不同,在對賬時,需要看到的或是能夠看到的交易記錄對應的具體字段也會不同。比如,一筆交易中可能包含多個分賬方,每個分賬方只能看到交易記錄中與自己相關的字段的值。
若是在與客戶溝通需求或在制定產品方案時,不詢問客戶具體的對賬需求,可能會導致客戶對接了支付產品并且開始走量之后,發現對賬文件中的字段不滿足其對賬需求;從而引發該客戶交易量的下降。
所以不論在與客戶溝通需求或在制定產品方案時,都應當提前和客戶溝通對賬需求,或根據客戶的交易場景提供對賬文件模板給其提前確認;避免在線上運行時出現問題從而直接影響交易量。
四、忽略商戶的潛在產品需求
客戶能提出新的需求對第三方支付公司來說是好事——這意味著客戶對我們很信任,后續可能會切更多交易量到我們的平臺上。
客戶的潛在需求會出現在交易的各個環節,對于支付公司來說,將商戶需求轉化到產品方案上之后。
大致可分為兩類:
- 已對接功能的升級;
- 開發全新的功能。
比如,在使用APP中錢包余額支付停車費的場景下,支付訂單幾乎都是小額訂單,客戶在剛接入時只需要對接移動支付的相關產品;但是線上運行一段時間之后,很有可能由于用 戶反饋而要求支付公司提供小額免密支付的功能。
對現有功能的升級,由于在最開始做相關功能的時候,沒有從產品角度考慮,要求開發人員預留出足夠大的修改空間;那么功能升級可能會對開發測試的工作量會產生比較大的影響。
比如開發可能需要針對某種優化對相關業務邏輯進行重構。即便是開發新的功能,也可能會因為新功能與交易環節中其他功能的出現沖突而難以實現,從而延長工期。那么客戶就有可能將交易量向其他第三方支付平臺切。
其實,當產品經理在規劃產品功能時,可以多把自己放在實際交易場景中的用戶角色上,。去思考哪些支付功能是非常合理的而客戶并沒有提出的,盡量挖出客戶的潛在需求;雖說這些潛在需求可能在當前不會作為一項開發內容,但是可以幫助開發同事選擇功能實現邏輯、為未來的功能優化預留空間。
五、忽略商戶測試需求
1. 產品測試方式需要提前溝通確定
大多數支付產品的測試都是在生產環境通過對真實交易的驗證進行的。但是也遇到過有一些客戶希望對接商測環境進行上線前預測試。如果不提前確定客戶的測試需求,會影響我們提前準備測試環境等測試條件。
為了保證測試的順利進行,還是要提前和客戶對測試方式進行溝通,確定測試方案,必要時也可以由測試工程師向客戶提出測試建議。
2. 特殊測試方式的可行性受渠道影響
在微信支付寶發生的支付交易比較特殊。除了主掃被掃,比較常見的微信公眾號、小程序支付、支付寶的生活號、小程序支付。
在測試前需要提前準備好可供測試的公眾號、小程序等,必要時可要求對接客戶提供,以免耽誤上線進度。
作者:今天吃洋蔥;公眾號:今天吃洋蔥
本文由 @今天吃洋蔥 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
就是客戶要解決A問題,但是往往會基于B來反饋,如果不能問清楚,可能我們就離A越來越遠了
是的,這是一種情況