No-Back-and-Forth Solar Design Intake Checklist

Back-and-forth begins before the first clarification email. Sales requests “a proposal-ready design” but supplies an address, one bill image, and a target module count. Design cannot tell which building, load period, roof evidence, equipment path, customer decision, or release level those fragments support. The designer asks questions because the requested output has no accepted basis.

The goal is not zero conversation. Design should challenge contradictions and ask specialist questions. The goal is to stop avoidable reconstruction: repeated requests for identity, missing source files, unexplained deadlines, unstated options, and assumptions that the sender could have labelled before assigning the work.

This page owns the acceptance packet at the sales-to-design boundary. The solar sales and design handoff guide covers the broader relationship. The rushed design red-flag checklist owns warning signs after pressure appears. This checklist answers a narrower operating question: what must arrive, in what state, before design accepts the named work?

This is a workflow proposal, not engineering, safety, code, permitting, utility, financial, contract, or legal advice. The correct fields and required reviewers depend on project type, stage, jurisdiction, company scope, and responsible professional practice.

Why does solar design intake create so much back-and-forth?

Solar design intake creates back-and-forth when a request transfers a desired conclusion without the project object, source evidence, assumptions, decision purpose, release level, or owner needed to produce it. The designer must reconstruct sales context, while sales interprets questions as delay. Every reply can introduce another version instead of resolving the original intake.

The failure usually hides inside ordinary phrases:

Treat intake as an interface between roles. NASA’s interface-management guidance applies to NASA programs, not solar sales. It describes defining interfaces, identifying their characteristics, maintaining compatibility, and retaining interface information. The useful analogy is that sender and receiver need a shared contract for the object crossing the boundary.

Back-and-forth is not always a sender failure. A template can demand fields the current stage does not need. Designers can ask broad questions instead of naming the exact evidence and affected output. Systems can hold the current record but surface an older attachment. Managers can reward queue entry instead of accepted work.

Measure the interface, not the personalities. Record why requests are returned, which fields repeat, how long contradictions remain unresolved, and whether the next owner can state the project decision without reconstructing a meeting. Do not claim a universal reduction in cycle time or rework without retained company evidence.

What belongs in a complete solar design intake packet?

A complete solar design intake packet contains the customer or project decision, stable identity, source-dated site and load evidence, requested artifact and allowed use, project stage, selected and excluded scope, equipment constraints, assumptions, options, commitments, open questions, specialist reviews, deadline source, current revisions, and one accountable owner for every unresolved item.

Complete does not mean final. An early layout request can be complete with planning assumptions when the packet clearly labels them and restricts the output. A construction release needs a much stronger evidence and review threshold. Define completion against the named work.

Decision and output card

State who will use the output and what decision it supports. “Create a layout” is an activity. “Create a preliminary roof layout so the customer can compare a base system with a separately identified storage option” names the job and audience.

Record:

• customer or downstream decision;
• requested artifact;
• audience;
• project stage;
• permitted use;
• prohibited use;
• release owner;
• deadline source and event.

The output may be a remote feasibility concept, site-survey plan, preliminary layout, energy-model input request, customer option comparison, design-review candidate, or another controlled artifact. Do not call everything final design.

Project and site identity card

Use a stable project identifier, customer or legal entity, site address, coordinates where relevant, parcel or facility, target building or array area, meter or service context, and person who confirmed the selection. Preserve the submitted identity and the accepted resolved identity when they differ.

Stop the request when identity conflicts. Patching the proposal name does not correct imagery, bills, layout objects, models, equipment, or prior notes attached to the wrong project.

Site evidence card

List imagery, survey, photos, drawings, roof or land information, obstructions, access, electrical evidence, structural or geotechnical questions where applicable, source, observation date, confidence state, and owner. The designer should be able to open the original evidence rather than rely on a pasted screenshot.

Do not ask sales to make engineering, safety, structural, or code conclusions. Sales can state what evidence exists and what the customer or site contact reported. Qualified roles decide what that evidence supports.

The Department of Energy’s PV system design basics describes modules as one part of a system that can include mounting, orientation, inverters, storage, and other balance-of-system components. It does not prescribe intake fields. It supports a practical boundary: a roof image and module target cannot settle every connected system decision.

Load, tariff, and customer-context card

Record the source file, account or meter identity, service address, billing or interval period, units, completeness, observation date, and any customer-stated future load. Separate measured past use, customer statements, and planning assumptions.

Do not turn a stated future EV, battery, equipment expansion, or business load into an accepted system size. Preserve the question and route the modeling decision. Financial, tariff, export, finance, incentive, and savings questions need their own sources and responsible reviewers.

Solar-resource and shading card

