6 Solar Sales Tasks to Complete Before Design Starts

Sales has the address, one bill photo, a rooftop screenshot, and a note that says “wants maximum savings.” Design receives the request and immediately has to ask which building, whose bill, what period it covers, whether a future load is included, and what “maximum” means for the customer.

The problem is not that sales failed to design the system. Sales should not design by inference. The problem is that the evidence arrived without identity, state, ownership, or a clear decision. The designer must reconstruct the request before doing design work.

Sales-side preparation is a bounded job. It makes the customer decision, project identity, evidence, objectives, unknowns, and exception route visible. It does not determine usable roof area, equipment, structural or electrical suitability, energy yield, savings, feasibility, price, code treatment, permitting, utility action, or approval.

The door-to-door sales guide owns prospecting and doorstep conversations. The sales-to-design handoff guide owns the receiving exchange and downstream controls. The design request process owns the complete organizational workflow. This page focuses only on the six tasks sales can finish before design accepts the request.

What may sales prepare without becoming the designer?

Sales may prepare customer and project identity, permission context, source-labelled energy and site evidence, stated objectives, requested options, known constraints, unknowns, and an exception-aware request packet. Sales should not infer roof suitability, layout, equipment, electrical or structural decisions, production, savings, price, eligibility, schedule, or approval merely because a form accepts those values.

Use an authority map:

This separation protects both teams. Design receives more useful context without inheriting an invisible claim that sales verified technical conditions. Sales can move the request forward without pretending to answer questions outside its role.

Give every collected item an evidence class:

• Customer-supplied: provided by the customer or prospect, with source, time, and relationship to the project recorded.
• Source-observed: copied or retrieved from a named source with context and date.
• Sales-observed: directly seen or heard by the representative, stated narrowly without technical interpretation.
• Assumed: chosen for a permitted preliminary scenario, with rationale, owner, and stop consequence.
• Pending: required evidence or decision has not been accepted.
• Rejected or superseded: retained for history but prohibited from current use.

A complete input box does not change its class. A customer estimate remains customer-supplied. A coordinate remains a source response. A photo remains a view of visible conditions. Design acceptance is a separate state.

Which rules should exist before sales begins collecting evidence?

Define the design-request classes, required and conditional fields, permitted sources, permission and retention process, evidence labels, sales authority, technical stop rules, customer correction route, exception owners, acceptance criteria, and downstream release meanings before collection starts. Otherwise representatives will optimize for form completion and designers will receive polished packets with unreviewed assumptions hidden inside them.

The company needs its own market-specific permission, privacy, retention, and communication rules. This article does not provide consent language or a lawful-basis conclusion. Record the purpose for collection, permitted use, customer correction, withdrawal state where applicable, and owner under qualified review.

Do not label all four “design ready.” The receiving designer needs to know what kind of work is requested and which conclusions remain prohibited.

What six tasks should sales complete before design starts?

Complete six tasks: define the customer decision and permission, resolve project and property identity, collect and classify energy evidence, gather bounded site evidence, record objectives without prescribing a solution, and assemble an exception-aware request packet. Each task needs a source, state, owner, missing-information rule, correction path, and explicit decisions reserved for design or other qualified reviewers.

1. Define the decision, stage, and permission context

Write what the customer wants to decide next. “Evaluate whether to continue a preliminary rooftop assessment” is bounded. “Design the best system” is not a decision record. Name the proposal or design stage, intended receiver, permitted output, and what it must not imply.

Record why the company is collecting the address, bill, photos, and customer information; which uses are permitted; how corrections are accepted; and what happens after a withdrawal or scope change under company policy and applicable review. Do not expand the purpose because another team finds the data useful.

Required record: request id, customer or account, decision, stage, permission context, permitted use, prohibited output, sales owner, and next receiver.

2. Resolve project and property identity

Preserve the raw address exactly as submitted. Store any normalized address separately. USPS Publication 28 documents postal addressing standards and delivery-address formats and components. Postal standardization does not verify the correct solar building, parcel, meter, owner, or customer.

The Census Bureau describes geocoding as taking an address and returning an actual or calculated latitude and longitude, with granularity depending on supplied parts and bounded service geography. A coordinate can be calculated. It does not prove project identity or suitability.

