← 返回

2026.09.23 | TB | Software | Hansen Energy Retail Platform

原标题：Hansen Technologies – Customer Evaluation on the Energy Retail Platform

#software

Third Bridge · 2026-09-23

Analyst-led • 8 Sep 2026

Companies: HSN AU, CRM US

Matt Grantham (MG) Independent Consultant

Joanna Chan (JC) — Third Bridge Sector Analyst

Agenda

Key Insights

Introduction

JC [00:00:04]: Welcome to Third Bridge's Interview entitled Hansen Technologies – Customer Evaluation on the Energy Retail Platform. I'm Joanna Chan, and I'll be facilitating today's Interview with Mr Matt Grantham, former Head, Operational Technology, Energy Australia and New Zealand at Veolia Environnement SA.

Before we start today's Interview, please state I agree or I disagree to the following statement: You understand the definition of material non-public information and agree not to disclose any such information, or any other information which is confidential, during this Interview.

MG [00:00:42]: I agree.

JC [00:00:43]: Could you please begin with a brief introduction about yourself?

MG [00:00:50]: Certainly. My name is Matt Grantham. Formerly worked for Veolia Energy in a Head of Technology role, Head of Operational Technology. Prior to that, I have experience working on the vendor side in terms of billing systems, having previously worked over two years ago now for Tally Group. That's my background. It's very much embedded in the Australian energy market context. Any responses that I give will be very focused on this geography and less able to comment on anything to do with Hansen's general technology stack outside of energy retail, specifically in the Australian market.

Questions

[00:01:40] Hansen Technologies' growth relies on buying regional billing software rather than building a single global core platform. How fragmented are these regional stacks? How does the company's legacy architecture in Australia compare to modular cloud-native engines such as Kraken?

MG [00:02:02]: I have no real working knowledge inside as in having worked for Hansen. Their specific architecture is not something that I have a really detailed knowledge of, but I can speak generally about the platforms globally in terms of how billing systems operate. At a high level, there's providers out there. Kraken is one that's known globally. They have an architecture where they have a SaaS product that sits globally across what they do vs the historic legacy way of doing things, which was through acquisition. There's Hansen and there's a number of other billing providers out there that have gone and essentially M&A or bought different billing technologies across the world. Those without commenting on where Hansen is up to in terms of integrating and bringing any of their systems together, those systems are traditionally very difficult to bring together. It's very challenging to bring together a lot of legacy systems and turn them into a SaaS product. Not to say that it couldn't necessarily be done because there's a lot of AI and a lot of things out there, but that would be something that I would comment at a high level there that these legacy systems are inherently difficult to bring into one overall SaaS product.

[00:03:36] From a user perspective, how do you view Hansen's platform? Is it fragmented between different modules and features instead of being a single core platform? How does it compare to cloud-native engines such as Kraken?

MG [00:03:57]: In terms of its architecture, as I said, I don't have an inner working knowledge. I've never worked for Hansen. I've done some loose integrations with them in previous roles. But an answer to your question is that's how I would define it, leaning back on that earlier response that I gave is that there are lots of different billing systems and you're either a SaaS-native system or you're not a SaaS-native system. You can try to convert older systems and bring them into a new system in terms of a cloud system, but there's also the way that architecture works is that it can be cloud-based but not necessarily cloud-native, so to speak, as in architected from the beginning with the idea that you'll have just tenants, if you like, of customers that might sit globally under a single software architecture.

[00:05:00] How do you view the differences in user experience between SaaS and cloud-native platforms?

MG [00:05:09]: The user experience is that you're generally tied into the system that you've got that's being made compliant to your specific market. In the energy market, specifically, they have to integrate with – in Australia, it's called AEMO – the market operator that gets all of the data and processes the bills, etc. Each one of those integration points can be quite unique globally. Just because you've got a billing product and a billing platform that has integrated nicely in Australia, doesn't necessarily mean it will integrate nicely in a part of Europe or a part of North America, depending on what their equivalent of that market operator is.

