7 Rules for Prioritizing a Solar Design Queue Fairly

A fair solar design queue does not treat every request as equally urgent. It makes urgency testable. Teams need a visible way to distinguish a proposal that is ready for a promised review from a project missing key site information, an installation-blocking revision, a legitimate approval deadline, and a request that simply arrived with a louder message.

Queue management matters because design work is connected to sales, engineering, procurement, and field delivery. When priorities change without a rule, the team loses more than time: people rebuild context, customers receive inconsistent expectations, and hidden work accumulates. Atlassian’s explanation of work-in-progress limits is a useful general resource on limiting active work; the exact method must fit a solar company’s roles, obligations, and local requirements. The Kanban Guide defines WIP as started-but-unfinished work. Keep that whole-workflow count separate from tasks receiving hands-on attention now; neither source prescribes this solar priority policy.

The Queue Is a Commitment System, Not an Inbox

An inbox tells a designer what has arrived. A queue tells the organization what it has agreed to work on next and why. Those are different functions. In a busy solar business, requests may originate from leads, customer changes, permit questions, sales follow-up, construction discoveries, equipment substitutions, or internal quality reviews. If each source can directly change the order, the system becomes a contest for attention.

The queue should therefore contain enough information for someone outside the original conversation to judge priority. At minimum: a project identifier, request type, request date, requested deliverable, promised or external deadline, current design revision, evidence readiness, estimated effort class, downstream consequence, named owner, and open blocker. A request with no site identifier or no defined deliverable is not “high priority”; it is incomplete intake.

Keep a start timestamp as well as the current state. A task that started and then waits for a photo, customer decision or technical review remains unfinished WIP. An unstarted request can remain outside the start boundary while its intake gap is resolved.

Rule 1: Define Priority Classes Before a Crisis

Use a small number of priority classes with concrete entry criteria. Too many tiers invite debate; too few force unrelated work into the same bucket. One reasonable model separates installation or safety blockers, external approval deadlines, customer commitments with complete evidence, normal planned work, and improvement work. The labels are less important than a shared definition.

An installation blocker might qualify when the field team cannot safely or responsibly proceed without a corrected drawing or decision. An approval deadline might qualify when a documented authority or utility date creates a material consequence. A promised proposal review could qualify when the commercial commitment is recorded and the requested package is ready. “Sales wants it today” is not enough by itself. The rule protects sales too, because it creates a defensible answer when a request lacks inputs.

Do not place every change in the top class. If a project moves into urgent status, state which event triggered it, who authorized it, and what work will move as a result. This makes the cost of priority visible rather than silently transferring it to other customers.

Rule 2: Separate Importance From Readiness

Some of the most valuable opportunities are the least ready to design. They may lack a utility bill, usable site evidence, intended system goal, roof access detail, or customer choice required to construct a credible scenario. Giving them first position does not accelerate delivery; it sends a designer hunting for information and creates interruption when the missing input appears later.

Create a simple readiness gate for each request type. A preliminary concept might need an address, stated objective, available consumption evidence, and customer contact context. A technical revision might need the current drawing issue, a clear change request, affected area, source evidence, and a responsible reviewer. A permit-related task may require a different package entirely. The goal is not to refuse work. It is to make the missing item explicit and help the requester obtain it.

Ready work should be easy to pull. Blocked work should stay visible with its reason, owner and started status. It may not need hands-on design now, but a started task remains in WIP and may still need coordination. Do not start incomplete tasks merely to make the board look busy.

Rule 3: Use Consequence, Not Seniority, as the Escalation Test

Fairness does not mean ignoring serious situations. It means defining a consistent test. Ask what happens if the task is not completed by the requested point: does a safe installation pause, a formally documented submission deadline pass, a customer commitment become inaccurate, a material order become wrong, or does someone merely prefer an earlier answer? Then ask whether the evidence is sufficient for the team to act.

Use a short escalation form or queue note. It should name the consequence, deadline source, affected project revision, required deliverable, evidence status, and decision owner. This prevents the queue from being altered by broad language such as “urgent customer” or “please prioritize.” It also protects the person making the request: they can explain the real need without escalating everything else by habit.

Rule 4: Define and Control Work in Progress

Inspect interruptions and unfinished work rather than assuming that more simultaneous assignments create capacity. Open drawings, email questions, pending reviews, and partial calculations make it difficult to remember what was assumed last time. Work-in-progress limits make capacity visible. They do not mean a team ignores incoming work; they mean the team chooses whether an item waits in a ready queue or displaces something already active.

