9 Fields Every Solar Sales-to-Design Request Needs

A request can contain an address, a utility bill, a module name, and a deadline and still be unusable. The designer sees facts with no project boundary, an attachment with no source date, and a target with no explanation of who approved it. The queue says “submitted.” The actual work has not started.

The fix is a request record that separates what sales knows, what the customer supplied, what the team assumed, and what a qualified reviewer still has to decide. These nine field groups provide a starting record for those boundaries; the required detail depends on the requested stage and project.

This guide is an operating template, not an industry standard. Adapt it to current contracts, jurisdictions, equipment, utilities, lenders, insurers, permitting authorities, professional responsibilities, and company policy. It does not provide engineering, electrical, structural, code, safety, utility, permitting, financial, tax, legal, privacy, or contract approval.

The broader sales-to-design handoff guide explains how to manage the bottleneck. The shared-definition guide explains how teams agree on completeness. This page gives them the field-level record to use.

What belongs in a solar sales-to-design request?

A solar sales-to-design request should preserve the customer decision, project boundary, evidence, usable technical inputs, operating constraints, requested output, accountable owners, and current version in one reviewable record. Designers need enough context to accept or return the request deliberately. They should never have to infer which attachment, assumption, scenario, deadline, or promise sales intended.

The useful test is not “Did sales fill the form?” It is “Can another person tell what the designer may rely on, what remains uncertain, and what happens next?” A field earns its place when it changes a design decision, review action, customer conversation, or release condition.

Start by giving every entry an evidence state. The labels can vary by company, but their behavior must be clear.

NASA’s technical data management guidance discusses how data are acquired, identified, accessed, managed, protected, and used in its own systems-engineering context. That is a cross-domain analogy, not a solar rule. Its practical lesson here is narrow: an attachment is not usable merely because someone uploaded it.

The request should keep source and permission boundaries visible as well. NIST describes its Privacy Framework as a voluntary privacy-risk tool. It does not authorize collecting, sharing, or modeling customer data. A team still needs current policy and qualified review for access, purpose, retention, correction, security, vendor, and jurisdiction questions.

Which nine fields should every request include?

The nine fields are request identity, customer decision, project boundary, evidence register, energy and electrical inputs, physical site evidence, equipment and layout constraints, deliverable purpose, and workflow control. Treat each as a grouped record rather than one text box. The group needs a value, evidence state, source, owner, date, exception, and effect on the requested output.

Field 1: Request identity and version

Give the request a stable project identifier, customer or account identifier, site identifier, request type, created date, submitter, current version, and status. Keep names separate from identifiers. Two sites can share a street name, one customer can have several meters, and one opportunity can produce multiple design scenarios.

The version should answer a plain question: which set of inputs is the designer working from right now? A filename such as final-new-revised.pdf cannot do that. Record the current version, the version it replaced, the change reason, who authorized the change, and whether work on the old version stopped.

NASA’s configuration management guidance discusses identifying configurations, controlling changes, tracking status, and auditing information in NASA programs. The article borrows that record discipline only. It does not claim a NASA process is required for solar work.

Use a small status vocabulary that changes behavior: draft, submitted, under review, accepted, held, returned, superseded, cancelled, or released. “In progress” hides whether design accepted the basis or merely opened the record. If the team cannot tell which version is active, no later field is trustworthy.

Field 2: Customer decision and approved scenario

Record what the customer is trying to decide next, not the outcome sales hopes to sell. Examples include reviewing preliminary roof use, comparing two bounded system concepts, discussing available consumption data, evaluating whether storage deserves a separate study, or preparing material for an internal stakeholder meeting.

Then name the requested scenario. State whether it is customer-requested, sales-proposed, contract-defined, or created for internal screening. Preserve any size ceiling, budget boundary, equipment preference, aesthetic constraint, schedule event, resilience question, or comparison the customer actually supplied. Do not convert interest in lower bills into permission to maximize array size.

This field helps reviewers detect a scope mismatch: design solves a different problem from the one the customer agreed to review. The layout may be technically careful and commercially unusable because it answers the wrong decision. Link the decision to a dated note, signed scope, meeting record, or another approved source when one exists.

Write forbidden interpretations beside the request when risk is high. “Customer asked about backup” does not establish a storage specification. “Customer wants the lowest payment” does not authorize a financing recommendation. “Customer mentioned future EVs” does not establish load, timing, equipment, or electrical capacity.

Field 3: Site and project boundary

Identify the physical site and the exact project boundary. Include the service address, parcel or campus detail when appropriate, building or structure identifiers, meter boundary, roof versus ground scope, access boundary, and any area excluded from the request. For portfolios, name which facilities belong to this version.

