在微信公開課2017Pro中•◕☁，張小龍反覆強調了•◕☁，小程式•◕☁，最大的入口•◕☁，就是在各類線下的商業場景中•◕☁，這是對“讓商業存在於無形之中”的理念的詮釋✘│☁↟•。

　　據鈦媒體瞭解•◕☁，目前小程式也已經官方邀請和接入了包括肯德基在內的第一批200家商戶•◕☁，功能則主要覆蓋的是會員服務和提前預定(預約)服務等✘│☁↟•。

　　如果你經常和小編一樣去肯德基吃早餐的話•◕☁，想必應該知道•◕☁，為了解決排隊難的問題•◕☁，在已有的人工服務檯之外•◕☁，不少門店還配自助點餐機•◕☁，你可以在上面選擇你喜歡的餐點•◕☁，然後掃描二維碼支付✘│☁↟•。

　　可以預見點餐一體機制造商將迎來一輪洗牌•◕☁，同時你的手機中又少了一款大小20-30M的 App•◕☁，延伸線下場景消費•◕☁，我們大概可以知道諸如保潔☁₪、美甲☁₪、洗車☁₪、打車等等O2O業務的App都將被以二維碼為入口的小程式所取代✘│☁↟•。

　　比起商家的幸運•◕☁，對於依附微信公號的媒體來說•◕☁，小程式似乎並沒有想象中的給力✘│☁↟•。張小龍明確提出小程式不能推送訊息•◕☁，不能轉發朋友圈•◕☁，彼此相互獨立✘│☁↟•。不過在小程式中可以看到企業做了哪些公眾號•◕☁，它們可以互相跳轉✘│☁↟•。

　　很明顯的消費場景是•◕☁，當你在書店☁₪、機場等線下店瀏覽或者購買書籍影像製品時•◕☁，以二維碼做入口的小程式•◕☁，可以讓你檢視媒體所涉獵的電商•◕☁，這就不僅限於雜誌☁₪、研究報告和線上線下活動等✘│☁↟•。比如鈦媒體的微信鈦坦白公開課☁₪、線下的 T-EDGE 活動等✘│☁↟•。當然如果小程式的上承載的內容足夠打動你•◕☁，關注微信公眾號應該就是隨其自然的事情✘│☁↟•。

　　媒體的發力點在於小程式的介面和刊載內容是否能抓取消費者的眼球✘│☁↟•。正如上海交通大學老師☁₪、天奇阿米巴基金投資合夥人魏武揮所言•◕☁，微信是瀏覽器•◕☁，而小程式要做的其實基於web端的一個小網站✘│☁↟•。

　　那麼具體哪些商業場景更適合小程式應用•◕☁，鈦媒體特邀騰訊雲高階產品經理佈道師•◕☁，從線下的商業場景•◕☁，來詳細闡釋微信小程式的場景化應用✘│☁↟•。

　　微信小程式從最初提出概念•◕☁，到內測•◕☁，到允許企業使用者公測•◕☁，持續在吸引各類群體的眼球✘│☁↟•。

　　我研究了國內很多小程式的開發者社群•◕☁，發現了一個現象•◕☁，就是一夜之間•◕☁，冒出了無數個“仿XXX的小程式”✘│☁↟•。很多專家提出了一些大膽的預測•◕☁，認為小程式會取代目前的微信服務號•◕☁，或者更有人認為會顛覆目前的APP的生態•◕☁，讓APP的開發成為歷史✘│☁↟•。

　　所以不難理解•◕☁，為什麼冒出了那麼多”仿XXX的小程式“✘│☁↟•。從技術角度去思考•◕☁，很多開發者•◕☁，從仿製某某應用•◕☁，去學習小程式•◕☁，是可以理解的•◕☁，但是如果從商業角度來思考•◕☁，難道客戶需要的是把現有的商城•◕☁，網站•◕☁，公眾號重新再用小程式開發一遍嗎?

　　顯然這不是商業的本質✘│☁↟•。從商業的角度來看•◕☁，人們期待的是小程式能夠解決以前的東西無法解決的問題•◕☁，或者解決起來客戶體驗不好的問題•◕☁，或者解決問題投入成本太大的問題✘│☁↟•。所以•◕☁，微信小程式•◕☁，需要一些場景化的應用•◕☁，而不是”仿XXX的應用“✘│☁↟•。

　　理解小程式的本質

　　要明白小程式的使用場景•◕☁，首先理解什麼是小程式✘│☁↟•。張小龍給出了一段對小程式的定義▩·：

