Complete Solar Design Request: Shared Definition

A solar design request can be full of data and still be impossible to accept. The address is present, a bill is attached, the customer wants a proposal quickly, and the roof screenshot looks clean. Yet the designer cannot tell which meter the bill belongs to, whether the screenshot shows the current roof, or whether sales wants a rough layout or a customer-ready system scenario.

To build a shared definition of a complete solar design request, sales and design need an acceptance rule, not a longer form. The rule should connect the requested decision to identified evidence, a defined design stage, known limits, and an owner for every exception. It should also give the receiving designer permission to return work that would otherwise begin with concealed guesses.

This is a desk-research workflow for multi-jurisdiction solar teams. It is not engineering, permitting, utility, code, safety, financial, contract, legal, or site advice. Each live project still needs the source material, responsible reviewers, and external approvals appropriate to its location and deliverable.

The solar project intake process covers the wider path from enquiry to a design-ready brief. This guide owns a narrower control: the moment sales asks design to begin, and the evidence needed for design to accept that request without inventing the assignment.

What does a complete solar design request mean?

A complete solar design request is an accepted work brief with a named purpose, project identity, requested output, source records, evidence status, constraints, assumptions, and exception owners. Completeness is stage-specific. It means the receiving designer can begin the defined work without guessing, not that every later engineering, authority, utility, financial, or construction question is already resolved.

That definition has two important edges. First, the receiving role decides whether the request meets the rule. The sender can prepare and attest to the request, but cannot unilaterally declare it usable for someone else’s work. Second, completeness applies to a particular output. The evidence needed for an early roof-layout discussion is not the evidence needed to issue a plan set, finalize equipment, or make a customer commitment.

Write the requested output in plain language. “Need design” is not a usable brief. “Prepare a preliminary south-roof layout for an internal feasibility conversation using the attached imagery, with roof geometry marked provisional” tells the designer what to make, who will see it, and what boundary must survive into the output.

The U.S. Department of Energy’s photovoltaic system design overview describes a PV system as more than modules. It may include mounting structures, power electronics, and storage. That broad technical context explains why an address and annual consumption figure cannot define the whole assignment. Equipment, site, energy, electrical, and documentation choices interact, even when an early request intentionally addresses only part of them.

Use three separate questions when testing completeness:

1. Can the receiver identify the assignment? The project, customer decision, design stage, requested artifact, due event, and intended audience are explicit.
2. Can the receiver inspect the basis? Every relevant file, statement, and assumption has a source, date or period where relevant, and evidence state.
3. Can the receiver handle uncertainty without improvising? Missing, conflicting, or provisional information has a named owner, permitted work boundary, and reopening trigger.

The third question is where many forms fail. They allow “unknown,” but do not say what unknown permits. One designer returns the request. Another proceeds with an assumption. A third messages the sales representative and starts something else. The field exists, while the shared definition does not.

Use evidence states that change behavior

Use a small vocabulary that every role can explain. The labels below are an operating proposal, not an external standard. Adapt them to your services and review policy.

Evidence status is not a judgment about whether a colleague or customer is trustworthy. It tells the next person what they are holding. A customer statement can be important and accurate while still needing different treatment from a dated utility bill or survey record.

NASA’s requirements-management guidance applies to NASA programs, not solar sales. It discusses identifying, controlling, tracing, and managing changes to requirements. The transferable discipline is useful here: if the requested output or governing input changes, the record should show the change and its effects instead of relying on the recipient to remember a conversation.

Which inputs belong in the shared definition?

The shared definition should cover the assignment, site identity, customer decision, requested design stage, source files, load and tariff context where relevant, site and equipment constraints, permitted assumptions, intended audience, due event, linked project version, and exception owners. Require a field only when its absence changes whether design can responsibly produce the requested output.

A universal intake form usually becomes either too weak or too burdensome. Residential screening, commercial interval-data analysis, storage discovery, a reroof revision, and an engineering handoff do not need identical records. Keep a compact core that identifies the work, then add conditional field groups triggered by the requested stage and project type.

