---
title: "How to run a four-week monitoring pilot"
description: "A monitoring pilot should prove three things before a plant-wide rollout: data your supervisor trusts, stops with reasons, and one decision made from the data."
category: "Machines and connectivity"
author: "Ulises Carrasco"
published: "2026-10-30"
updated: "2026-11-02"
source_url: "https://www.iotflows.com/blog/monitoring-pilot/"
---
> Question: What should a pilot prove before rolling out across the plant?

## Key takeaways

- A monitoring pilot should prove three things: the data matches the floor, stops carry reasons, and someone acts on it.
- Write the pass marks down and get them signed before the first sensor goes on, so the result is a fact, not a feeling.
- Pick at least 10 machines one supervisor runs, a line or a row of CNC machines, and include the bottleneck.
- Weeks 1 and 2 prove the data is right; weeks 3 and 4 prove operators classify stops and the plant acts.
- Judge a pilot on its pass marks rather than an uptime gain, because the before number is usually an estimate.

A monitoring pilot should prove three things before you roll out across the plant: the data agrees with what your supervisor saw on the floor, operators put a reason on the stops, and someone makes one decision from the numbers. Run it on at least 10 machines in one area of the shop for four weeks, and write the pass marks down before the first sensor goes on.

This guide is for plant managers and owners about to approve a pilot. It covers which machines to pick, what each week should prove, who owns what, and how to make the go or no-go call.

## What should a monitoring pilot prove?

> **Definition.** **Monitoring pilot** is a time-boxed trial of machine monitoring on one group of machines, run against pass marks agreed before it starts, to decide whether the method works on that plant's machines and people before it spreads to the rest of the floor.

A pilot is not a demo of features. It answers one question for the person who signs the rollout: will this plant trust the numbers and act on them? Three proofs answer it, and each one fails a different way.

- **The data matches the floor.** If the supervisor can name a stop the record missed, nobody will act on the record.
- **Stops carry reasons.** Stopped minutes with no reason show how much time was lost but never why.
- **Someone acts.** A pilot that ends with accurate, classified data and no decision has proved the sensors, not the plant.

Turn each proof into a pass mark with a number, and get the plant manager to sign it before week 1. Without it, the end of week 4 becomes a debate about impressions.

| Criterion | Check | Pass mark |
|---|---|---|
| Data matches the floor | Supervisor checks yesterday, daily | 5 checks in a row, no missed stop |
| No missing data | Unknown time per machine, week 4 | Under 1% of scheduled time |
| Counts match | Hand count of 10 parts per machine | Matches on every counted machine |
| Stops have reasons | Stops classified within 24 h, week 4 | 95% or more |
| One decision made | Written change: owner, date, hours | At least one |

A missed stop is one over 5 minutes that the supervisor remembers and the record lacks. Use the count row only if the pilot counts parts.

