SERVICEMAX MAINTENANCE PLANS + OPTIMIZATION ENGINE
ServiceMax generates work orders from maintenance plans against assets and contracted entitlements. Asset 360 (on Salesforce Field Service), Core (with the Dispatch Console) and FieldFX (for energy-services tickets) all model maintenance plans against the installed base. That covers a wide band of OEM service work cleanly. At thousands of recurring stops, with SLAs that vary by contract or entitlement, with cadence drift to keep capacity balanced, and where the recurring program interacts with reactive break-fix for the same technicians, work-order generation is no longer the same thing as optimization. eLogii’s engine models task and route template groups as constraint inputs to the optimizer.
Asset-centric field service management software that connects products, customers, and service teams.
From ptc.com/en/products/servicemax. ServiceMax positions the asset and the contract as the spine of recurring service. Maintenance plans generate work orders against assets and entitlements on the right cadence. Constraint-aware optimization across thousands of generated stops with interacting SLAs is its own decision layer. Verified June 2026.
ServiceMax covers maintenance and recurring service against the installed base across the three products:
The platform tracks the parent program and the child work orders, holds time on the dispatch surface, manages the contract documentation, and runs the standard route calculation between assigned stops. The vocabulary is generation-first: produce the work orders, hold them on the dispatch surface, manage the contract paperwork, route between them.
What no ServiceMax product positions as the lead capability is constraint-aware optimization across the generated work orders. The recurring program at scale isn’t just a calendar problem; it’s an assignment problem where SLAs interact (entitlement anniversaries, quarterly preventive cycles, customer service contracts), cadences drift, certification requirements pin specific technicians to specific assets, and capacity has to balance across the recurring program and the daily reactive break-fix.
The recurring programs that outgrow the dispatch surface are concrete:
In each case, the engine doesn’t replace ServiceMax’s work-order generation. It optimizes what the generation produces.
A medical-device OEM running monthly, quarterly and annual PMs across a hospital network. Fifty-five technicians in the field. Around 3,500 recurring work orders per month generated from maintenance plans, plus daily reactive break-fix for the same technicians. SLA windows vary by contract: entitlement anniversaries pinned to fixed dates, calibration on a hard 6-month cycle, regulatory inspections within calendar months, lab-instrument programs at four-week intervals.
ServiceMax generates the recurring work orders cleanly: stops appear on the dispatch surface at the right cadence, Salesforce Field Service mobile carries the job sheets and PM checklists, completion data flows back to BI. The planning task that grows past the dispatch surface is the balancing: reactive break-fix for the same technicians landing on top of recurring work orders; cadence drift to keep capacity even across the month; SLA windows that need protection from the optimizer rather than from a dispatcher spotting them in time. Template-group optimization absorbs cadence drift within rules, protects SLA-locked stops, balances against reactive, and outputs one plan that’s already reconciled across the book. The maintenance-plan data model stays in ServiceMax; eLogii owns the optimization across it.
The workaround is the same as for the wider planning problem: the dispatcher carries it. The generated work orders appear on the Service Board / Dispatch Console; the dispatcher assigns them to technicians, balances against reactive break-fix, allows cadence drift to keep capacity even, and signs off on the day. At small recurring books, this is straightforward. At several thousand recurring work orders a month, with SLAs and cadences interacting, the dispatcher becomes the optimizer. The friction shows up as SLA misses on specific contracts, drive-time creep on the recurring book, and over-reliance on the one or two dispatchers who know the recurring rules best.
Recurring programs are modeled as task and route template groups feeding the optimizer. Each template carries the cadence, certification requirements, SLA windows and depot rules; the optimizer treats them as first-class inputs alongside the daily flexible work.
ServiceMax stays in place as the system of record for the asset, the work order, the contract and the entitlement. Work-order generation from maintenance plans continues to run in ServiceMax. eLogii reads the generated work orders, plus the reactive break-fix, plus the technician/vehicle/depot model, runs the optimization across them, and writes back optimized routes and ETAs.
Most teams complete the connector build in 3 to 5 weeks. Typical first wave: the recurring program that is leaking the most against SLAs today, or the contract book where cadence interactions are hardest.
30-minute custom simulation with your actual maintenance-plan book, technicians and SLAs. Projected savings in drive time, SLA hit rate and dispatcher hours.
Yes, at the workflow layer. Asset 360, Core and FieldFX all model maintenance plans against assets and contracted entitlements, generating work orders at the right cadence with entitlement validation and contract documentation tied in. The assignment and route between the generated work orders is then handled by the standard dispatch surface (Service Board on Salesforce Field Service in Asset 360, Dispatch Console in Core, FieldFX surface in FieldFX). What no ServiceMax product positions as the lead capability is constraint-aware optimization across thousands of recurring work orders with interacting SLAs, cadences and certification requirements. That decision layer is where eLogii adds value.
Work-order generation: produce a list of work orders at the right cadence (monthly PMs, quarterly preventive, weekly commercial maintenance) against assets and entitlements. Recurring program optimization: take the generated work orders, plus the daily reactive break-fix, plus the technician pool, plus the SLAs and cadences, and decide assignments and routes that respect all of them at once. ServiceMax does the first cleanly. eLogii does the second, modeled directly through task and route template groups that feed the optimizer as constraint inputs.
When the recurring program runs to hundreds or thousands of work orders per month, when SLAs vary by contract or entitlement, when cadence drift (a stop shifting from week 1 to week 2 to keep capacity balanced) becomes a planning task, and when the recurring program interacts with daily reactive break-fix for the same technicians. PM programs across hospital networks, multi-site PMs for industrial OEMs, recurring commercial maintenance contracts, inspection programs across regions: each of these hits the optimization decision layer rather than the work-order generation layer.
Through task and route template groups: weekly, monthly, quarterly and bespoke cadences are modeled directly as inputs to the optimizer. Each template carries certification requirements, time-window constraints, SLA targets and cadence rules. When the run happens, the optimizer balances the recurring program against the daily flexible work, protects SLA-locked stops, allows cadence drift within rules, and outputs one consistent plan. Bristow & Sutor routes 200,000+ recurring case visits per year on eLogii.
Custom integration against the ServiceMax REST API and eLogii’s REST API. eLogii reads recurring maintenance plans and the generated work orders from ServiceMax (directly in Core, via Salesforce Platform APIs in Asset 360, via the FieldFX REST surface for energy-services tickets), plus the daily reactive break-fix and technician/vehicle/depot model. The optimization run considers them together. Routes and ETAs are written back to ServiceMax; the Salesforce Field Service app, ServiceMax Go or the FieldFX mobile app picks up the assignments. Completion data flows back. Typical connector build: 3 to 5 weeks.
Last updated: June 2026. ServiceMax scope is drawn from PTC’s ServiceMax product page and the Asset 360 AppExchange listing. eLogii capabilities documented at elogiiapidocs.apidog.io.
Custom simulation
A 30-minute working session with our solutions team. We take a sample of your real jobs, depots, vehicles and SLAs, run them through the eLogii engine, and show you the projected delta against how you plan today. No slides, no generic benchmarks.
