How can an equipment manufacturer connect service requests, spare parts, and maintenance contracts?

At 8:30 on Monday morning, the service desk at an industrial equipment manufacturer received three requests at once. An automotive supplier had a stopped production asset, a food plant reported unstable pressure, and another customer wanted to confirm its maintenance date. The coordinator wrote down the details and began calling regional engineers.

Forty minutes later, the engineer responsible for the automotive site was still travelling. He remembered replacing a sensor two months earlier but could not confirm the part number. The warehouse held three similar sensors, while the asset had been modified after delivery. The coordinator could only tell the customer that resources were being arranged. The food plant's issue might have been solved remotely, but it waited behind the louder emergency.

The manufacturer shipped several hundred standard and configured-to-order systems each year. Assets could remain in service for more than a decade. Service had grown from a sales obligation into a meaningful business covering repair, maintenance, upgrades, and parts. Its information model had not grown with it. Asset records lived in ERP, shared folders, and engineers' laptops. Requests arrived by telephone, chat, and sales referral. Parts usage was posted late. Signed paper reports were transcribed at month end. Account managers remembered renewals individually.

Service commitments came before the ticket interface

Because the service platform required ongoing integration and workflow monitoring, the manufacturer also used the DevOps service guide to define responsibilities across operations, engineering, and suppliers before launch.

Management first proposed automatic assignment to the nearest engineer. A review of 60 historical jobs showed that distance was only one constraint. Production impact, contract coverage, certifications, equipment versions, carried parts, site access, and existing commitments all affected the decision. A simple job marketplace could distribute work while leaving urgent incidents without accountable coordination.

The business defined three service classes. Safety risks and full production stops required immediate management confirmation of a response plan. Capacity-reducing faults followed the contracted response window. Advice and planned maintenance entered normal scheduling. Actual thresholds would be governed by each customer's contract and the manufacturer's delivery capacity.

Every service record had to identify the customer, site, and asset. Contract entitlements, response targets, included visits, and charging rules were visible. Unclear commercial terms went to an authorised reviewer. Technical response could begin without allowing field staff to make an accidental promise that the work was free.

The asset record became a timeline, not a static card

Serial numbers alone were insufficient. Components changed between production runs, and customers later commissioned upgrades. Each asset record therefore contained the model, serial number, bill-of-material version, critical components, installation date, warranty, commissioning data, and subsequent configuration changes.

When a component or control package changed, the record preserved the removed item, installed item, reason, date, and engineer. A historical failure could be viewed against the configuration that existed at that time. Unknown fields stayed visibly unknown rather than being populated with convenient defaults.

Legacy data was improved through live work. Contracted, high-value, and failure-prone assets were reviewed first. Other records were confirmed when the next service or maintenance visit occurred. Engineers scanned the asset, checked its plate and critical components, and made each intervention improve the record.

Customers could scan an asset code to start a request, but the code itself exposed no confidential information. After identity and account checks, a customer could see only its authorised assets and service history. The request form asked about observable conditions—whether production had stopped, whether there was leakage or an odour, and which alarm was displayed—rather than asking a customer to diagnose the root cause.

Dispatch recommendations exposed their reasoning

The system checked safety indicators and then ranked qualified engineers using service priority, response windows, skills, certifications, location, shift, current work, and available parts. Dispatchers saw why each person was recommended. If nobody met the constraints, the conflict was explicit; the software did not disguise an unsafe assignment as an answer.

Remote diagnosis became a formal stage. Engineers recorded checks, customer safety actions, evidence, and the next decision. A remotely restored asset closed only after the customer confirmed its status. If a visit was required, the record became the field engineer's preparation brief, eliminating repeated explanations.

For the automotive plant, the asset history showed that an upgraded sensor—not the original bill-of-material item—was required. The closest engineer lacked training on that controller. A second engineer, 30 kilometres farther away, had relevant experience and could collect the correct sensor from a regional cabinet. Dispatch selected the second engineer and used the first for an immediate video-assisted wiring check. The repair, removed component, replacement, and verification all remained on one incident timeline.