The core should be strict because it establishes identity and purpose. Conditional groups can be precise without forcing irrelevant questions onto every request.

Avoid requiring fields because they look professional. A field earns its place when one of four things is true: it changes the design task, changes the evidence threshold, changes the person who must review, or changes how the output may be used. Everything else can remain optional context.

For electricity records, capture the account or meter identity, billing period, file source, and known changes at the site. For imagery or drawings, capture source and date plus whether the material represents existing or proposed conditions. For customer statements, name the speaker and the decision affected. A folder called “documents” is not a source register.

The technical-data management guidance from NASA discusses planning how data are acquired, identified, accessed, managed, protected, and used in NASA work. Solar teams need their own policy, permissions, and retention rules, but the handoff lesson transfers: a file’s existence does not explain its identity, authority, permitted use, or relationship to the current request.

Separate the request from its attachments

The request is the control record. Attachments are evidence. Do not ask a designer to reconstruct the request by opening a dozen files and guessing which facts sales considers current. The control record should point to each source, state why it matters, and identify the fields or decisions it supports.

This separation also makes corrections cleaner. If a newer bill arrives, the team updates the evidence reference and reopens affected fields. It does not need to duplicate an entire form or leave two bills in a folder with no explanation.

Make due events more useful than naked dates

Record why the output is needed: internal qualification meeting, scheduled customer review, site-visit planning, revision comparison, or another real event. A date with no event invites false urgency. An event helps design understand the audience and choose the correct level of work.

The due event still does not override the acceptance rule. If required evidence is missing, the team can change the meeting purpose, provide a limited output, collect the evidence, or reschedule. It should not relabel an unsupported design as complete because a calendar reminder arrived.

How should sales and design build the acceptance rule?

Sales and design should build the rule from real returned requests, agree on stage-specific minimums, assign field owners, define acceptable evidence states, write exception outcomes, and let the receiving designer record the final intake decision. Pilot the rule on live work, then revise fields that fail to change a decision or leave recurring ambiguity unresolved.

Build the shared definition in a working session with examples on screen. Abstract policy debates tend to produce generic words such as “accurate,” “complete,” and “all information supplied.” A returned request exposes the actual disagreement. Sales may believe a customer email establishes scope, while design may need a site identifier, intended option, and explicit boundary before it can act.

Use this numbered process:

1. Collect recent acceptance failures. Bring returned requests, clarification messages, redesign triggers, wrong-site attachments, stale revisions, and cases where a designer proceeded with an assumption. Remove personal blame. The unit of analysis is the missing control.
2. Name the design stages your team actually sells or performs. Examples may include internal screening, preliminary layout, customer proposal design, survey-driven revision, permit or engineering handoff, and change request. Use the stages in your own service model.
3. Write the decision and deliverable for each stage. State who will use the output, what it may support, and what it must not imply. This defines how much certainty the request needs.
4. Turn recurring failure points into fields and evidence tests. Require the site identifier if files are often mixed. Require a load-source record if model basis is unclear. Require current-option identity if proposal revisions drift.
5. Choose one owner and one receiver for every controlled field. Contributors can help, but one role must attest to the submitted value and one role must judge whether it supports the requested work.
6. Pre-write the exception routes. For each required field, decide whether missing or conflicting information triggers return, conditional acceptance, alternate work, or escalation. State what design is prohibited from doing while the exception remains open.
7. Pilot, review, and prune. After a bounded pilot, examine returns and clarifications. Remove fields that never affect acceptance. Strengthen fields whose answers remain ambiguous. Keep the revision history so teams know which definition governed each request.

The receiver needs three decisions, not a binary checkbox:

Conditional acceptance is valuable only when it is narrow. “Proceed, everything to be confirmed” is a blank cheque. “Prepare an internal roof-layout option from the identified imagery; do not publish production, pricing, equipment, or customer-facing conclusions until the listed records are reviewed” gives the designer an actual boundary.

