Table of Contents
- The Most Urgent Process May Not Be the Best First Process
- Simplicity Has Real Value in a First Robot Project
- Turn the Chosen Process Into a Clear Specification
- Describe the Part as It Really Arrives
- Define the Quality the Process Really Needs
- State the Available Space—and Where You Can Be Flexible
- Do Not Prescribe Technology Without Describing the Reason
- A Robot Can Perform Many Tasks. The Project Does Not Need All of Them.
- A Short RFQ Produces Quotes for Different Projects
- The Specification Should Start the Engineering Conversation
In this article:
- Why the most urgent process may not be the best place for your first robot.
- Which information about the part, quality target and factory layout belongs in the specification.
- Which technical decisions are better developed with the integrator.
- Why a short RFQ can return several prices for several different projects.
Imagine that you have decided to make your first robot investment and set aside a budget of €100,000.
There may be no shortage of possible applications in your factory. A brass bar can be cut, heated, forged, deburred, machined, assembled, inspected and packed. A robot could contribute at almost every stage.
The first question is therefore not simply which robot to buy.
Where should the first robot go?
The manufacturer has an essential role in answering that question. You know the company’s strategy, the behaviour of the production process, the machines and the parts better than anyone outside the factory.
The integrator brings experience from other robotic applications. The strongest project begins when those two kinds of knowledge meet.
The Most Urgent Process May Not Be the Best First Process
An interruption or an obvious inefficiency naturally attracts attention. It creates pressure, so it can quickly become the first candidate for automation.
Urgency, however, is only one part of the decision.
The process creating the most immediate frustration may also be difficult to automate. It may require extensive preparation, or the installation and testing period may disturb production more than expected. Another operation that appears to run reasonably well may be carrying less visible costs and offer a clearer first result.
I would therefore compare potential applications through both a short-term and a long-term view.
What to examine | A useful question |
|---|---|
Production impact | Which operation limits output or creates the most costly interruption? |
Technical complexity | Can the first version of the process be automated with manageable risk? |
Preparation required | Which fixtures, machines or upstream processes must change first? |
Strategic value | Does the project support faster delivery, consistent quality or greater product flexibility? |
Learning value | Will this application give the team a repeatable model for later investments? |
This comparison helps prevent an urgent problem from automatically becoming the first robot project.

Figure 45. Complexity-benefits quadrant.
Source: Samuel Bouchard, Lean Robotics: A Guide to Making Robots Work in Your Factory (2017), fig. 45.
Simplicity Has Real Value in a First Robot Project
For a team meeting robotic automation for the first time, a simpler application can be a deliberate strategic choice.
The team has to learn the robot and the production system around it. Operators become familiar with daily use and recovery. Maintenance begins to understand the equipment. Engineering sees which preparations helped and which details should be handled differently next time.
A project with controlled technical risk makes those lessons easier to absorb. It also allows the manufacturer to observe the investment’s effect on ROI, OEE and daily production sooner.
The first cell then becomes more than one automation project. It becomes a working reference for the second one.
At Robsen, we work with manufacturers at very different stages of this journey: companies preparing for their first robot, companies adding a second after many years and companies working toward their hundredth installation. That range of experience helps us discuss not only whether one application can be automated, but also whether it is a sensible step in the manufacturer’s wider automation plan.

