The Problem I Actually Faced on the Project
In one of my recent SAP FSM projects, I noticed something that really stayed with me.
When I visited my client’s office, I saw a Service Manager going through multiple service calls. He was opening each call, checking checklists, reading reports, and trying to understand what the technician had done.
Out of curiosity, I asked him about it.
He told me this is part of his daily routine every day he goes through all these service calls to decide what needs to be done next.
At that moment, I realized how much effort it actually takes from the business side.
He opened around 30–40 service calls, and for each one, he had to:Open the activityGo through checklists or attachmentsRead long technician notesFigure out what actually happened
After some time, he said:
“All the data is there… but it’s too much to read.”
That really hit me.
Because at that point, I felt like at least I should be able to do something to make this easier for them.
That’s where this whole idea started.
Why I Went “Off-Road” with an External LLM
I know what you’re thinking: “Doesn’t SAP have native GenAI for this?” Yes, they do. And it’s great for standard scenarios.
However, many of the clients I work with have specific security requirements or already pay for an Azure OpenAI or AWS Bedrock instance. They want flexibility. They want to tune the “personality” of the summary to match their specific industry whether it’s Heavy Construction Equipments or medical devices. So, I built a side-by-side extension to prove we could get custom results directly in the FSM UI.
Look at a typical note a technician might enter into their tablet/mobile while standing at a hot customer site , often in a hurry and focused on getting the job done.
RAW TECHNICIAN NOTE — INSPECTION CARRIED: “Visited the site and reported motor overheating on 2nd floor pump room. Checked motor temp reading 94°C (max limit 75°C). Inspected cooling fan, blades partly blocked with debris and dust buildup. Cleaned fan blades as temporary fix. Checked ambient temp in room, high with no ventilation. Informed site supervisor about ventilation issue. Motor running temp dropped to 82°C after cleaning, still above normal. Added temporary warning tag on motor. Full motor replacement or rewinding required. Customer sign received, site engineer notified.”
This is great info, but it’s hard to scan. I wanted to turn that mess into a structured Work Performed / Issue / Next Step view without asking the technician to change how they type.
A note on data scope:
While working on this, I also explored whether additional checklist inputs or structured fields could help improve the output further.
That approach is definitely possible.
But for this solution, I intentionally kept it simple.
How I Wired It Together (The Technical Setup)
While building this, I tried to keep the setup as simple and stable as possible. I didn’t want something too complex that might break with future updates in SAP Field Service Management.
So I focused on using standard capabilities and just extending them where needed. Here’s how the flow actually works.
How the Flow Works
1. Technician Input :
Everything starts with the technician.
After completing the tasks, the technician fills out the checklist in the FSM mobile app and enters details in the “Inspection Carried” field (or any similar field being used).
There’s no strict format here , technicians write freely based on what they observe and do on-site. I didn’t want to change this behavior.
2. Trigger (Business Rule Execution) :
Once the checklist is completed, a business rule is triggered automatically.
This was important for me — the whole process had to run in the background without adding any extra steps for the technician.
3. Sending Data to LLM & Processing the Response :
This is where the main processing happens.
Using a webhook action in FSM, I send the technician’s notes to an external LLM through an HTTP POST request.
4. The Logic :
The key part here is the prompt.
Instead of just asking the LLM to “summarize,” I guided it to behave like a technical reviewer — someone who understands service reports and formats them properly.
Here’s the exact structure I used:
{
“model”: “your-model-name”,
“messages”: [
{
“role”: “user”,
“content”: “You are a professional field service report assistant. Read the technician notes and return a structured summary in exactly this format:nnWork Performed: [what was done]nIssue Identified: [what problem was found]nRecommended Next Action: [follow-up needed, or write Not required]nnRules:n- Preserve all technical terms exactlyn- Fix grammar and clarityn- Do not add information not in the original notesn- If a section has no information, write ‘Not mentioned’nnTechnician Notes:n{{InspectionCarried}}”
}
]
}
5. Storing the Summary Back in FSM :
The generated summary is then written back into SAP FSM , typically in a UDF on the service call.
This ensures:
Original data remains unchangedAI output is stored separatelyEasy access for users
6. Service Manager View :
From a user perspective, this is where the real value shows up.
When the service manager opens the service call:
No need to open checklistsNo need to go through long notesNo need to download reports
They can directly see a clean, structured summary on the same screen.
Before & After: The Transformation
Issue Identified: Motor overheating caused by obstructed fan blades and inadequate ventilation, resulting in temperatures (94 °C initially, 82 °C after cleaning) that exceed the normal operating limit.
Recommended Next Action: Replace or rewind the motor (full motor replacement or rewinding required).
What I Learned
The biggest win here isn’t the “AI hype” – it’s the consistency.
Whether you have a technician who writes ten pages or one who writes three words, the Service Manager now sees a standardized report. We aren’t replacing the technician’s input; we are just making it readable for the people making the big decisions.
In FSM, we often focus on “how to capture data.” I think it’s time we start focusing more on “how to consume it.”
The Problem I Actually Faced on the ProjectIn one of my recent SAP FSM projects, I noticed something that really stayed with me.When I visited my client’s office, I saw a Service Manager going through multiple service calls. He was opening each call, checking checklists, reading reports, and trying to understand what the technician had done.Out of curiosity, I asked him about it.He told me this is part of his daily routine every day he goes through all these service calls to decide what needs to be done next.At that moment, I realized how much effort it actually takes from the business side.He opened around 30–40 service calls, and for each one, he had to:Open the activityGo through checklists or attachmentsRead long technician notesFigure out what actually happenedAfter some time, he said:“All the data is there… but it’s too much to read.”That really hit me.Because at that point, I felt like at least I should be able to do something to make this easier for them.That’s where this whole idea started.Why I Went “Off-Road” with an External LLMI know what you’re thinking: “Doesn’t SAP have native GenAI for this?” Yes, they do. And it’s great for standard scenarios.However, many of the clients I work with have specific security requirements or already pay for an Azure OpenAI or AWS Bedrock instance. They want flexibility. They want to tune the “personality” of the summary to match their specific industry whether it’s Heavy Construction Equipments or medical devices. So, I built a side-by-side extension to prove we could get custom results directly in the FSM UI.Look at a typical note a technician might enter into their tablet/mobile while standing at a hot customer site , often in a hurry and focused on getting the job done.RAW TECHNICIAN NOTE — INSPECTION CARRIED: “Visited the site and reported motor overheating on 2nd floor pump room. Checked motor temp reading 94°C (max limit 75°C). Inspected cooling fan, blades partly blocked with debris and dust buildup. Cleaned fan blades as temporary fix. Checked ambient temp in room, high with no ventilation. Informed site supervisor about ventilation issue. Motor running temp dropped to 82°C after cleaning, still above normal. Added temporary warning tag on motor. Full motor replacement or rewinding required. Customer sign received, site engineer notified.”This is great info, but it’s hard to scan. I wanted to turn that mess into a structured Work Performed / Issue / Next Step view without asking the technician to change how they type.A note on data scope: While working on this, I also explored whether additional checklist inputs or structured fields could help improve the output further.That approach is definitely possible.But for this solution, I intentionally kept it simple.How I Wired It Together (The Technical Setup)While building this, I tried to keep the setup as simple and stable as possible. I didn’t want something too complex that might break with future updates in SAP Field Service Management.So I focused on using standard capabilities and just extending them where needed. Here’s how the flow actually works.How the Flow Works1. Technician Input : Everything starts with the technician.After completing the tasks, the technician fills out the checklist in the FSM mobile app and enters details in the “Inspection Carried” field (or any similar field being used).There’s no strict format here , technicians write freely based on what they observe and do on-site. I didn’t want to change this behavior.2. Trigger (Business Rule Execution) : Once the checklist is completed, a business rule is triggered automatically.This was important for me — the whole process had to run in the background without adding any extra steps for the technician.3. Sending Data to LLM & Processing the Response : This is where the main processing happens.Using a webhook action in FSM, I send the technician’s notes to an external LLM through an HTTP POST request.4. The Logic : The key part here is the prompt.Instead of just asking the LLM to “summarize,” I guided it to behave like a technical reviewer — someone who understands service reports and formats them properly.Here’s the exact structure I used:{“model”: “your-model-name”,”messages”: [{“role”: “user”,”content”: “You are a professional field service report assistant. Read the technician notes and return a structured summary in exactly this format:nnWork Performed: [what was done]nIssue Identified: [what problem was found]nRecommended Next Action: [follow-up needed, or write Not required]nnRules:n- Preserve all technical terms exactlyn- Fix grammar and clarityn- Do not add information not in the original notesn- If a section has no information, write ‘Not mentioned’nnTechnician Notes:n{{InspectionCarried}}”}]}5. Storing the Summary Back in FSM : The generated summary is then written back into SAP FSM , typically in a UDF on the service call.This ensures:Original data remains unchangedAI output is stored separatelyEasy access for users6. Service Manager View :From a user perspective, this is where the real value shows up.When the service manager opens the service call:No need to open checklistsNo need to go through long notesNo need to download reportsThey can directly see a clean, structured summary on the same screen.Before & After: The TransformationBefore: Unstructured NoteAfter: AI-Generated Summary”Visited the site and reported motor overheating on 2nd floor pump room. Checked motor temp reading 94°C (max limit 75°C). Inspected cooling fan, blades partly blocked with debris and dust buildup. Cleaned fan blades as temporary fix. Checked ambient temp in room, high with no ventilation. Informed site supervisor about ventilation issue. Motor running temp dropped to 82°C after cleaning, still above normal. Added temporary warning tag on motor. Full motor replacement or rewinding required. Customer sign received, site engineer notified.”Work Performed: Visited the site and investigated the reported motor overheating in the 2nd‑floor pump room. Measured motor temperature at 94 °C (maximum limit 75 °C). Inspected the cooling fan and found the blades partially blocked with debris and dust; cleaned the fan blades as a temporary fix. Checked the ambient temperature in the room, noted it was high with no ventilation, and informed the site supervisor of the ventilation issue. After cleaning, the motor’s running temperature dropped to 82 °C. Applied a temporary warning tag to the motor.Issue Identified: Motor overheating caused by obstructed fan blades and inadequate ventilation, resulting in temperatures (94 °C initially, 82 °C after cleaning) that exceed the normal operating limit.Recommended Next Action: Replace or rewind the motor (full motor replacement or rewinding required). What I LearnedThe biggest win here isn’t the “AI hype” – it’s the consistency.Whether you have a technician who writes ten pages or one who writes three words, the Service Manager now sees a standardized report. We aren’t replacing the technician’s input; we are just making it readable for the people making the big decisions.In FSM, we often focus on “how to capture data.” I think it’s time we start focusing more on “how to consume it.” Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
