知識庫作為呼叫中心的一個重要組成部分，目前在眾多行業中被廣泛應用。但是，就知識庫的功能來說，我們是否已經充分挖掘了知識庫的所有潛力？是否合理利用了知識庫系統呢？

一、知識庫不僅僅只是存放知識的數據庫
我們對知識庫的定義很多時候局限在“只是一個存放標準答案的數據庫”。我們希望這個數據庫能夠將產品的信息都存放在在里面，當客戶提問的時候，客服代表們能夠通過調用數據庫中的數據，及時的把答案拿出來告訴客戶。
這個觀點不能說錯，但是，這樣考慮知識庫的實際利用是非常膚淺的，它并沒有真正挖掘出知識庫的潛在價值。那么，什么是知識庫潛在的價值呢？我們先要從市場調研談起。

很多企業都有進行市場調研的經歷。想要進行一次科學有效的市場調研，它所需要的投入是巨大的。首先，我們需要準確定義我們的目標客戶；其次，我們要正確地在目標消費群體中進行抽樣；然后，我們要組織足夠地市場調研人員對這些抽樣人群進行調研；最后，我們還要對獲取的信息進行一定的量化分析以得到關于市場的預測。

從開始到結束，一次市場調研需要牽動企業很多的資源，而且成本投入及風險都是具大的。但是，我們并不能很自信地保證，在調研中可以得到關于客戶的準確客觀的數據！因為，在市場調研的整個過程中，有很多的不確定因素，包括最初的目標群體定義及最后的數據分析方法。那么，有沒有一種方式能讓企業在很少的成本投入之下獲得高度準確的市場信息呢？我們的答案是肯定的。呼叫中心的知識庫系統從另一個角度滿足企業的這樣一種需求。由于知識庫數據完全是因著客戶的具體需求而被的一次次調用，因此，如果對知識庫數據使用情況加以科學地分析，將會為企業帶來第一手來自消費者的市場反饋信息。

所以，一個好的知識庫，不僅僅只是一個存放信息的數據庫，更重要的是，它能夠為企業帶來第一手的消費者需求的信息，從而能夠幫助企業的決策者對一些重要的市場變化進行決斷。為了能夠使我們的知識庫系統承擔這樣的職責我們需要談一下知識庫的設計思想。

二、一切為了便于最終用戶的使用
知識庫的設計原則其實很簡單，就是一切為了便于最終用戶的使用。

或許我們會說，知識庫的使用者是我們的客服代表呀！不錯，但是，客服代表為什么要使用知識庫？他們是為了能夠更好地回答客戶的提問。所以，知識庫是為了滿足客戶的需求而設計的。因此，便于客戶使用，是知識庫設計的根本原則。具體來講可以從以下幾個方面來考慮：

1、便于查詢，保證座席代表能在最短的時間內調出所需數據
在知識庫的使用中，我們都希望能在最短的時間內查找到所需信息。假設知識庫可以被客戶直接調用，那么，如果找一個問題的答案需要花很長時間，客戶還不如直接打電話。長時間的等待，是客戶不希望看到的。同樣的，在座席代表調用知識庫數據時，如果知識庫查詢的速度較慢，而客戶又不愿意等待，這樣就很可能造成座席代表根據自己的印象提供不完整甚至錯誤的答案，而這種答案的提供，最終將嚴重影響客戶對企業服務的滿意度。所以，提高知識庫的查詢速度是設計時必須被考慮進去的。我們不訪可以設置一個查詢時間的參考值，比如5秒（這個值非實驗所得，僅為舉例），如果數據在大于5秒的時間內被查詢到，那么我們可以說，這個查詢速度是不合格的，接著就需要重新來分析我們的程序算法，想辦法提高查詢效率。

2、更專業的數據劃分
有了速度還是不夠的。我們知道，要讓一個龐大的數據庫更有效地被利用，合理地給數據分類就是提高查詢效率的有效途徑。因此，在設計知識庫時，我們應該盡可能地定義好不同的數據分類。比如服務類的，技術類的，常見問題類的等等，這樣，使用者在查詢信息時，能夠更有針對性，而這樣的做法將有助于我們之后的數據統計（有關這點，我們會在稍后詳細介紹）。

3、有效地反饋平臺
知識庫是為了滿足客戶的需求而產生的，如果我們發現了客戶的新需求，但是我們原有的知識庫系統卻沒有包含，這時，一個良好的信息反饋平臺可以使得知識庫的管理者及時獲取有用信息。在知識庫設計時，可以預留一個反饋的平臺，知識庫的使用者可以通過這個反饋平臺將自己的想法“告訴”管理員，而管理員也可以通過這個反饋平臺及時地了解使用者的想法并給予反饋。這種互動的形式是保證知識庫系統不斷完善的最好辦法。

