Talk to LIGC

Commercial robot evaluation

How to tell whether a commercial robot is actually a good investment.

The LIGC Robot Evaluation Standard

A robot is not evaluated as a machine. It is evaluated as a change to an operation. This is the method LIGC Robotics uses to decide whether a robot fits a real job, what it will demand once it is running, and what it will honestly cost — written out so that you can use it whether or not you ever work with us.

Start with the operation

A faster task is not the same as a better operation.

Most robot evaluations begin with the machine: what it can lift, how fast it moves, how long the battery lasts. Those questions matter, but they are the wrong place to start. The right place is the work itself — what is actually being done, how it moves from one step to the next, where people and material wait, where the handoffs are, and where the real constraint sits.

A robot that performs one step faster does not automatically improve anything. If the step it speeds up was never the bottleneck, the operation gains nothing and now carries a new machine. If it feeds work into a downstream step that cannot absorb it, it has moved the queue, not removed it. And every robot brings its own demands that are easy to leave out of a demonstration.

What a robot still needs while it is “saving labor”

  • Charging time, or battery swaps
  • Preventive maintenance
  • Repairs
  • Cleaning
  • Inspections
  • Software and firmware updates
  • Consumables and replacement parts
  • Human oversight
  • Training for the people around it
  • Recovery from faults
  • Planned downtime
  • Unplanned downtime

What a faster step can create elsewhere

  • Waiting upstream
  • Congestion downstream
  • Additional handling
  • New safety exposures
  • New maintenance work
  • Additional supervision
  • Integration problems
  • Dependence on a vendor with poor support

The comparison is never robot-hours against a wage.

It is the whole operating system before, against the whole operating system after.

That is the question this standard is built to answer: where, if anywhere, can robotics improve the operation enough to justify the change?

The LIGC Robot Evaluation Standard

Eighteen factors, in four groups.

Every candidate goes through all of them. The order runs from the work outward: first whether the robot fits the task and the operation, then whether it can work safely and physically where it needs to, then what depending on it will mean, and finally what it will cost and what the evidence is actually worth.

Operational fit

Whether the robot fits the work that exists, and whether improving that work improves the operation.

Task fit

The question to answer Can the robot reliably perform the work that actually exists — not a controlled demonstration of it?

Why it matters

A demonstration shows a task as the vendor has arranged it. Your task has variation, exceptions, interruptions and the particular way your people currently handle the awkward cases. The evaluation is of your task, in your conditions, at your frequency — and of whether automating it addresses the constraint you actually have.

What to examine

  • The exact task, step by step, as it is performed today
  • How much the task varies from one cycle to the next
  • Frequency, volume and the cycle time the operation needs
  • What the task depends on upstream, and what depends on it downstream
  • The exceptions — and how often they occur
  • Where a person will still need to step in
  • Whether this task is the constraint, or merely the most visible work

Questions to ask

  • Which parts of this task can the robot not do, and what happens to those parts?
  • What does the robot do when it encounters a case it was not set up for?
  • How much of the demonstration reflected our task, and how much was arranged for the demonstration?
  • Has this been run on a task with our variation, not just our task type?

Evidence to request

  • A trial on your actual task, with your actual items and exceptions
  • A written account of what the robot handles and what it hands back to a person
  • The setup effort required to move from the demonstration to your task

What should give you pause

  • The vendor wants to simplify or restructure your task before the robot can do it — sometimes reasonable, always a cost to count
  • Exceptions are described as rare without anyone having counted them
  • The demonstration cannot be repeated with your materials

Workflow fit

The question to answer Does improving this task improve the whole operation?

Why it matters

This is the factor most evaluations skip, and the one LIGC weighs first. Work flows from step to step. A robot changes the speed, timing and shape of one step, and every step around it feels the change. If the constraint is upstream, the robot waits. If it is downstream, the robot builds a pile. Either way the operation has paid for capacity it cannot use.

