After-Sales Robotics Support: Spares, Escalation and Field Service

Robot after-sales service is often described as a hotline plus spare parts. That is too narrow. A production robot is part of a site workflow, so recovery may depend on software, networking, maps, fixtures, doors, lifts, payload equipment, operating procedures and people as well as the robot platform.

A workable service model answers five questions before the first incident: who receives the issue, what that person may safely do, what evidence must travel with an escalation, which parts and skills must be reachable, and who has authority to return the service to operation.

Define support around the installed service, not the product box

OSHA's industrial-robot guidance describes a robot application as a system that can include controls, programs, sensors, communication interfaces, end-effectors and associated machinery. Although the exact regulatory scope varies by application and jurisdiction, the systems lesson is broadly useful: an after-sales boundary that stops at the chassis will create orphaned faults.

Create an installed-base record for every deployed service. At minimum, record the asset and serial identifiers, hardware and software configuration, payload or peripheral interfaces, site contacts, agreed operating envelope, approved backups, maintenance source and revision, warranty status, support entitlement and relevant access constraints. An escalation without configuration context is a fresh investigation.

Set service entitlement before the first ticket

Attach entitlement to the installed-base record, not to a salesperson's memory. Record the coverage window, supported channels, languages, named customer contacts, remote-access prerequisites, included labor, travel boundary, excluded consumables, software-support horizon and route for chargeable work. Also state what happens when the asset configuration, payload, network or operating environment changes. This prevents a technical incident from becoming a commercial negotiation while the service is stopped.

Use two tests. First, can the person receiving an alert determine the applicable coverage without reading the full contract? Second, can the next support layer see which diagnostics and actions are permitted? If either answer is no, convert the commercial promise into a one-page operational entitlement record and review it whenever the accepted configuration changes.

Separate L1, L2 and L3 by decision authority

Tier names mean little unless each tier has a decision boundary. Local first-line support should normally identify the affected service, secure the area, collect evidence and perform only approved recovery. Remote second-line support should correlate evidence, guide bounded checks and decide whether a field visit is justified. OEM or specialist third-line support should own protected product diagnostics, warranty decisions, product-level repair instructions and defect escalation.

The matrix below is a Warpify modelled framework. It is an illustrative scenario for service design, not a universal service-level agreement or permission to work outside site procedures, training or law.

Prioritize spares by service exposure, not unit price

A cheap component with a long and uncertain lead time can create more service exposure than an expensive module available next day. For each replaceable item, rate four inputs using locally defined ordinal bands: failure consequence, installed-base demand, replenishment uncertainty, and availability of a safe workaround or pooled spare. Then assign an action such as hold locally, hold regionally, secure supplier allocation, or monitor only.

Do not multiply arbitrary scores and present the result as science. Keep the reasoning visible. A recommended record is: part and compatible configuration; affected service; failure symptom; criticality rationale; on-hand and usable quantity; reserved quantity; replenishment time range; shelf-life or storage constraint; substitution rule; and named reorder owner. Count only parts that are identifiable, compatible, accessible and accompanied by the skill and instructions needed to fit them.

Build a minimum viable escalation packet

A useful escalation should let the next level begin analysis without repeating the first conversation. Capture: service and asset identity; accepted configuration baseline; time, timezone and clock quality; observed symptom versus expected behavior; current safe state; structured event or alarm identifiers; relevant logs, images and video; environmental conditions; actions already attempted and their outcomes; recent changes; business impact; site access restrictions; and the person who can authorize the next step.

Keep the raw evidence and add a concise chronology. Avoid pasting credentials, unnecessary personal data or uncontrolled customer information into tickets. If diagnostic data may leave the site, define the permitted transfer route, retention and recipient before an incident.

Turn field dispatch into a controlled work package

"Send an engineer" is not a work scope. Before dispatch, confirm the suspected failure domain, required competence, applicable safety and access prerequisites, expected tools and parts, remote contact, change and rollback authority, planned outage, and the test that will demonstrate recovery. A technician should arrive with a bounded decision tree, not just a list of guesses.

ABB and KUKA currently present remote support, preventive maintenance, on-site work, spares and training as separate service components. These vendor examples do not prove any Warpify capability or define the right package for every robot. They do show why partners should price and staff support as a portfolio of distinct activities rather than one unlimited promise.

Keep warranty, SLA and maintenance separate

A warranty addresses defined defects under defined conditions. An SLA describes response, restoration or other service commitments. A maintenance plan defines work intended to preserve condition and performance. One does not automatically include the others. Contracts and operating procedures should say who diagnoses, who authorizes warranty action, which travel and labor are included, what evidence is required, and how customer-caused, environmental or integration faults are handled.

Close a case only after the agreed recovery evidence is recorded: the service is in a known safe state, the accepted functional test passed, temporary changes are identified, configuration and parts records are updated, the customer contact knows any remaining limitation, and repeat-fault follow-up has an owner. “Robot moving again” is an observation; it is not by itself proof that the production service has returned to its accepted condition.

Review the service system with leading evidence

Useful monthly indicators include installed assets with current configuration records, cases resolved at each layer, escalations rejected for missing evidence, repeat faults, first-visit completion, parts fill rate, aging backorders, remote versus field resolution, overdue preventive work and changes made without an accepted baseline. Pair speed with recurrence and safety; a fast reset that repeats is not a durable recovery.

For the commercial and responsibility boundaries behind this model, see Warpify's robot SLA guide, RaaS responsibility matrix and integrator and distributor partner model. If you are building local support capacity, explore the partner pathway.