Case study
AMI 2.0 metering ops & remote connect / disconnect
RCD discovery and requirements: move-in connect from ~7 days (trucks) toward under 24 hours when eligible; program target 4M+ meters.
National Grid
- AMI
- Smart metering
- IoT
- RCD
- Regulated utility
- Enterprise
- Operations systems

Summary
Role
Principal Product Manager
Timeline
Nov 2022 – Present
Team
Process team, metering, field/grid ops, IT, care, billing, collections, risk, and partners—priorities often conflict; product owns the coherent requirements set.
Domain
Regulated utility; multi-state AMI; electric and gas; remote connect/disconnect where policy and hardware allow.
Metrics moved
Goal: RCD on 4M+ meters in the next year. Success when live: intent-to-confirmed-meter time and exception rate—not “commands sent” alone.
Key constraints
Safety and regulatory rules; mixed meter vintages; unreliable network delivery; auditable history for collections and emergencies.
Systems involved
Smart meters (RF/cellular), AMI head-end, MDMS, CSS, Salesforce for initiation and account context.
Stack
Tech stack
Vendor meters (RF/cellular), AMI head-end and MDMS, plus CSS and Salesforce where service actions start before commands hit the network.
Meters & connectivity
Smart meters from the network’s vendor ecosystem: configuration, commissioning context, and device behavior on RF and cellular paths.
- Vendor smart meters (RF & cellular backhaul)
- Electric & gas programs and device-level readiness
AMI core
Head-end orchestration and MDMS for command paths, readings, and meter events.
- AMI head-end
- MDMS
Customer & CRM
Where CSRs, collections, and account context connect to RCD and meter operations.
- CSS (customer service system)
- Salesforce
How RCD closes the loop
Business intent becomes a confirmed meter outcome—or a governed exception.
Authorized initiation
Care, collections, or emergency playbooks raise connect/disconnect with premise and account context in CSS-aligned systems.
Validation & routing
Eligibility, safety, and device readiness before the head-end issues a network command—fewer invalid attempts.
Meter action & confirmation
Meter actuates where applicable; verification and events reconcile to the customer record.
Operations & audit
CSRs see outcomes or structured exceptions; evidence supports regulatory and collections needs without shadow tracking.
Overview
I own principal-level product for AMI 2.0 field operations (meters configured and responsive on the network) and for RCD—remote service on/off at the meter where hardware supports it, with confirmation back to care, collections, and audit. RCD is still largely in discovery and requirements; the core problem is end-to-end correctness: right meter, clear outcome, or a controlled fallback.
Business context
AMI is both measurement and control: connect/disconnect can route from CSS through the head-end to the meter. National Grid spans electric and gas with different device classes—delivery is patterns and configuration, not one undifferentiated toggle.
Problem
Move-in connect today is often a week of trucks and scheduling; RCD should hit under 24 hours when eligible. Misaligned provisioning or IDs mean CSS says “ready” but the head-end cannot command—RCD raises the stakes for collections, safety, and move-in promises.
Constraints
Electric vs gas differ on commands and safety. The AMI network does not guarantee first-try delivery. Policy varies by scenario (collections, move-out, emergency). Product must preserve audit evidence without opaque failures for operators.
Role & ownership
Owned problem framing and roadmap for AMI field ops and for RCD (move-in/out, kill switch, emergency, collections). Ran discovery with the process team; prioritized by volume, revenue exposure, and customer risk; aligned vendor capability to internal release trains and rollout.
Goals & metrics
Stand up RCD on 4M+ meters with governance, not blind volume. When live: more completes on validated remote paths, fewer misconfiguration exceptions, shorter CSS-to-meter confirmation time, defensible trails for collections and emergencies.
Approach
Traced real scenarios (move-in windows, collections, emergencies) with the process team—not vendor slide decks. Measured handoffs between CSS, head-end, and events so debates used counts, not anecdotes. Piloted with territories that would tighten runbooks for faster exception closure.
Decisions & tradeoffs
Explicit failure semantics over silent retries that could duplicate disconnects. Slower parallel runs where regulators needed evidence before widening reinstatement. Unified electric/gas narrative where patterns matched; documented fuel-specific non-negotiables instead of false parity.
Cross-functional leadership
Research and design sessions with process, AMI ops, integration, care leadership, collections, dispatch, and vendors—sequencing and risk surfaced early. Turned scenario language into eligibility matrices, initiator contracts, and head-end behaviors operators can trust at peak load.
Execution
AMI work focused on measurable readiness: registration/config on the head-end, consistent keys across CSS and AMI inventory, playbooks for ambiguous acks. RCD: one story across move-in/out, kill switch, emergency, and collections—with initiation, validation, retries, and reconciliation so agents do not promise states the meter has not reached.
Outcomes
Metering ops advanced as a managed product surface. RCD requirements tightened intent-to-confirmation before broad rollout. At scale: faster eligible move-in connect and fewer avoidable truck rolls, with explicit non-remote fallbacks.
What changed
Field ops on AMI got clear owners for IDs, command eligibility, and visible outcomes. RCD is framed as an operational system (initiate → route → ack → exception), not a hardware-only feature.
Lessons learned
The product is the contract between intent and confirmation—weak events stall adoption regardless of hardware. Treat head-end and CSS integration as owned ops products (versioned, monitored), not one-off projects.