Interconnection Queue Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the statutory clock get built as a due date field?

Because everyone reaches for the tool they know, and every case tracking tool they know has a due date. Someone writes a requirement saying each application needs a target date and an overdue flag, a developer builds exactly that, and the system counts age from receipt like a support ticket.

Interconnection does not count age. It counts a specific timer per milestone, and the timer has behaviour. Your tariff or state rule says you acknowledge receipt within a set number of business days, confirm completeness within another, run the initial review screens within another, and issue a study agreement or an approval within another. Each of those timers pauses the moment you issue a deficiency notice, restarts when the applicant responds, skips weekends and state holidays, and behaves differently depending on the review path the application is on.

The engineer keeping all of that in a spreadsheet tab is not being lazy. No tool the utility already owns can express it.

The fix is to insist on a clock engine as a first class object before anything else is designed. Every milestone is a configured timer with a start event, a stop event, a business day calendar and explicit tolling rules, and every pause is written to an event log with the notice attached. That log is what you produce when a processing time is challenged. Ask any prospective developer to model tolling on a whiteboard before you sign. If they cannot explain how a deficiency notice pauses a business day timer and how that pause is evidenced eighteen months later, they have built a ticketing system before and will build one again.

What goes wrong with the circuit data your screens run against?

Screens are where the queue either works or quietly produces the wrong answers. They need current aggregate nameplate generation on the circuit and section, the line configuration, the transformer, and the applicant nameplate. In most utilities that data comes from a planning engineer's quarterly export, and by the time an application is screened the number is months old and does not include the projects approved since.

The failure is specific and it surfaces late. An application that should have failed a penetration screen passes because the aggregate figure is stale, the developer proceeds on that basis, and the problem is discovered during the study or worse during construction. Now you are having a conversation about who pays for an upgrade nobody flagged, and the answer to how it happened is that a spreadsheet was out of date.

The second data problem is your own queue. Approved but not yet energised projects are generation on that circuit for screening purposes, and if the queue and the planning model do not agree on which those are, both numbers are wrong in different directions.

Fix it by making the screen read a maintained aggregate that the system itself maintains, incremented by every approval and decremented by every withdrawal, reconciled against a scheduled refresh from the planning model rather than replaced by it. Then record with every screen decision the exact values used and their timestamps, so a disputed screen can be replayed rather than argued.

Why do planning model, mapping and billing integrations break after launch?

Four connections carry most of the risk, and they fail in different ways. The geographic information system, usually Esri, supplies circuit and transformer topology and is the most stable of the four. The planning model, commonly CYME, Synergi Electric or Milsoft, supplies circuit loading and existing generation, and it breaks when a planning engineer changes the export or renames a feeder as part of a reconfiguration. The customer information system handles the account, premise and net metering rate setup, and it is usually the oldest and least accommodating system in the building. Electronic signature and payment paths break on credential rotation.

The pattern in all four is that they are owned by other teams who change things on their own schedule and have no reason to tell you. That is the actual failure mode, not the technology.

Two things prevent most of it. Nightly validation against every feed, alerting a named person rather than a shared inbox, so a renamed feeder produces a failed check on a quiet morning rather than a run of screens against a missing circuit. And a written owner for each integration on both sides, agreed at kickoff, so change notice becomes somebody's job. Scope these connections in discovery with the people who own them, because access approval inside a regulated utility is measured in weeks and it is the most common cause of a slipped date.

What happens when the deposit ledger and cost allocation are left out?

This is the most commonly deferred scope in the category, usually because it looks like finance rather than engineering. It is both, and skipping it means the software solves the visible half of the process while the expensive half stays in spreadsheets.

Study deposits arrive, actual study cost accumulates against engineering hours, refunds are due against the difference, and none of it reconciles to the general ledger without someone reconstructing which hours went to which project. Upgrade cost allocation across a group of projects is harder still, and the reallocation after a withdrawal is where disputes live. When a project drops out of a studied group, the upgrade cost has to be redistributed among the survivors by the exact method in your tariff, and the result has to be reproducible months later when a developer challenges their share.

The other deferred item is permission to operate. The system is built, the inspection passes, and the account still needs the net metering rate code set and the meter configured. When that handoff is an email to a billing analyst, customers generate for weeks with no credit and complain to the commission about that too.

Fix both with the same discipline. Build allocation as a calculation over an immutable event history rather than as an update to a balance, so any past allocation can be replayed. Treat permission to operate as a handoff with a receipt, writing the approved size and rate code into the customer information system and holding the application open until the rate is confirmed as set.

Should you build custom or configure what you already own?

If you take fewer than roughly 50 applications a month, operate in one state, run no cluster or group studies and rarely allocate upgrade costs, configure PowerClerk and stop there. Clean Power Research built it for configurable forms, document checklists and templated correspondence, and it does that job without a project. Connect deposits to your existing finance process, accept that engineering will keep a spreadsheet for the study itself, and put the money into hosting capacity analysis, which will do more for your cycle time than any workflow tool.

If your volume is transmission scale queue processing, look at GridUnity before opening a build conversation, because that is the problem it was aimed at.

Build when the specifics that are yours have migrated outside the tool. Your screens run against your feeder data. Your cost allocation follows the cost sharing method in your tariff and not the next state's. Your study fee schedule, deposit refund rules, upgrade agreement template and permission to operate handoff are all local. When the configurable product owns the front of the process, engineers own the middle in spreadsheets and billing owns the end elsewhere, the queue status field in the product is a summary of work happening somewhere else, and that summary is not evidence when the commission asks.

How do hidden costs get into the quote?

Operating in more than one state is the largest multiplier and the easiest to under-price. Each state is a separate clock configuration, a separate screen rule set and a separate set of forms, and a proposal that treats the second state as a configuration exercise has not read both rule sets. Ask for the incremental price per jurisdiction in writing.

Cluster or group study support is the second. Grouping is straightforward. Reallocation on withdrawal is the hardest logic in the domain and it is where the review cycles go.

Then there is the security and hosting review. For a regulated entity this can add a month before a line of production code runs, and it is nobody's fault and always somebody's surprise. Include it in the schedule rather than in the risk register.

Finally, watch for planning model integration described as an interface when what exists is a scheduled export, and for the customer information system write-back described as a field update when it is a change request to a vendor. Both are commonly discovered in week six.

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

Start with the highest volume class of application, normally residential net metered solar under a defined size, and take it end to end including permission to operate. Leave commercial storage on the existing process for one more release. Teams that try to launch every application class at once spend a year building something nobody has run a real application through.

Give your highest volume installers a structured submission path early. Five installers usually account for most of your residential volume, and they will adopt an interface or a bulk portal because it saves them as much time as it saves you. Removing the deficiency loop before it starts is the single largest reduction in cycle time available, and it is mostly validation rules rather than anything clever.

Test the developer on the two questions that separate domain experience from enthusiasm: how they would evidence a tolled timer eighteen months later, and what happens on withdrawal from a group study. Then settle ownership in writing before kickoff, covering the repository, the cloud accounts and the right to hire anyone else, because this system holds records you may need to produce for a commission long after the original relationship ends.