CRM and CX Blogs by SAP
Stay up-to-date on the latest developments and product news about intelligent customer experience and CRM technologies through blog posts from SAP experts.
Showing results for 
Search instead for 
Did you mean: 

Part I: Introduction

Customer Service and Field Service represent a major part of every business with end customer satisfaction in mind. Both are key parts of a typical Service organization, and are closely interconnected. Despite that, each of the processes has its own scope and specifics, and collaboration between them requires attention before the implementation project and throughout Service operations. Interplay is vital, as the exact role of each component in an overall Service process needs to be well understood in order to increase the Service organization’s efficiency, and consequently increase Customer and Employee Satisfaction.

In this blog we are going to explore the specifics of each scenario and consider the interplay between them, by examining a generic E2E Service process.


Customer Service

SAP Cloud for Customer Ticketing allows an easy way to for tickets to be managed in an interactive and dynamic Customer Service environment, where multiple teams or team members might be required or help, or escalation might be needed. Reassignment, categorization and SLA, and contract determination are crucial to reduce ticket processing time.


CS Typical roles/personas

CS Manager

The CS Manager takes overall responsibility for Customer service, approvals, planning, and reporting for Management.

1st Level Support

The responsibility of 1st Level Support is to respond to received requests and make an immediate effort to resolve the Customers’ issues as quickly as possible.

If no immediate solution can be provided, 1st Level Support will reassign the request to the 2nd Level Support team, which usually consists of specialists for a specific type of a request.

In most cases, 1st Level Support will also maintain communication with users, keeping them informed about their Incidents' status at agreed-upon intervals.

2nd Level Support

2nd Level Support takes over requests that require deeper, topic-specific analysis.

There can be other tiers involved, or teams parallel in the hierarchy, but here we will stick to a typical, two-level support structure.


Field service

Field Service involves any type of support activity that can’t be executed remotely. These activities usually involve installation of machines, fixes, or maintenance. Installation processes can be complex in case of manufacturing business, for example, where new factories mean installing huge machines or pieces of equipment for the first time.

FS Typical roles/personas


A Dispatcher assigns work in the most optimal way, based on the skills required, availability, and so on.

Field Service Technician (FST)

An FST executes the work requested in a service order: fixes, maintenance, or installations. Access to and processing of service orders is done mostly via handheld devices, as FSTs work primarily on the road.

Back-end team

In addition to above, there is also a Back-end team, any team or a department that is not necessarily part of the Service organization. This will include FI, Procurement, Warehousing, and is closely related to and interconnected with the Service team’s operations.


Part II: Interplay – example E2E Process

There can be many Service scenarios, depending on the company’s specific business processes, as well as the specifics of certain industries—but here we will cover a simple, generic E2E scenario as an example, in order to describe personas and roles for each of the components in the landscape (SAP Cloud for Customer vs SAP Field Service Management vs S/4HANA), in an overall Service process.


SAP Cloud for Customer

Customer Service initiation

Customer Support can be triggered via multiple channels: phone integration CTI (supported by Live activity center or the Service Agent desktop add on), standard emails, social media integration, chat, and so on.

For more details on the Agent console, check out following webinar: Enhancing Agent Performance with the Agent Console

Emails sent to an e-mail address defined in the system will trigger automatic ticket creation. There can be multiple email addresses defined in the system, depending on the service organization setup and the product portfolio. This can act as a first step in routing, as tickets can be immediately routed based on the incoming email address. In addition, standard ticket routing functionality offers flexibility when it comes choosing suitable attributes for routing, as well as the sequence in which attributes will be checked. Automatic ticket routing saves time can be based on an org. unit or territory, or can be employee-based. It increases Service organization efficiency and reduces ticket processing time.

Immediately upon ticket creation, a ticket Priority can be automatically set using Workflow rules. Ticket priority can be additional element for routing, as well as an attribute for identifying tickets that need Service agent attention more urgently than others.

In the case of planned/preventive maintenance, a Service Ticket is directly created based on a maintenance plan defined in SAP Cloud for Customer. Maintenance plans (cyclical, one time, etc.) are related to the contract and define contractual maintenance intervals. Maintenance plans can trigger ticket creation, based on different condition attributes: time period, counter value (i.e., how much the machine has been operated), or a combination of the two. Automatic ticket creation increases the efficiency of the service organization, avoiding manual work and making sure that maintenance will be performed as planned, when planned.

Regardless of channel—e-mail, phone, social media message—generated tickets are now ready for further processing by Service agents.


Ticket Processing

Automatic ticket routing should cover most of the use cases, and avoid most manual intervention. However, it is still possible to check the queue (My Ticket, or My Team’s tickets, based on Org. structure assignment) and reassign tickets if needed. This task can be performed by a team lead or Service manager, based on different criteria: special attention customer, priority, severity, etc. However, manual initial assignment of tickets should be a rare case, as it can be time consuming—whereas during ticket processing, reassignment between teammates and teams is a common practice.