Record raw and normalized address, coordinate and source, match type, property candidates, selected building or site, confirmation actor, time, conflicting evidence, and known changes. If two plausible buildings remain, stop roof-specific work and ask for confirmation.

3. Collect and classify energy evidence

Collect the energy record required for the request class, not whatever file happens to be easy to send. Preserve customer or account identity, meter or service relationship, period, units, page completeness, source, observed date, anomalies, transformations, future-load statements, and any consent or access requirements under company rules.

Do not calculate a customer savings claim from a single unclear photo. Do not treat an amount due as consumption. Do not silently join files from different meters or periods. Sales can label the gap and request the missing material; responsible energy, utility, and financial reviewers decide how the evidence may be used.

FTC solar consumer guidance identifies project-specific energy, site, roof, sunlight, shade, bid, contract, finance, and pressure-related questions consumers should examine. It does not validate a private sales packet.

4. Gather bounded site evidence without technical interpretation

Ask for the views and records the receiving process requires: property overview, roof or site surfaces, visible obstructions, electrical areas where appropriate and safe, access conditions, known roof work, available drawings, and customer-reported changes. Each image needs source, time, orientation or description, and a note about what remains outside view.

Sales should not direct a customer or representative to create unsafe evidence. Company safety and access rules govern collection. A photo can show a visible object; it does not prove structural capacity, dimensions, code compliance, electrical suitability, or hidden condition.

Use four site states: adequate for routing, needs customer clarification, needs qualified remote review, or needs field evidence. The state describes the next action, not feasibility.

5. Record customer objectives, constraints, and option requests

Capture the customer’s words before translating them into a product. Bill reduction, backup, future vehicle charging, planned expansion, aesthetics, budget structure, timing concern, property plans, and decision stakeholders are discovery inputs. They do not automatically justify storage, a system size, financing, or a technical configuration.

For each item, record source, importance, time horizon, current evidence, conflict, owner, and next question. Separate “customer wants to discuss storage” from “storage recommended.” Separate “expects a future load” from an accepted load model.

DOE explains that suitability, production, and savings depend on site, system, energy use, ownership or lease, utility rates, and excess-generation compensation and recommends a custom estimate. An objective does not supply those dependencies.

6. Assemble the exception-aware design request packet

Package one request identity, decision, project, sources, evidence states, customer objectives, assumptions, unknowns, conflicts, corrections, requested design stage, and next owner. Do not flatten the packet into a completeness percentage. A nearly complete packet can still lack the one field that blocks the requested work.

Use explicit readiness states: ready for receiving review, conditional with named limitation, evidence requested, identity unresolved, withdrawn, or superseded. Sales proposes the state; design or the designated receiving owner accepts, conditions, returns, or rejects it.

How should evidence classes and stop rules work?

Give each field a source, evidence class, observed date, project relationship, owner, acceptance state, affected design question, and change trigger. Stop when identity conflicts, required evidence is missing, collection exceeds permission, site evidence is unsafe or ambiguous, customer intent becomes an unsupported recommendation, or sales has entered a technical, financial, legal, or approval decision outside its authority.

Unknown is a usable state. “Unknown roof condition, blocks final scope, customer asked for recent information” is more helpful than a completed field containing “appears good.”

Apply stops at the affected scope. An identity conflict blocks property-specific work. An incomplete energy record may block consumption-dependent analysis while still allowing a bounded identity or evidence request. A missing technical decision should not erase valid customer objectives, but it should prevent those objectives from being rendered as a system recommendation. This scoped treatment keeps legitimate preparation visible without letting partial progress become permission for a stronger output.

Review repeated stop reasons with both sales and design. If representatives repeatedly send the wrong document type, improve the collection prompt and example. If design repeatedly returns a field whose acceptance rule is unclear, define the evidence and authority more precisely. Do not respond to every return by adding another required box; improve the decision interface that failed.

How should design accept or return the packet?

The receiving owner should verify request identity, decision, project and property, evidence sources and states, customer objectives, assumptions, unknowns, exceptions, corrections, and permitted design stage. Accept, condition, return, reject, or request evidence with a reason and owner. Preserve the submitted packet and create a successor after changes rather than letting sales silently overwrite the record under review.

AHRQ describes flowcharts as visual process-step representations useful for examining handoffs, responsible people, problem sources, and improvement areas. Apply that as a workflow analogy only.

Use this acceptance sequence:

1. Freeze the submitted packet and assign a version.
2. Confirm the request class and decision.
3. Check customer, property, meter, and project identity.
4. Review source and evidence-state completeness for the requested stage.
5. Confirm customer objectives remain discovery inputs rather than hidden design instructions.
6. Identify every block, exception, and decision owner.
7. Record accept, conditional, evidence request, return, reject, or withdrawal.
8. Create a successor packet after material correction.
9. Link the accepted packet to the new design project state.

Copy-ready sales-side design preparation packet

Illustrative workflow: one address points to two buildings

This illustrative workflow is not a customer case, design, property verification, feasibility result, turnaround result, accuracy result, production or savings estimate, approval, or product claim.

A sales rep receives an address, a bill image, and a rooftop photo. A location source returns a coordinate near two buildings. The bill shows an account reference but does not identify which building consumes the energy. The rooftop photo could plausibly show either roof.

Sales records both property candidates and labels identity unresolved. The rep asks the prospect to confirm the building and the relationship between the bill and the project. No roof-specific design request is marked ready. After confirmation, the original record remains, a successor packet identifies the selected building and bill context, and design decides whether the evidence supports the requested stage.

The example claims no time saved. It shows why a plausible match should remain a question until the responsible evidence is accepted.

Where does SurgePV support this workflow, and where does it stop?

SurgePV can support verified roof modeling, array layout, shading, energy-yield and financial modeling, electrical workflow, BOM output, and proposal generation after appropriate project intake. It does not establish consent, verify property or customer identity, accept bills and site evidence, infer customer intent, decide technical or financial questions, approve a handoff, guarantee turnaround, or replace qualified review and external authority.

The repository-verified scope includes roof modeling, array layout, shading, energy-yield and financial modeling, electrical workflow, BOM output, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, and responsible review.

Useful intake measures include returned packets by reason, identity conflicts, missing evidence by field, customer corrections, assumptions created by sales, conditional acceptances, time in named states, and accepted packets later reopened for preventable intake gaps. None proves accuracy, conversion, capacity, or time saving. Use the measures to improve specific collection rules without treating every return as design resistance.

Frequently Asked Questions

What information should solar sales collect before design?

Collect the decision and permission context, raw and confirmed property identity, customer or account identity, relevant energy records, bounded site evidence, known changes, customer objectives, option requests, constraints, unknowns, source dates, and contact details for missing information. The company should define which fields block each design-request class and which may remain explicitly conditional.

Should a solar sales rep estimate system size before design?

A rep should not present an unsupported system size as a design conclusion. The company may permit a clearly preliminary range or educational scenario under written rules, accepted inputs, visible assumptions, and appropriate review. Sales should preserve the customer’s goal and evidence, then let responsible design and modeling owners determine what the project record can support.

Can customer photos replace a solar site survey?

Photos can document visible conditions and help route a request, but they do not automatically verify dimensions, hidden conditions, structural capacity, electrical suitability, code treatment, safety, permitting, utility requirements, or construction readiness. Record who supplied each image, when, what it shows, what remains unseen, and whether qualified reviewers require remote or field follow-up.

What should sales do when project information is missing?

Record the missing field, source attempted, affected design question, owner, customer request, allowed interim state, and release consequence. The request may pause, enter an evidence-request path, or proceed only to a clearly bounded preliminary stage under company rules. Do not invent a favorable value or hide the gap in free-text notes that design may overlook.

Can SurgePV automate the sales-to-design handoff?

The verified repository scope includes connected modeling and proposal capabilities, but it does not establish automatic consent handling, property verification, sales-intake acceptance, missing-evidence decisions, handoff approval, or a turnaround result. SurgePV outputs depend on sources, assumptions, equipment models, configuration, and responsible review. Each company must define owners, exceptions, and acceptance rules around the product.

Give design a decision, not a pile of files

Sales preparation succeeds when design can tell which customer decision is requested, which property and energy evidence belongs to it, what the customer said, what remains unknown, who owns each exception, and what design is not being asked to assume.

Do not evaluate the packet by length or attachment count. Evaluate whether every material item has identity, state, source, owner, and consequence. A short packet with those controls is more usable than a complete-looking form that mixes facts, guesses, and recommendations.

The boundary is productive: sales prepares the question and evidence; design and other qualified owners decide what that evidence can support.