What to examine

  • The workflow from beginning to end, not just the step being automated
  • Where the bottleneck is now, and where it moves if this step changes
  • Queues: where work waits, and for how long
  • Handoffs between people, between machines, and between the two
  • How material moves, and how information about it moves
  • Upstream capacity to feed the robot, and downstream capacity to take what it produces
  • Whether the robot moves the constraint, removes it, or becomes it

Questions to ask

  • If this step ran at the robot’s pace tomorrow, what would happen at the next step?
  • What has to be true upstream for the robot to stay busy?
  • Which handoffs disappear, and which new ones appear?
  • What does the robot need from people during a shift, and when?

Evidence to request

  • A current-state walk of the workflow, with times and volumes at each step
  • An honest map of where the constraint sits today
  • A description of the future-state flow, including the new handoffs

What should give you pause

  • Nobody has walked the process end to end before the robot was proposed
  • The improvement is described only in terms of the step, never the operation
  • The steps on either side are assumed to keep up

Reliability and uptime

The question to answer What happens to the operation when the robot stops?

Why it matters

Every machine stops. The evaluation is not whether it will, but how often, for how long, what it takes to restart it, and what the operation does in the meantime. A robot that fails rarely but needs a technician to recover is a different proposition from one that faults often but restarts in a minute — and both are different from what the brochure implies.

What to examine

  • The availability the operation actually needs, in hours and shifts
  • The ways the robot can fail, and which of them stop the work
  • How a fault is cleared, and by whom
  • How often someone has to intervene in ordinary running
  • How the operating environment affects reliability
  • What reliability has been demonstrated, as opposed to claimed
  • Service history where the vendor can legitimately share it

Questions to ask

  • What are the most common faults, and how is each one cleared?
  • Which faults can our own people clear, and which need the vendor?
  • What does the operation do while the robot is down — is the manual method still possible?
  • What reliability figures can you support with evidence, and from what conditions?

Evidence to request

  • Fault and intervention logs from a comparable deployment, where shareable
  • A written recovery procedure for each common fault
  • A pilot in your environment long enough to see faults, not just successes

What should give you pause

  • Reliability is described only with a percentage and no conditions
  • Recovery from a fault always seems to require the vendor
  • There is no plan for the work while the robot is unavailable

Battery, runtime and charging

The question to answer How much of the required operating window can the robot actually cover?

Why it matters

A runtime figure is meaningful only against a workload. Carrying a full payload, climbing a ramp, running a heavy brush or driving a long route draws more power than the conditions a headline number was measured in. Charging takes the robot out of service, needs a place to happen, and — over the years — the battery itself wears. The number that matters is coverage: how much of your shift, on your work, the robot is available.

What to examine

  • Runtime on your workload, not the advertised figure
  • How runtime changes with payload, route, terrain and duty
  • How long a charge takes, and where the robot has to be to take it
  • Whether the robot charges itself, or someone has to attend to it
  • Whether batteries can be swapped, and what that involves
  • How battery capacity degrades with age and cycles
  • Coverage across the shifts you actually run
  • What the operation does during charging

Questions to ask

  • Under what conditions was the runtime figure measured?
  • What runtime should we expect on our workload, and how do you know?
  • How many units would it take to cover our full operating window?
  • What does battery replacement cost and how often is it expected?

Evidence to request

  • Runtime measured on your workload during a trial
  • The battery specification, including expected cycle life and replacement terms
  • A charging plan that fits your floor and your shifts

What should give you pause

  • The runtime figure has no stated conditions
  • Charging is treated as free time rather than as lost coverage
  • Battery replacement is missing from the cost discussion

Maintenance and serviceability

The question to answer What does keeping this robot productive require after installation?

Why it matters

The purchase is the beginning of the cost, not the end. Every robot has wear items, consumables, cleaning needs, inspections, calibration and software to keep current. Some of that your people can do; some needs a technician; some needs a technician who may be far away. Serviceability is how much of this work the design makes easy, and how much it makes expensive.

