Service executives continuously watch their service revenues. One of the primary means by which service organizations drive service profitability is service contract management. By allowing efficient and effective creation, maintenance, and invoicing of service contracts, strong service contract management practices allow companies to differentiate their service delivery processes and increase customer retention. In a previous article, we discussed how Installed Base Management serves as the foundation for a company's service delivery activities. Service contract management serves as the backbone by which the various customer service and support activities are connected into a single, integrated service life cycle. We will cover the key capabilities of service contract management in SAP CRM 2007. In addition to discussing the core features of service contracts and contract processes, we will give insight into the application of service contract management in real-world scenarios and share tips based on our experience in designing and deploying service contract management.

Effective Service Contract Management

Service contract management processes have evolved into a key component of driving service-related revenue in modern businesses. Service contract management provides a means to define services offered through service-level agreements (SLAs) to avoid competing or confusing offers and inconsistent pricing. In addition, companies take advantage of service contract management because it creates entitlements and reduces revenue leakage while delivering the appropriate level of service. As a result of these two benefits, customer satisfaction rises through accurate entitlement processing and proactive delivery of planned services. This higher customer satisfaction, along with the potential to automate the renewal process, generates increased contract and warranty renewal rates. Through integration with SAP ERP Central Component (SAP ECC), service contract management also helps companies manage revenue recognition processing by providing a structure in which to track complex invoicing and billing cycles. With this suite of advanced contract tracking and management functionality, service organizations are better able to understand service profitability by service offer, product, geography, customer, and market segmentation. They can use this information to fine-tune their service delivery processes and differentiate themselves in the service marketplace.

Integration with the Service Life Cycle

Before we look at the ways in which service contracts manifest themselves in real-world applications, it is important to understand how service contract management is integrated with the service delivery process.

Service Level Agreements

The fundamental core of a Service Contract is the SLA, which is how a company defines the scope, coverage, and response time for performing the services guaranteed to a customer in the service contract. These parameters are represented in SAP CRM 2007 as service and response profiles. As service organizations look for differentiators in their industry, meeting or exceeding the parameters specified in an SLA becomes a key indicator of delivering quality service. Many service organizations offer improved response time to valued customers or those needing extended coverage beyond normal work hours. Companies must carefully consider the types of service profiles and response times appropriate for their service organizations to maximize the value of the service for the customer. When a company achieves SLAs that demonstrate this value, the SLA becomes one of these sought-after market differentiators, aiding in customer retention and subsequently bringing in supplemental revenue through service processes. In planning for the use of SLAs, it is our experience that companies generally treat service profiles and response profiles as two parts of the same service-time guarantee. The service profile refers to the time in which the services agreed upon in the contract are carried out (e.g., the weekdays and hours of coverage provided), while the response profile refers to the time that an engineer or technician takes to respond to a service request. Consider, for example, a company that has two service profiles, bronze and platinum, and two response profiles, also called bronze and platinum. SAP CRM allows companies to mix and match these service and response profiles, but it is a leading practice to consider these as pairs: the bronze service and response profiles represent one service-time guarantee, and the platinum service and response profiles represent a second service-time guarantee. For the sake of furthering our example, let's say the bronze service profile represents service coverage for nine hours per day, five days per week, and the bronze response profile represents a one-day response time. A customer who enters into a service contract with this pair of bronze-level profiles can expect to receive any required service during normal business hours and within one day of placing a service order. The systematic representation of a service and response profile pair is maintained via assignment to a service product master data record. After this assignment is maintained and the service product is subsequently assigned to a service contract as a service contract line item, the system defaults the service and response profiles on the contract with the service and response profiles on the product. When the contract is associated with a line item in a service order, this triggers the default SLA calculation for the request for service. (If necessary, the representative creating the service order can override the defaulted SLA times as dictated by the company's specific business processes.) Figure 1 shows the bronze-level service and response profile assignments for a corresponding service product in the Products view of the CRM WebClient UI.   Fewer SLA combinations in the service contracts create a more finite number of service products to reflect these SLAs and thus a more simplified contract pricing model. Conversely, more complex SLAs (including those that use other functionality to determine SLAs, such as custom development to determine response and service values from the line item variant configurator) result in a more complex contract pricing model. When designing your SLA offering, strive to find a balance that allows for appropriate SLA complexity and effective contract pricing for your company.

Service Entitlement Processing

