When a council hears that a new AI capability carries a licence fee of around $100,000 per year, the instinctive reaction is predictable. Is it affordable? Is it necessary? Is it defensible to ratepayers? Those questions are understandable. But they are also the wrong place to start.
In the Australian local government context, scale matters but it must be properly defined. That is because population size, service complexity, and rate base do not move in lockstep. A council with a population of 20,000 might reasonably be described as a city whereas a council with 20,000 rateable properties might not. But it may still be a significant regional centre, a fast-growing fringe council, or a large rural authority managing a dispersed population across a wide geography.
This distinction matters because councils are funded per property, while services are experienced by people. AI value sits somewhere between the two. When those measures are blurred, cost conversations drift and hesitation becomes sticky. It is also why vendors price by organisational scale. It is not out of generosity, but because the underlying economics demand it.
So before debating AI investment as “a lot of money,” the math needs to be normalised (all cost debates drift unless they’re normalised properly). Using $100,000 as a reference point shows how quickly per-property cost collapses as scale increases, regardless of whether pricing is flat or tiered.
At this point, it is also important to place these numbers in the further context of existing tech investments.
Councils already accept a per-rateable-property cost for their core ERP platforms, typically somewhere in the range of $15 to $45 per property per year, depending on scale, module mix, and contractual structure. That cost is rarely debated in isolation because, after decades, the ERP is understood to be foundational. Against that baseline, an additional AI capability priced at around $100,000 per year looks very different.
At approximately 10,000 rateable properties, it adds around $10 per property per year on top of the existing ERP cost. By 15,000 properties, that incremental figure drops to around $6.70. At 20,000, it settles at $5. Beyond that, the marginal impact becomes progressively smaller. Approximately $3.30 per property at 30,000, $2.50 at 40,000, and around $2 per year for councils with 50,000 rateable properties.
Viewed this way, the question is no longer whether $10 per property is “a lot of money” in absolute terms. For some councils, it may represent a modest uplift on an already high ERP cost base. While for others, it could be a material increase of 25 per cent, 50 per cent, or even more. That variability matters and should not be ignored. The real question, however, is whether an incremental uplift of that order, relative to an already-accepted ERP baseline, can deliver measurable improvements in how work flows through the organisation and how residents experience council services. Framed properly, this becomes a value and design question, not a headline pricing debate.
This is precisely why vendors price by scale. Once costs are normalised in this way, the headline pricing debate largely dissolves. Even allowing for tiered models, the per-property burden quickly falls into single-digit dollars and, for larger councils, into background noise. At that point, the question is no longer affordability, but whether councils can extract even modest, repeatable value from the way work actually flows through the organisation.
And this is where the conversation often goes off course. While the per-property cost diminishes with scale, the underlying workload does not. Customer requests, regulatory enquiries, correspondence, and service follow-ups do not shrink in proportion to the rate base. In many cases, they grow faster. So while the cost becomes less visible, the operational pressure increases, and it is this mismatch that AI is meant to address.
AI is too often justified through internal productivity narratives. Faster drafting. Better summaries. Reduced administration. For example, HR efficiency is frequently positioned as a lead use case because it is familiar, controllable, and politically safe. There is nothing inherently wrong with this. In fact, under a PaaS-driven architecture, a reimagined corporate services model can deliver significant organisational value through better decision support, reduced friction, clearer accountability, and materially improved cost-to-serve across the enterprise. The problem arises when internal efficiency is presented as the primary value story for a rates-funded organisation.
While HR, finance, and corporate services matter enormously to how a council functions, they are not how residents experience council. Residents experience response times, clarity, follow-through, and consistency. When AI is justified almost exclusively through back-office gains, the connection between investment and community value becomes abstract, and the political-buyer argument weakens.
This is not a critique of corporate services transformation. It is simply a sequencing issue. Internal AI gains are real and important, but in a public-sector context they cannot carry the whole case on their own. The strongest AI strategies are those that improve internal capability and deliberately translate that capability into frontline service outcomes residents can see and feel. That is, where it is tied to the services P&L. If AI is going to earn its keep in a rates-funded environment, it must be applied where residents actually feel friction.
The highest-return workflows are also not sophisticated. They are the relentless “are we there yet?” pleas from the back seat. AI earns its keep not by inventing new destinations, but by giving everyone (staff and customers) a clear view of the journey. You know the questions:
“Where is my request up to?”
“Who is responsible for this?”
“What happens next?”
“Why did I receive this notice?”
“How long will this take?”
These questions generate enormous effort not because they are complex, but because they recur thousands of times a year across customer service, rates, planning, compliance, waste, roads, and facilities.
At that scale, small efficiency gains compound quickly. So saving thirty seconds per interaction across live, resident-facing workflows produces a return that dwarfs the original licence cost even at the smallest end of the scale. A three-to-five-times return is not ambitious. It is conservative. Yet many councils hesitate precisely here.
Instead of embedding AI into frontline workflows, there is comfort in quarantining it in the back office. Piloted in HR. Restricted to internal drafting. Treated as a novelty rather than an operational capability, twelve months later the conclusion quietly emerges that the value was unclear. The value was not unclear. The application was timid.
AI does not create value by existing. Like a financial derivative, it only generates value when it is anchored to an underlying asset. In this case, live workflows where volume and repetition provide the leverage.
Customer service. Request management. Rates and property enquiries. Regulatory correspondence. Field service updates translated into resident-ready language. These are the domains where AI will invisibly earn its licence investment many times over.
I think there is also a “sweet spot” where AI becomes almost impossible to argue against in local government. Somewhere between 15,000 and 40,000 rateable properties, the per-property cost drops low enough that the burden disappears, while service complexity remains high enough for compounding returns to take hold. That is a meaningful slice of the overall sector. At that point, the risk is no longer financial. It is organisational.
The uncomfortable truth is that at $5, or even $10, per property per year, AI does not need to be transformational to be worthwhile. It just needs to be used. Which is why the real AI question for councils is not “can we afford it?” but “are we prepared to change how work flows through the organisation?” In my experience, that is often a hard no (for reasons I’ve explore before). When the answer is no, no licence price will ever make sense. If the answer is yes, the return will arrive long before the debate finishes.
In the end, AI is not testing council budgets. It is testing council confidence. Confidence to stop hiding behind internal efficiency stories. Confidence to apply capability where residents actually notice. Confidence to accept that the real risk is not spending a few dollars per property, but failing to extract even modest value from it. That is the cost problem local government actually needs to confront.
What’s also worth being explicit about is this. Everything above is the business case and the strategic positioning for AI in the sector. AI belongs squarely in every council’s five-year technology and service roadmap.
This precedes demo theatre and product selection and any vendor comparison exercise. The strategy is actually straightforward. AI must be deliberately applied to high-volume, resident-facing workflows where small reductions in effort compound quickly over time, and where the value is felt directly by the community rather than disappearing invisibly inside the organisation.
Framed this way, AI is not a discretionary experiment or a short-term initiative. It is a structural capability that can be planned, sequenced, and embedded alongside other long-term service and platform decisions. And, unlike ERP projects, in relatively fast time.
Once the cost drops to a few dollars per rateable property per year, the strategic question is no longer financial. It becomes organisational and architectural. The issue is no longer whether council can afford AI, but whether it is prepared to redefine what “the system” actually is (for the next 5- or 10-year investment cycle). What is clear is that the system is no longer the ERP alone. It is the broader architectural framework through which work flows incorporating core transactional platforms, PaaS capabilities, integration layers, data, and now AI as a native component rather than an add-on.
So the real question, then, is whether council is willing to deliberately change how work moves through that system, rather than simply bolting new capability onto old pathways. That is the strategy and it has never been clearer in over a decade. Everything else is execution, including the discussion about whether any given AI product can actually do these things well. Some can, very well. Others simply claim and obfuscate.
That’s where we left things in 2025.
There was a growing tendency in the market to blur these two conversations. Councils were told that because the business case made sense, the product must therefore be fit for purpose. That leap is dangerous and fed the hesitation and anxiety we also saw. Establishing that AI should be applied to certain workflows is a strategy decision. Determining whether a specific solution can support those workflows, with acceptable accuracy, governance, integration, security, and operational maturity, is a product and architecture assessment.
Confusing the two simply leads to justified purchases, weak adoption, and quiet disappointment. So be clear-eyed about the sequence. First define where AI must create value. Then test whether the technology can actually deliver it in those places. Strategy before tooling, not the other way around.
For paid subscribers, I’ve outlined 20 representative workflows where AI can quickly earn its keep in local government. If you’re trying to assess which technical solutions can genuinely support this level of capability in practice, rather than simply claiming to, I’m always open to a conversation.
And if you’re doing that assessment yourself, the test is straightforward. If an AI solution whether a point capability or a platform in its own right cannot be embedded into a material subset of these workflows, the issue was never price. It is relevance. If it can, then the original question of whether $100,000 is “a lot of money” becomes almost impossible to sustain.
A brief clarification: I’m well aware there are AI offerings in the local government market priced well below and well above this level, and I expect the inevitable “ours is much cheaper” responses. That is a different conversation. At that point, the question shifts from cost to architecture and specifically whether a tool is a point solution or a platform capable of supporting AI at scale across the organisation over time. That distinction matters far more than the headline price, which I’ve used here simply as an indicative benchmark to unpack the broader argument.