The advantage you get from a SaaS offering is that you can deploy code over the top. When someone makes some upgrade in the case you mentioned there before of Kraken, someone makes some upgrade in London for their platform over there is that it can then be more easily enabled and switched on in other countries than it might be able to if you're dealing with essentially separate billing products across the world. Not to say it's easy and they will tenant things and separate them all, etc, but that process just gets easier with a SaaS-like offering and being able to take code that you might deploy in another country that if it does work in Mexico or wherever you happen to be, Japan, that you can more easily do it, and it's just a bit faster to do. Its ability to move and deploy to market is quicker.

Generally speaking, there's always ifs and buts and sometimes you can have local providers that are doing customisation. You lose on the other side of it, you lose the ability to customise and do things really locally in terms of having your own code base and structure. You lose some of that, but you gain efficiencies if your platform has got a SaaS offering and it's able to, for example, make market changes, which is when energy markets bring in different changes, they're able to do that and share the cost among all of the customers they might have in a particular region vs having to do it all for that one customer who might have a highly customised version of whatever that operating system is.

[00:07:50] How important is the advantage of a SaaS platform in deploying code and original modules to clients?

MG [00:08:04]: As I said, speaking at a high level, it seems to be getting increasingly important. I would believe that there's a bit of a tailwind in the market. You can see that through the success that Kraken and others have had in terms of their market penetration and winning deals in that space. I think customers view it as increasingly important. They also view some of the compliance advantages you get from that for a vendor that is in multiple markets that's able to share those compliance costs, I think they view that as increasingly important because it minimises their need for testing in some cases and just generally can make their overall operations a little bit lower cost.

JC [00:09:02]: Do you have an estimate of the lower operational cost?

MG [00:09:09]: If I speak generally, I can speak very generally, is that… This is in the Australian context, that if you have a billing vendor, that goes out to market and now market operator brings in a market change of AUD 1m, as a random number, is that for legacy providers where they've got their own code base or a low number of customers on that code base, if it's one customer, then that one customer usually under those billing contracts will have to pay the full AUD 1m if there's just one customer on the system, and there's no way to share that, once the platforms… Even if there's two, but they're highly customised, they may need to pay AUD 1m each for two customers. If you've got a true SaaS offering, those providers can either absorb that within their SaaS fees that they've got or they can then choose to share it evenly or provide some model there where they make the bigger customers pay 30% each and everyone else pays 10% each or something like that, but they're better able to share that compliance cost. In a SaaS world, they're better (inaudible 10.30).

What you lose, though, is you lose the ability to have your specific rules because then you might have a weirder rule, so this is the downside of it is that if you have one or two particularly large customers who say, "Look, we think this type of calculation should be done in this way," and other smaller vendors disagree, they think, "Our legal team says we should do it in an alternate way" or "We're not quite sure that calculation is correct," then they're all on one code base. Then it biases towards the biggest, loudest voices on the platform setting the rules and everybody else just having to follow on. Then in the event there's any challenges with regulators, everybody says, "We're all in the same boat, the big guys do it this way." That's how our billing system calculated it, and then they would have to plead forgiveness from a regulator if there were to be some disagreement about how a particular calculation for the energy market is done.

[00:11:35] What are the primary functional and usability differences between a legacy and cloud-native system? Where does each system hold a competitive advantage?

MG [00:11:51]: Cloud-native systems's data is just more accessible. I'm speaking at a very high level here, just generally speaking. It tends to be a bit more accessible and it would tend to be a little bit more ready for some of the future use cases that retailers are looking at. Having the latest versions of data and being able to integrate them nicely to be able to run your own custom reports off that data and having that data there so you can self-serve and use the data in your way. That's traditionally, and I'm speaking very generally because some of those cloud-native systems, it's still not that easy to do that, but just at a high level, that tends to be easier for them. For legacy systems where they might have multiple databases, lots of things strung together, for example, for a pricing change or something like that, if there's lots of parts of the billing engine where that price needs to be changed in the system, then that can lead to challenges operationally because you have to make sure you're changing it in multiple parts of the system to make sure the calculation flows through correctly, at a high level. Hansen, I wouldn't know Hansen's specific, how complicated it is within their systems for that, but that's just a general overview of how legacy platforms work vs the cloud-native ones.

[00:13:26] How long does it take to introduce price changes on a legacy platform compared to a cloud system where data is more accessible?

