Service organizations continuously watch their service revenue by reducing service costs and providing efficient services to their customers. To meet this goal, service executives need a closed-loop service delivery process that starts with logging a service event, identifying services to perform, tracking time and parts consumed, keeping an up-to-date installed base, and accurate service billing. Service organizations that effectively manage service order and confirmation processes have seen decreased service costs, increased service revenue and margins, improved customer satisfaction, and improved customer retention rates. The first step in any service order management life cycle is the creation of the service order. I begin by reviewing some communication channels and processes that you can use to initiate service order creation. Refer to “Configuring a Communication Channel” in SAP Help for supported communication channels and supported vendors. You can initiate an SAP CRM service order using a variety of sources, but I focus on reviewing those channels that I find clients use most frequently, including direct phone calls, incoming email, installation service orders based on CRM sales orders, preventive maintenance service orders from planned services via CRM service contracts, and field change orders using product service letters. I’ll review these processes briefly to provide an overview on how you can create a service order. I’ll show you how to log a service event through various channels and how to plan, instruct, and track services that field technicians perform using different service delivery models. I’ll also discuss how to capture actual time spent and parts used while performing a service and go over service billing with SAP CRM billing. The processes in this article apply to SAP CRM 2005 and later.

Phone Channel

Typically, contact center agents in your service organization receive incoming phone calls via computer telephony integration (CTI). Figure 1 illustrates the high-level flow of an incoming phone call. The contact center agent, using the SAP CRM Interaction Center WebClient (IC WebClient), accepts the incoming call. The agent identifies and confirms the caller using account identification, either by account details or product details (i.e., installed base), and creates the service order by populating the appropriate information.  

Email Channel

Similar to incoming phone calls, incoming email messages are routed to an available contact center agent, and the agent can view the email body content to initiate the service order. You can also use the E-mail Response Management System (ERMS) to route the incoming email to the available agent. Figure 2 illustrates the high-level flow of incoming email. Based on the incoming email address, the system populates the IC WebClient Account Identification screen with the account information. The agent can validate and confirm the account information, identify and confirm the product involved for reference on service order, and log the problem using a service order.  

Install Services Orders Using CRM Sales Orders

Some companies provide installation services to their customers as part of the sales order or an additional service for those products for which the customer cannot perform self-installation. You can create install service orders in SAP CRM based on the CRM sales order using actions. You can use these service orders to track and manage installation-related activities in SAP CRM after the sales order is delivered to the customer. For example, say you use SAP ERP Central Component (SAP ECC) for your sales process and SAP CRM for service management. In this scenario, you can set up the install service order creation in SAP CRM with the following steps: Step 1. The sales representative creates the sales order in SAP ECC and releases it for production. The sales order is then automatically replicated to SAP CRM via CRM Middleware. Step 2. After the CRM sales order is created, you can set up an action to create an install service order. A standard Post Processing Framework (PPF) method call (CRM_SUR_PROCESSES) is available to create the service order, but you need to enhance it to reference the product on the install service order, the service order template to create line items in the install service order, and other client-specific attributes from the sales order. Figure 3 provides a conceptual flow of install service order creation using SAP ECC and SAP CRM.  

Preventive Maintenance Orders Using Service Contracts/Planned Services

