吳明宜八成的解決方案
評估 SaaS 的另一項因素是服務能滿足貴公司多少需求。或是說，你得因此放棄什麼功能。
「你沒有辦法做到 100%，」Stoney 說：「一定只做到某個程度，可能最後 20% 是達不到的。」例如在產生 Salesforce 定義格式外的報表上，該公司已經做到極限了。
Monteiro 也碰到類似問題，他希望能阻擋特定類型的流量或拒絕某些協定，但這超出 Klir 的能力範圍。「在流量管理產品上，你可以設定哪些協定你不允許，」他說：「但在 Klir 上，你就只能用防火牆把它擋掉。」
他也想要更細膩的報表，像是追蹤協定或應用到個別使用者。不過 Klir 還是未能讓他如願。
「如果你買了套 SaaS，你就得照單全收了，」Monteiro 說。
雖然許多 SaaS 已可以做高度客製化，不過客戶就會碰到客製化的成本問題，這樣一來當初導入的原意就打折扣了。因此，IT 人員必須仔細評估 SaaS 以確保應用是不是真能滿足關鍵功能的需求。
你得到服務了嗎？
SaaS 最大的弱點是斷線—而這又是使用者最擔心的（請見「SaaS 採用因素」）。當你把關鍵應用委外出去後，就等於是放棄瞭解決問題的主導權，而得仰賴供應商的解決能力。 Salesforce.com 去年 12 月發生斷線，長達 7 個半小時，受害客戶不知凡幾。而去年一年這家應用或主要元件也間或發生斷線。
Select Business Solutions 就是去年 12 月的受災戶之一。「我們氣壞了，」Stoney 說：「但還好並沒有影響到我們作業。但如果我們因此停了一筆訂單，就會有人吵著要換別的產品。」
在評估服務，你要記得檢視它在穩定性，包括斷線原因或服務回覆時間等過去的紀錄。
這項評估應該要與貴公司內部的營運情況相對照。自己管的應用也經常因為組態錯誤、維護、下載修補程式問題而斷線，那問題就成了「你覺得貴公司 IT 部門能做得比 SaaS 業者好嗎？」
在可用性方面，SaaS 廠商也向電信業/ISP 學到一招半式。大部分 SaaS 都已提供基礎的服務層級協定 (service-level agreement, SLA)，像是 3 個或 4 個 9 的可用性。儲存服務供應商 EVault 則是例外，該公司表示正努力做到 99.99% 不停機，合約卻不包含 SLA 。
和一般 SLA 一樣，SaaS 也是繁瑣得不得了。聰明的 IT 主管要找的是一份依據使用者經驗來測量服務的 SLA 。斷線是一個很粗糙的測量，但一個反應時間過長的 Web 應用一樣也能把使用者搞瘋，並降低生產力。
你還要記得檢查供應商的基礎架構。資料庫有沒有備援、 Web 伺服器及備用電源等等都很重要。
供應商願不願意公開問題及解決方案也是應該觀察的地方。通訊服務供應商 BlueTie 就會公佈它可用性統計數據，像是 Web 伺服器回應時間。它也會發佈事後報告讓客戶知道問題何在，BlueTie 又是怎麼解決的。你也可以問問你供應商是不是有相同服務。