Smart-city services: procurement should begin with a working public service

A city platform needs a practical purpose

The phrase smart city can describe a wide range of projects, from traffic information to maintenance scheduling and citizen-service requests. That breadth can make the opportunity appear large while leaving the business proposition vague. A supplier should begin with a specific public service and the people responsible for delivering it. The technology becomes useful when it helps them resolve a defined problem and continue doing so after the initial launch.

UN-Habitat's World Smart Cities Outlook 2024 focuses on people-centred smart-city development. This article uses that public reference as context for an independent commercial assessment. In BRICS urban markets, a credible proposition should connect infrastructure, staff capability and public accountability. A visually impressive dashboard is insufficient if the organisation receiving a report has no process or budget to act on it.

Map the service before specifying the system

Consider a maintenance request for a streetlight or a public facility. A complete service includes receiving the request, identifying the asset, deciding priority, assigning work, obtaining materials and confirming resolution. Different departments or contractors may own different steps. A supplier should understand these handoffs before promising that a new application will shorten the response time.

Interviews should include frontline staff and residents or service users where appropriate. The design must account for people who cannot easily use a digital channel. An accessible alternative may be necessary to ensure that a system does not improve convenience for one group while excluding another. These operating decisions affect staffing and cost, so they belong in the project scope rather than being treated as optional additions after procurement.

Distinguish an announcement from a funded contract

City strategies can identify important needs without specifying a purchasing timetable. A supplier's opportunity pipeline should therefore distinguish policy interest, budget allocation, procurement preparation and an awarded contract. The responsible public authority's current requirements must be checked for the specific project. A business should not assume that an international partnership or a technology demonstration creates permission to proceed directly to deployment.

Market sizing should count the service units the business can actually support: facilities, assets, users or transactions, depending on the offer. Estimate revenue using plausible contract terms and delivery capacity. A city's population is a poor revenue base for a product bought by one department with a limited budget. The difference between social reach and paying customers needs to remain explicit.

Plan for the operating life of the service

Implementation costs include data preparation, integration, training and the effort needed to change established workflows. Recurring costs include hosting, support, equipment maintenance and updates. An illustrative scenario can compare a limited district deployment with a citywide expansion, allowing for additional coordination as the number of departments increases. These are planning assumptions rather than a forecast of public spending.

The project also needs an orderly exit or supplier-change plan. Public organisations should be able to retrieve their information and understand essential operating documentation. A service that depends on undocumented customisations can become expensive to maintain. Clear ownership, access controls and data export arrangements should be addressed early, with appropriate review of the obligations applying to the information involved.

Measure outcomes that staff can influence

• Track elapsed time at each stage of a service request, rather than only total requests received.
• Record unresolved cases and the reason they are waiting.
• Check whether completed work was accepted by the responsible service team.
• Review use across different access channels so performance does not hide exclusion.

Metrics should also reveal whether additional demand creates a staffing bottleneck. A successful reporting tool may make previously invisible maintenance needs apparent. If operating budgets remain unchanged, the number of open cases can rise even though discovery has improved. Suppliers and public managers need to interpret that result honestly rather than treating every increased count as failure or every new submission as success.

Build partnerships around accountable roles

BRICS businesses can collaborate through engineering, equipment, software and local service expertise. The partnership should identify who supports the public customer, who maintains the infrastructure and who resolves a cross-system incident. A collection of capable vendors does not automatically function as a coherent service. Integration responsibility must be assigned rather than left between contracts.

Local knowledge is particularly valuable in understanding assets, operating conditions and service expectations. A design that works in one city may depend on staffing or infrastructure that is absent elsewhere. A pilot should test these dependencies and include a plan for reviewing results before expansion. The pilot's purpose is to learn, not merely to provide photographs for a launch announcement.

Commercial durability follows public usefulness

A supplier can build a stronger position by helping a public organisation deliver a modest service reliably than by promising a universal platform without an operating model. Project records, service tickets, asset information and finance should provide a consistent view of obligations and results. Repeatable delivery, transparent costs and usable documentation can support future opportunities. Growth should follow evidence that the service works for the institution and the people it serves.