When selling a product or service you establish a relationship with your customers. To protect both parties and to support the sale a number of aspects should be clearly defined so that both parties understand the boundaries of the relationship.
Particularly important in this respect is the SLA. SLAs are formal contracts guaranteeing quantifiable performance under specified conditions that define Quality of Service and attempt to quantify it so it can be measured.
MorganDoyle has developed a rich library of SLAs covering:
MorganDoyle's White Papers - Don't Get Bitten by Your ASP and Writing SLAs - provide further detailed information.
| A generic SLA should address the following issues: | |||
| Define the service | being provided, in terms of parties to the contract, boundaries, responsibilities and service features. It is often worth including an explicit statement of what is not included if this is not obvious. | ||
| Specify |
|
||
| Quantify timeliness | i.e. delay or response times, usually in terms of a percentage of events, e.g. round trip acknowledgements or user transactions, which will be completed within the specified time. | ||
| Define procedures | for reporting and rectifying faults, e.g. response times, Mean Time To Restore, escalation, etc. | ||
| Prescribe responsibilities | for users and/or consumers, so that the provider can perform his part of the bargain. | ||
| Describe service monitoring | both in terms of report contents and the reporting period. | ||
| Define all parameters | or metrics in unambiguous, technical terms. | ||
| Allow for renegotiating | the SLA in the longer term, as industry norms and your needs change. | ||
| Provide guarantees | in terms of compensation if service levels are compromised. | ||