What to examine

  • The preventive maintenance schedule and what each item involves
  • Cleaning requirements, and what happens if they are skipped
  • Wear items and consumables, and their cost and availability
  • Calibration: how often, who does it, and what drifts if it is missed
  • Software and firmware updates: how they are delivered and what they interrupt
  • Which repairs are possible on site, and which are not
  • Technician availability and how far away they are
  • Remote diagnostics and support
  • Mean time to repair, where the vendor has evidence
  • Physical access to the parts that need attention
  • The internal labor all of this consumes

Questions to ask

  • What does a year of maintenance look like, item by item?
  • What can our own people be trained to do, and what must the vendor do?
  • What is the longest the robot has been out of service at a comparable site, and why?
  • Can maintenance be scheduled around our operation, or does it interrupt it?

Evidence to request

  • The maintenance manual and schedule, before purchase
  • A parts and consumables list with prices
  • The training that is available for in-house maintenance

What should give you pause

  • Maintenance is described as minimal without a schedule to show for it
  • Routine items require the vendor
  • Parts that wear are proprietary and priced later

Environment

The question to answer Was the robot designed for the environment in which it will actually work?

Why it matters

Robots are designed for a range of conditions, and a demonstration floor is usually near the middle of it. Your floor may not be. Dust, moisture, washdown, temperature, floor condition, slopes, thresholds, lighting, network coverage, tight spaces and the traffic of people and vehicles all affect whether a robot works as intended, wears as expected, and stays safe.

What to examine

  • Indoor or outdoor, and any transition between the two
  • Temperature range, including the extremes the site actually reaches
  • Dust, moisture, washdown and chemical exposure
  • Floor surface and condition, slopes, thresholds and transitions
  • Lighting, including changes across a day and reflective surfaces
  • Wireless and network conditions, where the robot depends on them
  • Confined, cluttered or difficult spaces on the route
  • Interaction with people, forklifts, vehicles and other equipment

Questions to ask

  • What are the rated operating conditions, and how close is our site to the edge of them?
  • What happens to sensors and navigation in our lighting, dust or moisture?
  • Has this robot run in an environment like ours, and can we see it?
  • What changes to our site would you expect us to make?

Evidence to request

  • The environmental specification and ratings
  • A site survey by the vendor, with findings in writing
  • A trial in the actual space, at the actual times of day

What should give you pause

  • The site survey happens after the order
  • Site modifications appear late and are described as minor
  • The demonstration environment looks nothing like yours

Safety and physical fit

Whether the robot can do the physical work, and do it without introducing risk the operation does not accept.

Safety

The question to answer Does the proposed system reduce risk without creating unacceptable new exposure?

Why it matters

Robotics is often justified on safety — taking people out of hazardous, repetitive or strenuous work. That case can be real. It is also incomplete on its own, because a robot introduces hazards of its own: moving mass, pinch points, traffic, behaviour under fault, and the interaction between a machine and people who did not expect it. The evaluation weighs the hazards removed against the hazards introduced, and then confirms the system is reviewed by people qualified to do so.

What to examine

  • The hazards present in the work today
  • Which of those hazards the robot removes or reduces, and for whom
  • The new hazards the robot introduces
  • How and where people interact with it
  • Emergency stop: where, how, and what state the robot enters
  • Guarding, detection and safe states
  • Traffic — the robot among people, forklifts and vehicles
  • Payload behaviour, including under fault
  • What the robot does when something goes wrong
  • The manufacturer’s safety documentation
  • Whether the deployment needs a qualified safety or integration review

Questions to ask

  • Which hazards does this remove, and which does it introduce?
  • What does the robot do when it detects a person — and what does it do when it fails to?
  • What is the safe state on loss of power, loss of network, or a sensor fault?
  • What does your documentation require of us, and who signs off on the deployment?

Evidence to request

  • The manufacturer’s safety documentation and any applicable standards it cites
  • A hazard review of the deployment, not just the product
  • A qualified safety or integration review where the deployment warrants one

