Many smart meter tenders include long feature lists. After installation, teams ignore many options. I focus on the functions that support daily operation.
The smart water meter features utilities use most are remote reading, 事件记录, 警报, 电池状态, and diagnostic data. Advanced configuration tools and special testing functions are useful, but they are often used only during commissioning or abnormal troubleshooting.

I usually separate “available functions” from “used functions.” A feature can be technically impressive, but if the utility team has no workflow, alarm rule, platform connection, or field response process, the value stays on the slide.
What Is the Full Menu of Smart Meter Features?
Smart meter menus can become too large. Buyers feel safe adding more functions, but every function adds cost, 训练, and support work.
A smart water meter feature menu may include metering, 远程抄表, 事件记录, prepaid mode, postpaid mode, low water alarm, 漏电报警, dry pipe alarm, low battery indication, 通讯测试, and optional pressure detection.
The Feature List Is Not the Same as a Use Case
I see many tenders list every possible feature. The list may include metering, TOKEN recharge, STS prepaid operation, switchable prepaid and postpaid mode, low water alarm, 和事件记录. It may also include NB-IoT system functions, daily frozen meter data, database storage, and test verification for connectivity and data transmission accuracy. For ultrasonic smart meters, the feature list may include ultrasonic static measurement, R400 measuring range, starting flow down to 0.001 立方米/小时, optional pressure detection, IP68防护等级, 泄漏检测, and dry pipe detection.
This full menu is useful during technical selection. But it does not mean every utility will use every feature every week.
I usually divide features into four groups.
| Feature Group | Examples | Typical Utility Use |
|---|---|---|
| Core daily operation | 远程抄表, frozen data, billing data | high |
| Risk warning | 漏电报警, dry pipe alarm, low battery alarm | high |
| 可追溯性 | 事件记录, fault messages, tamper-related logs | high |
| Special operation | test verification, handheld setup, advanced configuration | low after commissioning |
ISO 4064 also reminds us that a remote reading device may be used for testing, verification, and remote reading when satisfactory operation of the water meter is guaranteed. It also states that added ancillary devices must not alter the metrological characteristics of the meter. This point is important. I do not treat communication as a decoration. It must support metering without disturbing metrology.
For battery-powered smart meters, I also check whether low battery indication is available. ISO 4064 需要低电量或电量耗尽指示器, 或仪表更换日期, for non-replaceable battery meters. If the register displays “low battery,” there must be at least 180 days of useful display life from the low battery indication to end of life.
The full menu is useful. But the tender should not buy a menu. It should buy a workflow.
Which Features Did Utilities Think They Needed?
Utilities often ask for many advanced functions before installation. They worry about future needs, consultant comments, and tender comparison tables.
安装前, utilities often think they need every available smart function. 在实践中, they mainly need reliable data collection, clear event records, actionable alarms, battery visibility, and simple integration with billing or AMI platforms.

