微信公眾招商銀行帳號開發高級篇

摘要：招行經過一年多的發展，2014年已超過1500萬粉絲，高居銀行類微信公眾號榜首，堪稱最成功的微信公眾帳號案例。深圳雲軟作為招行信用卡微信平台的研發廠商，就微信公眾帳號開發的高階應用，總結了以下幾點經驗。

2013年4月，招商銀行信用卡微信公眾帳號以「小招」的親民形象推出，不到半年時間即獲得數百萬用戶的青睞，經過一年多的發展，截至目前已有超過1500萬粉絲，高居銀行類微信公眾號榜首，堪稱最成功的微信公眾帳號案例。深圳雲軟作為招行信用卡微信平台的研發廠商，就微信公眾帳號開發的高階應用，總結了以下幾點經驗。

規劃要超前

大部分企業在規劃時，抱著試試看的態度，投入不足，僅是因為領導說要做微信而做微信，並未做長遠打算，導致淺嚐即止。很多微信公眾帳號只是掛了個連結鏈到頁面，做個微網站，沒有深入考慮怎樣透過良好的體驗把企業的服務提供給客戶。一個超前的規劃，首先必須選好平台－具有穩定合理的架構，足夠的業務彈性和開放性，可以逐步疊加發展業務，可以靈活調整體驗，可以對接後端的各種系統資源等。

架構要合理

微信平台不是單純的連結入口，它更是連結企業服務與使用者之間的管道。因此微信平台需要有合理的架構設計，使平台能在不同的互動模式以及各種形態的服務資源之間靈活地進行切換，並保持良好的體驗。總的來說，微信的互動包括：點擊選單的輕App體驗、聊天視窗的訊息互動、頁面的互動三大類，其中訊息互動又包含自動訊息互動和手動訊息互動。從長遠的規劃來看，平台需要滿足以下要求：

1. 高效能和高可用；

2. 容量的可擴展性;

3. 可監控、可管理;

4. 業務可擴展，可靈活進行業務變更與載入；

5. 開放性，可由客戶進行業務流程的二次開發，提供標準化的介面與第三方系統進行對接，包括接入多種IM管道等。

我們許多客戶都已在應用或規劃全通路接入，可以實現微信、微博、QQ、WebChat、郵件等多種模式。

平台架構上許多細節的設計，都是來自業務及營運的需求，如下圖所示。

1. 對並發量的要求，決定了介面設計的模式，採用非同步、無狀態、多執行緒的介面模式，才能滿足超大並發量的處理，並且易於擴展。招行目前每天發出的消費提醒，就達到400萬條，尖峰時段半小時可達20萬多條。

2. 可靠性的要求，決定了快取的持久化，保證了即使某個節點的程式宕機甚至物理故障，也不會遺失交易資料。我們早期的方案也存在缺陷，在特殊的情況下如果介面程式崩潰或重啟，就會使發送佇列中的資料遺失。雖然量不大，但對銀行業務很重要，會導致用戶的投訴。

3. 資料庫效能對DB交易量的支持，以及分散式架構的要求，決定了資料庫中間層的存在。好的架構，不僅要支援單一資料庫把效能發揮到極致，還要考慮伺服器硬體如果出現瓶頸也能擴展，因為資料庫由於運算能力、I/O吞吐、儲存等多方面的原因，總是會在某點達到無法超越的瓶頸，就像12306，當海量的使用者請求在短時間內湧入時，會給系統帶來極大的壓力，整個系統的最後瓶頸往往就是資料庫，解決的辦法就是採用分散式解決方案。雲端軟IMCC在架構上支援橫向和縱向的擴展，理論上只要網路頻寬許可，就可支撐無限容量。

4. 通訊連線的效率，微信的協定是HTTP雙向POST的協議，採用短連線方式。這種通訊方式其實效率是很低，每次要求都需要建立連線、釋放連線。對於單一服務節點，其效能遠低於TCP長連接，協定的位元組冗餘也比較多，對傳輸頻寬要求較高，但好處在於可以方便地透過多節點進行擴展，開發的難度也較低。隨著電腦效能和網路頻寬的提高，以前要按位元組來節省的傳輸資料量已可被忽略，短連接方式以後會得到廣泛的應用。雖然我們平台內部的通訊採用TCP長連接，在百兆網路環境下最高可以達到每秒數萬次的訊息量，效率高很多，但缺點是對開發的要求比較高，需要處理很多網路異常事件，也不便於多節點擴充。

招行輕體驗、重後台的體驗設計