Figure 46. The typical change in opinions about a robotic cell during a deployment project.
Source: Samuel Bouchard, Lean Robotics: A Guide to Making Robots Work in Your Factory (2017), fig. 46.
Turn the Chosen Process Into a Clear Specification
Once the process has been selected, the next task is to prepare the specification behind the RFQ.
I do not see a good specification as a document that must dictate every component and technical decision. Its main purpose is to make the production requirement, the known constraints and the expected result clear.
For a robot-cell project, the following subjects usually deserve particular attention:
The specification should describe | Why it matters |
|---|---|
Parts and product variants | They affect robot payload, gripper design, part presentation and changeovers |
Part geometry and process variation | Flash, distortion and surface variation can change how the robot locates and grips the part |
Required production sequence | It defines what happens before and after the robot’s operation |
Quality expectation | It determines which inspections and acceptance limits are actually needed |
Available layout and access | It affects reach, guarding, maintenance access and material flow |
Current machine and fixture conditions | They reveal which interfaces or modifications may be required |
Target KPIs and acceptance criteria | They give both sides a measurable definition of success |
The objective is not to eliminate every question before speaking with an integrator. It is to make the important facts and assumptions visible enough for the engineering conversation to begin in the right place.
Describe the Part as It Really Arrives
A nominal weight and a drawing rarely tell the complete handling story.
How many different parts will the cell run? Does the geometry vary? Is there flash, distortion or another feature that changes from one workpiece to the next?
Variation from forging or casting can create very different problems later in machining, assembly, quality control or sanding. If those variations are known, include them in the specification and show representative samples where possible.
An integrator who sees only the ideal part may design for a production condition that does not actually exist.
Define the Quality the Process Really Needs
Quality requirements should be clear, but they should also reflect what the process genuinely needs.
We once worked on a sanding and polishing application in which the expected surface quality had not been defined precisely. The uncertainty led to revisions and lost time. Yet the part went through a surface-coating process afterwards, and that later operation removed the small surface imperfections being discussed.
The lesson was not to lower the quality standard. It was to define it in relation to the complete production route.
What will happen to the part next? Which defects will remain visible or functional? Which tolerances determine whether the next operation can begin?
Those answers give the integrator a far more useful target than a general request for the “best possible quality.”
State the Available Space—and Where You Can Be Flexible
Every manufacturer would prefer the cell to use as little floor space as possible. Sometimes, however, a little more room creates a significant advantage in robot reach, material supply, changeover or maintenance access.
You may not be able to identify that advantage while writing the RFQ.
For this reason, state the area available for the project and explain where there is flexibility. If a machine can move, say so. If an aisle, service zone or material route cannot change, make that equally clear.
This is also one of the points at which the integrator’s experience should influence the final concept. A strong specification defines the constraint without preventing a better solution from being proposed.
Do Not Prescribe Technology Without Describing the Reason
Some technical decisions naturally fall outside the manufacturer’s everyday area of expertise. Detailed robot selection, machinery safety and application risk assessment are examples.
That is normal. They are part of the integrator’s responsibility.
We often receive requests that specify a collaborative robot. A cobot can be valuable in the right application, but the robot alone does not make the complete operation collaborative or safe. The application, tooling, workpiece, speed, forces and possible contact conditions still have to be assessed.
If the process requires a guarded cell in any case, the reason for choosing a cobot may disappear. The result can be a more expensive robot working more slowly without providing the intended operational advantage.
Instead of writing only “use a cobot,” explain why operator access or collaboration matters. That gives the integrator room to evaluate the complete application and recommend a suitable solution.
This is one reason choosing an integrator with relevant application experience matters before the project begins.
A Robot Can Perform Many Tasks. The Project Does Not Need All of Them.
A single robot may load a CNC, deburr the part, wash it, take measurements, inspect the surface, run a leak test, apply a serial number and place the finished product into its packaging.
The technical possibility is impressive. It does not automatically make the complete sequence a good first project.
Every additional function adds engineering, interfaces, testing and possible failure modes. It can also increase cycle time and make acceptance more difficult.
Return to the objective of the investment. Which task creates the value you are trying to capture? Which KPI will show that the project succeeded? Which functions are necessary now, and which can remain part of a later roadmap?
Realistic KPIs help prevent a useful robot project from becoming a collection of every automation idea discussed during the RFQ.
A Short RFQ Produces Quotes for Different Projects
The specification is what makes quotations comparable.
Suppose several integrators receive an RFQ containing only this information:
“Feed a 6 kg part into a CNC machine. Machining time: 3 minutes.”
One integrator may assume a simple cylindrical billet and one part number. Another may imagine a forged component with several possible resting faces. A third may include the equipment needed for ten product variants. Each company will interpret the unknown risks differently and price a different solution.
What the RFQ does not say | Possible interpretations | What may change in the proposal |
|---|---|---|
Part geometry | A billet, a cylindrical part, a casting or a forging with many faces | Gripper, feeder, orientation method and vision requirement |
Product range | One stable part or ten different parts | Changeover concept, recipes, tooling and fixture scope |
Part condition | Consistent geometry or variable flash and distortion | Sensing, compliance, gripping method and development risk |
Required result | Basic loading or loading plus inspection and traceability | Equipment list, software, cycle time and acceptance tests |
All the quotations may look like responses to the same request. Technically, they may describe four different projects.
The Specification Should Start the Engineering Conversation
A useful RFQ does not need to contain every answer. It needs to describe the production problem well enough for the remaining questions to be asked intelligently.
Before sending it, I would check whether another integrator could understand:
- which parts will run and how they vary;
- what the robot must do within the complete production sequence;
- which quality level and production result will define success;
- what space, machines and fixtures already exist;
- which constraints are fixed and where alternatives are welcome.
When that information is clear, differences between quotations become easier to discuss. One proposal may still cost more than another, but the reasons are visible in the concept, the scope and the expected production result.
Once the order is placed, the focus changes. The question is no longer only what the integrator will build. It is also what the manufacturer must prepare before the cell reaches the factory.
Continue with: What Must Be Ready Before the Robot Cell Arrives?