You can create a preventive maintenance (PM) service order for service events planned for a future date. You can then use the PM service order to perform scheduled maintenance for a product with a predefined set of tasks that you want executed on the service event date. SAP CRM Planned Services functionality manages all PM services and uses service orders to track the PM orders. You can initiate a PM service order from a service contract or the installed base using service plan items. This section covers PM service order creation from the service contract. For service contract-based PM orders, the following setup is required: Step 1. A contract administrator sets up a service order template with a list of services and tasks to be performed on a planned service event date. Step 2. The contract administrator sets up the service plan interval with the schedule interval and the associated service order number from the service order template transaction type. The contract administrator informs the master data management (MDM) group to set up the service plan product. Step 3. The MDM group creates the service plan product by associating the service plan interval in the product master. Step 4. An agent sets up the service contract with PM service offerings and the next planned service date is calculated in SAP CRM based on the service plan interval. This step occurs when the action in step 5 is triggered and sets the next planned service date. Step 5. The contract administrator assigns an action profile to the service contract transaction type using IMG configuration to trigger a PM service order on the next planned service event date. You can access the action profile definition and assignment to transaction type using transaction SPRO and following IMG menu path Customer Relationship Management > Basic Functions > Actions > Actions in Transaction. Step 6. On the next planned service event date, the PPF process executes the preassigned action in the service contract, creating a PM service order with line items based on the service order template assigned in the service interval of the service plan product in the service contract. The service order template contains the tasks and services to perform, including the required spare parts. Refer to the “Service Order Structures” section for structure considerations.

Field Change Orders Using Product Service Letters

You can use SAP CRM product service letter (PSL) functionality to initiate a field change order (FCO). An FCO is a service request for a field technician to visit the customer site and perform a certain range of services to fix a product because of a known defect or upgrade a product to prevent future failures. A PSL is the official document from the manufacturer that documents a service request for a certain range of products and the conditions of the services to be performed for a list of service parts. PSLs are usually issued to either identify a potential or actual technical failure or to avoid costly product corrections. For example, a product manufacturer can request its global service department to perform a mass replacement of a spare part in its customer installed base to prevent a certain defect that the manufacturing group identified. The customer cannot perform this product replacement due to the nature of the installed product, so a field technician from the manufacturer needs to carry out the replacement. To accomplish this, you need to notify the customer about the potential product replacement and schedule a time for the product to be taken out of production to perform required tasks. Figure 4 provides a conceptual flow of FCO creation using PSL functionality in SAP CRM.   The following is the process for PSL and FCO service order creation: Step 1. The service manager creates a PSL transaction for the affected product based on instructions from the manufacturer. Step 2. In the PSL, the service manager creates a FCO service order template with a list of product-specific services and tasks to be performed for FCO service orders. Step 3. The service manager executes a preassigned action called PSL_CREATE_SO_ITEM with the PSL to create an FCO service order immediately for each affected product. The action creates the FCO service order with items in the template that was assigned in PSL. Step 4. The service manager triggers FCO creation and standard SAP functionality creates a document flow between PSL and FCO transactions.

Service Order Structures

Now that I’ve explained the ways in which service orders are created, I will discuss the structure of service order items for various service delivery models. I provide a brief overview on how some service industry companies are adopting the standard SAP service order item hierarchy model to meet their business needs without missing the intended functionality of SAP CRM. Companies are trying to reduce service costs by achieving remote resolutions as much as possible using various knowledge-based tools, such as discussion forums. If the customer can’t solve the problem remotely, agents dispatch field technicians onsite with clearly defined solution steps to resolve the customer’s reported problem while avoiding any back-and-forth interaction with remote technical support at their service organization. This approach is called “diagnose before dispatch.” It forces service organizations to adopt clearly defined processes and tools and make them available to agents or technical support teams to make better remote diagnoses. This approach also demands that agents track all activities in the service order so that the technical support team can provide solution steps to help field technicians resolve the reported problem. To meet their business needs, companies use various service order structures while avoiding overcomplicating the management or increasing the burden on field technicians to report actual working hours against each planned activity in the service order. You use the service order item hierarchy to achieve this. You can control it by defining which items are the high-level items in the service order and which are defined as subitems. Based on the type of service, items are flagged as planning relevant so that the scheduler gets the appropriate number of service order items to use when scheduling a field technician using the Resource Planning Application (RPA). The field technician subsequently receives email notifications when an assignment is created via Groupware integration. When designing the service order item hierarchy for your organization, you need to take the nine questions in Figure 5 into consideration. While these can vary from business to business, these items represent the core considerations during the hierarchy.   You can structure service order items in various ways. I discuss two service models that some of my clients have used:

• Delivery-based for corrective maintenance, PM, and FCO
• Milestone-based for install, project-based, and professional services

Delivery-Based Service Order Structure

You use the delivery-based service order item structure for services billed to customers based on actual working times reported using service confirmations rather than planned activities in the service order. There is no billing carried out directly from the service order using this model. You perform service contract entitlement on service confirmation items to identify out-of-entitlement services and to change the item category of those items to reflect billable status. Standard contract determination on confirmations looks at contract coverage hours and references the contract if it is valid. Figure 6 shows the conceptual structure of a service order structure for delivery-based services.   However, you may encounter situations in which a contract exists, but the provided services are out of entitled hours and should be billed. This functionality does not exist in standard contract determination. Refer to the “Service Confirmation for Time and Spare Parts Use” section for more information about service contract entitlements after service is provided. The delivery-based service order structure contains:

• Any services, such as activities, solutions (high-level names), or tasks to be performed
• Any spare parts required for executing the service. Parts are associated with the service as a subitem to schedule a resource based on parts availability. The field engineer is the sold-to party and the ship-to party in the parts order. You can set up the system to prevent adding parts to service orders without services as a high-level item using item category determination configuration.

Milestone-Based Service Order Structure

The milestone-based service structure in Figure 7 looks similar to the delivery-based service structure, but item categories are only billable if they are not covered by a service contract or pre-paid sales order (e.g., install services). This service order structure allows you to group all the tasks to be performed on a milestone-based delivery and track information such as the order status, who is assigned, and project start/end dates.   You can create service order item hierarchies with simple item category determination configuration. Figure 8 shows a sample of the item category determination configuration, which you can access using transaction SPRO and following IMG menu path Customer Relationship Management > Transactions > Basic Settings > Define Item Category Determination. Note the designation of ZSGP (high-level service product item in the service order structure) as the main item category for item category ZRSP (subitem service product in service order structure). This configuration step is required to build the service order structure as shown in Figures 6 and 7 using item category determination definitions for main item and subitem.  

Service Confirmations for Time and Spare Parts Usage

After you create a service order and complete the required service the next step is to create a service confirmation documenting the work. I will review service confirmations and how some of our clients are using them. Also, I will briefly discuss the service industry needs regarding re-entitlement of services provided to eliminate any revenue loss and improve service efficiency. In SAP CRM, field technicians and contact center agents use service confirmations to report actual working times, service parts use, expenses, and tools used when performing services. Service parts disposition codes (e.g., part used or part unused) track the service parts status via codes and code groups in subject profiles. Service orders allow you to create multiple service confirmations against a single service order. I have found that companies often enhance the copy control between service orders and service confirmations so that field technicians who are not dispatched to work on the service order cannot copy line items from the service order into the service confirmation. In addition, companies prevent their field technicians from picking a service order at will and creating a service confirmation without referencing an existing planned activity in the confirmation. You can enhance the service confirmation ORDER_SAVE Business Add-In (BAdI) to enforce these rules. Copy control can limit what items you can select, but the user can enter unplanned items in service confirmation even though they are not dispatched to work on that service order. This ORDER_SAVE enhancement prevents users from cherry-picking the service orders to report their actual working times in service confirmation. For example, if you are not a dispatched field technician on a service order, you cannot create a service confirmation for that service order. This forces field technicians to choose the appropriate assigned service order to report actual working hours using a service confirmation. This enhancement emphasizes the need for companies to have proper document flows. It also helps you verify that any services provided out of service contract hours can be billed to the customer. The enhancement further allows customers to perform product-level service profitability analysis and service contract profitability analysis. Spare parts use is also tracked using the service confirmation items and disposition codes. You can use an enhanced program via actions to update the installed base structure to keep track of configurations. Service confirmation items (i.e., time, parts, expenses, and tools) are tracked in service confirmations with reference to service. Unplanned items are added to the service confirmation. After the field technician creates the service confirmation, companies check the service confirmation items to ensure there is no revenue loss for the service provided that were out of service contract hours. Service confirmation items that are not covered or only partially covered by the service contract require a billable flag or are split into multiple billable/non-billable line items using separate item categories as needed. Standard contract determination can assign the contract to the service confirmation item but it does not split items if the service hours are out-of-coverage hours, nor does it flip the item category if it is covered by contract. Companies do not want their field technicians to make the decision of splitting the confirmation items manually. They instead enhance the service confirmation ORDER_SAVE BAdI to incorporate custom rules to identify the out-of-entitlement services, overtime work, parts that are not used to resolve the customer problem, or parts that are damaged on arrival. After the field technician completes the service confirmation creation, re-entitlement (through the service confirmation ORDER_SAVE BAdI enhancement) is performed for every line item. First, the service confirmation service items are split for the purpose of service costing. For example, this is used when the field technician worked hours that do not match actual hours reported in the service confirmation. Those reported hours are considered non-regular work hours, and your service cost for those hours may be higher than regular hours. Regular and non-regular hours are tracked using the Value Type field in the service confirmation. This allows you to track service cost and assign it to the appropriate cost element when you integrate service confirmation to SAP ECC FI-CO (Financials and Controlling). Next, the service confirmation service items are split for service pricing purposes. The service-provided hours are out of entitlement and the customer may be billed at a standard labor price or a higher labor price, depending on the pricing conditions defined for Service Type in the product master and tracked in Service Type in the service confirmation. After all the line items are split, you create each service line item in the confirmation with the following attributes:

• Service type
• Value type
• Accounting indicator
• Start date/time
• End date/time
• Item category (i.e., billable or non-billable)

Using the disposition code, you can change the item category to billable, not billable, or do not update installed base. The item category differs from the original item category of the line before the splits because the original item category is not relevant for controlling, pricing, or billing.

Service Billing in SAP CRM

After all the work has been recorded in the service confirmation, the service order management cycle ends with billing for any portions of the service not covered by a contract or warranty. The SAP CRM billing engine provides integration with the service order and confirmation process with appropriate configuration. You need to perform basic configuration, such as billing types, billing item categories, service item categories, assignment to billing item categories, and also account assignment for revenue tracking in SAP ECC. Typical benefits of billing in SAP CRM include:

• You can generate a single invoice to the customer in scenarios in which you have service order/confirmation and sales order items as part of one service event
• You can use integration with SAP ECC Financials account receivables (AR) and CO for revenue recognition and costing
• You do not need to transfer SAP CRM transactions to SAP ECC as debit memo requests for billing in SAP ECC. You can post the SAP CRM billing document to the appropriate SAP General Ledger (GL) account in SAP ECC using account assignment configuration in SAP CRM.
• You can use SAP CRM service-specific pricing by leveraging attributes only maintained in SAP CRM and not available in SAP ECC, such as pricing based on service-level agreement parameters
• You can bill for partial services and milestones in service orders or confirmations

In the next section, I review a few of the key concepts of SAP CRM billing and how you can carry out service billing for the two service delivery models discussed in the “Service Order Structures” section.

Delivery-Based Service Model

In this model, the billing is based on the service product’s price and is billed in SAP CRM. Billing is performed as a follow-up transaction to the service confirmation. You can copy all billable line items in the service confirmation into the billing documents based on your business requirements. Refer to Figure 9 for a conceptual view of service confirmation items copying to the billing document.  

Milestone-Based Service Model

In this model, the billing is based on the price of the milestone, and billing is done directly from the service order. The milestone line item copies over to the billing document, leaving the subitems behind. The milestone does not copy over until all the milestone tasks have been completed. This model is also called “fixed-rate billing” (i.e., the price you commit to on the service order is used regardless of how much time the field technician spent to resolve the issue). The service confirmation only serves the purpose of costing and has no impact on billing. Refer to Figure 10 for a conceptual view of service order items copying to billing document items.