
An MDM RFP for a utility should evaluate eight criteria: AMI head-end compatibility, VEE engine configurability, CIS integration method, interval data retention, TOU rate support, customer portal data feed, pre-billing validation rules, and vendor pricing model. Most utilities that select the wrong MDM platform discover the gap during AMI rollout, when they find out their system cannot process 15-minute interval data at scale. This guide gives you the evaluation criteria, a scoring approach, and the questions to put in every MDM vendor RFP. For the underlying capability requirements that drive each criterion, SMART360's meter data management platform covers what the system must do before you evaluate any vendor.
Before writing RFP criteria, you need a working definition of what a modern MDM system is responsible for. Utilities that skip this step issue RFPs that a legacy MDMS can satisfy on paper because the requirements were written around end-of-period reads, not interval data.
A modern MDM system must handle four functions end to end: data collection from AMI head-end systems, VEE (Validation, Estimation, and Editing) of every interval read before it reaches billing, delivery of validated consumption totals to the CIS or billing engine, and outbound data feeds to customer portal and analytics platforms. If your RFP criteria do not test each of these functions at AMI data volumes, a legacy vendor can pass on credentials alone.
For a technical breakdown of what distinguishes modern Smart MDM from legacy MDMS at the architecture level, what is Smart MDM meter data management explains the difference and maps the functions any evaluation must test.
Does your current RFP distinguish between a system that stores billing-period totals and one that stores and processes 15-minute interval reads separately?
The most common MDM RFP failure is writing requirements that a traditional MDMS can meet. A traditional system stores one read per meter per billing cycle. A Smart MDM system stores 2,880 reads per meter per month at 15-minute resolution. Both can claim "meter data management" in a response. Your RFP criteria must test at the interval level, not the billing-period level.
Three architectural questions your RFP must answer before scoring any vendor:
A vendor that cannot answer these clearly, or that answers with "depends on configuration," has a legacy architecture designed for a different data model.
For a foundational explanation of what MDMS is and how the architecture has evolved, what is MDMS: a utility guide covers the core data flow and integration model in detail.
Use this table to build the scoring rubric in your RFP. Each criterion should be tested with a specific requirement, not a yes/no checkbox. The "minimum acceptable" column represents the floor below which a vendor should not advance to shortlist. The "best-in-class" column describes what a modern integrated MDM platform delivers.
| Evaluation Criterion | Minimum Acceptable | Best-in-Class |
|---|---|---|
| AMI head-end integration | Supports your current AMI vendor via API or file import | Pre-built connectors for 5+ major head-ends (Itron, L+G, Sensus, Aclara, Honeywell) without custom development |
| VEE engine | Configurable validation rules, manual exception queue | Automated estimation with configurable methods, exception queue with SLA tracking, audit trail per read |
| CIS integration | Can deliver billing-ready consumption totals to CIS | Real-time API push to CIS on read receipt, with field-level mapping and delivery confirmation |
| Interval data store | Stores interval reads at 15-minute resolution for 12 months | Full-resolution storage at 15-minute or shorter intervals with 36-month minimum retention |
| TOU rate support | Interval data maps to TOU windows for billing | Native TOU window configuration inside MDM, maps directly to CIS rate codes without manual mapping |
| Customer portal feed | Exposes daily usage data to customer portal | Near-real-time interval data via API, configurable threshold alerts, outage notification feed |
| Pre-billing validation | Flags outlier accounts before billing run | Configurable outlier thresholds by account type, automated hold queue, release workflow with audit log |
| Pricing model | Transparent per-meter or per-read pricing | Per-meter pricing with no per-integration or per-module add-on fees; scales linearly with deployment |
Which AMI head-end systems does your utility currently operate, and does each vendor on your shortlist have a pre-built connector or only a custom interface option?
AMI integration is the criterion that eliminates the most MDM vendors for US utilities, because most utilities have deployed AMI hardware from Itron, Landis+Gyr, Sensus, or Aclara and need native connectivity, not a custom-built file import process.
Include these specific integration requirements in your RFP:
A vendor that supports your head-end via a custom interface adds integration cost, creates a maintenance dependency, and introduces a data sync lag that affects both billing accuracy and customer portal data freshness. For a technical explanation of how MDM and AMI head-end systems exchange data across the full interval data pipeline, AMI MDM integration: how smart meters connect to billing maps each integration point and the common failure modes.
For a detailed breakdown of what operational improvements to verify during reference checks, meter data management system benefits for utilities covers the billing accuracy, loss detection, and customer service benchmarks utilities typically achieve after MDM modernization.
Include these questions verbatim in your RFP. Vendors that cannot answer specifically are either working from legacy architecture or have not deployed at AMI scale with a utility similar to yours.
A utility MDM RFP should include: meter environment specifications (current and projected meter count, AMI percentage, head-end systems), functional requirements for VEE, CIS integration, TOU rate support, and customer portal data feed, a request for working demonstration before scoring, and a five-year total cost request that includes all integration and support fees. Generic RFPs that rely on vendor-provided capabilities summaries typically produce shortlists that include legacy platforms that cannot handle AMI interval data at scale.
Three to five vendors is the standard for a utility MDM evaluation. Below three, you risk not having a competitive pricing reference. Above five, the demonstration requirement becomes operationally difficult and evaluation quality drops. Eliminate vendors that cannot confirm pre-built connectivity to your specific AMI head-end before issuing the full RFP.
The most common failure is selecting a vendor based on general capabilities presentation without a working demonstration on interval data. A vendor with legacy MDMS architecture can present an impressive response that satisfies requirements written around billing-period totals. The failure appears 12 to 18 months after deployment, when AMI data volumes hit the system and VEE processing times extend to the point where billing cycles are delayed.
Modern MDM platforms for US utilities are typically priced per meter per month, which aligns the vendor's revenue to your deployment scale. Enterprise license models with flat fees favor large utilities but create overpayment for small and mid-size utilities deploying AMI incrementally. Per-meter pricing is more transparent for utilities growing from partial AMI coverage to full deployment over 3 to 5 years.
For a comprehensive view of how modern MDM fits into the full utility data pipeline from meter to billing to operations, meter data management in utilities: how modern MDM works covers the architecture, data flow, and integration model in an operational context.