Any Contract that may exist for a given customer and/or piece of equipment will be automatically determined, based on different attributes: customer, product, installed base, registered product ID, etc. All of this helps initial evaluation of the ticket, and of the job that needs to be done.

An important parameter of performance for any Service organization (and in some cases, a contractual obligation) are Service Level Agreements (SLAs). SLAs can be defined in the system on a very detailed level, allowing the organization to define operating days/hours, milestones (both custom and standard) and appropriate response times, based on given parameters for each of the defined priorities. Standard SLA determination can be configured based Ticket Type, Service Category, Source, or Channel ID, and it will help all Service employees to transparently plan appropriate steps for meeting defined SLAs.

For more details on SLAs, check out following webinar: Working with Service Level Agreements (SLAs) in Ticket Processing with SAP Service Cloud

In a typical Service organization, L1 support agents will try to resolve requests that can be dealt with immediately, such, information requests, typical issues with a product, etc. To support L1 agents in this, SAP Cloud for Customer offers integration with KB solutions, which are a key component of any customer service organization. All of the solutions provided earlier can be maintained in a Knowledge Base (KB), saving them for later. Reusing previously provided and proven solutions can reduce processing time, and provide uniform solutions for recurring issues, over longer period of time.

After checking all the details of a ticket, and checking KB for potential solutions, an L1 agent can respond to a customer, either via the built in e-mail editor, or using Outlook integration. Going forward, the L1 agent will be a point of contact for that ticket.

If the L1 agent can’t provide a solution, the ticket is forwarded to the L2 support team. L2 teams usually deal with specific issue topics (e.g., shipping, warehousing, payment questions) or products or product ranges (e.g., elevators, doors, forklifts). In some cases, external support will be required from the machine or hardware manufacturers, or from a supplier, for example. In such cases, this team will keep the communication with 3rd party open, and will provide updates to 1st level support.

For more details on how to reduce ticket processing times, check out following webinars: Efficient Ticket Processing with Service Cloud - Webcast, Deliver Service Excellence with the power of AI/ML.


Field Service Initiation

In our scenario, we are working on the assumption that a customer requests a fix for their machine, and that the solution can’t be provided remotely. This is where Field Service comes in. (Other types of jobs that require field service are planned/preventive maintenance, ad-hoc fixes, and installation).

Upon Ticket creation, the Service contract and Entitlements are determined automatically, based on a configuration done with standard SAP Cloud for Customer Service contract determination functionality. An L1 Customer support agent checks the contract, the registered product in question, and its warranty. After confirmation that the product is indeed covered by a warranty, and that the service contract covers the fix, the Customer support agent’s next step is to initiate Field service by releasing the ticket to SAP Field Service Management, using standard SAP Cloud for Customer – SAP Field Service Management integration, which creates an SAP Field Service Management Service order based on the SAP Cloud for Customer ticket


Field Service Management

Scheduling and Dispatching

Once a Service order is created in SAP Field Service Management, it’s a Dispatcher’s job to take the processing further. The Dispatcher first needs to check the affected equipment to see if there are any special skills required for maintaining or fixing it. Based on this information, the dispatcher checks availability of all FST’s that have the required skillset.

SAP Field Service Management allows for technicians to maintain availability hours/days, which combined with their already-allocated jobs, provides the dispatcher to see the availability of all technicians in a calendar view.

Worth mentioning here is the option of crowd service. Crowd service is an SAP Field Service Management feature that allows companies to create an ecosystem of potential external technicians, in order to allow for wider workforce, with experts in specific fields, or in geographical areas not covered and not supported by technicians within the organization.

Some special cases can influence the dispatching process, including locations with limited accessibility (such as oil rigs or other open sea locations, ships, platforms, or plants) and locations with little or no internet connection—often due to areas with sensitive machines (i.e., hospitals) or areas where no electrical equipment is allowed at al (i.e., semi-conductor factories). In these cases, the FST can’t rely on their handheld device for tracking time, materials used, instructions, or task/check lists. Hence, these activities need to be planned and recorded accordingly.

These scenarios might require hiring a 3rd party workforce that specializes in those sorts of challenging environments.

The final step in the process is to identify the type of work to be done, and check if there are any parts that need to be ordered and delivered to the work location prior the FST’s arrival. This can occur, for example, when a part is too big for the FSE/Technician to carry it with themselves. These special cases, will require one additional check to ensure that the equipment in question is covered by the contract/warranty, and whether it needs tools or parts for which a price needs to be agreed upon first. These cases may require triggering of quotation, procurement, or advance shipping processes.

Once all of these considerations about location, equipment, skills, and availability have been taken into account, the Dispatcher assigns the Service order to the most suitable FST. Worth noting is a scenario wherein there can be a primary and secondary FST assigned, in case the equipment requires multiple technicians or a team to fix it.


Field Service execution

Once an FST is assigned, they can accept the job—or reject it, if they are unable to execute it for any reason (wrong assignment, FST is temporarily unavailable, etc.) This is all done via handheld device, through the SAP Field Service Management mobile app.

Before going onsite, final coordination is performed with the customer, to make sure that the arrival time is correct and that access to the site (building, room, machine, etc.) is assured.

