---
title: "Plan your rollout"
description: "A four-phase plan for putting a plant on IoTFlows: pilot one line for two weeks, win operator adoption and turn on alerts, cut the downtime category list down to reasons you can act on, and only then add scheduling and maintenance. Each phase carries a gate that has to close before the next one starts."
category: "Plan your deployment"
source_url: "https://www.iotflows.com/docs/get-started/roll-out-plan/"
---
# Plan your rollout

Take a plant from a boxed sensor to a shop floor that acts on its own data, in four phases.

Rollouts stall in the same place. The pilot produces numbers nobody trusts, so nobody acts on them, and the project is judged on that. The sequence below is built to close that gap in the first two weeks.

Each phase ends at a gate. Do not start the next phase until the gate closes, even if the hardware for it is already on site.

## The four phases
| Phase | Duration | Who | Done when |
|---|---|---|---|
| 1. One line | 2 weeks | Installer, plant admin | A supervisor reads yesterday's numbers and agrees with them |
| 2. Operator adoption | Weeks 3 to 6 | Supervisors, operators | 95% of downtime events are classified within 24 hours |
| 3. Reasons that mean something | Weeks 6 to 12 | Continuous improvement, maintenance | The top three downtime categories each have an owner and a date |
| 4. Scheduling and maintenance | Month 3 onward | Planners, maintenance | Jobs and work orders are created in IoTFlows, not in a spreadsheet |

Diagram: A left-to-right timeline of four rollout phases, each box naming the phase and its duration: 1. One line, 2 weeks; 2. Operator adoption, weeks 3 to 6; 3. Downtime reasons, weeks 6 to 12; 4. Scheduling and maintenance, month 3 onward. An arrow runs left to right beneath the boxes and passes through four diamond gate markers, one under each phase. The gate under each phase reads, in order: a supervisor agrees with yesterday’s numbers; 95% of stops classified within 24 hours; top three categories have an owner and a date; jobs and work orders live in IoTFlows. The arrow only continues past a gate once that condition is met.

*The four rollout phases and the gate that has to close before each one ends.*

## Phase 1: one line, two weeks
Pick one line and monitor three to five machines on it. Choose the bottleneck and the machines whose problems you already argue about, because those are the ones a supervisor can check the data against from memory.

Choose a pilot line with a single-shift schedule and a stable part mix. A three-shift cell with changeovers will produce data you cannot yet explain, and the pilot will be judged on that.

Set the organization timezone and the shift schedule before the first sensor reports. A *shift* is a named window of the working day, and every number IoTFlows reports is bucketed into one. Shift changes do not apply to data already recorded, so a shift set wrong in week 1 leaves week 1 permanently unreadable. See [Set shifts and the organization timezone](/docs/admin/shifts-and-timezone/).

Then bring up the hardware. [Quickstart](/docs/get-started/quickstart/) covers one machine end to end: mount the device, get it on Wi-Fi, create the asset, and confirm data is arriving.

Spend 15 to 20 minutes calibrating each device rather than five. A SenseAi on the machine housing can read the machine well, but only [calibration](/docs/hardware/calibrate-senseai/) tells you whether it does.

Run the machine cutting and then idle, and adjust the thresholds until the two read differently. Until someone does that, a device can report a cutting machine as stopped, and every number built on it is wrong.

Set a first uptime goal 5 to 10 points above the current average, not at the number you wish you had. *Uptime* is the share of scheduled time a machine spent running; see the [metrics reference](/docs/monitoring/metrics-reference/). If the line runs at 55% today, set the goal at 60%.

**The gate.** A supervisor opens yesterday on the [assets overview](/docs/monitoring/assets-overview/) and agrees with what it says. If they can point at a stop that the system missed, fix calibration before going further.

## Phase 2: operator adoption
Phase 1 tells you a machine stopped. Only an operator can tell you why. This is the phase most rollouts skip, and skipping it is what leaves you with months of unclassified downtime.