Parts inventory followed service reality

Parts were held at headquarters, regional stores, engineers' vehicles, and customer consignment cabinets. Each location became controlled inventory with traceable movements. A job produced a preparation list, not an automatic issue. Warehouse staff scanned parts to the engineer; installed parts were linked to the asset; unused items were returned or formally transferred to vehicle stock. Removed items entered warranty return, repair, or disposal states and could not reappear as available stock.

Approved substitute parts included applicability and required adapters, software, or parameter changes. Safety- or performance-sensitive substitutions needed engineering approval. Early replenishment rules stayed simple: actual regional consumption, failure criticality, and supplier lead time determined minimum levels. More sophisticated forecasting waited until movement records were trustworthy.

The mobile workflow supported field work

Before departure, engineers checked tools, parts, and access requirements. On arrival, they confirmed the asset and safety isolation. Diagnosis captured symptoms, tests, and cause. Repair captured components and parameters. Closure captured verification, current status, and open issues.

Encrypted offline data supported poor connectivity in industrial sites and synchronised later. Conflicting edits were reviewed instead of silently overwritten. Dictation and templates reduced typing, but engineers still confirmed cause, action, and evidence. High-risk assets required reproducible symptoms and measurements; routine advice used a shorter record.

A customer's field signature confirmed attendance, work performed, current condition, and unresolved items. It did not automatically determine warranty or price. Those decisions followed contract and review rules, reducing disputes caused by asking a field contact to accept a broader commercial statement.

Service data improved products and account planning

Once workflows stabilised, managers could separate response delay from repair delay. Waiting for access, parts, travel, diagnosis, and customer verification appeared as distinct intervals. The product team reviewed incidents by model, configuration, and confirmed cause. Repeated connector failures in humid environments led to a manufacturing change and a planned inspection for affected assets.

Account teams received a renewal view containing asset age, incident history, maintenance completion, parts use, and open risks. Instead of sending a generic renewal message, they could discuss a relevant maintenance plan, parts package, remote-support option, or upgrade.

After six months of stable operation, the median time to confirm a plan for high-priority incidents fell from 55 minutes to 18. Repeat visits caused by the wrong part fell from about 12 per month to two. Same-day completion of service reports rose from 40% to above 90%. Reviews completed at least 60 days before contract expiry rose from below 30% to about 80%.

Mean time to repair improved by only about 10%, below management's initial hope. The evidence showed that long supplier lead times and customer access approval remained major constraints. The next investment was therefore operational: position selected critical spares, agree emergency access arrangements, and connect appropriate equipment data for secure remote diagnosis.

The result was not simply cleaner ticket administration. Engineering knowledge became an organisational asset through configuration history, diagnostic evidence, compatibility rules, and verification. Experienced engineers spent less time answering repeated context questions and more time solving difficult faults and improving the product.

Customisation mattered because assets, contracts, qualifications, parts, and field verification were tightly related. A CRM could hold customer details, an ERP could hold accounting inventory, and a generic ticketing product could allocate tasks. Without a reliable link around one asset and one service event, staff would still reconcile those facts manually.

A manufacturer considering similar work can reconstruct 20 representative recent incidents: a major stop, a remote fix, a parts delay, a warranty dispute, and a recurring fault. For each, ask what configuration existed, why the engineer was selected, which parts moved, what the customer confirmed, and why the final charge applied. Any question the organisation cannot answer points directly to the first useful scope.

Customers ultimately buy confidence that an asset will remain productive. Custom software can support that promise by making context easier to find, resources easier to prepare, contract decisions clearer, and learning reusable. When that cycle operates consistently, service becomes a measurable product and a durable source of customer value rather than a sequence of emergencies.

The broader custom-software decision framework can help clarify the boundary among CRM, ERP, and a new service platform.