SaaS提供におけるSLA設計のヒント(その1)

SaaSのサービスを提供する際には、顧客に対するサービスレベルを
SLA(Service Level Agreement)で定義しますが、
何を織り込み、どこまで約束すべきかは迷うところです。

こちらの記事はSLAを設計するのに参考になります。

Smart SLA Design for Your SaaS (by Chis K.)  英語です。
http://blog.inetu.net/2010/04/smart-sla-design-for-your-saas/

内容を抜き書きします。

  • SLA設計はマーケティングとITの両者で設計すること

マーケティングはとても魅力的なSLAを作るが、非現実的なものにしてしまい、
実際には問題を引き起こしてしまう可能性がある。一方、ITチームは保守的に
なりすぎて潜在顧客に対してまったく魅力的にはみえないSLAにしてしまう傾向がある。

  • 何を織り込むべきか

技術的な側面とカスタマーサービスの側面の両方を織り込む必要あり。
技術的な側面: 障害復旧時間の保証
        システム応答時間の保証
        システムの可用性または稼働時間保証など
カスタマーサービスの側面:
        技術サポートの受付可能時間
        応答時間など

  • 稼働時間保証

99.9%(年間8時間45分57秒のダウンタイム)や
99.999%(年間5分42秒のダウンタイム)という形が多い。
一般的な最低ラインは99.5%か。
SLAを満たさなかった時の支払い額を取り戻すことは難しくないが
顧客の信頼を取り戻すことは非常に難しいことを念頭に。
自社が完全にコントロールできること、自社が選択したベンダーに
よって保証されることのみを含み、顧客の操作によって起こることを
含まないように。

  • 定期メンテナンス時間の重要性

予防的なメンテナンスを過小評価しないように。定期メンテナンスを
減らすことによって顧客へのサービスの低下や顧客データの喪失リスクが
高まることがないように。

  • プラットフォームからもたらされるSLA 

サービスプロバイダーを利用している場合、そのSLAが影響する。
サービスの設計の仕方によってはプロバイダーのSLAを超えることも
可能(複数プロバイダーを使うなどによって)であるが、プロバイダー
が提供するSLAを参照する必要あり。

  • 補償 

二つのパターンが考えられる。

  1. SLAを下回る状況にはまずならないという前提のもとで
    堅実な補償を提示する
  2. 高めのレベルで保証設定をすることで、支払い機会がある程度
    発生することを見越し、補償を軽めに提示する
  • 結論

SaaSを提供する企業にとってSLAは顧客の信頼を獲得する重要な要素。
うまい設計をすれば自社サービスの評判を保持しつつ、SLAで潜在顧客に
アピールすることも可能。

 

ちなみに、SaaSの基盤となるPaaSであるWindows Azure Platformの
SLAはこちらからダウンロードできます。
各国語で用意されていますので、 -Japanese.doc をどうぞ。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中