MG [00:13:40]: That's very difficult because it will depend on the type of change you want. What we can say is that, generally speaking, they are a lot easier to do on a cloud system and a lot harder to do on a legacy system. I think that's an appropriate answer to that question. There would be some things you could change on a legacy system that actually wouldn't be too bad. I don't want to necessarily throw the baby out with the bathwater there, but as a general principle, a lot of the legacy architecture struggles a bit more relative to the cloud-based or the next-generation-type platforms where that data is able to be more easily accessed.

[00:14:24] How do Hansen's operating and integration costs compare to cloud-native platforms as customer volume scale?

MG [00:14:35]: Again, as I said, I wouldn't talk specifically to Hansen here, but some of the points I've made earlier do apply those laws of economics would apply is that if you have lots of customers on your platform and it's SaaS-based and you can win more customers and smear that cost across, then specifically, if you look at compliance in particular, that cost then is not a lot lower, but it's a chunk lower than it might be if you were one of the two customers on that platform that needed to manage market share on your own and you didn't have the ability to share that cost around as easily. That cost of ownership rises on legacy platforms, and that can be one of the things that eventually gets retailers or owners to think, "This is just costing us too much in terms of what our cost is relative to migrating or what those options are." That's one of the ownership costs as well as compliance is one of them.

There's also integrations with Salesforce and CRMs and all these other things that need to happen. Once they're built and in place, then they're generally fine, but quite often, some of the set-up costs depending on how complex the ecosystem of the retailer is, there can be costs of legacy systems. Just generally speaking, again, not specifically to Hansen, but generally speaking, it's a little bit easier to integrate cloud-native systems and the next generation of cloud-based systems relative to some of the legacy ones, even for CRMs and other bits and pieces like that.

[00:16:30] How much could clients save on shared compliance costs without having to pay the integration and set-up cost for a legacy system?

MG [00:16:50]: It's going to depend on their volume. It will depend on the following factors. Essentially, it depends on how easily their vendor is able to or how willing their new vendor, their alternative non-legacy vendor, are to want to share the cost of that compliance cost with their clients and how they want to do that. They're dependent on the billing vendor to do that. It's willingness by the alternate vendor and it's also then the scale of what that vendor has to play with themselves. If you've got 20 customers and even if you just divide it by 20, and you've gone out aggressively and won market share and you could divide that evenly across 20 customers, then that's going to be materially different to a vendor who has only got it across two even if they're cloud-native and that they're easy to work with. If there's AUD 1m cost and you're sharing it somehow, whether it's SaaS fees or in terms of your contract, if you're sharing that cost among two customers, it's AUD 500,000 each. If you can share across 20, then obviously, it's a lot less.

Customer numbers and willingness of vendor are the two key elements, and quantity as well. Some of these things can come in fairly regularly in the Australian market about these market changes. Sometimes they can just disappear for a few years or not be too much. I wouldn't say disappear. It never works out that way, but they can be more in some years than others, let's just say that.

[00:18:30] How is the competitive dynamic shifting in the Australian market between legacy providers, such as Hansen, and market disruptors, such as Kraken or Salesforce, in winning new energy retail bids?

MG [00:18:45]: I think that would all be fairly publicly available. I think legacy providers are not gaining market share and the new entrants are gaining market share. A lot of it is around some of those cost-to-serve elements. Some of them have been strategic things that have happened with Kraken and Origin in the Australian market. That's all publicly available. The dynamic would certainly… The tailwind would certainly sit with the new providers and away from the legacy providers, I think that dynamic is playing out or has played out, if you can make a case for that in the Australian market.

[00:19:31] Is there a pattern within the clients' tendency to shift to a SaaS provider, say, for a large energy client vs small-to-mid business clients? Do you observe a difference in their preference towards legacy providers vs cloud-native providers?

MG [00:20:03]: No, I think both segments have got some of the same pressures and some of the same software challenges. I don't see there being necessarily a material difference in whether you've got a C&I customer or a B2B customer vs a small-market customer. I think both of them have pressures to change for different reasons, but I see the tailwind applying, I would say, roughly equally to both of them.

[00:20:30] How rapidly could energy utilities transition away from legacy stacks over the next 2-3 years? What percentage would remain in the legacy stacks, and how defensible is Hansen's footprint if it fails to deliver a true cloud-native solution?