Identify the resource or weather source, location, time basis, shading evidence, near-object and horizon treatment where relevant, current vegetation or development questions, model stage, and limitation. DOE’s solar radiation basics explains that solar resource varies with geography, time, season, landscape, and weather.

NOAA’s Climate Data Online provides historical weather, climate, and station-history access. Neither source chooses the correct dataset or shading method for a private project. They explain why a location or annual figure needs provenance rather than being self-validating.

Scope, option, and equipment card

State selected scope, excluded scope, options still under consideration, customer duties, allowances, known work by others, equipment constraints, accepted models where applicable, substitution state, and current commercial boundary. Give every option an identifier and lifecycle state such as requested, modeled, reviewed, presented, selected, rejected, expired, or superseded.

Do not use “same as discussed” or “standard equipment.” Link the current source. If the customer has not selected an option, say so. If sales wants design to explore alternatives, identify which decision each alternative supports.

Commitments, assumptions, and exceptions card

Preserve statements already communicated about aesthetics, equipment, access, schedule, production, savings, scope, finance, service, warranty, or other material issues. Link exact source wording when meaning matters. Distinguish a customer preference, sales statement, contract term, technical assumption, and external dependency.

Each exception needs the fact, source, affected artifact, work allowed now, blocked release, owner, required decision, and return event. “Engineering later” is not a complete exception.

How should design accept or return an intake request?

Design should issue one of four recorded dispositions: accept when the named output has a sufficient basis, conditionally accept when limited work can proceed under visible assumptions, return when a specific gap blocks responsible work, or escalate when the next decision belongs to a specialist or authorized role. Silence and queue placement are not acceptance.

Use a receiver check before status changes:

Accepted

Accepted means the requested work can begin from the identified packet revision. It does not mean the complete project is approved. Record the output, owner, due-event source, reviewers, and next handoff.

Conditionally accepted

Conditional acceptance allows bounded work under named assumptions. Put the limitation on the resulting artifact, not only in the intake note. State which release remains blocked. If later evidence contradicts the assumption, reopen connected design, energy, equipment, electrical, BOM, commercial, and proposal objects.

Returned

A return should name the missing or conflicting field, why it blocks this output, the controlling evidence requested, responsible owner, and next review. “Incomplete intake” teaches nothing. “Target building conflicts between the customer record and selected roof; resolve project identity before layout creation” is actionable.

The current owner retains responsibility when the request is returned unless the workflow explicitly accepts a limited transfer. Do not leave incomplete work assigned to design simply to keep an intake metric green.

Escalated

Escalate an exact decision request. Include project identity, question, evidence, proposed configuration, affected artifact, deadline source, and consequence. Structural, electrical, code, safety, utility, permitting, contract, finance, tax, or other specialist work should not be compressed into a general design comment.

OSHA’s Recommended Practices for Safety and Health Programs discusses management leadership, worker participation, hazard identification, training, and other program elements. The exact workplace duties depend on the jurisdiction and activity. An intake packet can flag a safety dependency and link to the controlled process; it cannot replace site-specific safety planning.

How do you handle missing or conflicting intake information?

Handle each gap as a controlled exception: identify the source state, affected output, interim assumption if permitted, responsible owner, evidence request, work allowed now, prohibited release, verification trigger, and downstream objects that must reopen. Never convert missing into zero, copy another project’s value, or hide conflict to preserve an artificial deadline.

Use six evidence states consistently:

• Observed: directly recorded with source and context.
• Customer-stated: attributed to the customer or site contact, not independently verified.
• Modeled: produced by a named method and input set.
• Planning assumption: explicitly temporary and owned.
• Contradicted: current sources disagree and require resolution.
• Missing: required evidence is not available.

Add expired or superseded when age and version control matter. Never use “confirmed” without identifying who confirmed what, against which source, and for which decision.

NASA’s configuration-management guidance is written for NASA programs. It describes making product state known, distinguishing versions, and controlling baseline changes. The transferable lesson is that a new file or message should not silently overwrite the basis of work already underway.

Exception decision table

Do not turn conditional work into a loophole. If most packets enter conditionally with the same missing field, fix the intake source or qualification process. If designers routinely request fields that never affect the named output, simplify the checklist.

What should the copy-ready solar design intake checklist contain?

The copy-ready checklist should capture one decision-ready object: project and customer identity, requested output, audience and release level, current evidence with provenance, site and load context, scope and options, equipment constraints, assumptions, commitments, exceptions, specialist reviews, deadline source, receiver disposition, and the precise downstream artifacts affected by later change.

Solar design intake and acceptance record

Use one packet link rather than attaching multiple copies. If a document must travel, label project, object type, revision, creation context, owner, state, and superseded relationship. A screenshot can support discussion but should not become the only evidence for geometry, load, equipment, or approval.

Illustrative workflow: an urgent layout for a future EV

