7 Questions Before Sales Requests a Solar Layout

Illustrative scenario, not a customer case: “Can you draw this roof?” sounds like a small request. It may hide three buildings, two meters, an old utility bill, a planned electric vehicle, a customer preference about street-facing modules, and a salesperson who has already mentioned a panel count. The designer receives one address and a due date. The real assignment is scattered across calls, attachments, and memory.

A useful pre-layout handoff turns that scattered context into seven decisions. Sales does not need to finish the designer’s work. Sales needs to state what the customer is trying to decide, identify the records behind the request, preserve uncertainty, and name who will answer the questions that remain.

This article covers the conversation before a layout request enters design. The sales-to-design handoff guide owns the wider process through layout, bill of materials, proposal, financial review, and later delivery. The shared definition of a complete design request owns the company-wide acceptance rule. The solar design intake checklist owns the full packet and its formal intake states.

Use these seven questions to prepare a layout request under your team’s agreed evidence and review rules. They do not establish a universal technical standard or replace project-specific qualified decisions.

What should sales resolve before requesting a solar layout?

Sales should resolve the meaning of the request: the customer decision, property and meter scope, energy basis, current site evidence, known constraints, prior customer language, and ownership of open items. “Resolved” can mean confirmed, explicitly assumed, or assigned for follow-up. It should never mean that a designer must discover the assignment after work begins.

A pre-layout question is resolved when the receiver can see the answer’s evidence state and act consistently. The answer may be documented by a bill, drawing, survey, photo, system record, or customer communication. It may be stated by a named person. It may be a planning assumption that the team permits for a limited layout. It may remain open under a named owner.

Those states have different consequences:

The word “complete” can mislead when it is treated as a claim that every future project fact is known. An early layout can be complete for an internal roof-fit discussion while carrying provisional geometry. The same record may be inadequate for customer use or later technical work. Sales should name the stage and audience before asking design to decide what enough means.

NASA’s requirements-management guidance discusses identifying, tracing, controlling, and managing changes to requirements. NASA does not set solar sales procedures. The useful cross-domain lesson is record discipline: the request should show which requirement exists, where it came from, and what happens when it changes.

Use one sentence to define the assignment. “Prepare an early south-building rooftop layout for internal sales planning using the attached imagery, with roof geometry and equipment locations marked provisional” gives the designer a purpose, boundary, audience, evidence basis, and qualifier. “Need proposal design by Friday” supplies urgency without defining the work.

Which seven handoff questions make a layout request usable?

Seven questions make the request usable: what decision the layout supports; which site and meter are included; which consumption and future-load basis applies; what site evidence is current; which preferences and constraints are real; what the customer has already heard; and who owns exceptions, review, and handback. Each answer needs a source, state, and owner.

1. What decision should the layout help someone make?

Begin with the decision, not the drawing. A customer may want to see whether a named roof area merits further investigation, compare a current-load concept with a future-load scenario, discuss appearance, prepare an internal capital request, or understand what another site visit must verify. Each purpose changes what the layout must show and how it may be used.

Record the decision in terms a customer and designer can both inspect. “Test whether the detached garage belongs in the initial residential concept” is more useful than “maximize panels.” “Prepare a roof-fit discussion for the facilities team” is more useful than “commercial layout.” The first version of each statement explains what question the picture will answer.

Then name the audience. An internal sales screen, a customer discussion, an estimator’s planning view, and a later technical package carry different evidence and review expectations. Do not let an internal sketch become a customer commitment because nobody recorded who could see it.

Write the requested artifact too. Sales may need a roof outline with possible array areas, a bounded panel-placement concept, a base case and a separately labelled option, or a list of site gaps before design proceeds. If sales asks for “a layout” without the output, the designer must pick the level of detail and may solve a different problem.

Use a short decision statement with five fields:

• decision to support;
• person or group making it;
• layout stage and intended audience;
• question the layout must answer;
• decision the layout must not be used to make.

That last field has practical value. An early roof-fit picture may help the customer discuss usable areas while remaining unsuitable for final equipment selection, permit submission, structural approval, installation, or a production promise.

2. Which property, structure, roof area, and meter are in scope?

An address is an index, not a site boundary. It may contain a main house, detached structure, several commercial buildings, carports, ground area, multiple meters, tenant accounts, or property lines that the available imagery does not explain. Sales should identify which physical and energy assets belong in the request.

Record the site name and address exactly as the project system uses them. Add parcel, building, unit, meter, or account identifiers where they are already available and appropriate. Mark the specific roof planes or ground areas the customer wants considered, the areas excluded from the current assignment, and any ownership or access question that remains open.