What should give you pause

  • The safety case is only that a person is no longer doing the task
  • Behaviour under fault is not documented
  • Nobody can say who is responsible for the safety of the deployment

LIGC Robotics does not perform machine-safety certification and does not represent itself as a certification body. Where a deployment needs qualified review, we say so and help you find it.

Payload and physical capability

The question to answer Can it perform the physical task with appropriate operating margin?

Why it matters

A rated figure is a ceiling, not a working number. Loads shift, floors slope, items are heavier or larger than average, and a robot working at its limit wears faster and behaves less predictably. The evaluation asks not whether the robot can handle the task at all, but whether it can do so with room to spare, every time.

What to examine

  • Rated payload against the real range of loads, including the heaviest
  • Dimensions of the items and the spaces they move through
  • Centre of gravity and load stability, where relevant
  • Reach, lift, grip and precision the task actually requires
  • Stability on slopes, thresholds and uneven floors
  • Towing or pushing loads, where that is the task
  • Speed the operation needs against speed the robot delivers under load

Questions to ask

  • What is the working payload you recommend, as distinct from the rated one?
  • How does performance change at the top of the load range?
  • What are the largest and heaviest items in our task, and has the robot handled them?

Evidence to request

  • A trial with your heaviest, largest and most awkward items
  • The specification, with the conditions behind the ratings

What should give you pause

  • The task sits near the rated limit
  • Margin is not discussed
  • The awkward items were left out of the demonstration

Autonomy

The question to answer How much human work remains after the robot is deployed?

Why it matters

“Autonomous” describes a very wide range of products. Some run a shift with nobody watching; some need a person to set each mission, clear each exception, and step in whenever conditions change. The word is not the evaluation. What remains for people to do — and when, and how skilled they have to be — is.

What to examine

  • What autonomous actually means for this product, in specific terms
  • How much supervision ordinary running requires
  • Whether teleoperation is part of normal operation, and who provides it
  • How exceptions are handled, and by whom
  • The setup, teaching or mapping required before it can work
  • Geofencing, mission planning and how routes or tasks are changed
  • How the robot recovers, and how much recovery needs a person

Questions to ask

  • Walk us through a shift: at what points does a person have to do something?
  • What does it take to set up a new task or route, and who can do it?
  • Who handles exceptions during a night shift?

Evidence to request

  • A trial run under your supervision levels, not the vendor’s
  • A written account of the human roles in normal running

What should give you pause

  • Human intervention is described as occasional without a count
  • Remote operators are part of the product without being part of the price
  • Setup and changes require the vendor

Sensors and perception

The question to answer What must the robot perceive correctly for the task to remain safe and productive?

Why it matters

Everything a robot does depends on what it can sense, and every sensor has limits: blind spots, conditions it struggles in, drift over time, and lenses that need cleaning. The evaluation names what the robot has to perceive to do the task safely, and confirms it can, in your conditions, reliably.

What to examine

  • The sensor types and what each is for
  • Blind spots and coverage around the robot
  • Performance in your lighting, dust, moisture and reflections
  • Calibration needs and what happens when it is missed
  • What the robot can and cannot detect — including low, thin or transparent objects
  • Degradation over time and the cleaning it needs
  • How a sensor fault is indicated, and what the robot does about it

Questions to ask

  • What can this robot not see?
  • What in our environment interferes with its sensors?
  • How does it tell us when a sensor is dirty or failing?

Evidence to request

  • Detection testing in your environment, with the objects and people that are actually there
  • The cleaning and calibration schedule for the sensors

What should give you pause

  • Blind spots are not documented
  • Sensor cleaning is not in the maintenance schedule
  • Detection is demonstrated only on the vendor’s objects

Support and business risk

What depending on this robot — and on the company behind it — will mean over its working life.

Support and parts

The question to answer When something fails, how quickly can the operation recover?

Why it matters

A robot that is down is costing you. Recovery depends on things that are rarely in the demonstration: who answers the phone, when, how far away the parts are, whether they are proprietary, and whether the documentation lets your own people do anything. Support is where a good product can become a bad purchase.