Do not treat a mailing address as a design boundary. A customer may occupy one unit in a multi-tenant building, lease the roof, control only some meters, or share electrical infrastructure. Sales does not need to resolve every property or legal issue before a preliminary request, but it must expose what is known and what is not.

The source matters. Record whether the boundary came from the customer, site visit, contract, utility document, property record, approved imagery, or another current source. Note the observation date and any conflict. If a utility bill names a different service address from the opportunity record, hold the relevant work instead of picking the value that makes the form pass.

This field also names jurisdictional routing facts without pretending to interpret them: project location, utility, authority having jurisdiction if verified, property type, and any known program or contract boundary. Qualified reviewers must determine what those facts require.

Field 4: Source evidence and field state

Create an attachment register inside the request. For every file or external record, capture a document identifier, descriptive name, source, received date, coverage period, site or meter association, version, access restriction, quality note, and the fields it supports. Preserve the original and point to it. Do not paste a number into the request and sever it from the file that gave it meaning.

Evidence quality belongs here too. A partial bill, cropped image, screenshot without a date, unreadable plan, stale equipment sheet, mixed portfolio export, or customer estimate should carry a visible limitation. Design can then accept a bounded use, ask for a better source, or omit the dependent output.

NASA’s requirements management guidance discusses identifying, controlling, tracing, and changing requirements. For a sales-to-design request, the useful analogy is traceability: the requested scenario should point to its approved source, and any later change should point to the decision that changed it.

Avoid a generic attachment checkbox. “Bill uploaded” does not say which meter, which months, whether every page is present, whether the account matches the facility, or whether the team may use it for the proposed analysis. A field state plus a short quality note is more honest than a green check.

Field 5: Energy and electrical inputs

Separate measured, billed, interval, customer-stated, and modeled values. Record the meter or service identifier, utility and tariff only when verified, consumption period, units, missing periods, demand data where relevant and available, planned load changes, and the source for each input. Do not merge several meters unless the project boundary and analysis purpose support it.

For interval records, include the channel meaning (energy in kWh, interval-average power in kW, peak demand or another defined quantity), interval duration, timestamp convention, time zone and import/export direction. Utility import after onsite generation is not automatically total facility load. The consumption-profile error checks provide the detailed validation workflow; the request should carry its accepted boundary and unresolved limitations.

Record electrical information as evidence, not as sales interpretation. The request can include service documents, equipment photos, existing one-lines, panel schedules, interconnection records, and customer-authorized notes. It should flag legibility, source date, observed versus customer-stated status, and the need for field verification or qualified review.

Never backfill missing energy periods with an unlabelled average. If company policy allows a preliminary assumption, record its method, owner, reason, limitation, and replacement trigger. Make sure the proposed output labels it. A modeled scenario should not quietly become a customer history claim after it moves into a proposal.

The solar project intake process can carry the upstream collection workflow. This request should contain the accepted design basis and a link to the underlying record, not a second uncontrolled copy of every customer file.

Field 6: Roof, ground, and obstruction evidence

Describe which physical surfaces are in scope and which evidence supports them. For a roof, that can include roof planes, material, age if customer-provided and relevant, known work areas, setbacks requiring qualified confirmation, access paths, visible obstructions, tree context, imagery date, and site-visit records. For ground work, record the bounded area, terrain evidence, exclusions, access, and known land-use questions.

DOE’s photovoltaic system design basics explains that modules sit within complete systems that can also involve mounting structures, power electronics, and storage. The page does not assess this customer. It supports the limited point that a module canvas alone cannot represent the whole project boundary.

Use observation language with remote evidence. “Object visible near the south roof edge in imagery dated…” is different from naming equipment, dimensions, condition, or structural effect. Give the designer a way to mark uncertain geometry and request confirmation rather than tracing an image as though it were a survey.

Photographs also need identity. Capture who supplied them, when, which structure and orientation they show, and whether any editing or compression removed detail. Ten unlabelled phone images can create more uncertainty than two correctly identified views.

Field 7: Equipment, layout, and commercial constraints

Record commitments and constraints without assigning technical approval to sales. The group may include customer-requested equipment, approved product families, procurement availability state, module or inverter options, storage question, mounting preference, aesthetic boundary, expansion question, contractual exclusion, and sales promise that a reviewer must verify.

Separate “must,” “prefer,” “may compare,” and “not yet decided.” If the customer prefers an all-black module, that preference should not appear as a fixed equipment model unless the responsible teams confirm product, procurement, configuration, warranty, lender, insurer, code, utility, and permitting implications.