The U.S. Department of Energy’s homeowner solar guide identifies roof age, tree cover, size, shape, and slope as general considerations. DOE has not inspected this customer’s roof. Its categories explain why “the address is correct” does not settle which areas are usable or whether current evidence supports a layout.

Sales should also distinguish the energy boundary from the physical boundary. One roof may serve one meter, several meters, or a facility whose consumption records need separate treatment. Several buildings may share a commercial objective while remaining separate design and utility questions. Do not merge them because the customer uses one company name.

If ownership, access, meter identity, or building scope is unclear, sales can still preserve a useful unresolved state. Name the question, owner, and effect. “Warehouse B included for visual roof-fit only; meter relationship pending facilities confirmation; exclude its capacity from the base energy scenario” gives design a boundary. “Check meter later” does not.

3. Which energy-use basis and future loads belong in the request?

The layout request should identify the energy record that informs the assignment, even when design is not yet producing a full energy model. Sales should record the account or meter, billing period, file source, known gaps, and whether the value represents measured history, a customer statement, or a planning assumption.

Avoid collapsing present and future demand into one number. A planned electric vehicle, heat pump, process line, tenant change, building extension, or operating-schedule change needs its own description, evidence owner, timing, confidence, and confirmation event. The customer may want it studied, but that does not turn it into observed consumption.

Separate at least three cases when relevant:

Do not ask a designer to infer the customer’s preferred basis from an attachment folder. If sales wants a current-use base case and a future-load option, say that. If the request is only a roof-fit conversation with no energy scenario, say that too. A missing energy assignment should not become a silent system-sizing choice.

Sales should preserve customer questions without answering outside its authority. Utility treatment, tariff selection, export value, incentive eligibility, financing, tax, and savings can require current source material and qualified review. An early layout request can name those open commercial inputs without turning them into design facts.

4. What site evidence is current, identifiable, and usable?

List the records that actually exist: imagery, survey report, roof sketch, photos, measurements, equipment labels, electrical observations, drawings, customer statements, or prior layouts. For each item, record the project match, capture date or source date when relevant, subject, evidence state, and known limitation.

A file count is not an evidence review. Forty photos can leave the designer unable to locate a vent or match a dimension to a roof edge. A bill can belong to a different meter. An old layout can predate a roof change. Sales does not need to verify technical sufficiency, but it should avoid representing unidentified records as current.

The missing site-information guide explains how the sender indexes records and how design accepts, limits, or returns them. At this earlier handoff, sales should answer two simpler questions: what evidence is present, and what does sales already know is missing, provisional, unreadable, or conflicting?

Keep field observations separate from modeled effects. Sandia’s PV Performance Modeling Collaborative describes plane-of-array irradiance through inputs and relationships including solar position, array orientation, irradiance components, ground reflection, and shading. That modeling context does not validate a project’s imagery, tree record, geometry, obstruction capture, or production result.

Use an evidence index with narrow descriptions. An illustrative entry such as “West roof plane, looking east, survey photo, captured 2026-08-27, obstruction positions visible, dimensions not shown” identifies the source and its limits. “Roof pics” pushes interpretation into the design queue. Sales can assemble the index without declaring the roof acceptable for engineering.

5. Which customer preferences and project constraints are confirmed?

Separate preferences from constraints. A customer may prefer no modules on a street-facing roof, want a battery option, reserve an area for future work, or ask that equipment stay away from a particular entrance. A physical, contractual, authority, utility, structural, electrical, or safety constraint carries a different source and reviewer.

Record each item in the customer’s or source document’s own terms. Add who supplied it, when, whether it is verified, and what part of the layout it could affect. Do not translate “we would rather keep the north roof clear” into “north roof prohibited.” Do not translate “panel is in the garage” into an electrical conclusion.

DOE’s PV system design overview describes modules as one part of a system that can also include mounting structures, inverters, storage, and power electronics. That general context is enough to show why a layout request may need more than a desired panel count. It does not select equipment or approve a project configuration.

Use three columns in the handoff: customer preference, currently supported constraint, and unresolved technical or external question. This prevents a preference from becoming a requirement and prevents a real constraint from being buried in free-text notes.

Some items should stop or narrow the request. If sales cannot tell which structure the customer owns, which area may be accessed, whether the customer wants a rooftop or ground concept, or whether a stated exclusion applies, the designer may have no defensible boundary. Return the request instead of filling that boundary from imagery or habit.