MG [00:20:52]: That's a really difficult question to answer. You'd have to speak to the individual utilities who were on that system and establish what their plans are. I have no knowledge of how quickly. What I do know, I can speak openly is that it's very difficult to migrate billing systems. This is a decision that retailers won't take lightly and it's generally always easier to stay with your legacy billing provider. When you're going through any sort of transition, it's a big exercise to put one billing to take one billing system out and put it in. How defensible over what period of time is very difficult to manage, but it's certainly something that retailers will not undertake on a whim. It's a huge upheaval for an organisation, so there is certainly stickiness for a billing vendor once they're in. That's a general industry trend, not something specific to Hansen, but obviously, it would apply to Hansen if they're the incumbent.

[00:22:03] What are your thoughts on Hansen's overall competitiveness and the strength of its core technology stack?

MG [00:22:15]: Speaking of Hansen, I think, overall, its competitiveness, probably just with the trends I've outlined earlier, is moving, is dropping off. If they can find a way to migrate and go to a single SaaS offering and find a way to pivot across to what the market is looking for, what the market appears to be looking for, which is this kind of overall SaaS product that's easy to innovate on, that's got lower compliance costs, all those things, and it can stay as the incumbent while it makes that transition, then it can improve its competitiveness.

As you've articulated, there's lots of different versions of billing all around the world that Hansen have got across all of their markets, so it's very difficult for me to comment on all of them. I just have no visibility of what their North American operations and how good their billing system is over there vs the European stuff. That would not be… Given Australia is probably a small part of their revenue, I don't think it's too fair to comment on just their Australian offering and take that as representative of globally where their individual billing systems, their individual products sit globally. I would just be cautious of that, but the principle of what I've said probably throughout this would be that the overall competitiveness drops off unless they can find a way to do what their competitors are doing and start to bring some of those cost savings of having an overall unified platform and then translating some of those savings to their customers in terms of reduced cost as well as allowing customers to innovate faster and do the things they want to do with their platform.

The Australian market, I would say their competitiveness is probably waning a little bit, would be fair. I don't know when their last big win was, I don't know. I think relative the market is speaking with Kraken and Kaluza and others that are implementing and integrating clients over here, Hansen doesn't seem to be winning those deals like it maybe once did.

[00:25:19] You said Hansen should allow clients to innovate faster. The company outlined a transition strategy emphasising AI enablement and upgraded capabilities in its FY26 results. How effectively could AI or automation layers be retrofitted onto its legacy core? How could that improve time-to-market for energy retailers?

MG [00:25:48]: That is an extremely difficult question to give a very effective answer on. The most balanced way I could say it is that AI is improving very, very rapidly. Provided they can harness some of those things, I don't have any inner working knowledge of how difficult or challenging their particular stacks might be to bring under a unified product, if that's their vision that they're outlaying to the market. It would be highly challenging. I won't say that that is not, but what's AI's capability and what AI does position, it does enable that. It's very powerful and very clever, and it's getting cleverer and better as we speak. The short answer is I don't know because I don't have visibility of all of the architecture of all of the different technology stacks. I don't have good visibility of where AI is at in terms of being able to bring these and unify these all together and/or where it will be in 12 months' time. That probably is the best… Do you believe the team that they've got there has the ability to deliver on that promise? I don't have a good view on that one way or the other. If they do, then they'll obviously do well, but I don't have any good view on how hard it will be for their particular legacy infrastructure globally. It is very difficult to answer because the technology of AI is also moving very quickly as well.

[00:27:49] You mentioned that Hansen's competitiveness is dropping off. Aside from moving to SaaS or offering shared-savings models, what customer demands does the company need to innovate on faster?

MG [00:28:16]: I think it's ease of integration. It's the ability to quickly offer new products as they come to market. If you want to quickly pivot across and change a feed-in tariff or you want to incorporate some battery technology that requires some off-market data streams, all of that sort of stuff is the thing, and the ability to maybe change operational models as well in terms of how quickly might something be able to be integrated with a CRM that then could serve up that data or that billing information to an agent, how easy it is to integrate with the Salesforce or whatever the CRM of choice is for that vendor. It's really all of those things, and it's about helping the retailers to have essentially a low cost-to-serve per customer. Energy retailing is a particularly thin-margin game. Being able to help customers to reduce that cost to serve is probably the big thing. Then obviously, as I said, the innovation on products, EVs are starting to come to market, batteries, etc.