*Unknown time* is time with no data from a sensor, kept out of both uptime and downtime; the [glossary entry](/docs/get-started/glossary/#unknown-time) explains why. A pilot area with a lot of it has a network or power problem to fix before rollout.

## Which machines belong in the pilot?

Pick at least 10 machines that one supervisor runs, include the bottleneck, and include the machines whose problems the supervisor already argues about. The group doesn't have to be a production line. In a job shop it's usually a department or a row of CNC machines, each running its own jobs. If the area has fewer than 10 machines, add the ones next to it.

The *bottleneck* is the machine that limits how much work leaves the shop. On a line, it's the slowest station. In a job shop, where each job takes its own route, it's the machine with the longest queue of jobs waiting for it. An hour lost there is an hour of shipments lost, so the first decision the pilot makes is worth most on that machine.

The machines people argue about matter for a different reason. For example, if everyone knows the surface grinder waits for blanks every afternoon, the supervisor can check the record against memory on day 2. That check is the first pass mark.

| Machine | Why it belongs | Example |
|---|---|---|
| The bottleneck | Its hours set the shop's output | Grinder most jobs pass through |
| Machines people argue about | Supervisor checks them from memory | Mill that “always waits for material” |
| An old machine, if you have one | Proves the method on any age | 1990s lathe with no network port |
| Steady runners | Show what normal looks like | Machining center on a repeat job |

Leave out machines that run a few hours a week and machines due to be moved or rebuilt.

If your oldest machines carry the most hours, put one in the pilot; [monitoring an old machine with no port](/blog/monitor-old-machines-without-a-plc/) covers where to mount on it.

> **10 machines or 25?**
>
> Choose 10 to 12 when one supervisor owns the area and has an hour a day for the pilot. Go toward 25 when the area is larger and a second supervisor can split the daily checks. Below 10, there are too few machines to compare against each other; past the point where one person can check every machine, missed stops slip through.

Choose machines that work the same shifts, and a single shift if you can. A three-shift area produces differences between shifts that nobody can explain yet in week 2, and the pilot gets judged on them. High mix is fine: in a job shop, setups are normal work, and they get their own reason in week 3.

## Why run it for four weeks?

Four weeks is the shortest pilot that proves both halves: two weeks to make the data right, and two to show the plant uses it. Each half needs its own time, because a person can't classify stops they don't trust.

Figure: Four weeks in a row. Week 1: install and calibrate. Week 2: the supervisor checks the data daily. Week 3: operators classify stops. Week 4: a decision from the data. Weeks 1 and 2 prove the data; weeks 3 and 4 prove the plant acts on it.

*The first two weeks make the data right; the last two prove the plant acts on it.*

A two-week pilot ends the moment the data becomes trustworthy, before anyone has used it. An eight-week pilot loses its sponsor's attention, and the go or no-go call slides into the next quarter.

## What should each week prove?

Each week has one job and a gate at the end. Weeks 1 and 2 are phase 1 of the IoTFlows [rollout plan](/docs/get-started/roll-out-plan/#phase-1), which has the setup sequence in detail.

| Week | What it proves | Gate at the end |
|---|---|---|
| 1 | Every device reads its machine | Running and stopped read right |
| 2 | The supervisor trusts the data | 5 daily checks with no missed stop |
| 3 | Operators give stops a reason | Most stops classified the same day |
| 4 | Someone acts on the data | One decision with an owner and date |

### Week 1: install and calibrate

Set the shift schedule and the time zone before the first device reports, because every number lands in a shift. Shift changes don't rewrite data already recorded, so a shift set wrong in week 1 leaves week 1 unreadable.

Sensor installs are short work. Kentucky's MEP center notes that machine monitoring installations are usually completed within a few days.[1] Spend the rest of the week checking that each machine reads running when it works and stopped when it idles, and compare any part count with a hand count of 10 parts.

### Week 2: check the data every morning

Each morning, the supervisor opens yesterday for the pilot machines and looks for a stop they remember that the record lacks. Each miss points at a device to recalibrate, not a reason to restart the clock on the whole pilot.

### Week 3: classify the stops

Turn on reason codes at the machine and let rules name routine stops, so operators answer only the stops that need judgment. Operator buy-in decides this week, and [getting operators to log reasons](/blog/operator-adoption/) covers it in full. Hold the first weekly review on Friday.

### Week 4: make one decision

Rank the week's stopped minutes by reason, take the largest loss on the bottleneck, and write down a change with an owner, a date and the hours it targets. The [daily checks on a downtime record](/blog/how-to-track-machine-downtime/#daily-check) keep the classification rate honest while you do.

## Who owns what during the pilot?

The supervisor who runs the pilot area owns it day to day, and the plant manager owns the decision. A pilot run by a project manager or the vendor ends with data nobody on the floor has checked.

| Role | Owns during the pilot | Answers for |
|---|---|---|
| Plant manager | Signs pass marks; makes the call | One decision made |
| Supervisor | Daily check; weekly review | Data matches the floor |
| Maintenance lead | Mounting, calibration, devices | No missing data, counts match |
| Operators | A reason on each stop | Stops have reasons |
| Vendor | Setup help and training | None: the plant judges |

If the sensors join the plant network, book IT's review when you pick the machines; [a rollout with no IT team](/blog/rollout-without-an-it-team/) covers the other route.

## What should you measure at the end?

Measure the five pass marks, and record each machine's week 4 uptime as the baseline for the rollout. Don't judge the pilot on how much uptime rose, for two reasons.

The before number is usually an estimate. NIST's maintenance survey notes that it asks about issues that, for many firms, are not formally tracked.[2] At one Michigan manufacturer, leadership needed up to a week to turn written machine records into productivity reports before it added monitoring.[3]

People also change what they do once they know they're measured. A 2014 systematic review found that taking part in a study does change the behavior being studied, but that little is securely known about how large the effect is.[4] A rise between week 2 and week 4 can be that effect, and a rollout would not repeat it.

#### Worked example: Week 4 scorecard for 12 CNC machines on one shift

- Machines: 9 machining centers, 2 lathes and a surface grinder that most jobs pass through, the bottleneck. Each machine is scheduled 450 minutes a day, 5 days a week.
- Scheduled time: 12 × 5 × 450 = 27,000 minutes. Unknown time: 180 minutes, so 180 ÷ 27,000 = 0.7%.
- Supervisor checks: 5 mornings in a row, no missed stop.
- Stops: 640 recorded, 612 classified within 24 hours, so 612 ÷ 640 = 95.6%. Checked the other way, 28 unclassified is 4.4%, and 100% − 4.4% = 95.6%.
- Decision: the grinder stopped 900 minutes, 360 of them waiting for blanks. The supervisor will stage the next job's blanks at the grinder before the current job ends.
- Hours at stake: 360 minutes is 6 hours a week; over 48 working weeks, 6 × 48 = 288 hours. Checked the other way, 360 × 48 = 17,280 minutes, and 17,280 ÷ 60 = 288 hours.

**Result:** Every pass mark met: go, with one decision worth 288 bottleneck hours a year

[What a plant does with each number](/blog/what-is-machine-monitoring/#uses) shows which role acts on the baseline once the rollout starts.

## Run the pilot on IoTFlows

IoTFlows runs pilots on 10 to 25 machines for four weeks, with no commitment to buy; the terms are on [pricing](/pricing/). A SenseAi attaches magnetically in seconds and calibrates in under five minutes, with no wiring and no PLC connection. A machine shows its status on the Assets page within a minute of coming online, so week 1 goes to calibration and shifts, not cabling.

Operators classify stops in a tap at the machine, and the Downtimes report ranks reasons by the hours they cost. Old and new machines report the same uptime, downtime and part counts, as [retrofit machine monitoring](/solutions/retrofit-machine-monitoring/) shows.

[Sorinex](/customers/sorinex-exercise-equipment/) installed SenseAi sensors across its critical production equipment in under 5 days. Within the first month, it reported 60% faster issue identification and resolution.

## How do you make the go or no-go call?

Go when every pass mark is met, fix the gap before you roll out when the data or the habit falls short, and stop when the data is right but finds nothing worth fixing. Make the call at the end of week 4, against the signed sheet, with the supervisor in the room.

Figure: Three checks in order. Does the supervisor agree with the data? If no, fix calibration and shifts. Are 95% of stops classified? If no, shorten the reason list. Was one decision made? If no, name a review owner. Three yeses lead to go.

*Three checks in order: a no at any step names what to fix before you decide.*

- **Go** when all five pass marks are met. Roll out one area at a time, copying the pilot area's setup, and start phase 2 of the rollout plan on the pilot machines.
- **Fix it before you roll out** when the supervisor still finds missed stops, or classification sits below 95%. Both have known fixes: calibration and shifts for the first, a shorter reason list for the second. Most of these show up in the first two weeks, while the data is being made right, so fix them then and the pass marks hold by week 4.
- **Name an owner for the weekly review** when the data is right and classified but nobody made a decision. That's a meeting problem, not a monitoring problem.
- **Stop** when the data matches the floor and the reviews find no loss big enough to act on. Then visibility isn't what the area is missing, and a rollout won't change that.

You don't need a plant-wide return figure to say go. The hours at stake in the first decision, on one bottleneck, are the number the rollout has to beat.

## Questions

### Can a monitoring pilot cover more than one area?

Keep it to one area under one supervisor, and add the machines next to it if the area has fewer than 10. Two areas double the calibration work, split the supervisors' attention and leave neither area with enough weekly reviews to produce a decision. Prove the method in one area, then copy it to the next.

### Is two weeks long enough for a pilot?

Two weeks proves the data is right, and no more. It cannot show whether operators keep classifying stops once the novelty wears off, or whether anyone acts on the numbers, because a decision needs at least one weekly review that compares two clean weeks. Four weeks covers the data, the habit and the decision.

### Should we calculate ROI at the end of the pilot?

Calculate the hours at stake in the decision the pilot produced, not a plant-wide return. Four weeks in one area cannot show a lasting uptime change, and the before number is usually an estimate. The hours one fix returns on the bottleneck, multiplied out over a year, give a figure you can defend in the rollout decision.

## Sources

1. [Enhance Your Existing Equipment with Machine Monitoring](https://louisville.edu/servicecenters/news/enhance-your-existing-equipment-machine-monitoring), University of Louisville Service Centers (Kentucky MEP), accessed Oct 30, 2026
2. [Economics of Manufacturing Machinery Maintenance: A Survey and Analysis of U.S. Costs and Benefits (NIST AMS 100-34)](https://nvlpubs.nist.gov/nistpubs/ams/NIST.AMS.100-34.pdf), National Institute of Standards and Technology, accessed Oct 30, 2026
3. [M R Products, Inc: Technology Adoption Improves Data, Capacity & Quality](https://www.nist.gov/node/1741691), National Institute of Standards and Technology, Manufacturing Extension Partnership, accessed Oct 30, 2026
4. [Systematic review of the Hawthorne effect: New concepts are needed to study research participation effects](https://pmc.ncbi.nlm.nih.gov/articles/PMC3969247/), Journal of Clinical Epidemiology, via PubMed Central, accessed Oct 30, 2026