Layout targets require the same care. Record the reason behind a requested capacity, coverage, bill offset concept, production question, budget constraint, or visual preference. A naked target invites the designer to optimize toward a number without knowing which constraint can move. Preserve who supplied it and what evidence supports it.

This field is also the place for explicit exclusions. Examples include no storage modeling in this request, no structural conclusion, no final electrical design, no price approval, or no utility submission package. The actual exclusions depend on company scope and qualified review. Their value is preventing a preliminary asset from being mistaken for a later-stage deliverable.

Field 8: Deliverable, audience, and review purpose

Name what design should return, who will use it, and which decision it supports. A preliminary layout for an internal qualification meeting is not the same artifact as a customer proposal image, design review set, equipment comparison, energy model, electrical workflow output, or bill of materials.

Specify the output boundary, required formats, scenario count, labels, source notes, assumptions, customer-facing language, and review route. If the buyer needs to compare two choices, state the comparison basis rather than asking for “options.” If sales needs one visual for a meeting, say which questions the visual should and should not answer.

Record the audience. A homeowner, facilities leader, engineer, procurement reviewer, finance lead, lender, utility, permitting authority, and installation team read different documents for different purposes. Sales should not ask one preliminary layout to satisfy all of them. The designer should be able to say that the requested audience requires another workflow or qualified approval.

Tie the due point to an event, such as “ready for internal review before the customer meeting,” and name the event owner. A naked date hides whether upstream evidence can arrive after it, who reviews the draft, and whether lateness means reschedule, reduce scope, or return the request.

Field 9: Owner, due event, exception, and change route

End the request with people and decisions. Name the sales owner, design accepter, customer-source owner, technical reviewer, and person allowed to approve a scope or scenario change. Record the due event, priority reason, dependencies, acceptance outcome, return reason, resolution owner, and next review point.

NASA’s interface management guidance discusses responsibilities and interactions across boundaries in NASA programs. The useful analogy is that a handoff has two sides. A form submitted into a queue with no accepting owner, response rule, or escalation path is storage, not an interface.

Give design four honest acceptance outcomes: accept, accept with documented limitations, hold for a named resolution, or return with reason codes. Add route and cancel when another function owns the issue or the scenario no longer exists. Do not reward silent repair. If designers repeatedly research addresses, identify meters, rename files, or reconstruct customer intent, the queue hides upstream work.

Every change should create a record: changed field, old state, new state, source, requester, approver where required, affected outputs, and whether the active design basis changed. Preserve superseded versions. A revision history is useful only when another person can tell what to recheck.

How should teams accept, return, and revise a request?

Use one visible sequence: sales assembles the record, a named reviewer checks source and permission boundaries, design tests the nine groups against the request type, and the accepting owner records accept, limited accept, hold, return, route, or cancel. Any later change must identify the affected field, source, approver, output, and replacement version before work resumes.

The design review checklist belongs downstream. Acceptance does not mean the design is correct or approved. It means the team has a controlled basis for the specified work and has exposed the limitations that survive into review.

1. Choose the request type. Map required fields and permitted evidence states to the actual output, market, and stage.
2. Assemble the nine groups. Sales enters values, sources, dates, states, owners, and customer context without filling gaps with memory.
3. Run a source and access check. Confirm attachment identity, project use, conflicts, sensitive data handling, and qualified-review triggers.
4. Test the decision boundary. Make sure the requested scenario answers the customer decision recorded in Field 2.
5. Accept or disposition the request. Design records one explicit outcome and any limitation, missing item, route, or cancellation reason.
6. Create the active design basis. Lock the accepted version and preserve the original submission and evidence register.
7. Control changes. Route changed customer facts, equipment, scope, site evidence, output needs, or dates through the same record.
8. Review the output against the request. Check that the deliverable uses the current basis and exposes material assumptions and limitations.
9. Close the handoff. Record what was delivered, what remains open, who receives it, and which later workflow now owns the project.

Use reason codes that tell the upstream team what to fix. “Incomplete” teaches nothing. Better codes include wrong site, conflicting customer identity, missing meter association, unusable attachment, unknown decision, unsupported target, unclear output, unapproved equipment commitment, missing access authority, stale version, unresolved professional review, or due event without an owner.

Copy-ready sales-to-design request record

Copy this structure into the system that already owns the handoff. Keep linked source files in their approved repository instead of duplicating sensitive records into a notes field.

Add these columns to every material entry: evidence state, source, source date, owner, reviewer, expiry or refresh trigger, exception, affected output, and latest decision. A database can store them in related records. A spreadsheet can use separate tabs. The interface matters less than consistent behavior.

Visibly labelled illustrative example