Put a screen next to each monitored machine. In **Devices**, open **Assign to Local Device** and use **Assign Asset** to tie the tablet to its machine, so the operator sees their own line and nothing else. See [Set up operator stations](/docs/monitoring/operator-stations/).

Train on the why before the how. Operators need to hear that the data is used to remove the obstacles that slow them down, and that it is not used to rank people. A system introduced as a scoreboard gets gamed within a week.

Turn on alerts in this phase, not at the end. An alert that reaches a supervisor's phone while the machine is still down is what turns a report into a response. Start with one rule on the pilot line, for example a stop longer than 15 minutes on the bottleneck. See [Alerts overview](/docs/alerts/overview/).

**The gate.** 95% of downtime events on the pilot line are classified within 24 hours, for two consecutive weeks.

## Phase 3: downtime reasons that mean something
A *downtime category* is the reason an operator assigns to a stop, for example **Tool change** or **Waiting on material**. The category list is the single largest lever on whether the data is worth reading.

Keep the list short. Eight to twelve categories that map to an action beat forty that map to a feeling. An operator facing a forty-item list picks the first plausible one, and a Pareto chart built from that answers nothing. See [Set up downtime categories](/docs/monitoring/downtime-categories/).

Automate the stops that have only one possible reason. Rules can classify micro-stops under two minutes, shift changeovers, and scheduled breaks without an operator touching them, which leaves the operator's attention for the stops that are actually ambiguous. See [Classify downtime automatically](/docs/monitoring/auto-downtime-rules/).

Review the data on a fixed weekly slot with supervisors, maintenance, and continuous improvement in the room. Sort [Downtimes](/docs/monitoring/downtimes/) by total duration for the past week, take the top three, and give each one a name and a date.

**The gate.** The top three categories each have an owner and a deadline, and last week's top three were reviewed against this week's.

## Phase 4: scheduling and maintenance
Once downtime data is trusted, the same machine records can carry the work. [Production Scheduler](/docs/production/scheduler/) plans jobs against real cycle times instead of estimates, and [Maintain](/docs/maintain/overview/) turns a recurring downtime category into a preventive maintenance schedule.

You do not need phase 4 if your goal was to find out where the hours go. Phases 1 to 3 answer that on their own, and a plant that adopts scheduling before its operators classify downtime is planning against numbers it does not believe.

Add these one product at a time, on the pilot line first, for the same reason phase 1 started with one line.

## Pitfalls
**Monitoring the whole plant in week 1.** Forty machines produce forty calibration problems at once, and nobody can tell a bad sensor from a bad shift schedule. Start with three to five.

**Setting the goal at the industry benchmark.** A team that starts 30 points below its target stops looking at the target. Raise it as the line improves.

**Using the data to punish.** Operators who are measured rather than helped hide problems, and the classification rate collapses. The gate in phase 2 is the first thing to go.

**Installing and forgetting.** Devices drop off Wi-Fi and calibration drifts. Check [Devices](/docs/hardware/view-devices/) weekly for anything offline or reconnecting repeatedly.

**Growing the category list to cover every case.** Every category added past roughly a dozen dilutes the ones that matter. Add a category only when someone would act differently because of it.

## A readiness checklist
Before you call a phase done:

1. The organization timezone matches the plant, and every shift is defined with its real start and end times.
2. Each monitored machine reads as running when it is cutting, and stopped when it is not.
3. Each machine has an uptime goal set from its own history.
4. Every monitored machine has a screen an operator can reach without leaving the machine.
5. Operators have been told what the data is for, by their own supervisor.
6. At least one alert rule reaches a phone or a chat channel.
7. The category list is under a dozen entries and every entry names an action.
8. A weekly downtime review is on the calendar with named attendees.

## See also
- [Set shifts and the organization timezone](/docs/admin/shifts-and-timezone/)
- [Set up downtime categories](/docs/monitoring/downtime-categories/)
- [Alerts overview](/docs/alerts/overview/)
- [Quickstart: see your first machine's data](/docs/get-started/quickstart/)