Once onsite, the FST executes the needed work. To help FSTs in their activities and to drive standardized work, and to make sure that no steps are missed, the FST refers to a checklist—a standard SAP Field Service Management functionality that lists all the steps required for the given job. Checklists are created based on the Install base in question.

During work execution, there are several potential scenarios where parallel a process is triggered. These include processes that are not essential to the Field Service processes, but can certainly happen, and for which exact steps need to be defined, based on companies’ policies:


  • Quotation can either precede the Order (Customer needs to accept the quote before the work is done) or it can be a parallel process, where FST identifies that additional work, not initially foreseen, needs to be done. This can involve parts that must be purchased, which are not covered by warranty or contract

  • As a next step, a Procurement process is triggered, inventory and availability of parts are checked. Worth mentioning is a scenario where parts aging and shelf life needs to be checked, in case of environment sensitive parts.

  • A Return Material Authorization (RMA) is triggered in the case that a machine part needs to be dealt with offsite, or replaced, or in the case that an unused part needs to be returned to a manufacturer. In this scenario, integration to a 3rd party system is quite often needed. (The RMA item is created, and a follow-up processes then kicks in: shipping label, shipping, warehouse…)

  • Note: these steps are usually not performed directly by the FSE. Processes are only triggered by FST, and then executed in backend on 3rd party systems.


Once the work is done, FST captures details about work done:

  • Work description

  • Working time – regular hours, overtime

  • Travel time – to and from the customer location

  • Parts used

    • Replaced Parts – track both the part that is taken out of the equipment and that was built in

    • Follow-up documents will be issued in this case: billing request and goods movement issued.

    • Spare parts/Consumables (nuts, bolts, wire and any material that is not serialized)

      • In this case, the consumables will be billed, and a billing request will be generated, but there will be no goods movement generated, as consumables are tracked in the storage per-piece

    • Tools – In some cases certain machines need special tools that may or may not be billed to a customer (e.g., special measuring devices)

  • Expenses

    • Planned/unplanned travel costs

    • Accommodation

    • Meals

    • Miscellaneous


The Customer will have to confirm that job is done by signing the summary document that was generated within the app. The Customer will then receive the signed work summary via email.

Captured time and materials will, in any event, be required for the internal approval process, which the FST’s manager will perform in the SAP Field Service Management backend.

After all the formalities are done, the Service Order is completed and released.

Part III: Integration with S/4HANA and Back-end processes

In addition to the processes described above that can be triggered during the Service order processing and FS execution (e.g., Quotation, Parts order and Procurement, RMA) and that may or may not happen, the following process in S/4HANA will most probably be triggered, and in if it is, appropriate data will be sent from SAP Field Service Management to S/4HANA:

  • Time sheets

    • Working and travel hours

  • Goods movement

    • Stocks of parts and consumables that were used/installed must be adjusted

  • Invoice and Billing

    • Billing requests for travel costs, meals, overtime, materials used, additional services provided, etc

  • S/4HANA Service confirmation


The following blog provides more a detailed overview of the SAP Field Service Management – S/4HANA integration, and the data exchanged between them: Service Order Processing with SAP Field Service Management & SAP S/4HANA Cloud – At a Glance.

Part IV: Survey and Reporting

Once the job is done, the SAP Cloud for Customer ticket needs to be updated with the work/travel time and the materials used. Once all settlements are done in S/4HANA, a Service confirmation can be generated there. Its number will be sent to SAP Cloud for Customer to update the ticket, which can then finally be set as completed.

A survey can be triggered from SAP Cloud for Customer using integration with SAP XM—or using built-in SAP Cloud for Customer surveys, for a more basic approach.

For more details on SAP Cloud for Customer Survey capabilities, please check following blog: Familiarizing with Surveys in C4C.

After service is conducted, and survey results are collected, it is a good practice to utilize all of the data collected during the service execution, from Customer service all the way through Field Service. This may include not only survey results, but also the performance of Service organization, in terms of SLA compliance, for example. In case of any problem during the service execution, or poor feedback from a customer, the organization can utilize these data to identify the root cause of the issue. In addition, analytics and survey results can be used proactively, to improve performance of any Service organization.

Find out more about Service Analytics capabilities in the following webinar: Service Analytics for Smart Decision-Making Webcast.


Part V: Summary

In this blog we covered a typical E2E Service scenario. We tried to show the position of SAP Service Cloud in an integrated environment, covering a complete E2E Service, as well as the interplay between SAP Cloud for Customer Service, SAP Field Service Management, and S/4HANA in a scenario where different processes steps are covered in different solutions.

By understanding the E2E process, and understanding the role of each of sub-processes and components of each of the solutions in an integrated scenario, customers can design their processes in such a way as to make the most of their implemented solutions, and increase adoption and Service organization efficiency as well as end customer satisfaction.

Find out more about this topic in an upcoming webinar Webcast Topic “Achieve a seamless interplay between customer service and field service scenarios in Service Cloud” July 2022. (Open for registrations – registration link –).