NASA’s interface-management guidance addresses responsibilities and interactions where work crosses organizational or system boundaries. It is not a solar intake rule, but it supports the operating point: the boundary between sales and design needs named inputs, responsibilities, and controlled changes, not an assumption that both roles interpret “ready” the same way.

Copy-ready complete design request record

Copy this asset into your CRM, ticket system, project workspace, or controlled form. The bracketed prompts are field names, not placeholders for the published article.

Solar design request identity
Project ID and site:
Request version and prior version, if any:
Sender and receiving design role:
Submitted date and due event:

Decision and output
Decision this work supports:
Requested design stage and deliverable:
Intended audience:
Explicit exclusions and prohibited downstream use:

Evidence register
Source name, link, date or period, project identity, and evidence state:
Customer-supplied statements with named owner and date:
Team assumptions with reason, owner, affected output, and review trigger:
Conflicting or missing records:

Scope and controls
Site areas and options in scope:
Load, tariff, equipment, storage, financial, and electrical context relevant to this stage:
Known site, access, roof, authority, utility, lender, insurer, contract, or schedule dependencies:
Current design, model, BOM, and proposal references, if this is a change:

Receiving decision
Accepted, conditionally accepted, or returned:
Permitted work and prohibited use:
Exception owners and next actions:
Receiver, decision date, and request version:

Do not turn the record into a wall of free text. Use controlled choices for evidence state, design stage, intake decision, and project version where practical. Keep short explanation fields for context that a dropdown cannot express.

The sales-to-design handoff guide can help teams place this record inside the wider operating path. The scalable design workflow addresses downstream gates. The request rule should stop at acceptance instead of trying to duplicate the full project workflow.

What happens when a request is incomplete or changes?

An incomplete or changed request should enter a visible exception state, not a private chat. Record the affected field, competing or missing evidence, current owner, allowed work, blocked outputs, next action, and reopening trigger. If an accepted input changes, identify every linked design, model, BOM, proposal, and customer statement that needs review before reuse.

The fastest bad response is to make the designer repair the request silently. That may save one message while teaching the organization that submitters do not need to meet the rule. It also hides the real cost. Nobody can later distinguish design work from intake reconstruction, so the same missing fields survive.

Return the request when the assignment itself is unclear, the project identity is unreliable, a required source is unreadable or mismatched, or the requested output would misrepresent the retained evidence. Use conditional acceptance when limited work has a clear purpose and the unresolved information cannot contaminate that work. Route alternate work when the responsible next step is evidence collection, survey planning, customer clarification, or qualified review rather than design.

NASA’s configuration-management guidance discusses identifying configurations, controlling changes, tracking status, and auditing configuration information in NASA programs. Solar teams should not copy aerospace governance wholesale. The relevant principle is smaller: once a request is accepted, a changed governing input should reopen the affected work instead of leaving old and new outputs looking equally current.

Visibly labelled illustrative example

This is an invented workflow example, not a customer case or performance claim.

Sales submits a request for a customer-facing commercial rooftop option. The site address and decision are clear. The attached electricity record covers one meter, while the notes refer to two meters. Roof imagery is identified and dated. The customer has discussed a future load, but no owner or timing is recorded.

The designer conditionally accepts a narrower task: prepare an internal roof-use sketch for the identified site. The acceptance record prohibits a customer-facing production or financial scenario. Sales owns meter reconciliation and asks the customer operations lead to document the future-load basis. When those records arrive, the team creates a successor request that links the sketch, identifies both meters, and states whether the future load belongs in a separate option.

Nothing in the example requires design to decide whether the future load is real. Nothing requires sales to wait for every possible project fact before receiving useful work. The shared definition changes the deliverable to match the evidence.

Review the definition when behavior changes

Do not treat the definition as permanent. A new service, financing path, jurisdiction, design stage, survey method, equipment family, or customer workflow can change which inputs matter. Review the rule when returned-request reasons cluster around a field the form does not capture or when submitters supply a field consistently and designers never use it.

