#文末註釋，有關於運營商的彩蛋~#
大約半年前，我被抽調到一個新成立的部門，開始研究「互聯網+」這個熱門概念下，互聯網與傳統行業相結合所產生的各種可能性。我手裡的項目，主要在關註醫療這個方向。
做「互聯網+」相關的產品，與之前做純互聯網產品很不一樣，因為除瞭必須瞭解互聯網之外，還必須去比較深入的瞭解所關註的傳統行業，去瞭解他們的行業中，用戶的需求、技術的動向，以及遇到的困難。傳統行業本身有深有淺，有的專業性強，有的專業性弱；有的門檻高，有的門檻低；有的相對開放，有的很封閉。而醫療這個行業，偏偏是專業性極強並且相對封閉的行業。
我為此做瞭大量的調研，結合國內的現狀，互聯網公司的特點，以及部門的實際情況，（在現階段）得出的結論如下：
- 不要去碰特別深入醫學專業的領域（比如互聯網醫院？）
- 關註宏觀政策，但最好別去做政策直接倡導的事情（比如三明醫改？）
- 暫時不要改變醫生和患者固有的習慣，暫時不要挑戰已經形成的偏見（比如分級診療？）
- 互聯網公司，對於「互聯網+」，在現階段，可以以做連接、提升現有行業的運轉效率為切入（比如滴滴，做的是車主和乘客之間的連接，不是買瞭一堆車出去跟公共交通搶生意；更不是試圖讓乘客坐火箭出行。）
所以，排除瞭各種我認為不靠譜的方向之後，我把主要的研究方向放在瞭對現有就醫流程的優化上面。那段時間，與深圳一些醫院的醫生、護士，以及信息科的同事交流過多次，詳細梳理瞭病人在就診過程中遇到的問題，審視這些問題，結合部門的實際情況，我決定從流程的第一步，也即掛號做起。
提起掛號，看起來實在已經是一片紅海瞭，現在做掛號的app好像比做直播的還多，並且很多都已經很成熟瞭，比如我們常用的就醫160、微醫等。現在起步做這個，有戲嗎？我當時也面臨這個問題的挑戰，但是仔細研究市場之後，發現還是可以做的。那麼首先，容我先簡單介紹一下目前的醫療相關app中，掛號這個功能的實現方式。
一、前置研究：市面上的app是如何實現「掛號」功能的？
目前，市面上可以提供掛號服務的app，主要的業務實現方式有兩種：
第一種，叫做「直連方式」。顧名思義，就是醫院提供相應的數據接口，平臺與醫院直接連接。當有用戶需要掛號的時候，平臺向醫院直接請求號源，醫院有，就會幫他完成掛號。
這個業務模型很簡單，也是理論上最靠譜的方式，但是它有一個致命的弱點，就是：需要醫院提供數據接口！醫院並不是專業的IT或者互聯網公司，他們的開發、運維能力非常有限，即便可以通過外包的形式實現功能，但是，號源這東西往往很敏感，外包公司做的軟件，安全性、穩定性等等，都讓人不放心（並且很多醫院也並沒有付費開發的動力）。其實，醫院使用的HIS(註1)系統廠商也可以開發這些接口，但是它們動不動一套接口報價是幾百萬，即便存在一些有心做這些的醫院，也很崩潰。雖然從商業模式層面，掛號平臺也可能找到各自各樣願意出這筆錢的機構或者公司來做成這件事情，但實際情況是，在市面上您見過的可以掛號的app裡面，隻有少部分的醫院是采用這種方式進行掛號的。
第二種，叫做「號源池方式」。既然直連方式在當前的條件下難以走通，所以很多醫院和掛號平臺就想出瞭一個更加簡單的方式，就是，醫院把一部分號源的「使用權」分配給平臺，平臺相當於隻需要在這部分號源范圍內收集用戶的掛號需求，然後定期同步給醫院即可。這裡面的「定期同步」，您別想得太高級，有的醫院技術能力比較差，可能是采取平臺每天給醫院發一封郵件，裡面附帶一個Excel文檔，醫院專門找一個護士，手工錄入的方式實現的… 您看看，為瞭能讓您掛到號，大傢多不容易啊~
由於「號源池方式」幾乎沒有成本、安全、無政治風險，所以事實上，我們用的大部分掛號平臺都是采取這種方式與醫院交互信息的。基於此，您可能已經想到，您遇到過下述這些問題，其實是來源於這個模式的：
- 為什麼大多數掛號app都不能掛當天的號？（因為來不及同步…）
- 為什麼有些醫院的公眾號可以掛當天的號？（人傢跟自己的系統交互，不需要「同步」…）
- 為什麼對於很多醫院來說，我在app上成功掛號後，還需要再排隊走一遍「取號」流程？為什麼不能憑短信看病呢？（因為您在app上的行為隻是「預約」，相當於占瞭一個坑而已，這個預約信息並不一定直接到瞭醫院HIS系統中，很有可能還留在上文提到的Excel文檔之類的地方呢。您必須拿著「憑證」去領取「用坑券」，人傢可能是重新錄入一遍，才真正進系統，完成瞭掛號）
二、競品分析：它們和我們各自面臨什麼問題？
首先，不同的app其商務拓展能力不一樣。可能出現這樣的情況：app1拿到瞭該城市A,B,C,D四傢醫院的號源；app2拿到瞭C,D,E,F四傢醫院的號源。這時候就有一個問題，如果您用app1，就會發現，不能掛E醫院的號源；如果用app2，則不支持A醫院掛號。另外，作為一個app1的用戶，您可能根本不知道有app2存在，這時，如果發現沒有E這個醫院，沒辦法，隻能去線下排隊瞭。也即：無法最大限度覆蓋資源。
如上圖：左側app可以支持深圳的多傢醫院，而右側的app隻支持4傢。
其次，不同app對醫院的議價能力也不一樣。有可能對於同一個醫院C，app1拿到瞭10個號源，app2拿到瞭50個號源。這樣，可能app1上已經沒有號瞭，app2上卻還有剩餘。如果我每次掛號，需要把所有app打開一遍，實在是太辛苦瞭。也即：無法最大限度利用資源
如上圖：左右兩側是不同app在同一個醫院同一個科室的號源情況（它們UI長得有點兒像，但確實是不同的app…）。但是「張斯為」醫生和「龍豐」醫生在左側均顯示「約滿」，而右側則顯示綠色的可以預約。
第三，對於當時我所在的團隊來說，在掛號這個領域起步是非常晚的。如果我們像競品一樣，派商務同學一傢一傢醫院去談，不但費時費力，而且可能錯過「掛號」這個服務的最佳窗口期。
三、回歸本源：用戶最底層的「體驗」究竟是什麼？
我們每天都在談「用戶體驗」，對於一個掛號平臺來說，【最基礎】的用戶體驗是什麼？並不是它擁有多麼強大的功能，並不是它的UI特別流暢又漂亮，而是它能夠「最大可能的幫用戶掛到號」。
基於以上，我希望從最基礎的體驗做起，不去跟競品拼功能。基於這個思路，掛號平臺（分發模式）誕生瞭。
拿一個大傢熟悉的產品做類比吧。很多同學喜歡使用類似「去哪兒網」之類搜索機票，去哪兒自身並不產生機票，它其實是一個機票搜索引擎，它的背後連接瞭各大航空公司，各種代理商的資源。所以，搜索兩個城市間的機票資源，在去哪兒上得到的結果，一定比在任何一傢航空公司的官方網站上更豐富。
同樣的道理，我們暫時不去拓展醫院，而是搭建一個平臺，與有號源的其他平臺合作，拿到他們的接口，這就相當於把他們的號源資源接入瞭我們的「聯合號源池」，這樣理論上可以最大限度幫助用戶實現「掛到號」的基礎需求。
這個設想很有趣，但是，作為一個「互聯網+」的產品經理，隻把這個邏輯走通還不夠，同時需要思考的是一個很現實的問題：那些有號源的平臺，憑什麼把接口給你？「互聯網+」相關的產品，除瞭產品策略，還必須同步思考由產品策略延展出的商業策略，同時，根據商業策略，同步調整產品策略。
現在面臨的問題是：如果隻做一個簡單的搜索，向百度一樣，然後用戶跳轉到合作方的頁面上完成掛號，這樣很難保證線上的體驗（有一些地方是跟ZF平臺合作，您知道，一般都不怎麼樣），對於我們來說也是一個不劃算的生意（號源可沒辦法做競價排名變現啊）；如果要求合作方對接我們的後臺，那憑什麼呢？我們可以給他們什麼好處？號源這種資源，是沒辦法直接變現的（不像機票，賣出去就可以獲得分成）。我們所熟悉的可以掛號的app，包括就醫160、微醫、百度醫生等等，掛號部分很多都是為其他服務導流用的。如果僅後臺跟合作方對接，相當於合作方僅有的用戶和流量被截取瞭，商務層面將很難推進。
四、我們要如何做？
經過反復糾結與談判，我采用瞭一種折中的方式。
具體是這樣的：首先，我們的平臺內嵌在微信城市服務中，可以調用微信的一些基礎能力。用戶掛號的主操作流程依然留著我們的平臺上，用戶選好醫院、科室、日期、醫生等（這些步驟看起來，跟一般的掛號平臺沒什麼區別）。然後我們去請求所有合作方，將號源情況展現給用戶，並且會給予合作方品牌曝光：
用戶選擇某個合作方，點按其後方的「掛號」按鈕，會跳轉到該合作方的頁面上：
在合作方頁面，用戶隻做兩件事：
- 註冊/登錄合作方的賬號（僅一次）該操作隻需一次，會要求合作方將該用戶的微信OpenID與該用戶在合作方的賬號綁定，下次掛號，再次使用該合作方，不需要重復登錄。並且會要求合作方針對騰訊的流程重新設計登錄頁面，以保證用戶最快速完成掛號。例如上圖左側，是微醫為我們設計的註冊/登錄頁面。
- 確認掛號信息用戶取得合作方登錄態後，我們會將用戶選擇的所有信息（如醫院、科室、醫生、時間等）傳給合作方（要求合作方必須開發接口接收，對於無意願或者無能力或者接口不穩定的合作方，不予接入），合作方直接顯示最後的確認頁面，並補充就診人信息（如果用戶是登錄瞭合作方的賬號，則可以直接調取用戶以往在合作方處留下的就診人信息）。然後點按「提交」按鈕，即可完成掛號。
而當用戶完成掛號後，流程則交給合作方公眾號，便於後續的通知、提醒等場景。
如此，從產品、技術、商務三方面構建瞭一個基礎的可能性，即：將多個合作方的號源池拼合在一起，構建瞭理論上更大的號源池，優化瞭用戶掛號的最底層體驗（最大限度掛到號）。
哦，對瞭，掛號平臺雖然是用網頁形式承載，但是由於使用瞭https，所以，可以最大限度防止各種運營商的流量劫持(註2)哦~ 跟這種討厭的球說再見吧~
五、未來，我們將擁有一個怎樣的就醫體驗？
<廣告>
目前，掛號平臺（分發模式）已經在微信城市服務中上線，具體覆蓋城市為：上海、太原、哈爾濱、西安、蘭州、成都等。您可以打開微信，進入我-錢包-城市服務，在相應城市中找到入口。
</廣告>
但是，掛號隻是用戶診療流程中的第一步。事實上，患者在醫院看病的過程，依然是一個水深火熱的過程。本文一開始提到，我與醫院的同學們梳理瞭病人在就診過程中遇到的問題，那麼，掛號之後，很長很長的未來，我們還有可能做什麼呢？下面，用一個虛擬的故事來跟大傢暢（Y）想（Y）一下吧（其實下面您將看到的故事裡面的很多步驟在一些醫院的公眾號裡面都已經實現瞭，隻是還不成體系）。
王小明兩天前覺得胃有點兒不舒服，當時他以為喝一點兒熱水就好瞭。可是到瞭今天晚上，癥狀依然沒有消失。於是他打開掛號平臺，預約瞭南山醫院消化內科明天下午3點的醫生。此時，他收到瞭預約成功的消息通知。
第二天上午，王小明開瞭一上午的會。下午2點，他收到瞭一條消息通知，提醒他下午3點預約瞭醫生：
於是王小明花瞭20分鐘交接好工作，請假前往醫院。他於2點50分到達醫院門診部，上3樓找到瞭「消化內科」，發現分診臺上方大屏幕上已經顯示瞭當前的排隊情況，他位於第3位。他點按手機上的排隊提醒信息，進入排隊列表，發現手機上顯示的位置與分診臺大屏幕是一致的：
王小明決定先去個廁所，當他剛方便完，跨出廁所門的時候，發現手機提示有新消息，原來是輪到他就診瞭：
王小明去往5診室，見到瞭醫生，簡單描述瞭一下病情。醫生做瞭一些基礎檢查，告知王小明：「你的情況建議做一下胃鏡，這樣可以更加精準的確診。如果胃鏡結果沒問題，那就是普通的胃炎；如果有問題，可能還要繼續做其他檢查。」於是按照醫生的建議，王小明準備接受胃鏡檢查。醫生在電腦上開完單，王小明的手機上又收到消息：
王小明離開診室，來到一樓收費處，看到排隊的人群是這樣的：
瘋瞭！這樣的隊伍，先去一樓收費處排一次繳費；然後去住院處2樓，檢驗科門口再排一次預約。這沒半個小時都搞不定啊。並且這種檢查一般約不上當天的。於是王小明拿出手機，點按那條檢查信息，進入網上繳費及預約頁面：
使用社保繳費（在深圳已經實現，也即，你可以使用微信支付操作社保卡裡面的錢），看一遍註意事項，預約瞭明天早晨8點的胃鏡檢查，前後不超過1分鐘。王小明又看瞭一眼排長隊的人群，轉身離開瞭醫院。
第二天，王小明按時前往醫院，做瞭檢查。第三天上午，他的手機收到提醒，原來檢查報告出來瞭：
王小明點進去看瞭一下，有一些數據項看不懂，但是貌似意思是，除瞭有點兒潰瘍之外，沒有大的問題。王小明把手機放在一邊，想著一會再重新掛個號，去讓醫生給開點兒藥。到瞭中午，王小明拿起手機，發現有一條未讀的消息，打開一看：
原來是他的醫生已經查看過胃鏡報告，並已經幫他開好藥。王小明點按這條信息，出現瞭更加詳細的醫囑、藥品清單及取藥選項頁面（話說，病例那裡，我實在編不好；藥和劑量也是編的，您就將就著看一下哈~）：
王小明支付瞭藥費，發現除瞭親自前往醫院藥房取藥，還可以使用其他途徑：
於是他選擇在公司附近的一傢社康取藥，下班路上，順便就把藥拿到手瞭。 （YY到此結束）
對瞭，如果有任何朋友對於「優化現有就醫流程」這件事兒有興趣，不妨我們交流一下。我的微信是 liuhanyusz
(註1)HIS系統：HIS即「Hospital Information System」，我們簡單將其理解為，醫院裡面醫生、護士等工作人員電腦上用的軟件的統稱。
(註2)流量劫持：具體解釋清自行搜索。如果遇到流量劫持，可以打電話給運營商客服投訴。臺詞這麼說：「（先描述情況），你們這種行為幹擾瞭我的正常通訊，是違法違約行為。請你們1小時內給我關閉，否則我將向工信部投訴。」聯通親測有效~ 隻是可能過一會會有所謂「客服經理」打電話過來裝傻問想「取消」哪個「業務」，告訴他即可。
//—–
註：作者新書《解構產品經理》，已由電子工業出版社出版。這是一本互聯網產品策劃入門書，適合3年及以下工作經驗的同學閱讀。
//—–
劉涵宇 xidea
騰訊高級產品經理
騰訊學院講師
關註互聯網與傳統行業融合的歷史進程，關註互聯網產品與用戶體驗。
微信公眾號：產品經理劉涵宇（ID:uxcafe）
專欄原名：xidea的咖啡館