Robot supplier support due diligence: test the recovery path before buying

Map who supports each part of the application

List the arm, controller, tooling, machine interface, application software and site installation separately. Name the party responsible for diagnosing each element and the party that owns the whole application when the cause is uncertain. A robot manufacturer may support its product while an integrator owns the custom program and a tool supplier owns the gripper. The buyer needs a route through those boundaries that does not depend on guessing the faulty component first.

Universal Robots' FAQ describes support through its customer portal, technical support and distributors, with ticket response depending on the service plan. Use that as a concrete example of why a logo or sales relationship does not fully describe support entitlement. Ask your proposed supplier to identify the actual service organisation, relevant region and escalation contact. Verify any claimed manufacturer relationship through the manufacturer's official channels. Record what has been confirmed, what is only a sales assertion and what still requires a written commitment.

参考资料： Frequently asked questions: support and myUR

Define response, diagnosis and restoration separately

Ask the supplier to explain what its support promise measures. An acknowledgement says a request was received; technical engagement means someone qualified is working on it; restoration means the agreed function is available again. Request operating hours, time zone, languages and the treatment of local holidays. Ask how urgency is assigned and who can escalate a stalled case. Avoid converting a friendly promise of fast support into an assumed restoration commitment in the business case.

Use a service schedule with the covered equipment, eligible users, contact route, escalation steps and exclusions. Ask whether remote diagnosis, travel, labour and replacement parts are included or separately charged. Universal Robots' FAQ distinguishes service-plan response arrangements, but it does not establish the terms of another supplier's offer. Obtain the actual service documents and record conflicts with the quotation for clarification. The useful purchasing result is a promise specific enough to plan around, including its dependencies and limitations.

参考资料： Frequently asked questions: support and myUR

Run a disclosed tabletop support exercise

Invite the supplier to walk through a hypothetical stoppage before purchase. Tell them explicitly that it is a due-diligence exercise, not a real emergency. Provide a fictional application description and ask what information they would request, who would review it and how they would proceed if the cause remained uncertain. Evaluate the quality of the questions and the clarity of ownership. Do not damage equipment or create a fault to test whether the supplier answers the telephone.

For example, imagine that a loading application stops after an authorised software change and the cause is not yet known. Ask how support distinguishes an arm fault, an application issue and a machine-interface problem. A useful response requests relevant versions, logs and change history while keeping physical intervention under qualified control. Universal Robots documents remote support-log generation with compatibility and connectivity conditions; this illustrates why diagnostic access should be established before relying on it. Your exercise should record dependencies, not award a universal reliability score.

参考资料： Remote support log file generation

Trace a replacement part all the way to installation

Ask the supplier to identify likely service items for the proposed configuration and explain how the correct replacement is selected. Request the information needed to confirm compatibility, whether parts are stocked or ordered, and who can provide a current availability confirmation when needed. Treat lead-time statements as estimates unless the agreement says otherwise. A photograph of shelves does not establish that the correct part will be available for your robot when a fault occurs.

Discuss return authorisation, diagnostic review, shipping preparation, repair location and responsibility for reinstalling and validating the repaired equipment. Universal Robots' FAQ describes arranging repair-centre shipment after a support ticket and instructions; that is a useful prompt to ask for your own supplier's procedure. Explore whether an advance replacement or loan item is available under the actual contract, without assuming either is standard. Evaluate downtime through the complete sequence, including authorisation and qualified recommissioning, rather than counting only the advertised transport time.

参考资料： Frequently asked questions: support and myUR

Verify ownership of programs and recovery material

Ask what software, configuration and documentation the buyer receives at handover. Identify who owns custom application source, who may modify it and what licence permissions apply to transfer or recovery. Confirm that the buyer can access the agreed files without depending on a departing employee's personal account. A saved program is not automatically a complete recovery package; request an equipment-specific description of what is included and how restoration would be authorised and checked.

Universal Robots' historical PolyScope release notes document a full system backup and restore facility. That establishes a manufacturer feature, not permission to restore arbitrary data to a different robot or bypass compatibility checks. Have the supplier describe the supported procedure for the quoted configuration and explain how backups are identified, stored and verified. A recovery demonstration should be planned by qualified personnel in an appropriate test setting. Capture its result and limitations, including any application data or third-party licence material handled separately.

参考资料： Release note Software version 5.5.x.x: Backup / Restore

Make remote support usable under your site's rules

Involve the person responsible for site networks before accepting remote access as the main recovery method. Ask which connection is needed, who approves a session, what the technician can access and how access is ended. Identify what information a diagnostic upload contains and which team approves its sharing. The goal is a support arrangement your organisation can actually permit and operate, with an alternative route when a connection is unavailable.

The cited Universal Robots support-log page describes a connected-robot workflow and explicit compatibility conditions. Ask the proposed supplier to demonstrate the equivalent diagnostic route for the offered equipment and software. Do not assume that installing an unspecified remote-control tool is acceptable or sufficient. In your tabletop exercise, include a case where the site cannot provide a live connection. Request a documented process for obtaining permitted diagnostic information locally and transferring it through an approved channel, with physical work remaining subject to the responsible specialists' instructions.

参考资料： Remote support log file generation

Ask references about events, not general satisfaction

Request permission to contact a relevant customer reference and ask about a specific completed support event. Useful questions concern how the case was opened, whether ownership was clear and what happened when the first diagnosis was inconclusive. Ask what support scope that customer purchased so you do not compare their premium service arrangement with your proposed basic offer. Treat a reference as limited evidence about a past situation, not a guarantee of future performance.

Also review continuity if the salesperson leaves, the integrator changes its team or the buyer moves the equipment. Ask which records and accounts belong to the buyer and how an alternative authorised provider could obtain the necessary application information. The manufacturer FAQ establishes that formal support routes exist for its products; your independent procurement question is whether the proposed application remains supportable through ordinary staffing changes. Document unresolved dependency on a single person and decide whether the project can tolerate it.

参考资料： Frequently asked questions: support and myUR · Release note Software version 5.5.x.x: Backup / Restore

Turn findings into purchase conditions

Use an evidence register rather than a flattering supplier score. For each requirement, record the claim, supporting document or demonstration, remaining uncertainty and person responsible for closing it. Examples include a confirmed service entitlement, an identified spare-part route, a documented recovery package and an accepted remote-support process. Missing evidence does not automatically mean a supplier is incapable, but it should not be treated as a completed check.

Before award, resolve gaps that would leave the application unusable or unsupported under your operating conditions. Put agreed handover and service deliverables into the purchasing documents. Then budget any internal capability needed to make the arrangement work, including training and access administration. Repeat the relevant check when the configuration or service plan changes. This approach gives the buyer a defensible support decision based on observable arrangements, while acknowledging that documentary due diligence cannot predict every fault or establish a guaranteed repair time.

参考资料： Frequently asked questions: support and myUR · Remote support log file generation · Release note Software version 5.5.x.x: Backup / Restore

检查清单

• Name the owner of each component and the complete application.
• Verify service entitlement, region and escalation route.
• Distinguish acknowledgement, technical response and restoration.
• Run a disclosed hypothetical support exercise.
• Trace spare-part selection, repair logistics and recommissioning.
• Agree program access, backup ownership and recovery documentation.
• Confirm remote support with the site network owner.
• Close material evidence gaps in the purchasing agreement.

常见问题