[00:29:39] Where do you think clients are noting the biggest gap in Hansen's technology stack or overall products?

MG [00:29:49]: If you put it into that bucket, I think it will probably be in that cost-to-serve bucket. That, as I said, encompasses a whole lot of things, which will be how quickly they can build dashboards on top of that data, how quickly they can access that data, how easy it is to change product configurations and get out there and test products quickly? Those I would predict would be some of the challenges that they will be facing.

[00:30:30] How easily does Hansen's core billing stack integrate with external orchestration layers for distributed energy resources such as solar, residential batteries and EV smart charging tariffs?

MG [00:30:47]: I don't have any knowledge specifically of what they're doing in the market. It's not to say that they're not doing anything, but that's one that I don't have any visibility that they are doing directly. They might be doing it through different layers that sit on top of their billing, but I don't they've got some EV charging tariffs are in place. I'm sure they've got some of those in place, but they might be maybe more basic tariffs than anything too complicated. I don't have a really good view of that one, to be honest, but I want to say is I wouldn't say that the people who use them, so there's one customer, Amber Electric, who's done things in Australia, and they've got some really complicated tariffs. I'm unaware of what Hansen is doing in that space other than to say I don't hear it doing it. Nothing that is visible to me.

[00:31:51] How critical are DER [distributed energy resources] orchestration capabilities to utilities' customers, and how heavily do they weigh on clients' decision to renew or switch platforms?

MG [00:32:07]: I think a lot of them have… I think they know that that future is starting to come in, and I can speak generally in the Australian context is that they're all doing testing at the moment on what they call vehicle-to-grid and vehicle-to-load and the integration of electric vehicles and then being able to transact back with the grid is something that is on the cusp of starting to scale. The answer is it is going to be critical, but the question is when does that criticality arrive, and is that a customer base that the retailers, in this case, Hansen that you're asking about, might be working with? Is this a priority for their customers? The answer might be no, it's not, or the answer might be, yes, it is.

I think, generally speaking, over time, customers are going to want more of this as a general trend, but I wouldn't be able to comment specifically on what Hansen's customers would want and whether that's going to be critical for them or not, but as a market trend, I think that more and more customers in the Australian market are looking at their vendor through the lens of how is this DER orchestration going to work so that I can transact this value with my end customers, bill it correctly. Then obviously, how do I then also display that and make sure that that data then flows through to a user experience for a customer that then means what they get on their bill is the same as what they get in their user experience.

[00:33:47] What are the key architectural bottlenecks that energy retailers face when scaling or customising workflows on Hansen's platform?

MG [00:33:59]: I'll speak generally to legacy platforms, not Hansen specifically because, again, that is something where… The bottlenecks, some of them are easy or depending on what you're trying to do, are okay and manageable and some of them are quite complicated or depending on the complexity of the product or how many different bits of the billing system it might touch. I can speak at a high level, but it loops back to maybe some of the theme that I had said earlier, which is that some of these things are older systems and that as a result, when you're doing any testing or making any changes across something that touches lots of architectural pieces as you go… For an example, and I'll speak generally without talking about Hansen here, is that if you can imagine in some legacy bits of software, you might have a scenario when you put a price change and you might need to change it in four places, for example, within… That flows through nicely when customer calculation… All five places. That makes it harder vs a new provider where you change it in one place and then that information then flows through and gets built and that becomes a source of truth and it becomes nice and easy to manage or easier to manage than if you've got a place where you've got to change it in multiple places.

For example, I have no good visibility of how tricky or hard that is specifically in that pricing example, how difficult that would be within Hansen's platform, but that just gives you an idea. If you're asking the question about architectural bottlenecks, that I would say is one of an example of an architectural bottleneck where if you need to bring in a new price or do something and it has to get tested across multiple bits of testing, then it slows that process down, and it means that instead of you being able to get out quickly and for a lower cost, test the product in market and go, okay, this pricing doesn't work or we're going to change this, it just speeds up the iteration cycle so you can get to a final product that might have product market fit for end customers, you can get there faster, whereas if you've got an architecturally more complicated environment that traditionally, again, not specific to Hansen, but traditionally legacy platforms have had, then you just are slower. You've got to test in four places. It takes longer. It's generally more costly. If you talk about architectural bottlenecks, that will be just one example of how that might work, practically speaking.

