Before you buy a robot

The proposal has arrived. There is a product photograph, a specification and a price. Perhaps a demonstration video, too. Now add one more page: the first Monday after delivery. Who commissions the robot? Which task will it perform? Who gets the call when something goes wrong?

These questions clarify the investment. Hardware, task software, business-system connections and daily support complement one another. Assuming every proposal includes them all can lead parties to sign with different expectations.

This editorial framework helps operators, manufacturers and integrators discuss their responsibilities. It is not a product review or an account of an interview.

The operator: what outcome am I buying?

Define the task before specifying the device. Which objects will it handle? Where does the task begin and end? At what times of day is it needed? What quality condition defines success? Write down what is outside the task, too, so that everyone is working towards the same result.

Consider supplying a production station. Beyond payload capacity, part preparation, loading, shift intensity and the response to a stopped line affect the outcome. Include any additional preparation employees must do to make transport possible.

Understand the starting point: task duration, conditions causing delay and where errors occur. Consistent observations and records for one selected task can support comparable proposals without becoming an expensive research exercise.

The manufacturer: which robot, exactly?

Models in the same product family may have different hardware and software access. Are the hands, sensors, processor and accessories seen in the demonstration included in the standard delivery? Is an advertised function available in the current release or on a development roadmap? Naming the exact model and configuration in the proposal preserves this distinction.

If development is required, examine the scope of the software development kit, or SDK. Which sensor data are accessible? Which movements can be programmed? What are the commercial-use terms? How will support work if an update affects the application? The word “programmable” does not answer all these questions.

Discuss spare parts, maintenance and fault recovery. A part available for supply may not arrive when needed. Shipping, service locations and support hours matter especially across borders. Ask which test conditions produced advertised maximum performance.

The integrator: who connects the pieces?

An integrator addresses the technical work that connects a robot to a real business task. This may involve adapting objects and surroundings, developing task software, connecting other systems, handling errors and commissioning the application. Scope varies, so identify which elements are actually being offered.

Handovers between parties are easily overlooked. When a robot accepts a work order, which system records that event? If the network fails, does the task restart or wait? When remote assistance is needed, who must be available on site? Answering these questions keeps responsibility from falling into a gap.

The operator's role in a demonstration must also be explicit. The robot may be remotely controlled, assisted at particular steps or completing a defined task autonomously. Each may be a valuable mode of use. The proposal and acceptance test should be based on the same level of autonomy.

Read the documents alongside the use case

The European Union's Your Europe guidance explains CE marking as the manufacturer's declaration that a product complies with the applicable EU product requirements. Conformity assessment, technical documentation and a declaration of conformity are elements of that process. The assessment route depends on the rules that apply to the product. ^[1]

A mark visible in a product photograph is therefore an insufficient basis for a purchasing review. Consider the exact model, configuration, declared intended use and relevant documents together. The implications of planned integration or modification also need assessment. A product's conformity for placement on the market does not answer every question about a particular task in a particular facility.

This is why technical teams, operators and relevant specialists should examine the same use case. The workspace, interaction with people, loads, stopping behaviour and operating processes need to be considered together. The scope of that work depends on the product and location; one general checklist cannot cover every project.

Compare acceptance conditions as well as price

Purchase, rental and robotics-as-a-service can create different payment and responsibility arrangements. Suitability depends on usage, uncertainty, maintenance obligations and what the contract actually includes. Software, support and performance commitments should not be assumed to be part of a monthly fee.

An acceptance test makes comparison more concrete. Which tasks will be tested, under which conditions, with what quality requirements and limits on intervention? The robotics programme at the US National Institute of Standards and Technology, NIST, treats performance metrics and test methods in areas such as grasping, perception and motion as distinct research topics. That measurement mindset can help turn broad purchasing claims into specific questions. ^[2]

Agreement on acceptance before a contract is signed makes test results easier to interpret. Discuss how corrective work, additional development, scope changes or termination will be handled if the goal is not reached. Buying a robot also establishes the terms of a future working relationship.

Return to that first Monday. Unpacking the robot may be exciting. What allows work to begin is having the tasks, access permissions, support route and definition of success ready. A good purchasing file should explain how that Monday will unfold.