　　“小程式是一種不需要下載安裝即可使用的應用•◕☁，它實現了應用觸手可及的夢想•◕☁，使用者掃一掃或者搜一下•◕☁，即可開啟應用•◕☁，也體現了用完即走的理念•◕☁，使用者不用關心是否安裝了太多的應用•◕☁，應用將無處不在•◕☁，隨時可用•◕☁，但是又無需安裝✘│☁↟•。”

　　這段解釋中•◕☁，有幾個核心的理念•◕☁，觸手可及•◕☁，透過掃碼和搜尋馬上就得到•◕☁，並且無需下載•◕☁，用完即走✘│☁↟•。

　　我們先來思考一下•◕☁，小程式的價值觀✘│☁↟•。小程式文件中的運營規範中有一句話▩·：

　　”一切以使用者價值為依歸☁₪、讓創造發揮價值☁₪、好的產品是用完即走•◕☁，以及讓商業化存在於無形之中✘│☁↟•。“

　　小程式誕生的本質•◕☁，就是為了讓商業存在於無形✘│☁↟•。商業場景•◕☁，一定是小程式的最典型的應用場景✘│☁↟•。

　　在微信公開課2017Pro中•◕☁，張小龍反覆強調了•◕☁，小程式•◕☁，最大的入口•◕☁，就是在各類線下的商業場景中•◕☁，這是對“讓商業存在於無形之中”的理念的詮釋✘│☁↟•。所以•◕☁，我們首先從線下的商業場景•◕☁，來談一談微信小程式的場景化應用✘│☁↟•。

　　去中心化入口•◕☁，催生線上線下深度融合場景

　　在傳統的網際網路中•◕☁，流量是跟著入口走的✘│☁↟•。在PC時代•◕☁，流量集中在幾個大型的入口網站•◕☁，移動網際網路時代•◕☁，流量在微信這樣的超級APP裡面✘│☁↟•。

　　再往後•◕☁，就是一種去中心化的趨勢✘│☁↟•。讓流量消融在千千萬萬的實體商業裡面✘│☁↟•。早期的O2O•◕☁，其實線上和線下是割裂的✘│☁↟•。並沒有進行深度的融合✘│☁↟•。譬如•◕☁，你要在58到家找鐘點工•◕☁，還是需要在一個超級APP上去搜索•◕☁，比價•◕☁，尋找合適的鐘點工✘│☁↟•。線上下單後•◕☁，保姆到家服務•◕☁，就和線上沒有任何關係了✘│☁↟•。

　　線上和線下是一種割裂的關係✘│☁↟•。並不是我發現家裡很髒時•◕☁，立刻就呼叫鐘點工✘│☁↟•。等我辦完事情回家•◕☁，家裡就已經打掃好了✘│☁↟•。線下應該是一種很自然的場景過渡到線上•◕☁，然後再自然的過渡到線下✘│☁↟•。當服務完成後•◕☁，再回到線上✘│☁↟•。

　　我們設想一種場景•◕☁，加入一個理髮店•◕☁，怎麼更好的利用小程式•◕☁，實現一種線上線下自然融合的場景?

　　小蕾是一個很愛美的女孩子•◕☁，某一天•◕☁，她的閨蜜在微信•◕☁，分享了一個小程式頁給她了•◕☁，讓她評價一下•◕☁，在一家很時尚的美髮店新剪的一個髮型✘│☁↟•。

　　她看了之後•◕☁，立刻動心了•◕☁，也想去這家店去剪一個新發型✘│☁↟•。所以她在小程式預定了週末的服務•◕☁，小程式自動讓她拍一張臉部的正面照片上傳上去•◕☁，系統自動給出最適合臉型的髮型給她選擇✘│☁↟•。她選擇了喜歡的髮型後•◕☁，預定了合適的時間•◕☁，完成支付•◕☁，同時收到了一張會員卡✘│☁↟•。

　　預約的當天•◕☁，收到了小程式推送的提醒訊息✘│☁↟•。同時•◕☁，使用者小蕾獲得了臨時進店的許可權✘│☁↟•。原來這是一家沒有前臺的門店✘│☁↟•。

　　需要預約使用者到店後掃碼解鎖門禁✘│☁↟•。當進到店裡後•◕☁，店裡的後端系統就已經知道小蕾已經來了•◕☁，小程式自動提示•◕☁，由哪一個技師為她服務✘│☁↟•。