[00:36:57] What difficulties have you faced when using Hansen's platform?

MG [00:37:07]: I wouldn't want to comment because even in that case of pricing, I don't have enough of a working knowledge of the changes that need to get made within their platform to comment on that comfortably. Speaking generally, I used that random number of four. It could be 10 or it could be two or it could be one depending on exactly how it works, but generally speaking, the legacy platforms will be a lot more than the new architected, cloud-based platforms where they're pulling from a single source of truth for the pricing or whatever information they need. They're just less open-handed.

[00:37:55] Could you break down the process and time lag required for customers to update model inputs in Hansen's legacy platform?

MG [00:38:11]: For your audience, there's a huge amount of complexity and it's going to depend what the product is. Are you just changing a feed-in tariff rate, or are you looking to bring in a more complex solution to do with batteries or… It depends what the change is, but certainly, I would say, at a very high level, something could take 3-4x as long. In a proper old-school legacy system, it could take 3-4x as long and cost 3-4x than it might in a newer, well-architected system where the data flows through in a bit more of a smoother way and there's less points of failure and less testing required.

[00:39:00] What would be the hardest change to make on a legacy platform compared to a SaaS platform?

MG [00:39:15]: That takes the longest? Anything that's really complex, anything to do with bringing in feeds of data that the system might not be used to, bringing in what we call off-market data would be challenging because it's not data that's in the format that they process energy market data in AEMO, which is generally in what they call NEM12 form. If you wanted to do any billing on different forms of data, I would imagine, again, without having any specific knowledge of how this works, but that would make it more challenging to bring off-market data or data in different formats. That I would imagine would be a harder thing. Changing pricing and keeping the input data the same, I'd imagine would be easier. It still may have its complexities depending on what the product is that you might be wanting to build, but that's how I would answer that one at a high level.

[00:40:15] Billing engines are notoriously sticky given their operational risk of customer data migration, as you mentioned. Since switching costs are quite high and vendors attempt to raise prices, what is the price ceiling before customers churn, and what are the true switching costs?

MG [00:40:42]: The switching costs are usually pretty immense because you've got to get all of your data out, you've got to mobilise teams internally. There's operational risk to the business. It's a bit like having a heart transplant. These businesses work on very thin margins. If they can't get bills out for 1-2 months, it can sometimes be terminal for them depending on what their wholesale positions and things are. It does cost you a lot of money and you really can't afford to have the heart of your retail operation out for very long at all. That's always a consideration in the background. Then there's the huge operational cost that your business may need to do in terms of changing over operationally, how you work. Everybody in the organisation knows the system that they're meant to use. These things are quite sticky for those reasons.

[00:41:40] Do you have an estimate of the switching costs for an average energy retailer?

MG [00:41:50]: It can vary wildly. I don't think you'd probably get much change out of AUD 2m-4m. I wouldn't have thought AUD 2m-5m, depending on the size of the book you're trying to migrate would be something typical. That might only include the billing piece. Then if the billing engine is connected to a CRM or some other data streams or other things like that, you'd have the billing migration piece of it, but you also have the other bits of your infrastructure that are tied in to the billing system, and all of those integrations would need to get rebuilt and moved, etc, so they would obviously add cost to it as well. It will depend on are you using Salesforce, aren't you using Salesforce, all of those things. The cost quite often of maintaining two systems for a period of time and the support you need from both the vendor as you're leaving and as well as the new vendor you're using to get them to set it up, those things can be quite significant.

[00:43:04] How do clients evaluate the trade-off between operational risks and compliance or integration cost savings from switching platforms?

MG [00:43:14]: I think they weigh them up very heavily, and I think customers really… Almost no CTO ever gets out of bed in the morning and says, "I really feel like doing a billing migration today." Everyone will leave it for as long as they can until eventually maybe the compliance risk rises too much or it just becomes too operationally inefficient and/or, as I said, the compliance risk around a particular platform, not giving the right reporting to a regulator, something like that might be the thing that would trigger a utility to migrate. That's suppose to be the big things, no one gets out of bed and really wants to migrate their system unless they absolutely have to. That is what I would say about it.