6. What has sales already said, shown, or implied to the customer?

The designer needs the customer-language record before producing a picture that may appear to confirm it. Sales should attach or summarize any panel count, system size, production figure, savings scenario, equipment statement, placement description, deadline, incentive reference, price range, or “this should fit” message already shared.

This is not an audit of the salesperson’s character. It is a version and claims control. A casual number can become the customer’s reference point. If design does not know it exists, a materially different layout can look like an unexplained reversal. If design quietly forces the old number to fit, the drawing inherits a commitment that the available evidence may not support.

Classify prior language as one of these:

• sourced and current for the stated use;
• preliminary and visibly qualified;
• superseded by a later record;
• unsupported or unclear and requiring review;
• customer interpretation that sales needs to correct or clarify.

Preserve the exact message or customer-facing artifact when possible. A summary such as “discussed about twenty panels” may omit whether the statement was a question, rough range, firm claim, or reference to another building. The receiving designer needs the language and context, not an improved recollection.

If a statement needs correction, assign the customer conversation to sales or another authorized owner. Design should explain the technical change and affected artifact, while the customer-facing owner decides how and when to communicate it. The new layout should not be used as a silent correction.

7. Who owns open questions, design review, and the handback?

Every unresolved item needs one owner and a next event. “Sales and design to confirm” names two departments and no accountable person. Use a role or individual who has authority to obtain the record, make the commercial decision, route qualified review, or communicate with the customer.

Define the receiving designer too. A queue is not an acceptance owner. The named receiver should accept, conditionally accept, return, or escalate the request against the published intake rule. If the work moves between designers, the acceptance record should move with it.

NASA’s interface-management guidance discusses responsibilities and interactions across organizational or system boundaries. It does not govern a solar company. As a cross-domain analogy, it reinforces a practical point: the handoff must describe who supplies, accepts, changes, and receives each part of the work.

Set the handback owner before design starts. That person checks whether the returned layout answers the commissioned decision, preserves assumptions, and matches the customer-language record. They also own the next customer conversation. Without that role, a layout can be uploaded and treated as complete while its key limitations remain inside a designer note.

Use due events instead of naked dates where possible. “Before the customer review is scheduled” or “after facilities confirms the included meter” explains what the timing depends on. A date can remain in the record, but the event shows whether the next action is ready.

How should design accept or return the layout request?

Design should compare the request with the agreed layout stage, then issue one visible decision: accept it, conditionally accept limited work, return it with specific gaps, or escalate a question outside the receiver’s authority. The response should name affected outputs, permitted assumptions, prohibited uses, owners, and the event that reopens or advances the work.

Use this sequence:

1. Freeze the submitted version. Record the request ID, submitter, timestamp, attachments, customer-language record, and current evidence index.
2. Read the decision before the data. Confirm what question the layout must answer, who will see it, and what it must not be used to decide.
3. Check physical and energy scope. Match the property areas, buildings, meters, accounts, and scenarios named in the request.
4. Inspect evidence identity. Confirm each load-bearing file belongs to the project, can be identified, and carries its known state and limits.
5. Test the seven answers. Mark each documented, stated, assumed, open-but-owned, conflicting, or stopped.
6. Choose the intake decision. Accept, conditionally accept, return, or escalate according to the team’s rule.
7. Write the work boundary. Name permitted tasks, prohibited downstream uses, assumptions, qualified reviews, and customer-facing limits.
8. Send one response record. Route gaps to owners, preserve the accepted baseline, and state the next review or reopening event.

The decision table should be explicit:

Avoid partial acceptance by private message. If the designer says “I can start the roof model while you find the bill,” that agreement belongs in the request record with the energy outputs it prohibits. Otherwise the model may continue downstream after everyone forgets why it was limited.

NASA’s technical-data management guidance discusses planning how technical data are acquired, identified, accessed, managed, protected, and used. This is NASA guidance, not a solar intake standard. The transferable discipline is to preserve who supplied a record, how it may be used, and who can change it.

Repeated returns deserve a process review, not an argument about one project. Sample the returned questions, identify the earliest point where the answer could have been obtained, and decide whether the sales conversation, form, evidence index, owner, or training needs to change. Do not invent an industry return-rate benchmark. Use the team’s own records as diagnostics and preserve their definitions.

What copy-ready pre-layout handoff record can sales use?

Use one record that captures the seven answers, their evidence states, the requested layout stage, prior customer language, open-item owners, and the receiver’s decision. Keep unknowns visible. The record should travel with the layout so the next reviewer can reconstruct what sales asked, what design accepted, which assumptions survived, and what event requires another review.