　　此時•◕☁，技師的手機端已經收到了小蕾需要剪的髮型✘│☁↟•。當完成服務後•◕☁，小蕾的手機自動收到了服務完成的訊息•◕☁，並提醒小蕾評價技師的服務•◕☁，如果很喜歡•◕☁，還可以分享給自己的好友✘│☁↟•。好友消費後•◕☁，自己也可以拿到優惠券了✘│☁↟•。

　　這是小程式應用下的•◕☁，一種線上和線上深入融合的場景•◕☁，在這個場景中•◕☁，使用者經歷了多個入口▩·：

　　訊息資訊流入口▩·： 小蕾收到了好友的分享•◕☁，驅動她去預定服務✘│☁↟•。

　　提醒訊息入口▩·：服務的當天•◕☁，小蕾收到提醒訊息•◕☁，提醒她到店服務

　　掃碼入口▩·：進門時•◕☁，小蕾掃碼•◕☁，撥出小程式開門•◕☁，同時門店後臺•◕☁，也知道•◕☁，小蕾現在已經到了✘│☁↟•。

　　評價訊息入口▩·：完成服務後•◕☁，由訊息驅動小蕾評價技師•◕☁，分享✘│☁↟•。

　　讓入口融入到線下的商業場景✘│☁↟•。是微信小程式所最追求的目標•◕☁，也是詮釋讓商業融入到無形的真諦所在✘│☁↟•。張小龍在微信公開課提到了掃碼和訊息流兩個入口•◕☁，但是我覺得•◕☁，還有一個更有想象空間的入口✘│☁↟•。也可能更好的詮釋“去中心”化的理念•◕☁，也就是•◕☁，讓每個小程式•◕☁，都是一個入口✘│☁↟•。

　　當小蕾在預約服務時間的前1個小時•◕☁，收到了提醒•◕☁，提醒她一個小時後•◕☁，要開始服務✘│☁↟•。

　　這個時候•◕☁，微信小程式完全可以根據地理位置資訊•◕☁，判別小美如何去•◕☁，這個時候•◕☁，小蕾可能需要打車•◕☁，在這個場景下•◕☁，店鋪的微信小程式•◕☁，可能就扮演了滴滴打車的入口✘│☁↟•。

　　在上面的場景下•◕☁，使用者直接跳轉到滴滴打車的小程式•◕☁，完成一鍵預約打車•◕☁，不用重新輸入起始地址和目的地址✘│☁↟•。傳統的APP模式•◕☁，是一種資訊孤島•◕☁，而微信小程式•◕☁，消除了這種資訊孤島•◕☁，讓小程式和小程式之間•◕☁，能夠自由的聯通•◕☁，讓每個小程式•◕☁，都成為入口✘│☁↟•。

　　本地化執行•◕☁，媲美APP的流暢體驗

　　在小程式出來之前•◕☁，很多線下的商業場景•◕☁，其實試圖透過微信服務號來提供低成本•◕☁，便捷的解決方案✘│☁↟•。

　　到店微信點餐其實就是一個非常典型的場景✘│☁↟•。雖然很多服務商都做了微信點餐的方案•◕☁，但是其實•◕☁，微信的方案•◕☁，在很多飯店•◕☁，使用的並不好✘│☁↟•。很多飯店•◕☁，更傾向於使用區域網+APP的解決方案✘│☁↟•。為什麼大家並不看好微信服務號點餐•◕☁，主要原因是有下面幾點▩·：

　　點餐是一種需要即時響應的場景

　　點餐需要多步完成•◕☁，流程中的每一步的流暢性非常重要

　　服務號是H5來實現的•◕☁，每一步•◕☁，都需要載入•◕☁，流暢性體驗會很差

　　微信服務號現實與實際體驗的差異

　　任何一種線上的場景•◕☁，如果使用者體驗很差•◕☁，自然就無法繼續流行下去•◕☁，客戶的行為也會影響商家•◕☁，所以比較大的商家(譬如海底撈)更傾向於使用保證使用者體驗的本地網路+APP的解決方案✘│☁↟•。

　　小程式由於是在本地執行•◕☁，體驗會非常的流暢✘│☁↟•。並且•◕☁，點餐入口•◕☁，都是由貼在桌面上二維碼•◕☁，使用者需要時•◕☁，可以隨時撥出小程式✘│☁↟•。所以•◕☁，點餐是小程式一個非常有代表性的應用場景✘│☁↟•。難怪張小龍在演講時•◕☁，舉的第一個例子•◕☁，就是微信小程式點餐的場景✘│☁↟•。