Illustrative workflow, not a customer case, design, production result, sales outcome, or technical approval. A homeowner asks whether a larger system might support a future vehicle. Sales requests an urgent “maximum layout” and attaches a recent bill image. The request does not identify the full billing period, expected vehicle use, selected option, or purpose of the customer meeting.

Design returns the packet instead of choosing an EV load and filling the roof. The return asks sales to confirm the current customer decision, supply the complete load record, preserve the future vehicle as customer-stated context, and choose whether the output should compare a base case with a labelled planning scenario.

Sales responds with the complete source, meeting purpose, and two requested option identifiers. The future load remains an assumption with a customer owner and verification trigger. Design conditionally accepts a preliminary comparison, states that neither option is a final sizing or engineering conclusion, and blocks customer savings claims until the responsible inputs and reviews are ready.

The customer meeting can proceed with clearer choices. No invented vehicle consumption becomes project truth. If the customer later selects an option or supplies new evidence, the packet reopens the affected design and model objects.

Audit the intake boundary and fix the earliest repeat failure

Sample accepted, conditional, returned, and delayed requests. Trace the packet, source evidence, questions, responses, output, and later change. Count return reasons using defined categories, but read the actual records before interpreting a pattern.

Useful internal signals include identity conflicts, inaccessible evidence, missing load periods, undefined output purpose, option-state confusion, stale equipment records, unowned assumptions, arbitrary deadlines, specialist questions routed late, and limitations that failed to follow the design output.

Do not reward acceptance rate by weakening the threshold. A high acceptance rate can mean strong intake or passive design ownership of incomplete work. Pair it with evidence quality, return reason, downstream correction, and whether the output stayed within its permitted use.

When a repeat appears, fix the earliest controllable source:

1. remove a field that never affects the named output;
2. add a required source link where teams repeatedly paste screenshots;
3. change a vague label into an event or decision definition;
4. assign a default owner for a recurring exception class;
5. block submission when identity or output purpose is absent;
6. allow a conditional path when preliminary work has a legitimate boundary;
7. update training with a real anonymized return pattern under company policy;
8. review later projects to confirm the failure stopped recurring.

The solar project intake process helps teams define purpose and evidence earlier. The 15-minute handoff guide can structure the receiver acceptance conversation after the packet is ready. Neither substitutes for qualified technical or jurisdictional review.

Where SurgePV fits in design intake

SurgePV supports 3D roof modeling, solar array layout, shading analysis, energy-yield and financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. Connected project objects can reduce detached transcription after an intake is accepted.

Evaluate the solar designing workflow with exception cases, not only a perfect request. Change the target building, return missing consumption evidence, create two option states, revise equipment, conditionally accept a preliminary layout, and supersede a customer-facing proposal. Check whether identity, evidence, assumptions, revisions, and limitations remain visible to the next owner.

SurgePV cannot establish what a customer meant in an unrecorded conversation, verify every external source, decide which missing input is harmless, interpret local requirements, or turn a general response into engineering, utility, permit, safety, financial, or contract approval.

Results depend on source data, assumptions, equipment models, configuration, and review. Confirm access, implementation, pricing, and commercial terms through a written quote. Publication remains subject to human consolidation review because several existing pages cover adjacent sales-to-design workflow intent.

Frequently Asked Questions

What information does a solar designer need from sales?

Design needs the customer decision, controlled project and site identity, current site and load evidence, requested output and permitted use, selected and excluded scope, equipment or commercial constraints, assumptions, open questions, required review, deadline source, and owners. The exact fields should match the project stage and market.

Should a solar designer start when site information is incomplete?

Only under an explicit conditional acceptance that names the missing evidence, planning assumption, work allowed now, output limitation, blocked release, responsible owner, and verification trigger. Design should return the request when the gap prevents the named output from being responsibly produced, or escalate questions that require specialist authority.

Who owns errors in a solar design intake packet?

The sender owns accurate transfer and source links, the intake owner governs required fields, the designer owns acceptance and visible return reasons, and each specialist owns decisions within their authority. Managers should repair the workflow rather than assigning all blame downstream. The release owner reconciles customer-facing outputs to the accepted project state.

How do you stop sales and design from using different project versions?

Use a stable project identifier and link the current site, load, design request, equipment, scenario, and evidence records. Record revisions and superseded relationships, prevent detached screenshots from becoming source truth, and require the receiver to acknowledge the accepted packet version. Reopen affected fields whenever material source evidence changes.

Can SurgePV guarantee a complete solar design intake?

No. SurgePV can connect solar modeling, layout, shading, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal work. People still own source accuracy, customer commitments, site evidence, qualified review, safety, code, permitting, utility, contract, and release decisions. Test the workflow with incomplete and conflicting requests.