Yes — that is the point of a portal rather than just a ticketing inbox. A logged-in customer can raise a request against a specific asset, track its live status and SLA, see their service contracts and warranty coverage, view their installed base and service history, approve quotes, book appointments and, where relevant, pay. Because it reads and writes to the same S/4HANA Service records the agents use, the customer sees the real status — not a copy that drifts out of sync. The practical payoff is twofold: customers get 24/7 transparency and stop calling in for routine updates, and the service desk gets a meaningful chunk of low-value volume deflected so agents focus on the work that actually needs them.

When a request is logged against a customer and an asset, S/4HANA Service determines entitlement automatically. It checks whether the asset is under warranty, whether an active service contract covers this type of work, and what SLA applies. That determination drives everything downstream: whether the work is free or billable, what response and resolution times the customer is owed, and what service level the request should be handled at. This matters because the most common source of margin leakage in service is effort spent on work that should have been billed, or warranty claims honoured that were actually out of coverage. Automating the check at intake — rather than relying on an agent to remember to look — is what turns entitlement from a good intention into a control.

When a request needs an on-site visit, it becomes a field service assignment in SAP FSM. The scheduler — assisted by optimisation — matches the job to an engineer based on skills, location, availability and parts, either automatically or with a dispatcher's oversight. The engineer receives the job on a mobile app that works offline, with the customer and asset context, checklists, and the parts they will need. On site they record time, parts consumed, readings and a signature, and when the job is closed that data writes back to the service order — which is what allows it to be billed accurately. The design goal is that nothing about the visit lives only on paper or in the engineer's memory: the schedule, the execution and the billing are one connected flow.

Each request carries the response and resolution targets its entitlement determines, and the system tracks elapsed time against them, accounting for the service calendar and any pause conditions. As a target approaches, escalation rules fire — reassignment, notification to a supervisor, priority change — so a request in danger of breaching gets attention before it does, not after. Agents and dispatchers see which requests are at risk on their queue, and customers see live status on the portal. Beyond the individual request, SLA performance is measured across the operation, so you can report attainment by customer, service type or team and see trends rather than only reacting to complaints. The point is to make the SLA an operational control that shapes daily work, not a number you calculate at month-end to see how you did.

Yes, across all three of the common models. Recurring service contracts — maintenance agreements, coverage plans — are billed on a periodic schedule directly from the contract. Time-and-materials work is billed from what the service order captures: the labour recorded, the parts consumed and any expenses, priced according to the customer's terms and net of whatever entitlement covers. One-off charges — a chargeable call-out, an out-of-warranty repair — flow the same way. Because billing runs from the same service records as execution, the invoice reflects the work that was actually done and the entitlement that actually applied, rather than being re-keyed by finance from a job sheet. That closed loop from work to invoice is exactly what stops service revenue leaking away between the field and the ledger.