What to examine

  • Technical support: hours, channels and who actually answers
  • Response commitments, and what they cover
  • Parts availability and where parts ship from
  • Whether parts should be stocked on site, and which ones
  • Consumables and their supply
  • Proprietary parts and what that means for sourcing
  • Documentation: is it good enough for your people to use?
  • Local or regional service, where it matters to your operation

Questions to ask

  • When we call at 6 a.m. on a Saturday, what happens?
  • Where do parts ship from, and how long does it take?
  • Which parts should we keep on the shelf?
  • Can our own people be trained and equipped to service it?

Evidence to request

  • The support agreement in writing, with hours and response terms
  • A recommended spares list with lead times
  • The documentation, before purchase

What should give you pause

  • Support hours do not cover your operating hours
  • Parts lead times are not stated
  • Documentation is only available after purchase

Vendor stability

The question to answer Are we comfortable depending on this company for the useful life of the robot?

Why it matters

A robot is a relationship with the company that built it: for parts, for software, for support, for the next version. That relationship should last as long as the machine does. This factor is judged on what can be supported with evidence — history, maturity, support infrastructure, documented commitments — and never on speculation about a private company’s finances.

What to examine

  • How long the company and the product have existed
  • Product maturity: how many versions, and how stable the current one is
  • Installed base, where it can be verified
  • Support infrastructure: people, locations, capacity
  • The quality of the documentation
  • Warranty capability and how it has been honoured
  • Software continuity: what happens to the robot if the software stops being maintained
  • Written commitments to parts availability
  • Business continuity signals that are publicly supportable

Questions to ask

  • How long do you commit to supplying parts and supporting the software for this model?
  • What happens to the robot if your cloud service is discontinued?
  • Can we speak to customers who have run this product for several years?

Evidence to request

  • Written parts and software support commitments
  • References that can be contacted, running the same product
  • Documentation and support material that already exist, not that are promised

What should give you pause

  • Parts and software support have no stated horizon
  • The product depends on a service the vendor could switch off
  • References cannot be contacted

Privacy, data and cybersecurity

The question to answer What information leaves the operation, who can access it, and what happens if connectivity or the vendor cloud is unavailable?

Why it matters

Modern robots carry cameras, microphones, maps of your building, and a continuous record of your operation. Much of that goes to a vendor cloud. Some of it is essential to the product; some is not. The evaluation asks what is collected, where it goes, who can reach it — including the vendor and their vendors — and what the robot still does when the connection or the cloud is gone.

What to examine

  • Cameras and microphones: what they capture and where it goes
  • Mapping data and what it reveals about the site
  • Operational data: what is recorded and how long it is kept
  • How dependent the robot is on a cloud service
  • Where data is stored and under what terms
  • Remote access: who has it, how it is controlled, and whether it is logged
  • Account and permission management
  • APIs and integrations with your own systems
  • How software updates are delivered and verified
  • What network access the robot needs, and what it should not have
  • Vendor access to your systems and data
  • Data ownership, where the contract states it

Questions to ask

  • What does the robot do if it loses connectivity? If your cloud is down?
  • Who at your company can see our camera feeds and maps?
  • What data do we own, and can we have it deleted?
  • How are updates signed and delivered, and can we schedule them?

Evidence to request

  • A data flow description: what is collected, where it goes, who can access it
  • The contract terms on data ownership and retention
  • Documented behaviour when offline

What should give you pause

  • Nobody can say what happens when the cloud is unavailable
  • Remote vendor access is always on and not logged
  • Data ownership is not in the contract

Warranty, SLA and commercial terms

The question to answer What happens contractually when the robot does not perform as expected?

Why it matters

Every promise made in the sales process either survives into the contract or it does not. Warranty terms, response commitments, replacement terms, uptime commitments where they exist, and the division of responsibilities between you and the vendor decide what you can actually rely on once the money has moved.

