Turning Your Intake Meeting into a Winning Service Level Agreement
Service Level Agreements form a solid base for the relationships between a provider and their customer by ensuring both parties understand the service offered while having a clear picture of the support provided and its cost. The intake meeting for the sale of a service or an internal intake meeting for creating a new service offers an opportunity to document availability and support requirements alongside its feature requirements. These then become the service level requirements upon which the service level agreement is based.
This is an import aspect of the intake meeting as focusing on features alone fails to address the level of service needed by the customer, dooming the relationship to struggle from the start.
ITIL® is a service management framework that enables providers to define and meet their customers’ needs by ensuring services are well-managed from inception through operation and improvement. ITIL stresses the importance of ensuring both the warranty and utility of a service throughout its design. Without both of these considerations, the resulting product will not meet all of the needs of the customer.
This overview takes readers from the intake meeting through the creation of the product and its service level agreement in a few simple stages:
- Intake to requirements
- Requirements to design
- Design to service level agreement (contract)
From Intake to Requirements
Including warranty requirements in all initial intake and design sessions ensures the service can be designed and delivered in a way that meets the overarching needs of the customer. The initial intake process provides the opportunity to document the customer’s expected use of the service and from where it will be used. Thus, any intake questionnaire used to define the service and its support should include a discovery of the following needs:
- Expected hours of staffed-use: single shift to round the clock shifts
- Number of users expected throughout the day in detail: for example, 9-5 use vs. overnight use
- Locations from which it will be accessed: corporate locations only or home use after-hours
- How the service will be accessed: via private network or Internet
- The level of criticality of the service to the business:
- Low criticality administrative tool that can manage some downtime
- Highly critical internal service that needs high availability
- External customer facing site: downtime would cause loss of confidence in the business
- Stability of user base: understanding any projected growth/decrease in the next year
- Performance needs and expectations
The intake meeting should include a thorough discussion about how system-level support operates. Many providers are fully lights-out and automated, with the ability to know of system issues before their customer does and may not offer the ability to report issues 24×7 as a result. They might also not offer general user support without a special contract. It is up to the customer to determine if this will meet their needs, but also this discussion is critical at the first intake meeting to ensure both the customer and provider understand the agreement.
All of the support requirements gathered during intake should be captured and documented along with the feature/functionality requirements of the system and/or service.
From Requirements to Design
Once requirements are gathered during intake and documented as business requirements, they can be easily incorporated into the service’s design and architecture.
- Requirements related to availability, performance and reliability are incorporated into the technical design for the product
- Support requirements can be incorporated into a service level package that can be offered as part of a standard service level or as an upgraded contract.
In the latter case, this ability to offer an upgraded service level agreement at a higher price may make it possible to gain a commitment from a provider that would normally be off the table, but which the customer needs and for which they are willing to pay, leading to better service for the customer and more revenue for the provider.
How does this change when the provider is internal?
This approach changes only slightly when the provider is internal vs. external. It’s important for internal IT organizations to consider charging for services and support, either via a budgetary exercise or through actual charge-backs or show-backs. Business units need the ability to get the support they need, in accordance with their contribution to revenue and/or the criticality of the service. If they don’t get what they need from IT, they will look for it externally, so leveling the playing field is important.
In a case where a customer is not willing to pay for a higher level of support or more resilient design, the cost can become a factor. In this case, a discussion of requirements that add cost to the final product design may help in lowering costs. There may be some support requirements the customer is willing to give up to reduce cost, whether it’s longer response times, shorter hours or slightly slower performance guarantees. In this case, the discussion is no longer a battle over cost, but rather a discussion on which requirements can be removed in order to lower the cost. This generally results in a more favorable outcome.
At this point, requirements can be re-written to lower the costs, but this creates a better relationship than the one created when the provider lowers costs and finds they don’t have the budget to build the system appropriately or the staffing to support it. In this latter example, lowering costs without changing the design requirement will likely lead to the inability to meet service level agreements and a poor ongoing relationship.
From Design to Final Contract
Once the design and costs of delivering them are complete and agreed upon, bringing the requirements into legal language for the resulting contract is a matter of writing the requirements into a formal service level agreement, along with the associated costs for the contract.
The last aspect of this is ensuring traceability: every requirement captured and agreed included in the final contract must accurately reflect the requirements captured during intake. In this way, the discussion that started during initial service intake/design meetings can be satisfactorily resolved during final contracting.
Success in Relationship-Building
Beginning the discussion of service level requirements during the intake process ensures both the provider and the customer understand the commitment. From the customer’s point of view, they know what they can expect and can communicate clearly with the vendor about these expectations as they use the service. They can clearly see whether the value of the service is able to be realized and the cost of providing the level of support and reliability they need. From the provider’s perspective, they have the ability to design the service and support organization to meet the needs of the customer along with the ability to charge (or budget) accordingly. This joint benefit to both parties leads to a stronger on-going relationship, built on understanding and communication.
Cover Image by Nidhi