The Tender Stage Encourages Over-Specification
At tender stage, the safest-looking meter is often the one with the longest feature list. I understand why this happens. Procurement teams compare datasheets. Consultants ask for options. Managers want future flexibility. Vendors also like to show many functions.
So the tender may request prepaid mode, postpaid mode, TOKEN logic, remote valve rules, 报警类别, handheld configuration, communication tests, frequent upload cycles, history curves, map views, pressure monitoring, and many dashboard modules.
Some of these functions are necessary in the right project. STS prepaid operation, 例如, is important when the project uses TOKEN-based prepaid water service. Switchable prepaid and postpaid mode can also matter when the utility needs policy flexibility. Low water alarm and event records may support customer warning and after-sales investigation.
But I ask one practical question: who will use this function after installation?
If the billing department does not use prepaid mode, the prepaid function has little daily value. If the customer service team does not read event records, the record function becomes hidden value. If the field team cannot respond to leakage alarms, the alarm becomes noise. If the platform cannot process pressure data, optional pressure detection may not help the utility make decisions.
| Feature Requested in Tender | My Follow-Up Question |
|---|---|
| Prepaid and postpaid mode | Does the utility operate both business models? |
| TOKEN function | Is STS prepaid actually used in this market? |
| Pressure detection | Who will analyze pressure data? |
| Frequent reporting | Can the battery and network support the cycle? |
| Remote alarm | Who receives and closes the alarm ticket? |
| Test verification | Is this for commissioning or daily operation? |
For NB-IoT meters, the manual describes a test verification function used to verify connectivity and data transmission accuracy when customers first use the meter. The same material states that this function is rarely used after normal use and is mainly used for on-site diagnosis when the meter is abnormal. This is a good example of a valuable feature that should not be treated as a daily-use feature.
I do not reject advanced features. I only ask buyers to connect each feature to a user, 平台, and response process.
What Does Post-Installation Reality Show About Usage?
After installation, the real ranking changes. The most expensive-looking features are not always the most used.
Post-installation feedback shows that utilities use remote reading, frozen daily data, 事件记录, 警报, and low battery information most often. Commissioning tools and advanced verification functions are valuable, but they are rarely used after stable operation.
I Separate High-Use Features from Occasional Tools
I do not like inventing precise usage statistics without project data. Instead, I classify usage based on field feedback and system behavior.
Remote reading is usually high-use because it replaces or reduces manual reading work. In an NB-IoT system, the background meter reading system can display frozen water meter data every night and save it in the database without change. This is exactly the kind of feature utilities keep using because it supports billing, consumption review, and routine monitoring.
Event records are also high-value. A prepaid water meter manual lists event records as a core functionality category. 在实际项目中, I see event records used when customers complain, when abnormal consumption appears, or when a utility needs to check what happened before a field visit.
Alarms also stay relevant after installation. Low water alarm is listed as a function in the prepaid water meter manual. Ultrasonic smart meters may support leakage detection and dry pipe detection. ISO 4064 also discusses fault-related messages when meters transmit data to peripheral equipment, and the transmission shall be accompanied by a message indicating the presence of a fault. These functions help utilities detect abnormal conditions earlier, but they do not replace site inspection or repair.
| Usage Level After Installation | 特征 | Why Utilities Keep Using Them |
|---|---|---|
| 高的 | 远程抄表, daily frozen data | supports billing and routine operation |
| 高的 | 事件记录 | supports complaint investigation |
| 高的 | alarms and fault messages | supports faster response |
| 中等的 | prepaid/postpaid settings | useful only when business model needs it |
| Low after commissioning | test verification | mainly used during first use or abnormal diagnosis |
Low battery indication also matters because battery failure creates field cost. ISO 4064 requires low battery or exhausted battery indication, or a replacement date, for non-replaceable battery meters. This makes battery status a practical maintenance feature, not just a technical detail.
The lesson is simple. Utilities use features that appear in daily workflows. They ignore features that have no owner.
Which Features Directly Support Non-Revenue Water Reduction?
NRW work needs field action. A smart meter can support the work, but it cannot repair pipes or correct customer databases by itself.
Smart meter features that support NRW reduction include better low-flow capture, remote consumption visibility, 泄漏检测, 干管检测, reverse or abnormal event records, and alarms that help utilities respond earlier.