Track operational signals without inventing an external benchmark. Useful internal observations include return reasons, conditional-acceptance reasons, clarification touches, exception age, requests reopened after input changes, and customer-facing outputs discovered on an unaccepted basis. Define each measure before comparing periods. A lower return count can mean better intake, or it can mean designers stopped enforcing the rule.

The solar design review checklist begins after the request has produced work worth reviewing. Keep the boundary clear: intake acceptance does not approve a design, and design review does not repair an undefined assignment retroactively.

Where should software support the design request?

Software should hold the request identity, evidence references, stage, version, intake decision, assumptions, exceptions, and linked outputs where the team can review them together. It may enforce required fields and permissions, but it cannot decide whether evidence is truthful, approve engineering, interpret every jurisdiction, or replace the people accountable for customer promises and external approvals.

Start with governance, then configure the tool. A required field is useful when the team has agreed what counts as a valid answer and what happens when the answer is missing. Automation cannot rescue a vague definition. It only makes the vague behavior happen faster and at greater scale.

Where a project moves from request to solar work, the record should preserve the accepted site, design stage, evidence basis, and option identity. The roof model, array layout, shading analysis, energy model, financial scenario, electrical workflow, bill of materials, and proposal should remain traceable to the request and current design version where each applies.

SurgePV supports 3D roof modeling, solar array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. Results still depend on source data, assumptions, equipment models, configuration, and review. The software does not validate every incoming record or replace approval by the responsible engineer, authority, lender, insurer, or utility.

The solar designing workspace belongs after acceptance, when the team has a controlled basis for the model and layout. Its presence does not change which role owns the source review or intake decision.

That product boundary matters. A platform can make a customer bill easy to attach, but a person must still check the site and meter identity. It can connect a layout to a proposal, but the team must still decide whether the evidence supports customer use. It can retain versions, but the organization must define who may accept a request and release an output.

Use the solar design source-of-truth guide when you need to decide which system owns each field after intake. A complete request and a source-of-truth model solve different problems. The request establishes that work may begin. The source-of-truth model governs which current values and released outputs downstream roles may use.

The most useful shared definition is a small operating agreement with teeth. Sales can see what design needs and why. Design can accept useful limited work without pretending uncertainty vanished. Managers can see recurring policy gaps instead of refereeing the same private dispute. And when information changes, the team can reopen the right work rather than sending every artifact back to the beginning.

Frequently Asked Questions

Who should decide whether a solar design request is complete?

The receiving design role should accept, conditionally accept, or return the request against the shared rule. Sales owns the commercial purpose and supplied records, while design owns whether those inputs support the requested output. A manager resolves recurring policy disputes, but should not quietly approve missing project evidence on the designer’s behalf.

Does complete mean every project fact is verified?

No. Complete means the request contains enough identified and appropriately labelled information for the stated design stage. A preliminary layout may use documented assumptions if their source, owner, effect, and verification trigger are visible. A later technical release needs a different evidence threshold and qualified review appropriate to that deliverable.

What should happen when one required input is missing?

Apply the field’s pre-agreed exception rule. The request may be returned, accepted for limited work, or routed to another task such as evidence collection. Record the missing item, its owner, the permitted output, prohibited downstream use, due event, and reopening trigger. Never let an empty field become an invisible design assumption.

Can a form create a shared definition by itself?

No. A form can capture fields, but the operating agreement also needs evidence standards, a receiving decision, ownership, exception handling, change control, and periodic review. If sales can submit anything and design must begin anyway, the form is only a mailbox with required-looking boxes. The shared behavior matters more than the interface.

Where can SurgePV support a complete design request?

SurgePV can support 3D roof modeling, array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. The project team must still decide whether source records are sufficient, route technical and jurisdictional questions, manage permissions, and obtain approvals from responsible engineers, authorities, utilities, lenders, and insurers.