What to examine

  • Warranty period, what it covers, and what it excludes
  • Response commitments — and what counts as a response
  • Replacement terms for a unit that cannot be repaired
  • Uptime commitments, if the vendor offers any, and what they are worth
  • What the vendor is responsible for, and what you are
  • Software and subscription requirements, and what stops working if they lapse
  • Cancellation and renewal terms, including for RaaS and lease arrangements

Questions to ask

  • Which of the things we have discussed today are in the contract?
  • What voids the warranty?
  • If the robot is not performing, what are our remedies, in order?
  • What happens to the robot and our data if we end the agreement?

Evidence to request

  • The full contract, warranty and any service agreement, read before commitment
  • Written answers to the questions above

What should give you pause

  • Promises made in the room are absent from the paper
  • Remedies are vague or end at “best effort”
  • A subscription lapse turns the robot into a fixture

Economics and evidence

What the capability will really cost, what it will really return, and how much the claims can be trusted.

Total cost of ownership

The question to answer What will this capability actually cost to own and operate over the decision period?

Why it matters

The purchase price is one line. A realistic cost of ownership counts every line, including the ones that arrive after the robot does: charging infrastructure, software, training, consumables, batteries, service, the internal labor to run and maintain it, downtime, and what replacing it will cost at the end. This is a schedule of factors to be priced for your operation, not a formula with a number at the bottom.

What to examine

  • Acquisition: purchase, lease, rental or robot-as-a-service — and the terms of each
  • Freight, installation and integration
  • Accessories and attachments
  • Charging infrastructure and any electrical work
  • Software licences and subscriptions
  • Connectivity
  • Training, initial and ongoing
  • Maintenance, planned and unplanned
  • Consumables and replacement parts
  • Batteries over the life of the robot
  • Service and support agreements
  • Insurance, where it applies
  • Downtime — the cost of the robot not working
  • Internal labor to supervise, maintain and manage it
  • End of life and replacement

Questions to ask

  • What will we pay in year one, and what will we pay in year three?
  • What is not included in the quoted price?
  • What do purchase, lease and RaaS each cost over the period we are deciding on?

Evidence to request

  • A written cost breakdown across the decision period, not just a quote
  • Prices for consumables, batteries and the parts most likely to need replacing

What should give you pause

  • The quote is a single number
  • Costs after installation are described as small without being listed
  • The comparison between acquisition options has not been done

Operational ROI and payback

The question to answer Does the credible benefit to the operation exceed the complete cost and burden of achieving it?

Why it matters

A robot’s advertised hourly productivity is not the operation’s realised benefit. The benefit is whatever changes in the whole operating system: hours genuinely avoided or reassigned, overtime reduced, throughput gained, waiting removed, exposure taken off people, rework avoided, capacity or operating hours added. The cost is the full cost of ownership plus the operational burden the robot brings. LIGC does not publish savings percentages or payback benchmarks, because those figures are only ever true for a specific operation once it has been examined.

What to examine

  • Labor hours actually avoided or reassigned — and what the reassigned time is worth
  • Overtime reduction
  • Throughput and uptime gained
  • Waiting and process delays removed
  • Repetitive or strenuous work reduced
  • Hazardous exposure reduced
  • Quality and rework improvement
  • Capacity gained, and operating hours extended
  • Set against the complete cost of ownership and the operational burden

Questions to ask

  • Which of these benefits can we measure in our own operation today, so we can measure the change?
  • What has to go right for the payback case to hold, and what breaks it?
  • What happens to the case if the robot runs at the coverage we measured in the trial, not the coverage in the brochure?

Evidence to request

  • Your own current-state baseline: hours, volumes, overtime, delays, incidents
  • Trial results on your work, used in place of vendor figures wherever they exist
  • A payback scenario that names its assumptions and shows what changes when they change

What should give you pause

  • The payback case starts from the robot’s productivity rather than from your operation
  • Benefits are counted in gross hours without asking what the hours become
  • A single scenario is presented as a forecast

The comparison LIGC uses