The Meter Supports NRW Reduction, but It Does Not Replace Operations
I treat NRW as a system problem. It may include real leakage, 表观损失, 电表注册不足, 非法连接, billing data errors, customer data errors, 压力问题, 延迟修复, and installation problems.
Smart water meters can help in several ways. 第一的, they can improve visibility. Remote reading and nightly frozen data allow the utility to see consumption without waiting for manual reading cycles. This supports faster analysis when a district, 建筑, or customer group shows abnormal use.
第二, certain ultrasonic smart meters can support low-flow measurement. The referenced ultrasonic residential smart meter uses ultrasonic measurement technology and has a wide measurement range of Q3/Q1 = R400. The same material states an ultralow starting flow down to 0.001 立方米/小时. I still separate starting flow from Q1 in technical discussions. Starting flow means the meter begins to register movement, while Q1 is the lower boundary of the certified measuring range. The datasheet or certificate must define the exact Q3 and Q1 before a buyer estimates revenue effect.
第三, alarms can support earlier warning. The ultrasonic meter material lists leakage detection and dry pipe detection. ISO 4064 also addresses fault messages during data transmission to peripheral equipment. These warnings can help a utility decide where to inspect first.
| NRW-Related Feature | Practical Value | Limitation |
|---|---|---|
| 远程抄表 | faster consumption visibility | needs network and platform |
| Frozen data | stable billing and trend data | needs database and rules |
| 泄漏检测 | earlier abnormal warning | does not repair pipe leaks |
| 干管检测 | helps find supply or installation issues | needs field confirmation |
| Event records | 支持调查 | must be reviewed by staff |
| 低流量性能 | may reduce apparent loss under conditions | depends on Q3, r, Q1, 安装 |
I would verify NRW impact in a pilot before full rollout. The meter supports NRW reduction, 但它不能取代泄漏修复, 压力管理, 非法连接控制, or billing data cleaning.
Which Features Improve Customer Service and Billing?
Billing complaints often start with missing data. Customer service teams need clear records, not complicated dashboards.
The most useful customer service and billing features are remote readings, frozen historical data, 事件记录, alarm records, low battery status, and clear meter indication. These features help explain bills and reduce manual investigation time.
Complaint Handling Needs Evidence, Not Decoration
When a customer disputes a bill, the utility needs a timeline. Remote reading gives consumption data. Frozen data gives a stable reference point. Event records show abnormal events. Alarm history helps explain leakage, 干管, low water, 电池, or fault conditions.
The NB-IoT system manual states that the background meter reading system displays frozen water meter data every night and saves it in the database without change. This is valuable for billing because the data point is time-based and stored. It is also useful for customer service because staff can compare customer claims with recorded readings.
Event records are also important. The prepaid water meter manual lists event records as a function category. 在实践中, event records help when a customer asks why water was cut, why an alarm appeared, or why the bill changed. If the project uses STS prepaid meters, TOKEN application and switchable prepaid/postpaid mode may also affect customer service workflows.
Clear local indication still matters. ISO 4064 规定指示装置应连续显示音量, 定期地, 或按需, and it shall be readily available to read. I do not recommend removing local readability just because the system supports remote data. Field technicians and customers still need a clear meter display in many projects.
| Service Problem | Useful Feature | Why It Helps |
|---|---|---|
| Customer disputes reading | frozen data | gives stored time-based evidence |
| Customer reports no water | dry pipe or valve-related records | supports diagnosis |
| Customer questions prepaid balance | TOKEN and event records | supports transaction review |
| Billing team lacks data | 远程抄表 | reduces manual reading dependency |
| Field visit needed | local display | supports on-site confirmation |
| Battery issue appears | low battery indication | allows planned maintenance |
Battery status also affects service quality. ISO 4064 requires low battery or exhausted battery indication, or a replacement date, for non-replaceable battery meters [6]. This helps utilities avoid surprise failures and plan replacement work.
The best billing feature is not the most complex function. It is the feature that gives reliable, explainable data when a customer asks a difficult question.
Which Features Look Good on Slides but Don’t Get Used?
Some functions are technically real but operationally rare. They should not drive the whole tender decision.
Features that often look good but see low daily use include special connectivity test tools, advanced local configuration, rarely used prepaid options, optional pressure data without analytics, and dashboard modules with no assigned user.
A Rarely Used Feature Can Still Be Necessary
I do not call these features useless. I call them conditional.
The best example is test verification. The NB-IoT manual says the test verification function is used to verify connectivity and data transmission accuracy when the customer first uses the NB-IoT water meter. It also says the function is rarely used after normal use, but can be used for on-site diagnosis when the NB-IoT meter is abnormal. This is a useful maintenance feature. But it should not be presented as a daily operational advantage.
Optional pressure detection is another example. The ultrasonic smart meter material lists integrated pressure detection as optional. This can be valuable in a pressure management or hydraulic analysis project. But if the utility has no pressure analytics, no district model, and no field response process, the pressure data may stay unused.
Prepaid and postpaid switching can also be powerful in the right market. The prepaid meter manual lists switchable prepaid and postpaid mode. But if the utility only uses postpaid billing, the prepaid features may not justify extra cost. If the utility uses STS prepaid billing, TOKEN functions become central.
| Slide-Friendly Feature | When It Has Value | When It Becomes Low-Use |
|---|---|---|
| Test verification | commissioning and abnormal diagnosis | stable daily operation |
| Optional pressure detection | pressure management project | no analytics or response process |
| Prepaid/postpaid switch | mixed billing policy | single billing model |
| Advanced handheld tools | maintenance team trained | no field workflow |
| Detailed dashboard modules | assigned operational owner | no one reviews them |
I also watch battery impact. More frequent reporting and extra sensor functions may increase power demand. ISO 4064 requires that a non-replaceable battery supports correct meter function for at least one year longer than the operational lifetime of the meter. So I always connect feature selection with battery life, 报告周期, and maintenance plan.
A feature that looks impressive is not automatically a bad feature. It becomes a bad purchase when nobody uses it, nobody maintains it, and nobody budgets for its lifecycle.
How Should You Prioritize Features in Your Next Tender?
A tender should not reward the longest feature list. It should reward the clearest operational value and responsibility boundary.
Prioritize smart meter features by daily use, billing impact, alarm value, event traceability, battery maintenance, communication reliability, platform compatibility, and field response capability. Treat rare diagnostic functions as support tools, not main scoring items.

