Before finalizing an outsourcing arrangement, you should have a service-level agreement (SLA) with the vendor. Simply described an SLA is a formal negotiated agreement between customers and their service provider, or between service providers. A typical SLA records the common understandings about services, priorities, responsibilities, guarantees, and the like, with the main purpose being to agree on the level of service. For example, it may specify the levels of availability, serviceability, performance, operation, or other attributes of the service such as billing, and even penalties in the case of violation of the SLA.
There are two major parts to an SLA — the governing document and the process:
◆ The SLA document is usually legally binding between a company and an outsourcing ven- dor(s). The document describes the exact services and service levels, with details about all agreements.
◆ The SLA process represents the methods that the outsourcing vendor will use to support the SLA document. The methods of supporting the SLA document are usually left to the out- sourcing vendor to identify. These processes should be discussed and possibly identified during SLA contract negotiation. It is important that both parties understand the processes and methods of support as well as the management and reporting tools.
The SLA process represents a third of the total solution. It is up to the outsourcing vendor and your company to ultimately choose the correct people to manage the systems and the best technology for implementation. The people involved in managing the process must also manage the technologies and understand the importance of reporting on and monitoring the entire system.
System management and service desk automation technology can provide a supporting environment for tracking, escalation, and management of service metrics. End-user satisfaction surveys can also provide input that will help target appropriate service levels and cost controls.
Proper Elements of an SLA
Let’s take a look at what needs to be considered in creating an SLA document for the fictional com- pany Maeder Enterprises:
Statement of objectives The primary objective of an SLA document is to correctly identify the support requirements for Maeder Enterprises in regard to supporting the messaging system needs.
Usually this will be negotiated between the Maeder Enterprises and the vendor.
Contacts and role assignment First, name the key contact for the service-level agreement and delegate SLA management tasks to others. You may need to include other contacts such as management, technical personnel, and the like.
Reporting The frequency and detail of reports must be identified as well.
Finances Payment terms and contract length are negotiated with the outsourcing vendor.
Contract termination procedures Specifies how the contract is terminated. Specifies penal- ties, if any. Specifies whether technology transfer must occur.
Review process There should be a formal review to evaluate the performance and customer service levels as well as staff reviews. A quarterly review is sometimes formalized in order to include discussions on SLA fulfillment, staffing, and future projects that may affect the SLA.
Change management Specifies how amendments and changes can be made to the existing SLA. Several things could require a change or addendum to the existing SLA:
◆ A change in the process workflow ◆ Additional services
◆ Missed performance or customer service thresholds ◆ Additional third-party applications
Usually these changes are detailed by contract riders appended to the SLA until such time that the SLA is rewritten to incorporate the addendums. The SLA can only be written during a renewal cycle, with both parties present.
Financial incentive plan Specifies penalties and bonuses for meeting or exceeding SLA per- formance guidelines. This can be used as a carrot/stick approach to ensure SLA compliance.
Performance-level guidelines These should be specified and metrics applied. In the case of an SLA for Exchange outsourcing, typical metrics might include:
◆ Intersite message transfers ◆ Intrasite message transfers
◆ Remote synchronization performance ◆ Offline address book refreshes ◆ Mailbox replication/size ◆ Directory update frequency
◆ Administrative task time limits (e.g., one business day to add a mailbox)
Uptime requirements System availability can be an expensive requirement. It is impor- tant to identify the specific requirements from a resource access standpoint and not neces- sarily on a server-by-server basis. The specifics dictate the availability of the services: ◆ Network and remote access
◆ Mailbox access ◆ Public folder access ◆ Intersite directory ◆ Intrasite directory ◆ Server availability
Equipment support requirements For access and security, you should require that named contacts be permitted physical access to the equipment at any given time. Moreover, over- all access to the equipment must be secured and restricted. Access to the equipment must be available 24 hours a day, 7 days per week for the vendor’s support personnel.
For backups, many companies require that the clients be able to request a ‘‘recovery of deleted items’’ for up to 30 days of deleted items. Moreover, backup tapes for the system should be placed in a 30 day rotation, then erased or destroyed. There should be no tapes that contain data over 30 days old.
For monitoring, specify any required monitoring or where appropriate the type of monitoring technologies to be used.
Staffing Certification and experience levels of supporting staff. Exclusive/nonexclusive use of resources.
Equipment Brand/vendor of equipment to be used. Any additional equipment for testing or recovery.