Now let's focus on how the contract is used in the service delivery process. You apply service contracts through entitlement, which determines the service covered by contract SLAs. It also specifies whether the customer should receive total or partial coverage. Note that although the process of entitlement determines which line items in a service order are billable or non-billable, SAP CRM does not process any Financial Accounting and Controlling data. For more information on this type of data refer to the “Integration with SAP ECC” sidebar. A good way to understand entitlement is to walk through an example scenario of a service order created against a high-tech manufacturer's equipment at a customer site. When you create the service order, SAP CRM uses the SLAs established in the contract (along with the combination of contract customer, sales organization, product, validity dates, and installed base record) to search for and identify an applicable contract. Once it finds the contract, the system references it on the appropriate line items in the service order. In turn, the service order line items release a value and quantity from the referenced service contract line. When a valid contract is identified, SAP CRM looks for a copy control between the service order line item category and the service contract line item category. You use this copy control to restrict the types of service order lines that the service contract lines can cover. You define it by specifying the combination of the contract line item categories and their valid target service order line item categories in the IMG under Define Copy Control for Item Categories (Figure 2).   For example, if a service contract line is meant only to entitle line items on service orders, such as the labor line item in our scenario, the copy control would only be set up between the specific contract line item category and the service labor item category. You can also configure SAP CRM to select and assign a matching contract line automatically if only a single contract line is determined, or to display multiple matching contract lines (if multiple lines are available) as a pop-up screen, allowing the user to assign a contract line manually to the service line. Beyond the standard selection and filtering criteria for contract determination, SAP CRM has a Business Add-In (BAdI) called CRM_ SERVICE_CONTRACTS that you can use to extend or limit the contract determination criteria. Companies often use this BAdI when they have unique requirements. For example, a service organization in the semiconductor capital equipment industry frequently has many active contracts for the same customer. Each contract is specific to a particular customer site, often with different service products. In cases like this, you can use the BAdI to include objects such as an additional site business partner in the contract determination selection criteria. In high-tech manufacturing organizations, when a technician logs the service provided in a confirmation and adds new lines, you can configure a copy control between the contract line item categories and the corresponding confirmation line item category. This allows the contract line to entitle the confirmation line. We have found this to be particularly useful (and, in some cases, a hard requirement) when supplementary service items, such as additional parts for the equipment in question, are required at the time of service and were not anticipated at the time the case was created. Finally, as with any implementation of SAP CRM, many companies have a requirement to take the standard entitlement process one step further by bringing pre-existing, complex, manual entitlement procedures into the system. The following are a few of the more common exceptions to the standard rule that we have encountered during our service contract management implementations:

• • Customers often require that a service order line or a confirmation line that is entitled by a contract line be non-billable. At the same time, service order lines in the same service order that are not entitled by a contract line are billable. You can use price agreements, which are based on condition records, to give customers specific prices on service orders and confirmations when a contract is applied to the line item. Based on negotiated prices, you can create a price agreement on a contract and apply it to follow-up transactions, thereby providing customers with their negotiated price. However, depending on the complexity of the rules for whether or not the line item should be billable, you may need custom development to determine the correct item category.

 

• • Many customers require contracts to cover expenses. However, when contracts do not cover expenses, the technician might include expense lines on his confirmations. These lines are not assigned to any contract line and always determine a billing-relevant item category. In this case, you can use price agreements to apply a flat rate for expenses (e.g., mileage, lodging, etc.) incurred while performing a service.

 

• We have found that entitlement and billing-relevancy determination can become more cumbersome for customers whose service sphere includes complex rules for SLAs (e.g., in which SLAs are driven out of 50 characteristics from custom development that replaces service and response profiles with values specified on service products via variant configuration, such as shifts, time zones, regular overtime on weekdays, or seasonal overtime). Similar to the first example, the complexity of such scenarios requires custom development to determine entitlement correctly in these situations.

Practical Application

The areas we have discussed to this point have revolved around the fundamental processes that comprise service contract management, but how do these concepts manifest themselves in the industry? In the following topics, we share the theory behind some of the more common service contract management scenarios we have encountered. Although each of the contract scenarios that we discuss is based on the same systemic contract functionality in SAP CRM, there are many ways to configure the system to meet diverse service contract needs.

Warranty Contracts

For many companies, especially those engaging in project-based purchases of installed machinery, warranty contracts are provided to their customers for an initial period of time to cover the services on an installed base or equipment after it is shipped to the customer and installed on site. When you create the warranty contract, the validity start date usually depends on the nature of the industry. For example, in the capital equipment industry, warranty contracts start the day after the equipment installation. This installation may be complex or highly specialized, requiring a field service engineer. Service before the warranty contract period is covered by an installation service order. For smaller equipment, however, the warranty contract starts anywhere from the day after shipment to 30 days after shipment depending on a number of factors, such as shipment terms and the customer's installation schedule. In all these start-date scenarios, the warranty contract starts based on the date profile assigned to the contract. Additionally, the date profile also drives the date rules, durations, and date types. Typically, the date profile is such that the warranty contract start date is configured to meet one of the following requirements:

• Day after the expiration of the install case
• Day after delivery
• Day of delivery + “n” days

The important thing to consider is whether the contract design should trigger the warranty contract automatically or manually. In the case of automatic warranty contract generation, the replication of an installed base object from SAP ECC generally triggers the warranty contract process. (Refer to part 1 for more information on this.)

POS Contract

Another scenario that we commonly encounter is the POS contract, also known as an extended warranty contract. These are contracts created at the point of sales order delivery to provide services covering an extended warranty on the product or equipment sold. If a warranty contract exists for the service, then the POS contract starts immediately after the warranty contract expires. The terms of agreement of the POS contract are negotiated with the customer, and the pricing and services are based on the variant configuration that defines the SLAs. This type of scenario is seen in a business-to-consumer (B2C) situation. For example, POS contracts are often presented to consumers when they purchase big-ticket electronics items at retail stores. The POS contract lines cover services on the specified object (e.g., a flat-screen television) or equipment assigned in the sales order line. These items often come with manufacturer warranties as well. It is a leading practice in this case to set up date profiles so that the start date equals the end date of the warranty contract plus one day. Typically, the customer chooses the end date, which is generally one to two years. One of the design considerations is that the contract is paid up front for a stipulated period of time. If the contract is valid for 24 months and the customer pays $24,000 up front, in this case, $1,000 should be realized as revenue per month. However, customers are usually billed once for the entire amount.

Preventive Maintenance Contracts

One of the manifestations of service contracts that we encounter often is the preventive maintenance contract. Preventive maintenance is a service that performs scheduled maintenance for a product with a predefined set of tasks that execute on a service event date. You can initiate preventive maintenance service orders from the service contract. Figure 3 provides an overview of the components used in preventative maintenance.   In the preventive maintenance scenario, you create a service order template with a list of services and tasks to be performed on a planned service event date. After you create the template, you associate a service plan interval with a schedule interval by using the appropriate service order template. The schedule interval on the service plan determines the frequency of preventive maintenance service order creation and its service events. You create a service product, used in conjunction with a service plan item, when you associate the service plan to a product in the product master. The system then creates a service contract with one of these products as a line item. The system calculates the next planned service date based on the service plan interval. Finally, the system assigns an action profile to the service contract, which triggers a preventive maintenance service order on the next planned service event date as described in the service plan. Scheduling in the Post Processing Framework serves as the mechanism through which the above actions are executed.

Blanket Purchase Order Contracts

The fourth and final service contract scenario is less common, but it is a good representation of the diverse ways in which you can extend a service contract into other service-related SAP CRM functions. This contract scenario is the blanket purchase order contract (blanket PO contract). Companies use blanket PO contracts to avoid issuing numerous purchase orders for an item or service to a vendor when the vendor tends to purchase the items or services regularly. The company negotiates the blanket PO contract with the vendor regarding quantities and prices, sets the maximum dollar or quantity limits, and places orders. The vendor invoices every order with reference to the blanket PO contract, which is either value or quantity based. One example of a value-based blanket PO contract is when a service provider orders spare parts regularly from a vendor. The customer company negotiates a blanket PO contract for $60,000, for example, which covers a period of one year. The company also negotiates fixed purchase prices with the vendor. The appropriate contract item categories in this situation are configured as not relevant for billing. Released service orders are created by service representatives for each spare parts purchase and are billed individually with reference to the blanket PO contract. The order value is released from the contract and tracked via the Release Orders tab on the contract line. Similarly, an example of a quantity-based blanket PO contract is one that you create for a specific number of hours of telephone support (e.g., 40 support hours) for which a technician may provide entitled coverage. Both contract scenarios can be configured to allow or reject ordering from the blanket PO contract after the customer exceeds the contract value. To verify that revenue is posted in the correct time period, it is a leading practice to recognize the revenue from the invoice that results from the order placed against the blanket PO contract.

Service Contract Renewal

Because service life cycle-oriented business has become an increasing focus of many companies, service contracts have grown into a significant source of revenue. In addition to selling products and accompanying service contracts to new customers, it is equally important that existing customers continue to renew their current service contracts. It is a good practice to alert the contract administrator within a predetermined amount of time prior to expiration to start the renewal process. You can configure an action profile with action types to send an email alert to the contract agent, notifying them to create a follow-up contract quotation. You can schedule the alert so that it triggers automatically when the specified conditions are met. This renewal quotation generally undergoes a series of customer negotiations and iterations before it can be finalized, updated, or rejected. A finalized quotation is approved as a valid customer agreement or a contract. You can design a copy control between the quote and contract to create a contract as a follow-up of the quote.