Illustrative only. A sales representative requests a preliminary roof-use concept for an upcoming customer planning call. The record identifies one facility and two meters, but the uploaded energy file covers only one meter. The roof imagery is current enough for a bounded visual screen under company policy, while electrical and structural conditions remain unknown.

The representative marks the customer decision as “review whether a data-complete assessment is worth scheduling,” not “approve a final system.” Design accepts a single preliminary visual with the second meter excluded, no savings or production conclusion, and a visible note that site, electrical, structural, utility, and other reviews remain open. This example proves no actual project result.

If the missing meter later arrives, sales does not replace the attachment in place. The owner creates a new request version, associates the new file with its meter and period, records the changed decision basis, and asks design whether dependent outputs must be revised.

Measure the process without inventing productivity claims

Review operational counts your own system can measure: requests received, acceptance outcomes, reason codes, time spent in each state, fields most often returned, changes after acceptance, outputs revised because the basis changed, and unresolved exceptions at release. Define each measure before using it and have the right owner verify the data.

Do not turn these internal measures into universal benchmarks. A high return count may reveal poor intake, a stricter acceptance policy, a new request type, or a temporary training need. Read reason codes and affected fields before blaming sales or design.

Check whether hidden repair moved between roles. If rejection falls because designers silently correct requests, the dashboard improved while the process got harder to see. Sample accepted records and compare the logged basis with the actual work performed.

Where should software support the request?

Software should preserve the accepted design basis, field states, evidence links, owners, assumptions, versions, and changes while carrying suitable inputs into the requested technical and customer-facing work. It should make uncertainty visible and make superseded records difficult to mistake for current ones. Software should not decide evidence validity, customer intent, engineering approval, compliance, or professional responsibility.

SurgePV’s verified solar design platform scope includes 3D roof modeling, array layout, shade analysis, energy-yield and financial models, electrical workflow support, bill-of-materials output, and proposal generation. Those functions depend on suitable source data, stated assumptions, equipment models, configuration, and responsible review.

That makes the request the beginning of a controlled design basis, not proof that the platform validated it. SurgePV does not establish property rights, customer consent, data permission, electrical condition, structural capacity, code compliance, equipment compatibility, utility acceptance, permitting approval, price, production, savings, or another outcome. Current qualified people and authorities retain those decisions.

Before configuring any system, test the workflow with several real request types and bounded sample records. Check access controls, required fields, conditional fields, attachment identity, version behavior, reason codes, change notices, exports, customer-facing labels, retention, security, integrations, and contract terms. Confirm current features and scope in writing.

The durable standard is simple: the software must preserve the question “Why may the designer rely on this field?” If automation turns unknowns into defaults or separates a value from its source, it weakens the record even when the interface looks tidy.

Frequently Asked Questions

Does every solar design request need all nine fields completed?

Every request should contain all nine field groups, but a field may carry a controlled state such as verified, customer-provided, assumed, unknown, not applicable, or blocked. The team must define which states permit design work for each request type. A blank cell is not a useful state because it hides whether someone checked the field.

Who should own the solar sales-to-design request?

Sales should own the customer decision, submitted evidence, requested scenario, and commercial context. Design should own technical acceptance, modeling choices, technical questions, and output status. One named person should own the handoff record and its due event. Qualified reviewers retain authority for engineering, electrical, structural, code, utility, permitting, finance, tax, and contract decisions.

What should happen when an input is missing?

Mark the input unknown or blocked, name the person who can resolve it, and choose an explicit outcome: accept with a bounded assumption, hold, return, route for qualified review, or cancel the scenario. Record where the assumption will appear in the output. Never let a designer silently choose a favorable value just to keep the queue moving.

Should sales specify the solar equipment in the request?

Sales should record customer commitments, approved equipment options, procurement constraints, and any scenario the buyer asked to compare. Sales should not choose technical compatibility or present a tentative product as approved. Design and qualified reviewers must confirm current equipment data, configuration, code, electrical, structural, procurement, warranty, lender, insurer, utility, and permitting implications.

Where can SurgePV support a sales-to-design request?

SurgePV can carry suitable project inputs into 3D roof modeling, array layout, shading analysis, energy-yield and financial modeling, electrical workflows, bill-of-materials output, and proposals. It does not validate source evidence, decide customer intent, approve assumptions, replace qualified reviewers, or guarantee design accuracy, production, savings, price, approval, schedule, close rate, or another outcome.

The nine fields do more than make a request complete. They preserve the reason behind the work. When a customer changes the decision, a meter arrives, equipment changes, or a reviewer rejects an assumption, the team can find the affected basis and respond without reconstructing the project from inbox fragments.