招行在微客服產品上的設計充分體現了「關注使用者體驗，重視服務細節」的用心服務理念。雖然招行在微信平台上實現了其傳統客服和App上超過70%的業務服務功能，但在用戶體驗上你會覺得很清爽，很多功能你不用的時候都是躲在後面的，展示出來的只是最常用的功能，而一旦你需要，透過簡單直接的操作，就能獲得，正所謂呼之即來，揮之不去，不用的時候絕不佔你眼球。例如你對小招說：“境外消費”，小招就能很快找到所對應的答案以及兌換手續費等相關問題。配合招行後來提供的語音辨識功能，更是將操作簡化到說到就能做到的程度。這種模式我們稱為平鋪模式，相對以往需要透過多層菜單、多次互動才能找到自己想要的功能，平鋪模式可以做到所想即所得，特別對於微信這樣的移動終端，展示的容量有限、操作輸入不方便的情況下顯得更方便。

應用了許多跨界的方法來解決問題

在通訊產業，流量控制是非常常見的，它可以阻擋系統能力以外的請求，不至於將系統弄垮，用戶可能會得到「系統正忙」之類的提示，但在電腦和網路產業，流控的概念還沒有廣泛應用。以微信為例，微信自己有提供對外的流控，超過一定頻次就予以拒絕，卻沒有考慮外部系統的流控，當超過系統處理能力的請求湧入時，就只能丟棄，因此提供的是有損服務。對於有損服務，我們需要採用快取重發的機制來保障資料的有效送達，對日常聊天還沒太大影響，但對一些要求嚴格的金融服務，就會造成客戶投訴。

再例如我們參考了NGN中業務與承載分離的設計理念，把訊息傳輸、會話控制與業務流程引擎分離，分層次的軟體架構設計，不僅是滿足業務靈活度的關鍵，也是進行軟體架構擴充的核心。作為一個千萬級用戶的營運平台，在追求穩定服務的同時，還要能不斷推出靈活的新業務，而不是每次業務變化都要去更新升級軟體，甚至重啟服務才能加載新的業務功能。招行所使用的雲端軟IMCC平台，從設計之初就考慮了這點，透過將訊息承載與業務流程分離，使基礎平台變成與業務無關的底層平台，而各種業務流程則透過流程引擎進行解析，實現業務的動態載入。

招行平台的業務流程引擎設計工具，也參考了傳統呼叫中心的視覺化流程開發方法，將各種常用的流程處理元件封裝，稱為「元件”，使後期進行業務的二次開發效率得以大幅提升，並且降低了對開發人員的技能要求，只要稍有編程基礎的開發人員就可以快速完成業務流程的定義和發布。而且這套引擎不是一個封閉的系統，透過自訂節點，我們可以呼叫外部系統接口，實現與其他系統的對接，並且可以呼叫自訂功能，具有很強的靈活性。

專業的多客服系統

招行微信平台最早的出發點就是建造一個基於網路管道的線上客服平台。因此，在平台選型時首選已在中國電信集團IM客服上有了沉澱和積累的IMCC平台，於2010年建設的基於營銷QQ的800010000平台已經有了5000萬好友，上百台服務器的集群架構。 IMCC有很多針對呼叫中心專業客服而設計的功能，所謂多客服，其實跟電話的呼叫中心很類似，用戶從一個號碼（電話、QQ、微信等）呼入，後台有一個呼叫中心團隊來處理用戶的聊天請求。因此系統需要有ACD伺服器來實現不同的路由及排隊策略，例如先來先服務、平均分配或按比例分配、上次服務優先、VIP插隊等。另外，呼叫中心團隊要能依技能組進行排隊和路由，例如諮詢的是一組，VIP服務是另一組，還要允許一個工號有多種技能，可以作為不同技能隊列的資源放到資源池排隊。

專業的呼叫中心業務十分密集，在操作效率上要求很高，坐席在操作上要求盡可能減少低效的動作。例如重要訊息置頂功能，可以避免重要的聊天訊息在視窗滾動中難以找到，還有來話原因採集，只需要在採集樹上簡單點擊，就可以完成。除此之外，為了提高話務員知識檢索的效率，我們設定了在聊天訊息中觸發知識庫自動檢索的功能，只要維護得當，從使用者的輸入就可直接觸發檢索出答案，大大降低了話務員的工作強度。

微信、QQ等個人聊天軟體，都是無狀態的，用戶可以不用管對方是否在線，不計較什麼時候回复，但這給專業客服帶來了很大麻煩。例如戶可能發了一句話就走開了，但會話視窗就一直掛在那裡，客服每天可能會接入數百個會話，如果一直佔用，會使客服無法專注處理，後台的各種KPI考核也無法進行。因此，專業的人工客服應用場景，一定是有狀態的會話，就像一通電話，有接入有掛斷。但考慮到使用者體驗，我們也在研究是否有可能實現無狀態會話的無縫兼容，即在用戶側感覺是無狀態的，什麼時候都可以發訊息，但在客服側處理稱為有狀態的，能確保會話效率和質檢考核，這套系統目前還在研發中。