Set limits by work type where possible. Define the start and finish boundary first, then choose trial limits for each role or work class. Record started tasks waiting for review or blocked inputs within the same boundary. Tune limits using actual outcomes rather than a theoretical ideal. If work repeatedly waits for a particular review, the bottleneck may be evidence quality, a missing owner, or an overloaded role—not the number of people drawing panels.

The person who authorizes an exception should identify the work being paused. Otherwise, exceptions are invisible and the queue quietly becomes longer than its stated capacity.

Rule 5: Estimate by Size and Uncertainty, Not False Precision

Solar design tasks vary widely. A standard update to an established model may take far less effort than a complex roof with incomplete site evidence, a new electrical configuration, or a customer scenario that changes several downstream outputs. Avoid promising exact durations before the team knows enough to assess the work. Use effort bands such as small, standard, complex, and investigation required.

The uncertainty label matters. A job may be small once a specific photo, measurement, or decision arrives. Until then, it is an investigation, not a routine revision. Showing this in the queue helps sales and operations give customers a useful explanation: the team is not delaying a drawing arbitrarily; it is waiting for the input needed to produce a responsible one.

Rule 6: Give Sales and Design One Shared Definition of Complete

Queue conflict often begins before the task reaches design. A sales rep believes the address and consumption are enough; a designer needs roof evidence, customer priorities, or an explanation of what has already been promised. Resolve this with an intake definition written jointly by the people who request and perform the work.

The intake form should capture the question the design must answer, not just fields. “Prepare a concept for a homeowner who wants lower bills” is different from “compare a roof-only option with a roof-and-carport option after the customer stated an electric-vehicle plan.” A clear question improves scenario design and reduces the rework caused by a technically correct output that answers the wrong commercial need.

Solar Designing is SurgePV’s solar design product area. SurgePV describes it as supporting AI roof generation, custom geometry, panel placement, DC stringing, BOM generation, and design outputs. In an evaluation, ask the presenter to trace the current input and output versions across the handoff. Confirm the workflow you require; outputs still need the company’s review, engineering and project controls.

Rule 7: Review the Queue as a System, Not a Blame List

A weekly review can reveal whether the priority rules work. Look at aged ready items, repeat escalations, blocked tasks, work returned for missing inputs, exception volume, and the time between design completion and required review. Ask where requests enter without enough evidence and why a particular class is consuming capacity. The purpose is to improve the operating system, not to rank employees by visible busyness.

When a project is delayed, distinguish delay caused by actual complexity from delay created by unclear intake, conflicting priorities, absent decisions, or queue thrashing. A team that switches a job five times may appear busy while making little progress. Measure whether a focused period on ready, consequential work improves completion and review outcomes.

For measurement definitions, use the queue metrics guide. Prioritization decides what is next; the metrics guide tests what is waiting and why.

A Practical Priority Conversation

When someone needs a change moved forward, use this sequence: identify the project and revision; describe the required output; provide the deadline source and consequence; confirm readiness; classify the effort and uncertainty; name the work that may be displaced; and record the approver. This takes longer than writing “urgent” once. Retain the note so a later reviewer can reconstruct the changed order and its consequences.

It also gives customers clearer updates. Rather than promising a date that depends on uncollected information, explain the next evidence required and the point at which a design slot can be confirmed. Good queue management is a customer-experience practice as much as an internal efficiency technique.

Frequently asked questions

What should make a solar design request urgent?

Urgency should be tied to a defined customer, safety, approval, installation, or commercial consequence with enough project evidence to act—not merely to the requester’s preference.

Should fast jobs always go first?

Small, ready jobs can be useful to pull through the queue, but they should not constantly bypass higher-consequence work or conceal missing inputs in the rest of the queue.

Should a signed customer always move to the front of the design queue?

Not automatically. A signed project may have a higher business consequence, but the team should still confirm the requested task, evidence readiness, external dates, and work already committed. The queue rule should prevent a new project from silently breaking responsible commitments to other customers.

How do teams handle genuine emergencies?

Define emergency or blocker criteria in advance, require a named authority to approve the override, document the affected project revision and consequence, and identify which work is deferred. Afterward, review whether the event was unavoidable or exposed a planning gap.

What metric best shows queue health?

Use several: age of ready work, number and duration of blocked tasks, exception rate, rework caused by incomplete intake, and cycle time by work class. One average can hide a queue in which simple work moves quickly while high-consequence projects wait.

Can a small solar team use this approach?

Yes. A small team may use a shared board and a short daily review rather than specialized software. The essential controls are visible priorities, named owners, readiness rules, and a clear record when an exception changes the order.