　　點餐•◕☁，是一個很有代表性的場景•◕☁，如果整個場景中•◕☁，使用者需要完成多個流程•◕☁，並且流程之間的流暢性對客戶體驗影響很大場景•◕☁，譬如購電影票選位支付•◕☁，買機票值機•◕☁，買汽車票支付等等•◕☁，這一類就是微信小程式的場景化的應用✘│☁↟•。

　　實時雙向通訊•◕☁，重新定義超乎尋常的互動場景

　　除了程式設計師以外•◕☁，很多有人會關心微信小程式所使用的技術✘│☁↟•。

　　但是微信小程式的一項關鍵性的技術•◕☁，將會讓微信小程式重新定義很多超乎尋常的使用場景✘│☁↟•。我們知道•◕☁，微信公眾號•◕☁，或則大部分APP•◕☁，都是使用http和後端進行通訊•◕☁，http可以理解是一種單項的•◕☁，無狀態協議✘│☁↟•。

　　使用者請求•◕☁，然後給出響應✘│☁↟•。沒有實時連線的概念✘│☁↟•。而微信小程式•◕☁，使用了websocket通訊✘│☁↟•。不同於http•◕☁，websocket可以實現雙向實時通訊✘│☁↟•。這就讓後端服務和小程式•◕☁，小程式和小程式•◕☁，可以相互感知狀態•◕☁，或者相互發送指令✘│☁↟•。

　　大部分人•◕☁，可能以為這是技術範疇✘│☁↟•。對於使用場景•◕☁，沒有太多概念✘│☁↟•。我們還是來看一個場景•◕☁，

　　小蕾沒有在線上預約剪髮的服務•◕☁，而是到店來掃碼請求服務•◕☁，這個時候•◕☁，髮型師可以在後端的系統或則自己的小程式•◕☁，直接控制小蕾的小程式•◕☁，讓它進入到需要的小程式頁面•◕☁，譬如自動進入髮型選擇的頁面•◕☁，讓小蕾拍照後匹配發型•◕☁，當完成服務後•◕☁，不需要小蕾操作•◕☁，自動進入到付款頁面•◕☁，小蕾來完成支付✘│☁↟•。

　　店員端小程式控制顧客端小程式的互動響應

　　得益於websocket的實時全雙工通訊能力•◕☁，讓小程式和小程式之間•◕☁，小程式和後端系統之間•◕☁，能夠實現雙向互動✘│☁↟•。前面的例子只是演示了一個在典型的商業場景下•◕☁，由店員生成付款頁面•◕☁，客戶買單的流程✘│☁↟•。

　　傳統模式下•◕☁，需要客戶掃碼去支付•◕☁，而在微信小程式的場景下•◕☁，顧客的小程式•◕☁，可以在店員端的小程式控制下•◕☁，自動跳轉到付款頁面✘│☁↟•。體驗會更加的優異✘│☁↟•。

　　除了實時全雙向的通訊能力以外•◕☁，websocket協議是支援點對點通訊的•◕☁，雖然微信現在沒有支援•◕☁，但是如果微信後續能夠讓小程式支援點對點的通訊•◕☁，又會催生出很多好玩的場景•◕☁，譬如小程式直接給摩拜單車的車鎖發指令•◕☁，而不需要經過雲端✘│☁↟•。

　　小程式和小程式之間•◕☁，直接的資訊傳遞✘│☁↟•。或者真的能實現有些geek所夢想的•◕☁，不透過網際網路•◕☁，而透過相鄰的節點將資訊傳遞到很遠的地方✘│☁↟•。如果說傳統的服務號安裝的是拖拉機的引擎•◕☁，實時全雙工的通訊能力•◕☁，就好比為小程式裝上了飛機引擎•◕☁，它不僅能跑•◕☁，還能飛起來✘│☁↟•。

　　後記

　　張小龍在微信公開課講到•◕☁，微信團隊為什麼要做小程式✘│☁↟•。不是為了用一種新的技術去取代另外一種老的技術•◕☁，而是想切切實實的解決一些問題✘│☁↟•。

　　有時候•◕☁，很多人醉心於技術的細節•◕☁，有些人忙於空泛的營銷✘│☁↟•。卻恰恰忽略了一個新事物存在的本質✘│☁↟•。小程式不是要取代什麼•◕☁，也不是要顛覆什麼•◕☁，其實它就是一個工具✘│☁↟•。(本文獨家首發鈦媒體)

　　【作者介紹▩·：騰訊雲高階產品經理•◕☁，佈道師】

本文連結: http://www.yixieshi.com/67356.html (轉載請保留)