The Interconnection Queue Process, and What Part of It Is Genuinely Automatable

Two processes wearing one name

You have a project with land, a lease, and a financing partner who keeps asking the same question. When does it connect? And the honest answer is that it depends on a queue you do not control, run by a transmission provider whose planning team is smaller than the pile in front of it.

Into that gap walks a growing list of vendors with a pitch: the queue is slow, the queue is manual, software makes it fast. Some of that is true. Most of it confuses two different processes that share one name.

The interconnection queue is an administrative process bolted onto an engineering process. The administrative half takes in applications, checks them for completeness, chases deficiencies, collects deposits, and assembles study models. The engineering half decides what the grid can actually absorb, what has to be built so it can absorb more, and who pays for it. Only the first half is a software problem. Treating the whole queue as one is how organisations buy a faster intake process and then discover they have arrived at the same bottleneck sooner, carrying a larger pile.

What the numbers say about the pile

Lawrence Berkeley National Laboratory tracks this every year in its Queued Up report. The 2025 edition found that of the capacity submitting interconnection requests from 2000 to 2019, only 13 percent had reached commercial operation by the end of 2024. Seventy-seven percent had withdrawn. Ten percent was still active. The typical project that did reach commercial operation in 2024 spent about 55 months in the queue.

Read those two numbers together. Most of what enters the queue never gets built, and what does get built waits four and a half years. That is not the signature of a slow intake desk. A slow intake desk costs weeks. Four and a half years is the signature of a scarce resource being spent on requests that were never going to be projects.

The scarce resource is transmission planning engineers. Every speculative request that enters a study consumes their time, and when it withdraws after the results come back, the study has to be rerun for everyone who remains. The queue's real cost is not paper. It is restudy.

What FERC itself counts as automation

FERC's Order No. 2023 is the clearest statement of where the regulator thinks software belongs, and it is narrower than the vendor pitch. The order describes automation as standardised data entry and collection, web-based application and submission with automated validation, automated construction of study models, and pre-population of manufacturer equipment models. It encourages these. It does not mandate them.

Notice what is on that list and what is not. Every item is about getting clean, complete, consistent inputs into the study. Nothing on it replaces the study. The regulator that wrote the rule, with every incentive to promise speed, drew the automation line at the edge of engineering judgment.

What Order 2023 did mandate points the same way. It moved transmission providers from serial, first-come studies to first-ready, first-served cluster studies, set a 150-day deadline for the cluster study, and replaced the old reasonable-efforts standard with per-day penalties for late studies, starting at $1,000 a business day for a cluster study and rising to $2,500 for a facilities study. It also raised deposits and readiness requirements. Those are not technology reforms. They are filters. The regulator's main lever on the backlog was making it more expensive to enter the queue with a project that is not real.

The half software genuinely fixes

The administrative half is worth automating, and the reasons are specific.

Deficiency cycles. An application that arrives missing a one-line diagram, a site control document, or a correctly formatted equipment model goes back to the developer, waits, comes back, and gets checked again. Each cycle is calendar time that nobody is studying anything. Automated validation at submission catches the missing field before the clock starts, which is the same move that made solar permitting faster when installers standardised their packets.

Model assembly. Building a power flow case from dozens of submitted models is work that an engineer does, but it is not engineering. It is translation and data entry with a high error rate. Pre-populated manufacturer models and automated case construction give that time back to the people who are scarce.

Status and communication. Developers call because they cannot see where their request stands. Every call answered is an hour of a planner's week. A portal that shows the truth reduces the calls, as long as the truth is kept current.

For developers, the parallel is the same: the fastest way through intake is an application that never bounces. That is document control, not software, and it is entirely within your control.

The half it does not

The study is where the 55 months live, and the study is judgment.

Power flow, short circuit, and stability analysis can be run faster on better tools. But deciding what a result means, what network upgrade resolves a violation, how to allocate that upgrade's cost across a cluster, and whether a restudy is needed after three projects withdraw: those are decisions made by planners who carry professional responsibility for the answer. Tools that speed up a simulation are useful. Tools sold as replacing the planner should be read the way you read any AI pitch that skips the question of who is accountable for the output.

The failure pattern we see is an intake automation project that succeeds on its own terms. Applications are validated in hours instead of weeks. The cluster window fills faster and fuller. And the study team, which did not grow, now faces a larger cluster with the same deadline and the new penalty clock. Intake became faster. The queue did not. The organisation can show a dashboard proving its automation worked while its developers wait exactly as long as before.

That is the same thing that happens in any process with a fixed constraint downstream. Speeding up the step before the bottleneck does not move the bottleneck. It raises the water level in front of it.

What decides whether automation pays

Whether you are a transmission provider, a utility running a smaller distribution-level queue, or a developer managing a portfolio of requests, the questions that decide the outcome are similar.

• Where does calendar time actually go? If deficiency cycles are a meaningful share of time before a request is study-ready, intake automation pays. If requests sit complete and waiting for a study slot, it does not.
• What does a withdrawal cost you? If one withdrawal triggers a restudy for the whole cluster, the highest-value work is upstream of software: readiness requirements and deposits that keep speculative requests out.
• Who owns the model data? Automated case construction is only as good as the equipment models submitted. If nobody owns their quality, you automate the assembly of a wrong case.
• Is the planning team being given back time or given more work? The only automation that shortens the queue is the kind that returns hours to the planners. Anything that adds volume in front of them lengthens it.

There is a version of this problem that looks like every other sequencing question in this industry. A municipal utility deciding what to automate before its GIS data is fixed faces the same split: automate the part whose inputs you trust, and leave the part that depends on a model you have not yet earned.

The honest edge

No software is going to make the queue disappear. Most of what enters it should never have entered, and the time it takes is mostly engineering time spent on a grid that is short of capacity. Software can take the paperwork out of the way. It cannot make the planners more numerous or the transmission system larger.

That is a useful thing to know before a vendor demo, because it tells you which half of the pitch to take seriously. What it cannot tell you is where your own queue is losing its time, whether your deficiency cycles or your restudies are the larger cost, and which of the four automations FERC lists would return hours to your planners rather than adding to their pile. Answering that means looking at your request history, not a slide.

If you are deciding what to automate in your interconnection process, or weighing a vendor who says the whole queue is a software problem, talk to us. We will tell you which half you are looking at.