Running a Cobot Pilot in a Manual Production Line

A plant manager at a mid-size automotive supplier described a cobot pilot she'd run the previous year this way: "The robot worked great. It ran for eight months. At the end of the year, Finance asked us to justify the next three units, and we had no data. We knew the robot was running, but we hadn't measured anything against baseline, so we couldn't prove it was doing what we said it would. The whole program got put on hold."

The robot worked. The pilot failed. This is the dominant pattern in industrial cobot deployments, and it's entirely avoidable with a structured approach that prioritizes measurement over installation.

This article is a 90-day playbook for running a cobot pilot in a manual production line — one that produces a defensible data-backed decision, not just a robot that happens to be running.

Before day one: the three decisions that determine everything

Decision 1: The right station

The best cobot pilot station has these four characteristics:

Fixed-cycle, measurable output. The station produces a countable output per shift. Parts inspected, assemblies completed, machine cycles tended. If the output is diffuse or hard to count, you can't establish a baseline or measure the improvement.

Single operator, single task. A station where one operator does one primary task for most of their shift. Avoid stations where the operator switches between tasks based on conditions — the baseline will be impossible to establish cleanly.

Human operator not required during robot operation. You want a station where the cobot handles the primary task and the operator can be reassigned or redeployed to higher-value work, not one where the robot does half the task and the operator stands adjacent doing the other half. (Those hybrid cells come later, after you've learned how to deploy.)

Manageable gate time. The station's equipment cycle time allows for a robot sequence that's achievable within PFL speed constraints. If the machine cycles every 3 seconds and the robot sequence requires 4 seconds, you've identified an incompatible application before you've spent anything.

Decision 2: The baseline metrics

Establish three KPIs that will be measured for 10 working days before the robot arrives. Not before the integration starts — before the robot physically arrives at your facility. Two weeks of clean baseline data is non-negotiable. Without it, you have no honest comparison at day 90.

Standard KPIs for common pilot applications:

Capture your three KPIs daily for 10 days. Calculate the mean and standard deviation. Record the conditions (shift, operator, machine state). That document is your baseline. File it and protect it.

Decision 3: The named owner

One person is accountable for the pilot. Not the automation engineer and the plant manager jointly — one person. Their name appears in the project charter. Their responsibilities:

• Weekly stand-up with the cobot vendor or integrator
• Daily collection of the three KPIs during the pilot
• Logging all incidents (stops, faults, near-misses)
• Running the operator feedback surveys at weeks 4 and 8
• Producing the day 90 recommendation document

Without a named owner, the unglamorous mid-pilot work doesn't happen, and you arrive at day 90 with no data to make a decision.

Phase 1: Installation and commissioning (days 1–14)

What actually takes this long

A cobot installation in a manual production cell is faster than a traditional arm installation — no fencing to build, no interlock engineering. But it still takes 5–10 business days of vendor/integrator time for a straightforward deployment:

• Day 1–2: Physical installation, cable routing, controller placement
• Day 2–4: Risk assessment documentation, safety configuration, speed-limit setup
• Day 3–6: EOAT integration, program teaching, basic path commissioning
• Day 5–8: Integration with upstream/downstream equipment (conveyors, fixtures, machine triggers)
• Day 7–10: FAT (factory acceptance testing) — running the full production sequence at speed and validating that cycle time, output quality, and fault behavior meet spec
• Day 10–14: Staff orientation sessions (see below)

Don't run production on a cobot that hasn't completed FAT. FAT is the test that validates the robot performs the task at production speed, with production parts, through a full shift's worth of cycles without unplanned stops. It is the integrator's responsibility to run and document FAT. If your integrator delivers a commissioned system without a FAT report, ask for one before accepting delivery.

Staff orientation: mandatory, before production starts

Schedule a 45-minute hands-on session for every operator and supervisor who will work in or adjacent to the cobot cell. This is not an announcement. It's a session where each person:

1. Hears the specific explanation of what the robot does and doesn't do in this cell
2. Sees the force-limiting behavior demonstrated (the integrator should demonstrate a stop at low speed against resistance)
3. Understands the emergency stop location and procedure
4. Has their questions answered

Be specific. "This robot loads the CNC. You load the input magazine and unload the output bin. When the safety stop activates, you'll hear a tone and see the yellow light — here's what you do." Vague reassurance ("it's safe, don't worry") doesn't reduce threat perception. Specific role definition does.

Log attendance. If someone wasn't present for orientation, they don't work adjacent to the cobot until they've completed a make-up session.

Phase 2: Early production (days 15–45)

What to measure and how often

During the first 30 days of production operation, collect your three KPIs every shift, not every day. Early-period variability is high — the robot will have more faults, more interventions, and more schedule variance than steady-state. Daily averaging hides the outlier days that tell you where problems are.

Log every fault event: timestamp, fault code, what triggered it, how long before production resumed, what the operator did. This log is the most valuable single artifact from the pilot. At the end of 30 days, you should be able to answer:

• What are the top 3 fault codes by frequency?
• What is the average time to production recovery per fault?
• Is fault frequency decreasing over time (learning curve) or flat (systematic problem)?

The operator behavior problem

Manual-line operators are reliable sources of ground-truth information about how the cobot is actually performing. They are also, in some cases, sources of behavioral drift that erodes the pilot without showing up in incident logs.

Behavioral drift looks like: operators who "help" the robot by pre-positioning parts in a way that changes the cycle or masks a fixturing problem. Operators who take over the task during the cobot's work cycle rather than allowing the robot to complete the sequence. Supervisors who route production to a manual workaround during maintenance windows that then become default workflow.

None of this is malicious. It's rational adaptation to a new system. But it means your KPI data stops reflecting robot performance and starts reflecting a hybrid human-robot workflow that wasn't the design intention.

Run anonymous operator surveys at weeks 4 and 8. Ask directly: "Do you find yourself doing tasks that the robot is supposed to handle?" "What would need to change for the robot to work better here?" The answers will surface the behavioral drift that the KPI data won't show.

The fault resolution SLA

Your vendor or integrator should have a written SLA for fault resolution. What does "within 4 hours for a production-stopping fault" mean in practice? Does it mean a phone call, remote access, or a technician on-site? For a pilot, remote support is usually sufficient during early production — most faults in the first 30 days are program-related (path errors, fixture tolerance mismatch, timing issues) and resolvable via software. Know your SLA before you need it.

Phase 3: Steady-state assessment (days 46–90)

The comparison document

At day 60, compile the first draft of the comparison:

If the trend from days 15–45 is positive, project to day 90 assuming the improvement trend continues. If the trend is flat or negative, investigate the cause before day 90 — this is the inflection point where programs get corrected, fixtures get adjusted, or the application design gets revised.

Day 60 is also when you compare the actual labor displacement against the TCO model. If the pilot deployed one robot to handle what one operator was doing, and that operator was redeployed to higher-value work: good. If the operator is still in the cell doing the tasks the robot was supposed to handle, something went wrong in the integration and day 60 is when to fix it.

The kill criteria (written before day one)

In the project charter, you defined what outcome at day 90 triggers a "kill" recommendation — not an extension request, a kill. Something like:

"If primary KPI improvement is less than 15% compared to baseline, or if the robot's mean time between faults is under 2 hours at day 90, the program does not proceed to Phase 2."

The kill criteria must be specific, quantitative, and agreed upon before the robot arrives. Their purpose is to protect you from the natural human tendency to keep extending a marginal pilot — "it's almost there," "the next software update will fix it," "we just need another month." Vendors have strong economic incentives to encourage extension over termination.

A negative result at day 90 against written criteria is a good outcome. It means you ran an honest test and learned something definitive for $70,000–$100,000, not $500,000.

The day 90 recommendation

The named owner produces a written recommendation covering:

1. KPI outcomes vs baseline — table format, quantitative, no narrative substitutes
2. Fault log summary — top faults, resolution time, trend
3. Operator feedback summary — aggregated (anonymous) results from both surveys
4. TCO actual vs projected — capital cost, labor saving to date, projected payback
5. Recommendation: Scale / Extend (with specific conditions) / Kill

The recommendation goes to GM and Finance — the same people who signed off on the KPIs in the project charter.

Scale means: proceed to 3–5 additional identical cells on the same program basis. The first cell proved the model; replication cost drops to 60–70% of first-cell cost.

Extend is only valid if a specific, correctable problem has been identified — a firmware bug with a committed fix date, a fixture tolerance issue being resolved by a toolmaker, a EOAT redesign underway. Extend is not valid as a response to "the data is ambiguous."

Kill means: this application, this vendor, this timing — not right now. Document the specific reasons, file them against future evaluation criteria, and move on. The capital is recovered faster by stopping than by extending.

For the vendor red flags that signal a problematic pilot before it starts, see the next article in this series.