Copy-ready pre-layout question record

Store links to governed systems rather than copying personal or commercially sensitive data into an unrestricted worksheet. The team still needs access, privacy, retention, deletion, vendor, and jurisdiction rules appropriate to its records.

NASA’s configuration-management guidance discusses configuration identity, change control, status tracking, and audits. The page does not prescribe solar project controls. Its value here is analogous: a request baseline should remain identifiable after a customer preference, energy record, site fact, or scope changes.

Illustrative example, not a customer case or measured result. A sales representative requests a detached-garage layout after the homeowner asks whether the garage could carry part of an early solar concept. The address record includes the main house and garage, but the utility bill does not identify which structures the meter serves.

Sales records the decision as a visual roof-fit discussion, not a sizing recommendation. The garage is the only included structure. Current imagery is identified, while roof dimensions and condition remain provisional. The homeowner’s preference to keep the street-facing plane clear is attached as a stated preference. No panel count or production figure has been promised.

Design conditionally accepts a geometry and placement concept. The response prohibits customer use as an installation-ready or production-backed design, lists the imagery and provisional roof model, and returns the meter question to sales before any energy scenario is prepared. The handback owner is the same representative who will explain the limitations. This example proves no performance improvement. It shows how an open answer can remain owned without being hidden.

How should a preliminary layout come back to sales?

A preliminary layout should return with the accepted request version, layout revision, source records, assumptions, exclusions, unresolved items, review status, and permitted customer use. Design should explain material departures from the request. Sales should compare the handback with prior customer language before sharing it, then route corrections, qualified review, or a new request through named owners.

The handback is not only an image. It is the answer to the decision statement. Sales should be able to see which structures and areas design included, what geometry and obstruction basis were used, which preferences were honored or challenged, which evidence remained provisional, and what the layout does not establish.

Return these fields with every preliminary layout:

Sales should compare the returned layout with the customer record before opening the next conversation. If panel placement, included area, scenario basis, or another visible point differs from what the customer heard, sales needs a plain explanation of the change and its evidence. Do not make the customer discover the conflict by comparing screenshots.

The returned design may also expose a new question. A roof area may be smaller than assumed, an obstruction may need field confirmation, or a customer preference may remove a section of the concept. Design should state the effect on the layout. Sales owns the follow-up conversation. A qualified reviewer owns any engineering, structural, electrical, safety, code, utility, permitting, financial, tax, contract, or legal decision.

Evaluate the solar design workflow with a sanitized request and one changed input. Ask the demonstrator to trace its effects on the layout, shade, energy or financial scenarios, materials and proposal. Confirm which source identifiers and versions are retained in your configuration, and where your team must separately record intake decisions, owners and review limits.

Those functions can keep project inputs, a layout, modeled outputs, equipment records, and proposal work connected. SurgePV does not verify source records, decide that a request is complete, infer customer intent, approve engineering, determine code or utility requirements, establish consent, or guarantee production, savings, accuracy, approval, conversion, revenue, time, or another outcome.

Frequently Asked Questions

What should sales confirm before requesting a solar layout?

Sales should confirm the customer decision, exact property and meter scope, current and future energy basis, available site evidence, known preferences and constraints, customer-facing commitments, and ownership of every open item. The request should also name the layout stage, intended audience, due event, permitted assumptions, and what design must return for review.

Does every question need a final answer before design starts?

No. A question can be resolved as documented, stated, assumed under policy, or explicitly open with an owner and due event. Design may accept limited work when the uncertainty is visible and the intended use permits it. Return the request when the missing or conflicting information prevents the designer from defining or bounding the requested layout.

Who decides whether a solar layout request is ready?

The receiving design role should accept, conditionally accept, return, or escalate the request against the team’s published rule. Sales owns the commercial purpose, customer record, and supplied evidence. Design owns whether those inputs support the requested layout stage. A designated manager should resolve policy disputes without silently approving a project-specific technical assumption.

Can sales promise a panel count before the layout is reviewed?

Sales should avoid presenting an unreviewed panel count as a commitment. A preliminary concept depends on the stated site boundary, source imagery or survey evidence, module basis, obstructions, access, shading treatment, and other constraints. If a planning range or concept is discussed, record its source, limitations, verification trigger, and the customer language that was used.

Where can SurgePV support the pre-layout handoff?

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 verify source records, decide whether a request is acceptable, manage customer commitments, route qualified reviews, and obtain approvals from responsible engineers, authorities, utilities, lenders, and insurers.