My Tender Priority Method
I start with the core job. The meter must measure correctly within its declared metrological range and rated working conditions. Smart functions should not disturb the metrological characteristics of the meter. ISO 4064 states that ancillary devices must not alter the metrological characteristics of the meter [5]. This is my first boundary.
Then I rank functions by daily value.
Remote reading is usually priority one because it supports billing and reduces manual collection work. Frozen data is also important because the NB-IoT system can display frozen meter data every night and save it in the database without change. Event records and alarm records are priority two because they support complaint investigation and abnormal condition response. Battery indication is priority three because it protects long-term operation and maintenance planning [6].
After that, I add project-specific options. If the project is prepaid, STS TOKEN logic and prepaid/postpaid configuration matter. If the project focuses on NRW, 泄漏检测, 干管检测, and better low-flow measurement may matter. If the project focuses on pressure management, optional pressure detection may matter. But I do not buy optional pressure detection unless the platform and field team can use it.
| Tender Priority | 特征 | Why I Rank It There |
|---|---|---|
| Must-have | metering and clear indication | basic utility operation |
| Must-have | remote reading and frozen data | billing and routine monitoring |
| Must-have | 事件记录 | complaint and traceability |
| Must-have | alarms and fault messages | faster abnormal response |
| Must-have | low battery indication | maintenance planning |
| Conditional | prepaid and TOKEN functions | only for prepaid projects |
| Conditional | pressure detection | only with analytics workflow |
| Support tool | test verification | commissioning and diagnosis |
I also specify the communication system. NB-IoT needs coverage, SIM or operator support, platform connection, and reporting-cycle control. LoRa or LoRaWAN may need gateways, 力量, 回程, 信号测试, and correct installation. M-Bus or RS485 needs cable design and concentrators. 仪表支持远程数据, but the system must move, 店铺, and use that data.
In the next tender, I would ask suppliers to separate “standard included,” “optional,” “project-specific,” and “diagnostic only” functions. This makes cost clearer and reduces the chance of paying for features that nobody will use.
相关阅读
结论
Specify remote reading, 事件记录, 警报, 电池状态, 平台规则, and response workflows first. Add advanced features only when your team will actually use them.