Realised value is the credible operational benefit, less the complete cost and operational burden required to achieve it — judged across the whole operating system, before and after.

A working principle for the evaluation, not an accounting formula. The inputs are specific to each operation and are established during an assessment, never assumed.

Evidence quality

The question to answer What evidence supports the claim we are relying on?

Why it matters

Every factor above rests on claims, and claims come in grades. A specification is what the manufacturer says the product can do. A demonstration is what it did once, in conditions someone chose. A pilot is what it did in a controlled setting. A reference is what someone else says it did for them. Independent evidence is what someone with no stake observed. And performance in your own environment is the only evidence that is actually about your decision. The evaluation records which grade each claim rests on, and weights it accordingly.

What to examine

  • Which claims rest on a specification alone
  • Which rest on a demonstration, and who arranged the conditions
  • Which rest on a controlled pilot, and how controlled it was
  • Which rest on customer references, and whether they can be contacted
  • Which rest on independent evidence
  • Which have been observed in your own environment

Questions to ask

  • For each thing we are relying on: how do you know that?
  • What has not yet been demonstrated on our work?
  • What would it take to move this claim from specification to observation?

Evidence to request

  • A record of every material claim and its grade
  • A trial designed to upgrade the claims that matter most

What should give you pause

  • The decision rests mainly on specifications and a demonstration
  • References are named but not contactable
  • A trial is offered only after the order

What evidence to ask for

Six grades of evidence, from weakest to strongest.

The same claim can rest on very different foundations. Before relying on any figure, know which of these it is.

  1. Specification

    What the manufacturer states the product can do. The starting point, and never the ending point.

  2. Demonstration

    What the product did once, in conditions someone else chose. Useful for ruling things out; weak for ruling them in.

  3. Controlled pilot

    What the product did in a controlled setting over a period. Better — and still not your floor, your items or your shift.

  4. Customer reference

    What another operator reports. Valuable when you can speak to them directly and their operation resembles yours.

  5. Independent evidence

    What someone with no stake in the sale observed. Rare, and worth seeking.

  6. Your own environment

    What the product did on your work, in your conditions, at your pace. The only evidence that is actually about your decision.

A good evaluation does not refuse weaker evidence. It knows which grade it is holding, weights it honestly, and works to upgrade the claims the decision depends on.

The four outcomes

An evaluation can honestly end in one of four places.

LIGC does not recommend robotics because someone asked about robotics. The standard exists to reach the right answer, and the right answer is sometimes no.

  1. Proceed

    The robot fits the task and the operation, the risks are understood, the economics hold on credible evidence, and the support is there. Move to sourcing and deployment.

  2. Pilot first

    The case is promising but rests on claims that have not been observed in your environment. Run a bounded trial designed to upgrade exactly those claims before committing.

  3. Reconsider, or evaluate another approach

    This robot, or this task, is not the right fit — but the problem is real. Look at a different category, a different task, or a process change that gets most of the benefit without the machine.

  4. Do not automate this task right now

    The constraint is elsewhere, the evidence is not there, the burden outweighs the benefit, or the operation is not ready. Delivered as plainly as any other outcome.

A recommendation not to automate is a valid outcome.

Public framework, paid assessment

This page tells you what to evaluate. The assessment does the evaluating.

Everything above is public on purpose. A business considering robotics should be able to hold vendors to a proper standard whether or not it ever works with LIGC, and the standard is only credible if it is written down where anyone can read it.

What the Robotics Opportunity Assessment adds is the work of applying it: walking your operation from beginning to end, establishing the current-state baseline, researching the categories and candidates that fit your task, comparing them against these factors on evidence rather than brochures, building payback scenarios from your own numbers, and putting a written recommendation in front of you — including when the recommendation is not to proceed.

Ask about an assessment How LIGC approaches robotics

Next step

Tell us about the operation.

Not which robot you have in mind — the work, as it runs today. That is where every good evaluation starts, and it costs nothing to describe it.

Talk to LIGC

El Paso, Texas · United States