Buying & ownership · Ownership
Robot warranties, spares and service support: what to secure
Build a supportable robot purchase by separating warranty cover, maintenance, service response, parts, software and lifecycle obligations.
Reviewed · Editorial review
The robot is only one part of a usable system. Once it is deployed, the practical product includes diagnostics, people, replacement parts, software access, maintenance and a route back to service. Buyers should evaluate that support system with the same care as payload, speed or appearance.
This guide is a commercial and operational checklist. It does not determine your statutory rights or interpret a particular contract. Obtain professional advice where those questions affect a purchase.
Separate six things that are often called “support”
Warranty
A warranty is a set of written promises and conditions from an identified provider. It should say what is covered, for how long, in which territory and through which claim process. It is not the same as maintenance, guaranteed uptime or all-cost repair.
Ask for the warranty document before purchase. Record:
- the legal entity providing it;
- the event that starts the period: shipment, delivery, activation or another date;
- component-specific periods;
- parts, labour, travel and shipping treatment;
- exclusions and required maintenance;
- territory and authorised repair route;
- whether cover transfers to a later owner;
- the remedy and escalation route.
Terms can differ by configuration. Unitree publishes warranty and after-sales policies with conditions concerning unauthorised modification, disassembly and accessories, while product pages can state configuration-specific cover. The lesson is not that one policy is standard; it is to obtain the terms for the exact model, seller, buyer and location.
Statutory rights and supplier obligations
Rights and duties can exist independently of a commercial warranty, but their application depends on the buyer, seller, product and transaction. Do not let a sales summary merge these into one vague promise.
Keep the contract, invoice, advertised specification, correspondence and acceptance record. If a dispute or safety issue arises, take advice appropriate to the jurisdiction and circumstances rather than relying on a warranty FAQ alone.
Preventive maintenance
Maintenance is the planned work that keeps the system in its intended condition. Obtain the manufacturer schedule and convert it into named tasks, intervals, responsible people, required parts and records.
The HSE’s maintenance guidance explains the need to keep work equipment in an efficient state, order and repair, with safe arrangements for maintenance activities. For workplace deployments, connect the robot’s schedule to the organisation’s wider equipment-management process.
Technical support
Technical support is the channel that diagnoses problems and guides recovery. Define its hours, languages, contact routes, severity levels, response targets and access requirements. “Email support included” does not establish when a qualified person will engage or what they can do remotely.
Ask which logs the provider needs and how they are transferred. Decide who may grant remote access. If the robot handles video, audio, site maps or operational data, ensure the support workflow fits the buyer’s security and privacy controls.
Field service
Field service means someone can attend the robot, but the promise is incomplete without geography, availability and cost. Establish whether engineers are employees, authorised partners or third parties; where they travel from; which tasks they can complete; and whether labour, travel and accommodation are included.
ABB’s robot service-agreement overview separates technical support, preventive maintenance, on-site response, parts, labour, travel, data services and training across different service levels. Even if buying another brand, that separation is a useful way to interrogate a bundled offer.
Spares and consumables
A parts catalogue is not evidence that parts are in stock locally. Identify wear parts, collision-sensitive items, batteries, chargers, cables, wheels or feet, sensors, actuators and model-specific tools. For each critical item, request a current part number, compatibility statement, price basis, stock location and indicative lead time.
Decide which parts should be held on site and which can remain with the service provider. That choice depends on failure impact, shelf life, safe storage, technician capability and replenishment time.
Create a supportability dossier
Before acceptance, assemble a controlled folder with:
- Exact asset identity, serials, configuration and installed options.
- Supplier, manufacturer, warranty provider and escalation contacts.
- Warranty terms and proof of start date.
- Operating, safety and maintenance instructions.
- Service schedule and completed commissioning record.
- Parts list, local stock agreement and ordering route.
- Software versions, licences, administrator ownership and update policy.
- Diagnostic and remote-support procedure.
- Training records and permitted maintenance roles.
- Backup, recovery and decommissioning plan.
If an item does not exist, mark it as a gap with an owner and decision date. A dossier should reveal uncertainty, not hide it behind a folder called “manuals.”
For a second-hand asset, combine this dossier with the new-versus-used evidence checklist. Transferability of accounts, warranty and service access must be proven rather than inferred from the hardware.
Define service levels around the operation
Start with business impact. A robot used occasionally for demonstrations has a different recovery requirement from one embedded in a daily process. Classify incidents in language the operating team can recognise:
- Critical: the deployment cannot continue safely or its essential task is unavailable.
- Degraded: the core task can continue with reduced capability or supervision.
- Minor: a non-essential feature is affected.
- Request: configuration, training or enhancement rather than a fault.
For each class, agree support hours, acknowledgement target, diagnostic start, workaround aim, on-site threshold and communications cadence. Be precise about whether targets are contractual commitments, service objectives or illustrative estimates.
Then define restoration. Does the provider repair the unit, exchange a module, supply a loan robot or provide remote recovery? Is transport included? Who decides that the robot is fit to return to service? An impressive first-response time is of limited value if the required part is unavailable for months.
Test the escalation path
Run a support exercise during commissioning:
- open a test ticket through the documented channel;
- verify asset entitlement and named contacts;
- export the required diagnostic bundle;
- simulate escalation to a technical specialist;
- locate one critical spare and confirm its ordering route;
- record out-of-hours instructions;
- verify who can authorise chargeable work.
This is not a demand for an artificial failure. It proves that accounts, permissions and handoffs work before an incident.
Protect software continuity
Ask the manufacturer or supplier to document:
- supported software and firmware versions;
- update release and security-notification channels;
- minimum network and cloud dependencies;
- licence renewal dates and consequences of expiry;
- rollback and recovery options;
- API or integration compatibility policy;
- expected product and service support horizon;
- data export and deletion process at exit.
Avoid promises that a connected feature will run indefinitely. Instead, decide what evidence would trigger a review: an end-of-support notice, unavailable security update, cloud-service change or incompatible control device.
Plan modifications before making them
Custom grippers, third-party batteries, altered enclosures and unofficial software can affect safety, support and warranty. Submit proposed changes through an approval process that considers the manufacturer’s instructions, risk assessment, documentation, cyber security and continued serviceability.
Keep a configuration history with who approved and implemented each change. If the modified system is materially different, obtain competent advice on any additional compliance responsibilities. Do not assume that returning the casing to its original appearance reverses those consequences.
Compare an owned-support plan with a service model
An ownership offer may be attractive when the buyer has technical staff, predictable utilisation and a credible spares route. A managed or subscription service may shift some operational work to a provider, but only the contract tells you which work and risk actually move.
Our Robotics-as-a-Service explainer dissects those contract components. For the broader capital-versus-service decision, use the rent, buy or RaaS framework.
Make support part of acceptance
Do not close commissioning solely because the demonstration succeeded. Acceptance should require the promised documents, accounts, training, spares, service contacts and baseline diagnostics. Record open issues and the commercial mechanism for resolving them.
When reviewing robot ownership research, use the same supportability dossier for every seller. Share the operating hours, location and acceptable downtime for research guidance; only a future authorised seller or service provider can confirm the support offer alongside the machine.
Next step
Ready to choose a robot?
Compare suitable models or send us the job. We will help you narrow it down.