[00:44:03] How much more likely are large business clients to execute a platform migration compared to mid-to-small clients?

MG [00:44:13]: I'll answer that like this. Larger clients will have much bigger books to migrate and generally better resources and they're better capitalised and all those other things. On one side of the coin, they're better resourced to manage it. They've usually got a stable book, they're usually profitable. In one sense, they are better resource-wise, able to manage, but in the other sense, they might be migrating across one million customers or two million customers, which then adds its own complexity given its scale. While they are better resourced, but their complexity of migration will tend to also be higher vs the smaller ones where their migration, because they've got less customers, will tend to be a little bit easier, but at the same time, they will quite often have less resources. That will also be its own thing. I don't think it's particularly easier or harder relatively speaking, for a big organisation. The easiest time to migrate is when you've got 100 customers on there, but nobody, generally speaking, with 100 customers on there is looking to migrate anywhere.

[00:45:30] What operational triggers cause a utility to issue an RFP [request for proposal] instead of renewing with Hansen when multi-year contracts expire? How frequently do tier 1 and 2 Australian energy retailers reissue RFPs?

MG [00:45:47]: Typically, it will depend on who the retailer is. Typically, a lot of them will have mandates to do it at least every 3-5 years. Some of them might go out sooner, but that's typically what they will do is a 3-to-5-year cycle. They'll be with their particular vendor and they'll generally go out to market and undergo that exercise in that timeframe.

JC [00:46:14]: Once the contract expires, what triggers them to issue an RFP vs renewing with Hansen?

MG [00:46:29]: I think they do the RFPs regardless. Even if they are probably even intending to stay with the vendor, they'll still undertake the process. It's those things is the operational triggers might be a perceived internal risk of compliance, of there being a compliance risk. It's going to be operational triggers around cost to serve in terms of what is this system going to cost us. On the plus side, they may also look at this and look at their system and say, "Okay, we've done this big, heavy lift and we've invested all of this capital in, for example, a CRM integration or some other big integration," and so the operational triggers, once that's complete, may then drop off. If someone's done a big Salesforce integration or something like that, that may play in the incumbent's favour because that investment has already been made in getting that… I'm using the CRM as a common case, but in the case of a CRM, if a particular CRM has been integrated with and it was very complex and it's now done and operationally, I think that actually plays into the favour of the incumbent because you don't want to have to do that process again. Even though it might be a bit easier with a cloud-native system, you don't want to have to do that process again for a new billing provider.

[00:47:57] Do you have an estimate of the average cost-to-serve difference between a legacy provider and a cloud provider for an average energy retailer?

MG [00:48:09]: I couldn't give a fair response to that. I would say that it is generally more. Generally more and it could be anywhere between 20% to 50% higher, but it depends upon, like I've said, how many particular customers they might have on the platform and what the compliance costs are and how easily they are to be shared and all those other things. It's a very difficult question to give like a really good response on, but it certainly would be more because legacy systems just are a bit harder to maintain.

JC [00:48:56]: Comparing Hansen Technologies and Kraken, would you say this cost-to-serve estimate holds true?

MG [00:49:13]: I don't have good visibility of that. I couldn't comment. If you're looking for market signal for the answer to that question is you could look at some of the retailers in the market that have gone out to tender and looked at their operations individually and how they operate and what they do and looked at their specific circumstances and then were convinced whether correctly or not that Kraken was a better option than Hansen using that example, they have gone out to market. They've looked at their specific situation, and they've obviously had some commercials from Kraken wave in front of them and a bunch of them have signed with Kraken. Not many of them have signed with Hansen in Australia. I think that's all barely publicly available. People could look at Origin, what they've done. They could look at Energy Queensland, and they could look at Red Energy. Those are all in the public domain that they were customers with complex processes that would have gone through the thing that you were describing there and for different reasons. Whether they turn out to be accurate or not, their view based on that assessment was that it probably was going to be easy to operate and work better with their call centres and operationally with what they do relative to going with Hansen.

