Nobody lost the utility deal. It slipped a quarter.

Selling software to a utility typically takes 9–15 months by Panelhop’s estimate, and up to 36 months at a US investor-owned utility. Co-ops and German Stadtwerke tenders sit at the shorter end; US IOUs, gated by rate cases, sit at the longer end. Small utility deals below tender thresholds can close in about 3 months, by the same estimate. The calendar comes from budgets, rate cases, board meetings and price controls.

A utility’s buying group for software, often called the buying committee, usually has 6–12 people on deals above €100k, by Panelhop’s estimate. It covers the executive sponsor, the business owner, IT, cybersecurity and compliance, procurement, finance and legal. Investor-owned utilities and British network companies add regulatory affairs. A selection consultant often shapes the requirements, and a city council, co-op board or supervisory board votes last.

Utility software deals slip because they wait on dates the vendor’s CRM doesn’t hold. The usual ones are a rate case order, a business plan determination, a tender standstill and the next board or council meeting. A utility deal that misses one packet deadline moves a full meeting cycle. Adding those dates to opportunity stages turns slippage into something the forecast can predict.

A utility RFP usually shows up in public records months before release. Look for council study sessions, budget requests, capital plans, consultant procurements, rate case filings and staff reports that mention a system’s end of life. Vendors that track these signals for each target utility reach it while requirements are still being written, instead of answering a specification shaped around a rival.

Software vendors sell to electric co-operatives through peer references, the board’s approval and the advice of the co-op’s G&T or statewide association. Many co-ops already run a long-standing integrated suite, so a cold approach to the general manager rarely works. Vendors do better by tiering co-ops by G&T and peer cluster, then leading with a reference from a nearby co-op of similar size.

MQLs work poorly for utility software because the utilities market is a finite list of named accounts. Lead counts can rise while pipeline at target utilities stays flat. A better measure is account coverage: how many tiered utilities are engaged, and how many seats in each utility’s buying group your team has reached.

A utility buys new software when a dated, usually public event forces a decision. Common triggers are a legacy customer information system (CIS) or billing system reaching end of life and a rate case order or price control that funds the work. Others are a compliance deadline such as the EPA’s lead service line inventory (LCRI), a security law such as NIS2 and a cyber incident at the utility or a peer. Most show up in commission dockets, council agendas, budget requests or tender portals months before an RFP.

Software vendors should tier utility accounts by ownership type first, then by size and live trigger. Investor-owned utilities, public power, co-ops, Stadtwerke and DSOs buy on different calendars: rate cases, council budgets, board meetings and tenders. Within each type, rank utilities by meters or customers served and by a dated trigger such as a billing end of life or an approved metering programme.