SERVICEMAX + MULTI-DEPOT OPTIMIZATION
ServiceMax models territory cleanly. The Service Board (Asset 360), the Dispatch Console (Core) and the FieldFX surface all support territory-based scheduling against the asset and work-order record. Service organizations with three or four regional service centers, OEMs with branch networks, and recurring maintenance programs across regions need something different: an optimizer that treats all depots as one problem and rebalances work between them under skill, capacity, time-window and SLA constraints, as a single solver input. eLogii owns that decision, custom-integrated against ServiceMax’s REST API (or the Salesforce Platform APIs underneath Asset 360).
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 territory as the spine. Cross-territory rebalancing as a single optimization input is not described as a lead surface in any of the three products. Verified June 2026.
ServiceMax’s product pages cover the territory model clearly across the three products. Asset 360 inherits Salesforce Field Service’s territory and policy modeling. ServiceMax Core ships territory-based dispatch in the Dispatch Console. ServiceMax FieldFX models field operations against the energy-services workflow. Technicians have base territories, vehicles are tracked from that base, the Service Board shows the day’s assigned work, and the scheduler calculates the fastest route between the work orders the dispatcher has placed for that technician within that territory.
What none of the pages position as a lead surface is cross-territory optimization as a first-class input: a single run that takes all depots as inputs, rebalances work orders across them under shared constraints, and outputs assignments that may move work between depots. That decision layer is a different shape of product, and ServiceMax’s dispatch UIs are not it.
Three concrete patterns make the case for multi-depot as a single optimization input:
In each case, the right answer is decided by the optimizer, not the dispatcher. The dispatcher steers the rules and signs off on the run.
A heavy-equipment OEM running four regional service centers. Eighty service technicians in the field. Daily routes for contract maintenance against installed-base assets; reactive break-fix for SLA-locked equipment; parts pickup between centers when a route needs a part from elsewhere in the network. ServiceMax Asset 360 handles the workflow cleanly: asset hierarchy, work orders, contracts and entitlement validation, Salesforce Field Service mobile in the technician’s hands.
The friction sits at the depot interface. Center A runs hot most weeks while center D runs underused; capacity drift accumulates because no one has time to look across centers in real time. Routes that should start at center A, pick up at center B, then continue to customers run as two separate trips because the dispatcher can only see one territory view at a time. Drive time creeps. The operations director can see the problem on the BI dashboard at end-of-week, but no one is solving it on Tuesday morning. A cross-depot optimization run takes all four centers as one input, drops drive time around 15–20% across the network, and rebalances capacity within roughly +/- 5%. ServiceMax continues to own the asset, the work order and the warranty; what changes is which center does which work order.
The workaround is the dispatcher. The dispatcher assigns work to centers based on rules of thumb (closest, certification match, current capacity), then ServiceMax routes within each center. At small numbers of centers and stable work mix, this is fine. The friction shows up at scale: capacity at one center stays underused while another runs hot; drive time grows because work isn’t reassigned to the center that should actually do it; SLA hits depend on the dispatcher spotting the constraint in time. The longer the operation runs without a cross-depot optimization step, the more drift accumulates.
Multi-depot is a first-class input. Each depot has a location, opening hours, vehicle pool, certification mix, capacity and (where it matters) shift patterns. Technicians are associated with home depots but the optimizer can reassign work between depots when constraints allow. A single run produces one consistent plan.
ServiceMax stays in place as the system of record for the asset, the work order, warranty, contracts and parts. The connector is custom-built against both products’ REST APIs; there is no published eLogii-ServiceMax integration on either side. Asset 360 is also reachable via the Salesforce Platform APIs (MuleSoft is a common middleware).
Most teams complete the connector build in 3 to 5 weeks. Typical first wave: the regional book where cross-depot rebalancing is the dominant planning task, or the OEM service arm running parallel to the contract-maintenance business.
30-minute custom simulation with your actual service centers, technicians, vehicles and recurring maintenance programs. Projected savings in drive time, capacity utilization and SLA hit rate.
ServiceMax supports multi-territory operations at the workflow level across Asset 360, Core and FieldFX: technicians can be associated with home territories, vehicles can be tied to specific centers, and the Service Board / Dispatch Console / FieldFX surface shows assigned work on the calendar. What no ServiceMax product positions as a lead surface is cross-territory optimization as a first-class input: a single optimization run that considers all depots together, rebalances work orders across depots under skill and capacity constraints, and produces assignments that may move work orders between depots when the math says they should move. That is the decision layer eLogii adds.
Three concrete patterns. First, OEM service organizations with three or four regional service centers: the optimizer needs to decide which center a work order goes to based on certification availability, drive time, current capacity and SLA, not just which center is closest. Second, service arms with branch networks: routes start and end at different centers in the same plan, and consolidation across branches drops drive time materially. Third, hub-and-spoke programs where technicians can start from one center, pick up parts from another, then continue to customer sites. None of these are solvable as the sum of single-center optimizations.
The workaround is dispatcher-driven: the dispatcher assigns work to each center based on rules of thumb, then ServiceMax routes within each center. At small numbers of centers and stable work mix, this is fine. At more centers, fluctuating work mix, or interacting certifications and SLAs, the dispatcher has to hold the cross-territory picture in their head. Capacity at one center stays underused while another runs hot. Drive time grows because work isn’t reassigned to the center that should actually do it. The longer the operation runs, the more this drift accumulates.
Multi-depot is a first-class input to the optimizer. Each depot has a location, opening hours, vehicle pool, certification mix and capacity. Technicians are associated with home depots but the optimizer can reassign work between depots when constraints allow. A single optimization run produces routes that may start at one depot, end at another, or pick up at a third. The output is one consistent plan, not the sum of per-depot plans. Both the Default engine and the Advanced engine handle multi-depot inputs.
Custom integration against the ServiceMax REST API and eLogii’s REST API. eLogii reads work orders, assets, technicians, vehicles and depots from ServiceMax (directly in Core, via Salesforce Platform APIs in Asset 360, via the FieldFX REST surface for energy-services tickets). The optimization run treats all depots as a single problem. Routes and ETAs are written back to ServiceMax, mapped to the appropriate depots and technicians; the Salesforce Field Service app, ServiceMax Go or the FieldFX mobile app picks up the assignments unchanged. Completion data flows back to ServiceMax for asset history, warranty and reporting. 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.
