Street Lighting Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the asset register get scoped as a data import so often?

Because there appear to be three sources and each one looks authoritative. Public Works has a geographic information system layer with pole locations. The utility sends a billing file with fixture counts by wattage class. The contractor who ran your light emitting diode conversion handed over a closeout spreadsheet. A supplier looks at that and quotes a load and merge.

Then you compare them. The conversion corridor shows as 250 watt high pressure sodium in the utility file because the change form used the old fixture code. A subdivision dedicated to the city three years ago appears in no file at all. Three poles knocked down and never replaced are still billed. Your layer uses your identifiers, the utility uses theirs, and the field has neither painted on it.

The fix is to design the register around uncertainty instead of pretending it away. Every record carries a source of truth flag and a date, so a fixture confirmed by a field survey last year is visibly different from one inherited from a closeout file. Nothing that feeds a billing dispute or a savings report is allowed to rest on an unconfirmed record. Then plan a field survey as part of the project, prioritised by the corridors where the sources disagree, and run it with the mobile app you just built rather than treating it as a surprise afterwards.

What goes wrong when the utility billing file is matched to your GIS layer?

The identifiers do not match, and that is the whole problem. The utility's file is keyed on their pole or account references. Your geographic information system layer is keyed on yours. Neither key exists on the other side, and a straight join returns almost nothing.

Suppliers who have not done this before propose a lookup table. On a real estate of ten thousand luminaires that table cannot be built by hand, and the residue after any automated pass is where the money is: the records that do not match cleanly are exactly the ones that were changed, added or removed without paperwork.

The other trap is the one to many shape. A pole can carry two luminaires on different circuits, one of them a decorative fixture the city owns and one a cobra head the utility bills. A model that assumes one light per pole quietly corrupts your counts in both directions.

The fix is spatial matching first, fuzzy identifier matching second, and a human review queue for whatever is left. Match on location within a tolerance, then on identifier similarity, then present the unresolved set to a person with a map and a photo. Expect a residue of a few percent and budget staff time for it. Ask any supplier how they handle unmatched records before you ask about anything else, because that answer tells you whether they have seen a real utility file.

Why do controller vendor integrations break after launch?

Because they were built as a dependency rather than an adapter, and because your estate will not stay on one vendor. Cities buy controllers in waves, so a typical estate carries nodes from two or three suppliers plus thousands of fixtures with no node at all. The failures follow a pattern.

• Authentication and rate limits differ per vendor, and a build that hard codes one vendor's behaviour breaks when the second arrives during a transition.
• Alarm semantics differ. One vendor's lamp fault is another's communication failure, and if you pass raw alarms into work orders your crews get dispatched for the wrong thing.
• The nodes only see themselves. A control management system knows nothing about the unnoded fixtures, so any report built purely on controller data understates your estate.

The fix is to normalise into your own internal model before anything else consumes it. Each vendor gets an adapter, alarms and status map to your schema, and the work order flow never learns whose node reported the fault. The TALQ interoperability standard helps on the control interface and is worth asking about, but standardising control does not give you a register, a bill check or a work order. Treat controller integration as phase two: the register, reconciliation and work orders deliver value with zero connected nodes.

What happens when outage intake and work orders are not joined up?

You get the same dark pole reported four times and fixed once, slowly. Residents report through a 311 platform, a web form, a phone call to a council office and sometimes a social post. Controller alarms land in a vendor portal the maintenance crew does not open. Crews notice faults on patrol and mention them.

The report itself is usually unusable: the light is out near the corner of Elm and Fifth describes four poles. A crew is dispatched with no pole identifier, spends time locating the right one, finds it needs a part they did not bring, and returns another day. Meanwhile a second ticket has been raised for the same pole and someone will close one of them as a duplicate without checking which.

This is not only a service quality issue. Outage duration on a street the city owns becomes a liability conversation after a night time collision, and the question in a deposition is when you knew and what you did. A ticket in one system, an alarm in another and a work order in a third is not an answer.

The fix is to deduplicate at the pole, not at the ticket. Every channel attaches to one issue on a specific pole, with additional reporters added as notification subscribers. The crew receives a work order carrying the pole identifier, coordinates, fixture type, expected part and last work history, and closes it in the field with a photo.

Should you build custom or configure what you already own?

Plenty of agencies should not build, and the test is simple. If the utility owns the poles and the lights and maintains them under a full service tariff, and you have no conversion programme underway, your best move is a data request and a sample audit on foot, not a system. If you own fewer than roughly 1,500 lights and your complaint volume is manageable, a well maintained geographic information system layer plus your existing work order system is proportionate, and the money is better spent on lamps.

If you already run Itron Streetlight.Vision, use it for what it is good at. It is a mature control management system that supports nodes from several vendors, which genuinely helps a mixed estate. Signify Interact City is a sensible default when your luminaires and controllers are Signify. Telensa, Ubicquia and Tvilight all deliver competent control and analytics on the devices they sell. Configure those for control, scheduling, dimming and fault reporting, and do not rebuild any of it.

What none of them do is reconcile an unmetered billing file against a city owned asset register, because that reconciliation needs your tariff, your layer and your fixtures, including the ones with no node. Build when you own the assets and pay an unmetered tariff you cannot verify, when you carry a savings guarantee you cannot substantiate, when you run controllers from more than one vendor, or when your inventory came from a conversion contractor and nobody has independently confirmed it.

How do hidden costs get into the quote?

Through work that is real but does not look like software.

• The field survey. If the register is going to be trustworthy, somebody walks or drives the estate. This is labour, it is not optional, and it belongs in the project budget rather than arriving as a surprise in month four.
• Data reconciliation. Merging a geographic information system layer, a utility file and a closeout spreadsheet into one register with confidence flags is analyst work with a human review queue attached.
• Each controller vendor is its own adapter, with its own authentication, its own alarm vocabulary and its own test cycle.
• Integration with 311, Cityworks or Accela. Residents will keep using the channel they know and crews will resist a second work order system, so a two way sync is usually mandatory rather than optional.
• A public facing outage map, which brings accessibility conformance and a different security posture.
• Tariff changes. When the utility revises the tariff sheet, your expected charge calculation has to follow, and that is a recurring maintenance cost.

Ask for the quote split into register, reconciliation, work management and each integration named separately.

What separates a build that works from one that fails here?

Starting with the piece that pays. Register plus billing reconciliation plus work orders is the value core and it works with zero connected nodes. Cities that lead with controller integration spend the first four months on vendor interfaces and still cannot tell council what they own, which is the question they were actually asked.

The second marker is that the variance report is a first class output, not a screen. What gets bills corrected is a document listing what is billed but not in your register, what is in your register but not billed, and what is billed at a wattage your register disputes, with location evidence attached and the expected charge computed from the tariff schedule. Hand that to the utility and the conversation changes. Show them a dashboard and it does not.

When vetting a developer, ask how they would reconcile the billing file when the identifiers do not match. A lookup table is the wrong answer. Ask how they model a pole with two luminaires on different circuits, because your estate has them. Ask which systems they have actually integrated by name, on both the controller side and the city side, since Cityworks and Accela are known quantities to people who have done the work.

Then settle ownership in writing before kickoff: repository, database and cloud accounts. At Digital Heroes the client owns the code from the first commit. A lighting register is a public asset record that will outlive several vendor relationships and may be cited in a claim years later, so it should not sit in infrastructure a supplier controls.