吐槽產品選型記
文章結合最近公司幾個產品模塊的替換選型過程中的苦逼與吐個槽這個活動，用一個虛擬的選型故事，分享一下產品/功能選型的坑，以及吐槽功能的迭代優化點。
因此【吐個槽】細節層面不展開。如果是有應用要新增吐槽反饋的功能，筆者是力薦各位接入【吐個槽】。結合一下最近公司幾個產品模塊的替換選型過程中的苦逼與吐個槽這個活動，用一個虛擬的選型故事，分享一下產品/功能選型的坑，以及吐槽功能的迭代優化點。
一個水平一般的研發可以坑死3個優秀的研發，一個規劃不好的產品可以坑死一羣人。
TIPS1：選型基本緯度
- 產品緯度、要立足當下，考慮後續的業務場景，對於強需求的功能，需要能敏捷上線；技術緯度，要考慮可拓展性，可配置性，後續的業務覆蓋及延伸，否則後續替換代價很高；運營緯度，要以數據導向，數據報表模塊是選型的一個重心。
TIPS2：問題分析法：5W1H要多用
TIPS3：【用戶體驗五要素】的戰略層與結構層與選型/產品方案的方向基本一致。
目錄：
- 突如其來的老闆任務激烈的方案討論產品的定位與初衷會議紀要【吐個槽】簡單分析功能上線是新的啓程【吐個槽】的落地現狀【吐個槽】的新功能遐（瞎)想
某日即將進入下班倒計時，辦公室大夥還在討論得熱火朝天（下班喫啥），突然微信羣彈出了老闆的一段話，辦公室頓時沉寂下來，最後還是背鍋王主動站出來爲老闆分憂
在背鍋王的組織下，公司內部迅速成立一個小組，準備解決的老闆需求，在羣聊內，大家初步貢獻了在線型、非實時型、運營/社羣型，爬蟲型的方案，由於爲羣聊，溝通成本較大，準備次日開會討論。
二、激烈的方案討論次日上午，召開了跨部門溝通會，會議上大家討論了在線型、非實時型、運營/社羣型，爬蟲型的方案討論。
1. 在線型營銷老王先拋出了在線客服1.0方案，他認爲，直接聽到用戶的心聲是最簡單明瞭的溝通方式，因此公司採購一套400電話客服系統，客戶就可以直接通過熱線電話反饋問題，通過系統配置IVR互助語音，能便捷引導用戶使用公司的業務。老王本以爲這個方案能讓大家服氣，結果遭遇大家一面倒的質疑。
財務莉莉：我先提一個疑問，購買一套電話系統要多少錢？聽說還要購買服務器，還要做開發？這個採購報價我提給老闆，估計立馬被開了，你想過採購成本麼？
運營喵小花：電話系統客服頂多支持1對1溝通，如果多個會話進入，就要排隊，客服人少了，排隊時間長就影響用戶體驗，客服人多了，如果沒那麼多的反饋，那麼就沒什麼意思了。這個還得考慮人力成本進去。
攻城獅（砍需求）：上次公司的服務器差點被沖垮，公司都說沒錢買新服務器，怎麼可能通過這個方案，要我說，還不如直接把公司的前臺固定電話公佈出去，還省錢呢。
前臺美美：你以爲我很閒麼？還要我負責接聽電話，我還負責很多跑發票，辦證等業務呢，誰愛聽就公佈誰的電話。
產品汪無聲：老闆說要數據報表怎麼辦，我們還得另外做開發麼？老闆說了這個需求很急喔。
背鍋王：電話客服系統不滿足我們當前的公司現狀，我們人少，業務不多，爲了一個不確定的業務，採購電話客服系統再付出人力成本與技術開發維護不現實，而且到時候節假日，誰回來公司上班處理進行值班？如果公司業務大了，那麼電話客服系統還能結合電話營銷，進行相關的運營促銷，如果沒有更好的方案，那麼就攻城獅說說他的方案吧
營銷老王不死心地提出在線客服2.0方案，既然在線客服只能1對1服務，而且需要回來公司上班，那麼可以接入QQ在線客服，那麼就可以實現在家值班，且能1對多服務，溝通完還能獲取客戶的QQ號，可以後續回訪。結果再次遭遇暴擊。
攻城獅（砍需求）：QQ在線客服系統，是PC上嵌入代碼，雖然簡單，但是我們是PC+APP，這個功能無法覆蓋業務場景，做了沒有多大價值。
營銷老王試圖再挽救一下，試圖用旺信這個例子說明IM是可行的方案，因爲已經集成了知識庫，自動應答，這個方案具備一定的可行性，最終在線IM這個思路暫時得到大家的認可，細節待定。
2. 非實時型攻城獅（砍需求）提出了非實時，內容沉澱型的概念，認爲相比在線客服這類單純的1對1服務，很難找到問題的共性，而且對於公司而言，在線客服消耗的都是公司的資源，無法通過KOL等方式把成本轉移出去。因此藉助開源的論壇，可以形成一種公司與客戶直接，客戶與客戶之間的良性互動，常見問題，熱點問題也可以通過置頂帖子的形式來展示，而且開源的功能足以滿足公司的功能訴求。更爲重要的是，不再需要實時回覆客戶的問題，可以大大降低大家的工作壓力。
攻城獅（砍需求）看到大家陷入了思考後，再拋出京東、天貓的商品評論。論證這種交流互動是一個強需求。於是大家的目光轉移去了運營喵小花。
運營喵小花：我先說說我的看法，我承認這個內容沉澱是一個很有價值的思考點，但是公司現在就我一個運營，我還得負責QQ，微信羣，要我還負責社區，有點喫力。
產品汪無聲：換我說，如果只是收集用戶反饋，建立一個留言板或者更合適（實現了英雄救美）。
背鍋王：攻城獅和產品汪無聲這種論壇/留言板的非實時型的方法很不錯，我們再看看其他人的方案。
3. 運營/社羣型運營喵小花提出了運營/社羣型的概念，如同她培養種子用戶那樣，建立QQ羣，微信羣，或者成立公司的微博號就可以與用戶實現點對點的溝通，依賴於騰訊當前的QQ號和微信號，微博的覆蓋情況，認爲這種方案成本低，無技術門檻，完全符合老闆的好用，簡單，成本低（近乎0）的想法。
營銷老王：我不太認同你的觀點，QQ羣、微信羣、微博號，後續都是用於做營銷活動的多，而且這種裏面產生的內容很多是沒有營養的，而且非在線/加入對應羣組，對內容無感知，即使加入羣聊，仍需要翻查相關聊天記錄，較難實現信息沉澱。
攻城獅（砍需求）：依賴於QQ羣，微信羣，微博，萬一老闆要問題反饋來源的統計，估計大家都得崩。
於是大家陷入了寂靜。
3. 爬蟲型產品汪無聲：我來說說我的觀點，由於這次老闆是在應用商城看到應用評價的，我們能不能做一些爬蟲的工具，去搜索我們相關的內容呢？我們再二次整理，收集，那麼這樣的工具開發之後，以後定時看下結果就行了，大家也不用那麼折騰。
營銷老王：我不太認可這種做法，雖然爬蟲獲取的數據很多，但是很多都是其他途徑獲取的內容，我們缺乏最關鍵的聯繫方式，無法與客戶進行二次確認。
攻城獅（砍需求）：目前很多網站，都有防爬蟲的機制，這個效果得看下實際情況才能得出。
三、產品的定位與初衷背鍋王看到大家討論得非常熱烈，但是跑題越來越遠，忍不住潑了大家冷水。
背鍋王作爲主持人，重新掌握話題：老闆是反饋功能要好用，簡單，成本低，大家在討論方案的時候，真的以公司的實際情況調研和方案選型麼麼？產品運營必讀的【用戶體驗五要素】，某種程度上，也是功能選型/產品思路的方向，大家有以這個作爲產品選型的起點麼？
商業目的：明確定義成功的條件，而不是成功的路徑，才能保證我們在這個階段不至於目的太抽象，也不至於由於目的太過於具體而限制了創新和思考。
成功標準：比賽都有終點，理解產品成功的標準，就是告訴我們是否達成了用戶的需求和我們的目標。
範圍層：把用戶需求和產品目標轉換爲“應該給用戶提供什麼內容和功能”，戰略就變成了範圍。包含產品的各種特性和功能，任何一個功能是否該包含在這個產品當中。
戰略層與範圍層，本身組合起來就是一個選型的基礎方向，在這個階段，我們可以複用問題分析法：5W1H進行論證。
問題分析法：5W1H
why：目的，爲什麼做這事；what：對象，怎麼回事；where：地點，在什麼地方執行；when：時間，什麼時間執行、完成；who：人員，由誰執行；how：方法，怎樣執行，採取什麼方案。5W1H套用現實場景就是：導航去目的地，要考慮路途的長遠，自己有的交通工具，其他交通工具，時間和效費成本。每種方案各有利弊，需要綜合考慮。
對於背鍋王提出的理論依據，參與會議的各方沒有異議，於是大家針對好用，簡單，成本低的思路逐一對於已有方案進行選型論證。
營銷老王的實時型思路首先PASS，原因是成本。
實時型對於用戶的感知是有幫助的，能快速響應問題。即使到了現在，客服仍是很多大型企業的必要崗位，把客服作爲面向客戶的第一道防線。但即使銀行，運營商，也在逐步從電話客服轉移到在線客服，然後再輔助各種知識庫？
科技是在進步不假，但是客服本身需要有專業的能力和素質，但人的精力畢竟有限，在線客服撐死了能同時對接10個左右客戶的問答，但前期投入較大。因此業務量少的時候，投入大量人力物力不划算，業務量多的時候，還得繼續增加客服人數，成本還是不划算。
公司屬於拓展階段，暫時沒有相關同事能及時響應客戶問題。再者即使到了需要客服支撐的階段，也不能作爲一個核心入口來收集客戶反饋，而是要解決客戶問題。
運營喵小花的運營/社羣型方案也出局了，原因是好用。
這個對於公司而言，QQ/微信/微博，前期開發成本近乎爲0，只要雙方登錄QQ和微信，微博就行了。但是這個是一把雙刃劍，把問題的反饋放於社羣，要麼就是各種聊天記錄把有用的信息覆蓋掉，這個對於數據報表是一個非常不利的一種方式。
而更爲關鍵的是，這個反饋模式，只能依託於當前的社交工具，無法植入我們的APP，也無法植入相關的PC/小程序，因此只能用於營銷類型，輔助收集一下問題，但不能作爲問題反饋的主入口，這個方案只能PASS。
產品汪無聲爬蟲型方案待定。
爬蟲型方案雖然有短板，即使有些網站無法爬蟲爬蟲，但是在基數大的情況下，仍可能收集到大量的數據，但是爬蟲型與其他方案最短板的，在於沒有聯繫方式，可以反向回訪客戶。再者現在很多【雲用戶】隨意發表意見情況下，如何收集到有用的信息，是一個值得考慮的問題，這個可以作爲是一個拓展方案，論證現有已經接收到的反饋是相對吻合的。
只能說，現階段的優先級不高，可以作爲後續輔助拓展使用。
攻城獅的非實時型的論壇/貼吧方案待定。
首先得肯定，這是一個很好的內容沉澱的模式，與其他模式相比，最起碼劃分了聊天的板塊，實現了內容的聚焦，置頂帖子也是可以勉強替代爲知識庫的功能，基於開源的技術，也可以實現一些報表功能，是一個比較完美的形態。對於一個產品而言，收集到用戶的信息，敏捷處理是可以大幅滿足用戶的滿足。
比方說：小米論壇，產品與研發經常與用戶溝通，獲取用戶的反饋加以改進，但是現有的模式，仍有一定的侷限性，比方說要內嵌到APP及小程序內。這樣的功能，是否能滿足，還需要論證。
最後背鍋王開始了小總結。
產品選型要回歸到公司的人力現狀。員工合計48人，大部分都是技術和運營，不適宜投入過多的人力。
公司的產品涵蓋APP+小程序+網站，未來可能涵蓋公衆號+H5乃至其他業務場景，要考慮拓展性問題。
關於這種情況，我個人傾向於論壇貼吧的方案，但由於存在較大的投入，可以嘗試用戶留言板類似的功能代替，實現快速開發，敏捷上線，內容沉澱在公司服務器，便於抽取數據報表等功能，可以對於用戶的信息也能實現追蹤回溯。
攻城獅補充，如果只是一個留言板的功能，那麼只是作爲一個數據的承載，對於開發的工作並不是很多，關鍵是要明確需要怎樣的功能緯度。只有需求明確的情況下才能進行工時的估算
四、會議紀要to： all
cc ：boss wang
【會議紀要】問題收集產品的選型方案暫定爲留言板
上午對於現有的收集用戶信息的方案進行討論，針對公司的現狀及未來發展所需的功能進行廣泛溝通，認爲留言板功能目前比較適合公司的現狀，輸出各類產品優劣對比如下：
兩分鐘後老闆又在微信羣給大家加油鼓勁了。
吐槽反饋功能5W1H：
吐個槽，如同一個精簡版但更垂直的反饋板塊，無論是前臺和後臺，都可以明顯看出都是爲反饋內容而打造的吐槽功能。
（1）關於反饋的這個需求，西蒙半年前曾收到過，曾想着用文本記錄敏捷上線，最終3個月前這個需求從需求池被清理掉。需求無法落地在於業務方僅僅把這個功能作爲一個用戶吐槽的入口，無運營方案，無相關對接人，真的就是一個【吐槽】，既如此，要來何用？若業務方帶着運營方案重提吐槽功能，說能給產品帶來更好的設計理念，我會選擇【吐個槽】，無他，敏捷省事。
（2）於筆者而言，一個功能的上線，只是另一個坑的開端。因此功能的開發前要有運營方案，與運營人員進行討論，功能上線後要驗證功能是否滿足運營需求，一個無法爲公司帶來實質性效果的需求，某種程度上也是一個僞需求。
（3）一個功能上線後的運營/技術/產品覆盤，能讓產品的成長有更多的可塑性。
（4）從騰訊產品接入的情況來看，產品的特性，公司的環境不一樣，未來發展趨勢，功能訴求點不一。那麼對於選型，都是一個不可忽視的內部因素。因此在選型前後，都要綜合考慮。這又回到了開頭的小結，一個水平一般的研發可以坑死3個優秀的研發，一個規劃不好的產品/功能模塊可以坑死一羣人。
七、【吐個槽】的落地現狀【吐個槽】功能足以覆蓋很多沒有專職客服的中小型企業，讓他們在較低成本與內容沉澱方面，與客戶進行對接，但是如上一段的功能上線是新的啓程，關於【吐個槽】的功能，在客戶使用層面有更多的改進空間（非純粹工具本身）。
在吐個槽的官網首頁，我們可以看到企業微信是作爲一個標杆，恰好西蒙公司也是用企業微信，於是對於這個頁面進行體驗，吐個槽的定位在實際場景中：從吐槽功能的入口演變成諮詢客服的入口。
一個置頂帖子裏，告知用戶要怎麼遇到解決問題。然而理想很美好，事實很骨感，帖子下面都是問問題的……
而這個在線客服的入口究竟在哪呢？
雖然最終找到了客服中心，但是這裏面引申自己很多的思考：
- 企業微信PC版本的【吐個槽】，沒有常見問題的展示。企業微信安卓APP【常見問題】，其實就可以用【吐個槽》常見功能】來代替。那麼爲什麼就不能整合在一起？是企業微信不肯替換，又或者說不支持問題的分類？如果是後者，還是一個共性問題，則需要【吐個槽】的產品經理思考，要不要實現問題反饋那種的3層級覆蓋到常見問題。企業微信的客服入口，常見問題與安卓APP的又完全不一樣，從信息的整合而言，維護一套常見問題，然後各子模塊能自適應展示，肯定比維護多套系統簡單，那麼這又是什麼呢？
騰訊視頻雖然有了常見問題，但是由於產品特性，把常見問題，無法搜索的問題放大了。因爲涉及費用，會員，VIP視頻等常見問題，心疼Dolly天天在論壇回覆客戶的問題。已經是一個客服的工作了。
雖然騰訊視頻的吐槽場景問題也有涉及VIP的問題，但是卻是另外一個客服支持的頁面，最終能夠支撐大量問題的，只能通過【VIP幫助中心】才能找到更核心的內容與在線客服。
八、【吐個槽】的新功能遐（瞎）想吐槽功能的共性與個性吐個槽某種意義上，就是一個SAAS化的服務，只要接入了這個服務，就能享受通用的服務，我想這也是這個產品能迅猛發展，攻城略地的一個基石。但就如用戶的需求是各種差異化的情況一樣，對於單一隻使用吐個槽的產品而言，已經基本上滿足了日常的反饋需求，但供應與個性終究是一個要面對的一個門檻，針對吐槽的情況，西蒙瞎想了以下功能的拓展情況。
瞎想1：就如企業的發展，終究會升級爲在線客服，可依託騰訊的QQ客服與微信客服，可以提前預置相關的QQ客服入口，微信客服入口，允許接入方升級相關服務，提升合作方與騰訊產品體系的粘合度及替換成本，甚至還能打包賣一個組合套餐。
瞎想2：對於【吐個槽】而言，一個常見問題的模塊固然能滿足吐個槽的功能，但卻沒有與合作方的具體需求形成強關聯，用戶需要在【吐個槽】才能查看常見問題，那麼或者可以考慮把這個模塊抽離出來做大做強？做成一個通用的模塊或者接口？但是實際上還是使用吐槽後臺來調用和配置？且做到多端統一，從而提升常見問題的效費比，基於這個還能深度切入騰訊系產品，降低自身產品體系的維護成本。
瞎想3：當前【吐個槽】設計初衷是隻是一個反饋問題的入口，但是在需求與問題混雜的情況下，是否需要區分2個或者2個以上板塊來滿足用戶的反饋訴求？這個就如一個論壇貼吧的模式，區分交流、問題反饋的歸集，從而形成一個微型的社區空間。衆所周知，開展且維護一個用戶社區的成本較大，通過新業務以及從而給吐個槽產品帶來更多的想象力與其他附加價值？
瞎想4：吐個槽可以新增運營活動的投票等情況，某種程度上也是帖子的一種屬性，也可以提升與用戶的溝通，比方說：下期活動是送皮膚還是鑽石，這個可以結合上面的社區空間進行結合，提升工具的實用性。
瞎想5：依據曾自研並上線過吐槽相關功能的電商產品反饋，他們下線吐槽功能，是因爲用戶在找不到客服的情況下，把吐槽當初問題的反饋問題的場地，遺憾的是當時他們設計時未與OA系統形成關聯。因此客戶反映的問題在吐槽層面與用戶回覆頁面形成數據斷層，客服無法處理的情況下最終只能黯然下線。
以目前看，吐槽的功能在產品層面能實現功能的可用，但是對於需求，基本上還是一個很原始的記錄。那麼要成爲【需求池】裏面的需求，以及跟蹤調研和上線，這個問題也未實現閉環，是否在增強版內，形成一個簡單的OA類流程？
瞎想6：讓我覺得更有意思的是，一個吐槽社區的官網最下方，還附上反饋羣與聯繫郵箱。本次活動也是用QQ羣交流，可以建立爲一個獨立的板塊（DEMO2號），針對熱點問題進行問答，或者可以在【我們的故事】分拆多一個模塊作爲公告欄，則版本號更新或者活動的更新則同步更新。
畢竟對於產品而言，產品的升級公告也是剛需，也是可以那麼是否可以通過各種手段，再節約人力與效能。期望下次的吐槽活動，能用吐槽產品進行處理~
感謝各位百忙之中閱讀，預祝各位新年快樂。
