A lot of AMI deployments look successful until the read data comes in.
Install numbers are on track. The crew is moving. Work orders are closing. Then the first billing cycle runs and read acceptance comes back at 70%. That means 30% of a utility's meters are effectively dark: hardware in the ground, endpoints installed, and no usable data making it to the back office.
The installs didn't fail. The gap did.
There's a phase between a completed installation and a confirmed, sustained read that most project plans don't account for. It has specific causes. And they're almost all preventable.
The signal test problem
When a field crew installs an AMI endpoint, a signal test confirms the device is communicating at that moment. The work order closes. The crew moves to the next address.
What a passing signal test doesn't confirm: that the endpoint will sustain reliable reads over time, across varying network conditions, under the collector density that actually exists in the field once the full deployment is in place.
Signal tests are point-in-time. Read acceptance is cumulative. The gap between those two things is where deployments quietly fall apart.
Three variables that determine whether your read rate holds
Collector placement sequencing. Most AMI distributors provide a propagation study, a model of where collectors need to be placed to achieve reliable coverage across the service territory, before deployment. That study is only useful if it's acted on before the first meter goes in. If collector placement planning happens after installs have begun — or worse, after they're complete — there are already endpoints in the ground that the propagation study would have flagged as coverage risks. Retrofitting collector placement around an existing install pattern rarely closes those gaps fully.
Endpoint programming. Wrong communication profile, wrong reporting interval, wrong mode for the network being deployed — these don't surface during installation. They surface at the first billing cycle, when the headend can't match field records to active endpoints. Endpoint programming errors are more common than utilities expect, and they're invisible until the data handoff happens.
The data handoff itself. This is where most read rate failures actually originate, and it's the least-discussed part of an AMI deployment. A work order can close clean in the field while the back office receives a dataset that doesn't map to the utility's AMI system. MIU IDs that don't match. Serial numbers that don't reconcile. GPS coordinates that aren't formatted for the headend's import. Each mismatch is a meter that won't read: the endpoint is in the ground and communicating, but the utility has no way to match it to an account.
What closing the gap actually requires
Closing the install-to-read gap requires treating AMI as a system from the start of project planning, not just during execution.
Collector planning needs to happen before the first install. That's not a technical observation — it's a sequencing decision that has to be made in the pre-mobilization phase, when there's still time to adjust placement before endpoints are in the ground.
Signal verification in the field needs to happen at each site, not just as a batch check at project completion. A site-level verification process confirms communication while the crew is still on-site and corrective action is still cheap.
The data handoff needs a defined close-the-loop process: every field record matched to the utility's system before the crew demobilizes. In practice, this means the billing export format is confirmed before the first install, column mapping is done at project intake, and records are reconciled continuously, not assembled at closeout and handed over as a batch file.
This is why involvement in project planning matters. A contractor who shows up to execute installs on Day 1 is already behind on all three of these variables. The decisions that determine read acceptance rates are made in the weeks before the crew arrives.
The meter is the last step
AMI is a system. The meter is the last component installed, but read rate is a function of everything that came before it: collector placement, endpoint programming, network configuration, and the data handoff process that connects field records to the utility's billing infrastructure.
A 70% read acceptance rate on a completed deployment isn't a network problem. It's a planning problem, and it shows up in the data long after the crew has gone home.
Utilities planning an AMI deployment or troubleshooting read acceptance issues are welcome to reach out. We're happy to compare notes on what read rate targets are realistic and what the field variables look like on projects we've run.