客觀看待智慧客服的應用

招行是微信智慧機器人最成功的案例，雖然同是IMCC基礎平台加小艾機器人，電信與聯通在應用時效果卻並不十分理想。原因在於，電信和聯通的業務太過複雜，產品數千種，知識庫數10萬條，問題過於開放。而招行信用卡業務領域相對比較窄，而且投入了大量人力進行人工知識識別和添加，才使得小招招人喜愛。由於技術局限，智慧機器人目前有兩個一直未能解決的問題：1. 自動學習能力；2. 真正的語意理解能力。如果有哪家公司能在這兩方面有所突破，將會為智慧機器人應用帶來極為廣闊的前景。

對實際應用而言，我們認為，如果坐席數量沒有到達10人以上，那麼應用智慧機器人的投入和收益並不匹配，反而不如透過關鍵字應答等簡單方法。根據我們統計的招行微信數據，使用者70%的操作是選單操作，25%是5個字以內的短詞，剩下的是與人工客服的對話。新開發的關鍵字匹配方法具備模糊匹配、最長匹配優先、自動分類未命中等方法，已經可以在很大程度上取代智慧機器人。

招行的安全措施

「安全」是金融類微信應用的基本要求，在保障安全性方面，招行採用專線接入的方式，保證了資料不在公網傳輸。最新消息顯示，騰訊已在進行加密協議的研發測試，未來將讓銀行的資訊安全更有保障。

其他安全性方面採取的措施包括：應用HTTPS協議，頁面傳遞參數加密防止中間人攻擊，應用動態密碼鍵盤防止駭客截獲密碼，後台安全性原則等。除此之外，應用安全掃描工具對系統進行模擬攻擊和漏洞掃描，也是必要的工作。

新進階介面應用

【群發的挑戰】

#招行已有1,300萬粉絲，群發訊息到全量客戶，將給系統帶來極大的壓力。騰訊的訊息下發能力非常強，1000多萬的訊息只需要幾個小時就可以全部送達，這些客戶收到訊息後必然會作出反應，簡單的有查詢餘額、瀏覽頁面，如果是互動式的活動，將會產生致命衝擊，在微信沒有提供高級群發介面之前，招行試過群發，基本上每次都導致系統的阻塞甚至宕機。因此，理想的群發模式，必須是流量可控，可依照目標使用者清單精確定位的模式。即包含兩種模式：1. 需要全量通知所有用戶的，根據活動的性質（純告知、互動）；2. 根據客戶群細分結果，按照目標用戶清單進行定時定向發送。

騰訊提供的分組群發高級接口，限制是每天100次，每次1萬條，也就是說每天最多100萬（實際是99萬），無法滿足全量用戶通知的需求，但又不能採用MP後台進行全量群發，這種情況就需要使用騰訊提供的分組功能，將使用者分成多個批次。我們很多客戶把這個分組功能與客戶群分組搞混了，並使用分組功能來實現客戶群細分。其實，客戶群細分是經常變動的，不斷透過介面同步騰訊的數據，既不合理也不科學，而應盡可能將客戶群細分的工作放在企業一側的CRM系統，透過客戶標籤的方法維護，才能確保基於CRM的精確行銷得以實施。

【矩陣帳號、分權分域管理和UnionID】

#現在很多集團級企業都存在多帳號的管理需求，但是由於微信OpenID只能跟一個公用帳號對應，導致各個帳號累積的使用者沒辦法統一管理。 UnionID實現了多個帳號之間相同使用者關聯，可以把分散在多個公用帳號的使用者統一辨識、管理，既能體現子帳號的個人化，又能將好友資源集中管理。

雖然招行平台可以支援多個帳號，每個帳號單獨管理，但並非帳號開得越多越好。因為分權分域的管理，如果粒度過細，會對使用和管理帶來過重負擔，開發的工作量也相應加大。對於集團級的矩陣帳號應用，我的建議是：子帳號的粒度最小是城市，更小的粒度，如支行、分店等，建議通過參數二維碼的方式進行客戶渠道的區分識別，在後台標識出客戶的歸屬，以便後續提供針對性的行銷和服務。

以上是微信公眾招商銀行帳號開發高級篇的詳細內容。更多資訊請關注PHP中文網其他相關文章！