The Smart City Shortcut: Why Sensors Alone Do Not Make Better Public Services

The most common smart city mistake is buying sensors before deciding what a public service should do with their readings. The cost is not merely idle equipment: residents may still wait for a bus, report a flooded underpass, or seek help from an office that cannot use the data it collects. Across Asian cities, the better question is not how many devices can be installed, but whether a useful decision follows.

Sensors can describe conditions, such as air quality, water level, or traffic flow. They do not assign staff, change a service rule, explain a delay, or make an office answerable. These seven checks expose the gap between collecting information and improving a service.

1. Name the service decision before choosing a sensor

Start with the decision an agency needs to make. A sensor is relevant only if its reading can change that decision in a defined way. “Monitor the neighborhood” is too vague to guide a purchase or tell staff what to do next.

For a drainage service, the useful question might be whether a reported water level should prompt an inspection of a particular underpass. That raises practical questions: who receives the alert, who can visit, and what happens if the reading conflicts with a resident’s report? If those questions have no answers, more precise readings will not create a response.

Write the service problem in ordinary language before discussing hardware. That keeps procurement focused on a public task rather than on a device looking for a purpose.

2. Give every alert an owner and a next action

An alert is a message, not a service. Someone must be responsible for reviewing it, deciding whether it requires action, and passing it to the right team. Without that chain, an operations dashboard can become an especially polished place for unresolved problems to sit.

Imagine a municipal team responsible for a low-lying road receives a water-level alert during heavy rain. The team has agreed that a designated duty officer will check the location and notify the road crew if access is affected. In this invented situation, the observable result to look for is whether the alert leads to a recorded inspection and a clear update for people using the road, rather than merely appearing on a screen.

Responsibility should include what happens outside office hours and when a signal is missing or implausible. A service process that works only when the right person happens to be nearby is not a dependable process.

3. Make the service legible to people without an app

Public services need more than one doorway. Some residents have limited data access, use older phones, need accessible formats, or prefer to speak with a person. A sensor-supported service should not quietly become an app-only service.

Keep established options such as a staffed counter, telephone line, or in-person report where they remain useful. If a new system changes how people receive updates, explain the change in plain language and provide a way to ask for help. Notices at transit stops or service offices can matter as much as a mobile interface.

Access also concerns what residents can see. A status message such as “request received” is not the same as an explanation of who is handling the request or what the next step is. Clear, limited information can reduce confusion without exposing personal details or turning a service screen into a wall of unexplained technical terms.

4. Treat data quality as a service condition

A reading can be wrong, incomplete, delayed, or taken from a place that does not represent the condition residents care about. Placement matters: a sensor near a road may describe that spot, not every street in the district. Agencies should record what a device measures, where it is installed, and what its limits are.

Staff also need a way to handle disagreement between a sensor reading and other information. A resident’s report, a site visit, or a second source may reveal that a device is obstructed or that the situation has changed. The service should have a sensible fallback rather than treating a dashboard as the final authority.

For decisions with consequences for access, eligibility, or enforcement, keep a human review route. Data can inform judgment; it should not make a contested decision impossible to question.

5. Budget for upkeep, not just installation

Devices need attention after they are installed. Batteries, connectivity, calibration, weather exposure, software changes, and replacement parts all affect whether a reading remains useful. A procurement plan that pays for installation but has no named maintenance team leaves the service dependent on equipment nobody is tasked to care for.

Before approving a system, ask which department checks device status, how faults are reported, and who can arrange repairs. Also ask whether local technicians can support the equipment or whether ordinary maintenance depends on a distant supplier. Those answers influence how readily a service can recover when a device stops reporting.

It is not worth the effort to build a grand dashboard with a separate display for every sensor if staff still lack a workable fault-reporting process. A modest set of clear service alerts is often easier to maintain than a screen designed to impress visitors.

6. Connect departments without losing accountability

City services often cross organizational boundaries. A flood report might involve drainage, roads, transit, and emergency management; the relevant data may sit in different systems. Sharing information can help, but it does not automatically settle who is responsible for acting.

Agree on basic operating arrangements before linking systems: which team owns the case, what information another team needs, and how a handoff is recorded. Use only the data needed for the task, and make access rules understandable to staff. A shared platform is useful when it clarifies coordination, not when it merely gives everyone another login.

Residents should not have to identify the internal department structure to get a problem addressed. The service can route a request behind the scenes while still giving the person a clear contact point and an update on its status.

7. Review whether the service changed, not whether the device reported

Counting active sensors answers a procurement question. It does not answer whether public service improved. Review the service process instead: Are reports reaching the correct team? Are staff able to respond? Can residents understand what happened? Are recurring faults being identified and addressed?

Choose a small set of observable checks suited to the service, and review them with the staff who handle the work and the people who use it. If alerts arrive but no action follows, revise the workflow. If the device adds little useful information, consider changing its role or removing it. The point is to make decisions based on service experience, not to defend equipment simply because it has already been installed.

How should a city decide whether sensors belong in a service?