One of few of those, then you might be able to make a counter case to it, but all I'm doing there is just commenting on some publicly available data, but I don't have any view as to whether those were really good decisions or whether the people in there just have made a bad decision and it's going to turn out to be a cookie that crumbles in their hands, I don't have a good view on that, but if you take the market at face value, then it seems like they've been able to convince those retailers that they are able to get those cost-to-serve benefits.

[00:51:30] Utilities view billing software primarily as a back-office utility. How is client spend typically split between annual CPI indexation and adopting new software modules?

MG [00:51:49]: It varies customer to customer. I don't have a good answer to that one. It is a back-office function. The CPI split generally tends to be small relative to the updating of new software, maintaining market compliance, building additional products, it tends to be. If I was to use an example, that split in terms of spend would be on enhancements and compliance and all the rest of it, it could be a 90/10 split in favour of compliance and product enhancement and integration costs and all those even more than that, maybe 95… It depends on the year again and how many customers and so on, but yes, let's just say 90/10 with 10 being CPI and the rest being product enhancement, compliance, etc.

[00:52:53] What is Hansen's average CPI increase, and how is it determined and contractualised?

MG [00:53:01]: I've got no visible working of how Hansen do it, but generally, there's an index that is in Australia, a CPI index, and there's also a wage price index sometimes gets used, and it will be some blending together of those. It's a number that the government produces and billing vendors will generally… I'm speaking generally, I've got no idea of what Hansen include in their contracts, but generally speaking, it's a number that's produced by the government and both parties agree that especially on longer-term deals that that number the government produces gets applied each year. That's not typically a big sticking point in any contract. Most billing vendors will do something like that.

[00:54:01] How much pricing leverage do utilities typically have to negotiate contractual CPI increases?

MG [00:54:08]: A little bit. They will play off length of contract vs "Take away that increase for those last three years, and we'll agree to give you a six-year deal or a seven-year deal instead of a five-year deal." They've got some ability to negotiate it, but it will be then usually weighed off against the tenure of the contract.

[00:54:34] What specific contractual levers or operational threats do utilities leverage during renewal negotiations to push back price escalations?

MG [00:54:48]: Yes, it's usually that. It's the only leverage you've got is the leverage to leave and then the tenure usually of your contract that you're about to sign. Those are two levers you've really got.

[00:55:06] What do you think prevents energy retailers from adopting Hansen's broader and add-on product suites?

MG [00:55:16]: I think that probably the big one is just how happy they are with core products. Are they really happy with the billing? Are they really happy with all of their other products? If they've got a happy customer, I think the sale and implementation of those things gets easier or the add-ons get easier, if they are add-ons that easily integrate with the billing system. We started the whole conversation around the fact that there's mergers and a lot of these billing systems are very different is does this module easily integrate with the French version of it or the Mexican version of it or the Australian version, whatever it is, does that product that you're looking to… Does that module easily integrate with that billing system, or does it stand alone and doesn't matter? I think the complexity of integration with the specific billing engine in that territory would also be a factor.

[00:56:24] What are Hansen's core strengths and weaknesses in an increasingly competitive environment?

MG [00:56:37]: The strength is that it's a good, known brand globally. It does what it says on the tin, which is it gets bills out, it wears away in the background. I think it's got a good reputation in the market in terms of its reliability in doing that. It's ASX-listed and it's got a lot of compliance processes on it, which I think utilities like. It's a trusted global brand that lots of energy retailers across the world use. I think that's certainly in its favour. Probably, on the other side of it, it's going to be its ability to help their end customers to then transition and start adopting some of these more complex tariffs and pricing and other bits and pieces that are going to happen as the market moves from more what we call a centralised model, which is coal and gas plants and nuclear plants, etc, all providing that power vs the new customer wave that's going to start to come in, in different territories at different times where customers are going to start to be generating their own power, selling back to the grid and how that gets managed among the product suite that Hansen can offer, that is where I would say the rubber will hit the road in terms of energy retailers being happy to stay with Hansen and be able to provide and service those customers.

Some of them may not even be interested in going after that market, they might just stick in a simple product world. If that's the case, then there's obviously room for Hansen to play in that simple market, even assuming that it wasn't to bring those other offerings to market in terms of complex products.

JC [00:56:37]: I think it is a good time to end the Interview here. Thank you so much for all your insights today.

Transcription ends at 00:58:48 of the recorded material