Hosted CRM -> SugarCRM

這些東西，兜起來，會是中小企業的殺手級應用，但是難賣（通路問題），價錢不好（OSS既定映象問題），『在台灣』開一家公司來作這個，不要說賺錢，要活都很難。

必需要加值，變成跟業務有關的套裝，才會有機會。

因為，台灣的觀念有點扭曲，硬體有價，軟體無價，服務是送的。國外的順序完全相反。所以國外可以有很多大大小小的service company，台灣？很少！

就拿最近最有名的ZK來說，他們的主要客戶也都是國外，如果他們靠台灣過活，大概早就倒了。

有幾個特定的產業，一定會買這樣加值的套裝，前天有跟朋友提起，不過他聽來還是很沮喪。但是，這樣的套裝，要賣進大企業，真的非常難。從中小企業下手才會是正途。

前台核心：各產業之絕對必要作業

附加功能：通聯歷史，話術，知識庫，客訴，訂貨

報表核心：通話量，通話品質，業績核算

熟悉產業：營養品、信用卡、基金、保險

要做的話：網頁還是ap呢？ 我還是偏好ap。

別人笑我太痴狂，我笑他人看不穿。是這樣嗎？

單選

複選

開放式

跳題

*量表題 (兩級：好，不好。 三級：好，普通，不好。 四級，五級 等）

*題目區塊

數量級的不同

台灣的系統跟大陸的系統，其中最大的差異，就是數量級的不同

就我本身參與規劃的系統來說。

台灣的核心銀行，目標客戶數600萬到800萬，很多了。但這在大陸只是一個中小型的省的數量，更別說是直管市了，那會上億。

所以相同的系統，相同的功能，從台灣搬過去就能用的？ 除非剛好是地方級。不然，像我客戶那樣，光客戶數就破億，要作系統大集中。有誰能確保自己設計的系統撐得住？

這時候 系統架構的強固性跟彈性的價值才會彰顯出來。
一個客戶端連線會消耗系統多少資源？
沒有做分散式規劃的話，一台機器能撐多少同時的連線？這麼大的機器，客戶願不願意買？
有做分散式處理的話，頻寬要多少？網點要怎樣分佈？整個伺服器群的規劃？資料的即時性？
會有千奇百怪的問題冒出來，這樣，你手上產品的價值還剩多少？要小修、大修還是重翻？
不修不改能給多少人用？留多久的資料？留多少的資料？
修修改改又能吃多少？
重寫，重翻，你有多少成本？客戶付你多少錢？你還剩什麼價值？
這些，不是我們在台灣隨隨便便用一台PC搞定幾百個concurrent connection的時候能夠想像的！
機器是n台，架構的好，管的好的話它的複雜度可能一直都是1，普通一點的是n，而更常見的是n^2。
PM，SA，Arch，DBA這些人都具有規劃得出這樣數量級系統的能力嗎？
就還不用說使用者需求，文化，法律等等的差異了。
待續

產出格式： Fixed Length, csv, xls

產生方法： 依照指定的週期，指定的格式，在指定客戶名單中的資料欄位以及電訪結果作調配

其他功能： 電訪結果匯入、電訪結果輸入、名單匯入、名單輸入

很小的大系統

很大的小系統

目前有個客戶每天用來調配千萬筆的客戶名單跟算億的通話結果。

是的，大陸的客戶。

通路 HTTP GET, XML, SOAP, MSN bot, Skype bot, SMS

範例 MSN機器人 （有很多人做了）

差異

機器人雖然有很多，但是沒人去作秘書的作業，像是

電話簿查詢/管理

行事曆查詢/管理/自動提醒

關鍵郵件追蹤提醒

……

還有 通路上的差異

沒人作SMS的通路

查股價的機器人 大家會愛玩 玩到爆

商用的機器人 就沒人願意去想 去作

就像是UMS，10年前IVR廠商努力推，沒人要。現在Exchange 2008內建了半套，說不定會帶動需求。問題是以中小企業為主的台灣，能賣幾套？