Robotics has become easier to notice and harder to dismiss. Mobile robots move stock through warehouses. Automated cleaning machines work across large commercial floors. Robotic arms handle repetitive movement with a consistency that is difficult to sustain manually. The technology is impressive, but that is not the best reason to buy it.
A robot is a feature. The process is the problem.
That distinction matters because automation projects can go wrong long before a machine is installed. A business sees labour pressure, slow fulfilment or inconsistent handling and jumps directly to equipment. The result may be technically capable but operationally awkward. Staff work around it. Layout constraints limit it. Software does not pass the right information to it. A bottleneck simply moves twenty metres down the line.
QBF stands for Questions Before Features. It is a useful rule for websites, digital systems and physical automation alike. Before asking which robot you need, ask what work should change, why it should change and what a better result would look like.
Start with the bottleneck, not the machine
The strongest automation opportunities are usually boring.
A pallet is moved along the same route hundreds of times. Staff spend part of every shift walking between fixed points. A cleaning task absorbs hours at predictable times. Goods are repeatedly transferred between storage and workstations. These are not futuristic problems. They are repetitive, measurable pieces of work.
Begin by mapping one process from start to finish. Record where work waits, where people travel, where errors occur and where manual effort adds little value. If the same task creates delays every day, quantify it before discussing hardware.
This is also the logic behind Enterprise Ireland’s Digital Process Innovation support, which is centred on introducing digital technologies and new ways of working to improve operational effectiveness. The order matters: understand the operational change first, then select the technology that can support it.
Do not limit the baseline to labour hours. Look at throughput, handling errors, damaged stock, missed scans, queue time, floor congestion, downtime and the number of times a process requires human intervention. A task can be expensive without consuming many hours if it regularly interrupts higher-value work.
A useful automation brief can fit on one page. What happens now? What is going wrong? How often? What does the problem cost or constrain? What result would justify changing the process?
That is enough to stop a technology conversation from becoming a catalogue exercise.
Separate a process problem from a technology problem
Some businesses do not need a robot. They need a cleaner workflow.
If stock locations are unreliable, automating movement can make bad inventory data travel faster. If picking instructions change constantly because the underlying system is poorly configured, a new machine will inherit the confusion. If people cross the same route because storage has been placed badly, layout may be the first problem to solve.
This is where physical and digital design meet. A robotic system depends on more than motors, sensors and navigation. It needs clear instructions, dependable data, sensible routes, defined hand-off points and people who know what happens when the normal flow breaks.
A good discovery phase should challenge the assumption that automation is automatically the answer. Could the process be simplified first? Can a step be removed? Is the task sufficiently repeatable? Does volume justify automation? What happens during peaks, exceptions and failures?
The goal is not to talk yourself out of robotics. It is to make sure the robot is solving the expensive part of the problem rather than the visible part.
Match the robot to a job you can describe clearly
Once the process is understood, the available technology becomes much easier to evaluate.
Mobile robots can be relevant where materials need to move repeatedly through a defined environment. Forklift-style mobile robots can address transport and material-handling workflows. Other service robots may be used for cleaning or delivery tasks in suitable commercial settings. The important point is that each category is designed around a different kind of work.
MJ Flood Robotics, for example, presents a range of advanced robotic solutions for your business, including latent mobile robots and forklift mobile robots intended to automate repeatable movement and material-handling tasks. The useful question is not whether those systems are advanced. It is whether the job you have mapped matches what the system is designed to do.
Ask suppliers to demonstrate the actual workflow rather than a generic feature set. How does the robot receive a task? What happens when an aisle is blocked? How does it navigate around people or temporary obstacles? Where does it charge? What information does it exchange with your warehouse, building or business systems? How are exceptions handled?
The answers should connect directly to the baseline you created earlier. If your problem is delayed internal transport, you need evidence about transport flow. If your problem is a repetitive cleaning task, you need to understand coverage, operating conditions and supervision. Features matter only when they change the outcome you care about.
Design the space and the data flow around automation
Robotics is physical software. It operates in a real building, with doors, thresholds, people, shelving, cables, lifts, cleaning schedules and the occasional trolley left exactly where nobody planned for it.
That makes the environment part of the system.
Before installation, walk the proposed route. Measure clearances. Check floor transitions, charging locations, traffic conflicts and access to workstations. Think about deliveries and seasonal layout changes. If a robot depends on a route that is routinely blocked at 10:30 every morning, the issue is not navigation technology. It is process design.
The same long-term thinking applies when designing commercial interiors that need to remain useful as a business changes. In our article on commercial interiors that age well, the argument is simple: fixed decisions should be reserved for things worth fixing. Automation adds another reason to keep circulation, services and access adaptable.
Digital integration deserves the same attention. Decide which system owns the task, what data must be accurate and what happens if connectivity is interrupted. Avoid building a workflow that relies on five manual fixes between two automated steps. That is automation theatre, not operational improvement.
A robot should sit inside the operating model, not beside it.
Treat safety and people as design inputs
Robotics changes the relationship between people and space. That means safety cannot be left to the commissioning checklist.
The National Standards Authority of Ireland maintains a dedicated committee for robots, cobots and robotics and highlights standards such as the ISO 10218 series for industrial robot safety. The practical lesson for a business buyer is straightforward: safety requirements depend on the application, environment, integration and how people interact with the system.
That is why risk assessment belongs in the project from the beginning. Think about pedestrian routes, loading areas, stopping behaviour, maintenance access, emergency procedures and the work people perform around the machine. A technically safe robot can still be placed into a badly designed workflow.
People also need to understand why the change is being made.
If staff hear “automation” only after equipment has been ordered, resistance is hardly surprising. Explain the problem the project is intended to solve. Involve the people who do the work now, because they usually know where exceptions happen and where the process breaks under pressure.
Automation should remove low-value repetition where that makes commercial sense. It should also make responsibility clearer. Someone still needs to own the process, review performance, manage exceptions and decide when the system needs to change.
A robot does not remove management. It makes good management more visible.
Pilot against operational measures, not enthusiasm
A demonstration can be convincing. A pilot is more useful.
Choose a contained workflow and define success before the test begins. The measures will depend on the job, but they might include cycle time, trips completed, handling errors, interventions, downtime, distance travelled, labour reassigned or throughput during a peak period.
Keep the measures close to the original problem. If the business case was built around internal transport delays, do not declare success because staff like the interface. If the aim was to reduce repetitive manual movement, track how much of that movement actually disappears from the process.
Also record the awkward moments. Where does the system hesitate? Which exceptions still require a person? What changes when stock volume rises? Does the surrounding process need to be redesigned before scale-up?
This is where a small pilot earns its keep. It turns assumptions into evidence while the cost of changing direction is still relatively low.
For Irish SMEs that want help evaluating advanced digital technology before a larger commitment, Enterprise Ireland points businesses towards European Digital Innovation Hubs, which provide support around digital and AI adoption. That kind of external testing and capability support can be useful when the technology is unfamiliar internally.
Build for the second year, not the launch day
The most dangerous time to judge an automation project is immediately after commissioning.
Everything is new. Attention is high. The supplier is close at hand. The process has been cleaned up for launch. The real test comes later, when volumes change, staff rotate, layouts move and the system becomes ordinary infrastructure.
Plan ownership before that happens.
Who monitors performance? Who can change workflows? Who responds to faults? What maintenance is required? How are software updates handled? Can the system expand if routes, shelves or workstations change? What data can you export if you want to analyse performance independently?
Scalability is not the same as buying more robots. A scalable process can absorb change without creating a fresh integration project every time the business grows.
That may mean standardising hand-off points, cleaning up master data, improving Wi-Fi coverage, reserving charging capacity or redesigning a route before adding another machine. None of those decisions is glamorous. All of them can determine whether the automation remains useful.
A good system gets less interesting over time. It simply becomes part of how the business works.
The useful question is not “which robot?”
Robotics is becoming accessible to more Irish businesses, but accessibility does not remove the need for judgement.
Start with the work. Map the bottleneck. Test whether the problem is physical, digital or organisational. Define the result you want. Only then compare technology.
That sequence sounds slower than shopping for features. In practice, it is usually faster because it removes weak options early and gives suppliers a clearer brief.
Questions before features is not anti-technology. It is the opposite. It is how you give technology a fair chance to solve something that matters.
When the process is clear, the robot has a job. When the measures are clear, the investment can be judged. When the people, space and systems are designed around it, automation stops being a demonstration and starts becoming infrastructure.