4、信息的表達形式
知識庫中信息的具體表答與數據庫的程序設計無關，但是，它卻是關系到最終的客戶滿意度的問題。我們都知道，在客戶服務中，我們會盡量避免使用過分專業的術語，改之以普通用戶能夠理解的語言。知識庫作為解答客戶問題的資料庫，座席代表在實際工作時，完全就可以按照知識庫上的答案給予回答。但是，如果知識庫上的表達詞匯過于專業化，客戶根本無法理解，這時，原本的一個問題，在得到答案后反而變成了2個或者更多的其他問題。這種情況的發生，就不是在提高服務效率了，而是在影響我們的服務。所以，當我們準備把我們的信息輸入知識庫中的時候，請從客戶的角度來看看我們的這些解答，能否被順利理解和接受。

以上，我們僅從最終用戶的使用感受的角度出發，分享了關于知識庫設計的一些想法。接下來，我們從企業的角度出發，從數據分析的角度來看看，怎樣的數據結構才便于以后的數據分析和挖掘。

三、量化我們的數據
在實際使用中，我們發現，知識庫的數據絕大多數都是定性的，都是文字的表達。那么，如果我們想對這些定性的數據進行分析，我們就必須事先做好定量的準備工作。只有量化的數據，才能更精確地反映實際的結果。

為了實現這一目標，我們可以將我們的數據結構做如下的定義：

如上圖，這是我們的一個簡單舉例。在一個知識庫的數據結構定義中，除了基本的編號、問題、參考答案以外，其他幾個都是為了統計而存在的。包括問題的所屬類型、問題的難度、被查詢的次數、最后查詢時間等參數，而這些參數的設置，就是為了給我們的企業決策者提供一定的決策參考。比如，被查詢的次數，這個參數可以告訴我們，這個問題被客戶關注的程度。如果，大多數用戶對這個問題表現出了極大的興趣，那么，就有兩種可能：從壞的角度來看，我們的產品是否在這個方面存在了問題，或者我們的說明書寫的不夠詳細，以至于客戶無法理解，而不得不再聯系我們的客服人員以求幫助；從好的角度來看，可能這個活動的確能夠引起客戶對我們產品的關注，它的確能夠抓住消費者的心。

總之，不同的參數設置，會為我們的決策記載更多的來自消費者的信息，從而幫助企業更好地把握市場。而這個，也正是知識庫所具有的潛在的價值。

四、教會座席代表使用知識庫
現在，我們已經知道了知識庫能夠為我們帶來什么，知道了知識庫在設計上需要注意什么，接著，我們就要來看另一個非常重要的東西，如何體現知識庫的價值？

要讓客戶真切的感受到知識庫的便捷，要讓企業真正能夠提取來自知識庫的有價值的信息，我們必須要讓我們的座席代表學會如何正確的使用知識庫。因為，座席代表是直接面向消費者的，而且，我們也需要座席代表在每次解決客戶的問題后做好適當的知識庫的登記，以幫助我們及時掌握客戶的動向。

對座席代表的知識庫培訓，從入職的時候就可以展開。在入職培訓之初，當所有的業務知識都還沒有教給他們時，我們就應該讓他們知道我們的知識庫，了解基本的知識庫的結構，操作方法。之后，在整個業務知識培訓期間，我們可以安排足夠多的內容讓新員工自己通過知識庫來找到答案。這樣做，就是為了幫助他們熟悉知識庫的使用。上線后，我們可以組織定期或不定期的抽查，來檢驗座席代表對知識庫的熟練程度，并且，還可以通過組織一些競賽活動，促使座席代表自己愿意，能夠主動地去掌握知識庫的操作。

另外，要明確規定知識庫的操作流程，要把這個流程融入到日常的業務工作中。當客戶來電尋求幫助時，第一反映就是要打開知識庫，查詢正確答案；當結束一次服務之后，需要在知識庫中做好電話小結，主要就是點選此次電話的主要類型等。當然，為了避免座席代表的誤操作，我們在系統中也會自動設置該功能。如果某個電話中出現了知識庫中沒有或者不詳細的解答，座席代表有責任第一時間通過我們的反饋平臺向知識庫管理員報告。

通過上述兩種方式，我們要讓知識庫成為座席代表日常工作必不可少的一部分。要讓他們習慣依賴知識庫而不是他們自己的記憶。講到這里，我們要強調一點，由于知識庫將作為整個呼叫中心的重要組成成分，那么，它的準確性就必須有嚴格的保障，所以，對于知識庫管理員也要有明確的要求，并且也要設置一定的監督部門，來確保這個關鍵組成部分的正常運作。

本文刊載于《客戶世界》2006年6月刊，作者為上海電信商業客戶服務熱線培訓師。