Back to Blog
solar business22 min read

Leave a Solar Site Visit With a Clear Proposal Plan

Turn a solar site visit into one proposal plan with confirmed buyer inputs, evidence gaps, technical handoffs, owners, conditions, and next steps.

Keyur Rakholiya

Written by

Keyur Rakholiya

CEO & Co-Founder · SurgePV

Rainer Neumann

Edited by

Rainer Neumann

Editorial contributor · SurgePV

Published ·Updated

Quick Answer

Leave a solar site visit with a clear proposal plan by confirming the buyer's decision, the option to be developed, the evidence collected, every unresolved technical or commercial input, and the next owner for each gap. Recap what the proposal may show, what still needs qualified review, and when the customer should expect the next update.

The solar site visit is ending. The customer asks when the proposal will arrive and what it will show. The sales rep has photographs, a utility bill, a preferred roof area, a battery question, and a note about future electricity use. Design has not reviewed the site evidence. Pricing has not accepted the new scope. The easiest answer is “we have everything.” It is also the answer most likely to create a second, more awkward conversation.

A clear proposal plan is not a promise that the design is feasible, the price is settled, or the project will be approved. It is a controlled account of the decision the customer wants to make, the option the team will evaluate, the records already available, the questions still open, and the people responsible for resolving them.

This page owns the on-site exit decision for solar sales reps. The reduce solar site visits guide owns evidence acceptance and avoidable return visits. The solar site-survey evidence package owns the deeper field record. The post-site-visit deal-risk checklist owns the later commercial risk review. Here, the immediate job is to leave the customer and the internal team with one honest proposal plan.

This is a desk-research sales workflow, not engineering, electrical, structural, safety, financial, tax, lending, equipment, utility, permitting, contract, legal, installation, or site advice. The company must define who can observe, interpret, approve, price, schedule, and communicate each item. A rep should never access an unsafe area, open equipment without authorization, or convert a customer statement into a verified site fact.

What is a clear proposal plan after a solar site visit?

A clear proposal plan names the customer’s next decision, the option to evaluate, the evidence available, the open inputs that can change the answer, each responsible owner, and the next communication event. It tells the buyer what the team will prepare while keeping design, production, price, equipment, approval, and schedule claims within qualified review boundaries.

Define the plan by the next decision

“Send a solar proposal” sounds specific until two people interpret it differently. The customer may expect a firm recommendation. The rep may expect a preliminary illustration. Design may be waiting for usage data. Finance may need ownership or term preferences. Operations may not know that the customer asked to preserve an area for future equipment.

Start with a decision sentence:

The customer wants to compare the named base option with the named alternative for the stated site and usage case, subject to the recorded design, equipment, production, pricing, utility, and other reviews.

Change the sentence to fit the real visit. If the customer only wants a feasibility conversation, say so. If the next document is a budgetary option rather than a contract-facing offer, name that boundary. If the buyer has not decided what comparison would be useful, the proposal plan is not ready merely because the visit ended.

The U.S. Department of Energy’s homeowner solar guide says there is no universal solar solution and discusses roof age, tree cover, roof size, shape, and slope as factors a homeowner may consider (DOE homeowner solar guide). It does not assess this customer’s property. The practical sales lesson is narrower: site and customer context must reach the people producing the custom answer.

Separate the proposal plan from the proposal conclusion

The plan can be clear while important conclusions remain open. It may say design will evaluate two array areas, production will review the selected scenario, and pricing will confirm the equipment basis. It should not declare the roof suitable, equipment compatible, production accurate, price final, incentive available, interconnection approved, or schedule certain unless the responsible evidence and authority already support that statement.

Use four information states during the exit review:

State Meaning Sales handling
Observed record An authorized person recorded a condition with usable identity and context Link the evidence; do not extend it beyond what was observed
Customer statement The customer supplied a preference, history, plan, or fact Attribute it and identify whether verification is needed
Team decision A responsible owner accepted an option, assumption, price basis, or release Record who decided, what object, and for which use
Open condition Evidence, interpretation, authority, or customer choice is missing Name the owner, affected answer, next event, and customer message

An assumption deserves its own label. It is not an observed record, and it is not automatically a team decision. A proposal may use a bounded assumption for a preliminary comparison when responsible owners permit it, but the customer should be able to see the limitation that matters to the decision.

What should a sales rep confirm before leaving the site?

Before leaving, confirm six things with the customer and the visit record: the decision the proposal should support, the active option or alternatives, customer-supplied inputs, identifiable site evidence, every unresolved question that could change the answer, and the next communication. Do not use the exit conversation to make technical or commercial decisions outside the rep’s authority.

Confirm the customer decision, not just product interest

Ask what the customer will decide after reviewing the next document. Are they choosing whether to continue discovery, comparing system concepts, reviewing ownership approaches, deciding whether storage should be evaluated, or aligning several stakeholders? Avoid turning that question into pressure for a commitment. Its purpose is to shape a useful deliverable.

Record who participated and who did not. A site contact may provide access without owning the budget. A facilities representative may describe operations without controlling contract terms. A homeowner may want another household member involved. The proposal plan should state whose decision it supports and which stakeholder input remains pending.

Confirm the option and comparison boundary

Name the base option in words another team member can understand. Record included structures or areas, customer priorities, excluded areas, requested alternatives, equipment preferences, storage interest, future-load statements, and anything the customer explicitly does not want evaluated. Do not invent technical viability to make the option sound complete.

If two alternatives are active, preserve both. State the variable that changes and the facts held constant. “Option A” and “Option B” are poor handoff labels unless the design and proposal team can tell what each means without asking the rep again.

The Department of Energy describes a photovoltaic system as involving more than modules, including mounting structures, power electronics, and sometimes storage (DOE PV system design basics). This is general background, not project validation. It supports checking whether a customer change can reach more than the visible panel layout.

Confirm customer-supplied inputs and their source

Identify utility bills or interval data provided, usage period, account or meter context when appropriate, occupancy or operating statements, future-load plans, equipment preferences, budget or decision constraints, ownership interests, and required stakeholders. Keep sensitive records inside the company’s approved handling process.

Attribute customer statements. “Customer reports an electric vehicle may be added after the stated date” is different from a measured load. “Customer prefers the west roof area” is not a design instruction. “Customer wants storage included for evaluation” is not an equipment selection. The source label lets qualified reviewers decide what additional evidence or clarification is needed.

Check that site evidence is findable by meaning

Before departure, make sure each material photo, note, measurement, label, and access limitation identifies the project, structure or area, subject, source, and capture context needed by the next role. A folder with many files is not automatically a usable handoff.

NASA technical-data guidance discusses planning how technical data are acquired, identified, accessed, managed, and used (NASA technical data management). NASA does not prescribe sales visits. The useful analogy is that evidence must keep its identity and use boundary when it moves from the site to sales, design, review, and proposal work.

If a field item is missing, record why: not applicable, inaccessible, permission unavailable, unsafe to collect, obscured, unreadable, conflicting, customer unavailable, or qualified review required. The rep should not guess simply to finish the form. Each state needs an owner and a consequence for the proposal plan.

Identify questions that can change the proposal answer

Ask the field or technical owner which open items could change geometry, equipment, system size, modeled output, price, scope, exclusions, schedule, customer wording, or whether a proposal can be released at all. The rep does not need to solve those questions on site. The rep needs to stop them from disappearing.

Use precise language. “Electrical pending” is too broad. “Service information requires review by the electrical owner before the proposal can show the named interconnection concept” states an affected answer and a release condition without pretending to decide it.

Confirm a communication event, not a hopeful deadline

The customer should leave knowing what happens next and when they will hear from the team. Sometimes the responsible team has authorized a proposal date. When dependencies remain, promise a dated update instead: the rep will confirm the proposal scope and timing after named design or commercial owners review the open inputs.

Do not use “soon,” “ASAP,” or “once engineering looks at it.” State the owner, event, and channel. If a missing customer record controls the next step, say what is needed and what the team can do while waiting.

How do you create the proposal plan during the visit?

Create the plan in eight recorded steps: restate the buyer’s decision, name the option, classify each input by source, review site-evidence completeness, expose decision-changing gaps, assign technical and commercial owners, agree on the next customer action, and send a same-record recap. Preserve uncertainty rather than drafting a clean answer that the internal team cannot support.

Use the eight-step exit review

  1. Restate the next decision. Ask the customer to confirm what the next proposal or option comparison should help them decide. Record participants and missing decision-makers.

  2. Name the proposed option. Describe included areas, requested alternatives, customer priorities, stated exclusions, storage or equipment interests, and the purpose of the document to be prepared.

  3. Classify the inputs. Mark each as site observation, customer-supplied record, customer statement, team decision, assumption, or open condition. Preserve source dates and option identity.

  4. Run the evidence departure check. Confirm that required items have an explicit state and that media, notes, measurements, labels, and limitations are identifiable. Follow the company’s safety, privacy, access, and qualified-review rules.

  5. List answer-changing gaps. Connect each unknown or conflict to the proposal elements it can affect. Do not label an impact immaterial unless the responsible owner made that decision.

  6. Assign owners and response forms. Name who must supply evidence, interpret it, decide, review, approve, or communicate. Specify whether the output is a design disposition, pricing confirmation, model review, customer choice, or another bounded response.

  7. Agree on the next customer action. Ask for the missing bill, stakeholder response, access coordination, preference, or confirmation the customer actually owns. Do not shift an internal technical task onto the buyer.

  8. Recap before departure and in writing. Read back the active option, open conditions, customer action, team action, and next update. Attach the written recap to the same project record used by the proposal team.

NASA requirements-management guidance discusses source and owner currency, traceability, and evaluating changes to a requirements baseline (NASA requirements management). The page governs NASA work, not solar sales. Used cautiously by analogy, a customer request should be traceable forward to affected proposal answers and backward to the person, date, and context that supplied it.

Review a Site-to-Proposal Workflow

See how SurgePV can support connected project inputs, design, modeling, equipment outputs, and proposal generation while your team retains evidence and release responsibility.

Explore solar proposals

Bring one representative site-visit handoff to the review.

What belongs in the site-visit-to-proposal handoff?

The handoff should contain the visit identity, buyer decision, active option, evidence index, sourced customer inputs, assumption register, gap and conflict log, affected proposal answers, named decision owners, permitted use, customer action, and next update. Design, pricing, finance, equipment, utility, permitting, and contract owners should receive only questions within their authority.

Copy-ready clear proposal plan record

Copy this table into the CRM or project workspace. Add company-specific privacy, safety, engineering, pricing, utility, permitting, and approval fields through the responsible owners.

Plan field Entry to complete
Project, site, structure, customer, and visit date
Visit purpose and authorized collector
Customer participants and absent decision-makers
Next buyer decision
Base option in plain language
Active alternative and variable changed
Customer priorities and stated exclusions
Customer records received, source, period, and context
Customer statements requiring confirmation
Site-evidence package id and source cutoff
Inaccessible, unsafe, unreadable, conflicting, or missing items
Assumption, reason, affected answers, and permitted use
Open technical question, owner, and required response
Open commercial question, owner, and required response
Affected layout, production, equipment, price, scope, schedule, and proposal fields
Customer action, exact record requested, and due event
Team action, owner, output, and due event
Proposal purpose and uses not supported
Next customer update, owner, date, and channel
Reopen trigger and revised-plan owner

Do not let a blank mean “no issue.” Use confirmed, pending, not applicable with reason, inaccessible, conflict, outside authority, conditionally usable, or hold. The plan should make it possible for design to reject or clarify a sales assumption without reconstructing the visit.

NASA interface-management guidance discusses defining interfaces, responsibilities, characteristics, and controls when work is divided among parties (NASA interface management). It is a cross-domain analogy. The useful application is to design the sales-to-design handoff as an interface with named inputs, outputs, owners, and exception routes.

The solar sales-to-design handoff guide covers the wider transition. This record focuses only on what the rep should establish before leaving and in the immediate recap. Later discovery may legitimately change the plan. The record should preserve what was known at departure so the change is explainable.

Give each owner a decision-shaped question

Avoid forwarding the entire visit folder with “please review.” Ask design whether the named option can be evaluated from the attached evidence and which conditions must remain visible. Ask the production owner whether the proposed scenario and inputs are ready for modeling. Ask pricing which equipment and scope basis it can support. Ask the customer only for the decision or record they own.

The question should include project and option identity, evidence links, source dates, known conflicts, requested output, permitted use, and response deadline or event. A yes or no response is weak if the owner cannot state what object and purpose they reviewed.

How should missing or conflicting information be handled?

Handle missing or conflicting information by preserving both source states, naming the affected proposal answer, assigning the underlying decision to its qualified owner, and restricting only the uses that depend on it. Ask for a bounded clarification, another observation, or a formal disposition. Never copy the preferred answer into the plan merely to keep the proposal moving.

Diagnose the gap before choosing the next action

Gap class What the record shows Immediate plan state Closing evidence
Missing customer record A bill, interval file, decision, or preference was requested but not supplied Identify what can proceed and which answer waits Identified record or customer decision
Inaccessible site area The visit could not observe a relevant location within authorization and safety limits Restrict affected design or proposal use Authorized observation or qualified disposition
Conflicting evidence Two dated records describe different physical or project states Preserve both; stop silent selection Source reconciliation by responsible owner
Customer statement needs verification A statement may affect technical or commercial work Attribute it and route confirmation Accepted evidence or bounded assumption
Internal authority missing The rep, designer, or pricing owner cannot decide the question Hold the affected answer Decision from the authorized owner
Active alternatives Two options intentionally remain under consideration Keep scenario identities separate Customer comparison and next decision

Not every gap requires another site visit or a full proposal hold. The responsible owner may allow a clearly labelled preliminary comparison. Another gap may block only a production claim, equipment line, price, or schedule statement. Some conditions require direct observation or external review. The release consequence should follow the affected decision, not the convenience of the workflow.

Avoid treating customer pressure as evidence. A requested deadline can inform priority, but it does not settle roof condition, electrical feasibility, equipment compatibility, modeled output, price, incentive treatment, permit path, utility response, or contract meaning.

The current Federal Trade Commission advertising guide says ads must be truthful and non-deceptive and that objective claims need evidence before dissemination (FTC advertising guidance). That is United States advertising background, not legal advice for a particular proposal. It supports one cautious rule: do not let a friendly on-site recap turn an unsupported objective statement into the next document’s premise.

Illustrative example, not a customer case

A homeowner tells the rep that electricity use will increase after adding two future loads. The visit captures the existing site and current utility bill. The customer also asks for a battery option, but the available record does not establish equipment location, configuration, product choice, or an accepted financial basis.

The rep does not promise a system size or savings result. The clear plan records the current usage source, dates the customer’s future-load statement, names the proposed base option, and opens a separate alternative for evaluation. Design owns the layout question. The production owner decides how the documented inputs may be modeled. The battery and electrical owners identify evidence and configuration questions. Pricing reviews only an accepted scope.

The customer action is to provide the requested information about the future loads and confirm which stakeholders should review the comparison. The team’s action is to return on a named date with either a supported proposal schedule or a precise list of remaining blockers. The recap explains that site feasibility, production, equipment, price, utility, permitting, and other outcomes remain under their respective reviews.

This example claims no design size, production, savings, price, compatibility, approval, schedule, or customer result. It shows that a proposal plan can be concrete without making its conclusions premature.

How should the customer recap describe the next step?

The customer recap should restate the requested option, records received, customer statements, unresolved conditions, customer action, team action, and next update in decision language. Use plain wording and attribute uncertain inputs. Do not call the proposal final, accurate, approved, guaranteed, or ready on site unless the responsible evidence and authority support that exact meaning.

Use a five-part departure recap

  1. What we heard. State the customer’s decision, priorities, requested option, alternatives, and stakeholders in neutral language.

  2. What we received. List the named bills, site records, photographs, notes, and statements without implying broader verification.

  3. What remains under review. Name the technical and commercial questions, their owners, and which proposal answers may change.

  4. What happens next. Separate customer actions from team actions and give the next update date and channel.

  5. What this plan does not decide. Qualify feasibility, production, equipment, electrical, price, incentive, utility, permit, schedule, contract, and other items as the project requires.

Digital.gov’s plain-language guide series emphasizes writing for a specific audience and organizing content so that audience can understand it (Digital.gov plain-language guidance). It does not promise comprehension or agreement. The proposal-plan recap should be short enough to use but specific enough that sales, design, and the customer recognize the same option and open questions.

Keep SurgePV inside its role

Within the SurgePV proposal workspace, the recorded product scope covers roof modeling in 3D, solar array layout, shading analysis, energy-yield and financial models, electrical-workflow support, material outputs, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, and review (SurgePV product source).

A connected workspace can help the team retain the chosen option and carry reviewed inputs into design and proposal outputs. It does not decide whether a site statement is true, whether evidence is adequate, which design is feasible, which equipment is compatible, what a customer should buy, or what the company may promise. External engineers, authorities, utilities, lenders, insurers, and other responsible reviewers retain their own decisions.

If new evidence changes the plan, revise the plan rather than defending the original recap. Record the trigger, old and new option state, affected outputs, decision owners, customer impact, and next update. The purpose of the departure record is not to freeze the project forever. It is to give every later change a traceable starting point.

Frequently Asked Questions

What should a solar sales rep confirm before leaving a site visit?

Confirm the buyer’s immediate decision, the option or comparison they expect, customer-supplied facts, site evidence collected, unanswered questions, decision owners, and the next communication date. The rep should also state which technical, utility, financial, equipment, permitting, or contract questions require qualified review instead of offering a confident answer from incomplete evidence.

Should the sales rep promise a proposal date during the site visit?

Only promise a date that the responsible team has authorized and that accounts for known dependencies. If design, usage data, equipment, utility information, or another review is pending, give a dated update commitment rather than inventing a completion date. Record who owns each dependency and what would require the plan or timing to change.

What if the customer changes scope during the solar site visit?

Record the requested change as a customer statement, not as an approved design or price. Clarify whether the original option remains active, identify affected evidence and decisions, and route the request to design, pricing, equipment, finance, or other qualified owners. Tell the customer when the team will confirm feasibility, implications, and proposal treatment.

Can photos from a site visit prove a solar proposal is accurate?

No. Photos can support a proposal when their project, location, date, subject, orientation, and purpose are identifiable, but they do not settle every physical, technical, electrical, structural, utility, or code question. Reviewers must decide whether the evidence is adequate for the stated use and record any condition requiring measurement, access, or qualified judgment.

Can solar proposal software decide what to promise after a site visit?

No. Software can support project records, roof modeling, array layout, shading analysis, energy-yield and financial modeling, electrical workflows, material outputs, and proposal generation. People must verify external evidence, select the proposed option, resolve exceptions, approve customer language, and authorize timing and release. Responsible external reviewers retain their own decision authority.

A strong departure record does not claim that every proposal answer is settled. It proves that the customer request, project option, evidence, uncertainty, owner, and next communication still describe one plan. That is the point where sales can leave the site without leaving design to guess what the visit meant.

Review Your Site-to-Proposal Plan

See how SurgePV connects project inputs, design, modeling, and proposal generation while your team retains evidence and release responsibility.

Book a guided demo

No credit card is required for the demo.

Sources

Primary research and reference material used for this desk-research article.

Where this fits

This article is part of SurgePV's Solar Business & Operations hub, which works through the topic from first principles to the decisions a project team actually has to make.

About the Contributors

Author
Keyur Rakholiya
Keyur Rakholiya

CEO & Co-Founder · SurgePV

Keyur Rakholiya is identified by SurgePV as its CEO and a company co-founder. His SurgePV author page lists only role information that can be tied to the public profile below; credentials, project totals, testing claims, media appearances, and speaking engagements are not asserted without retained evidence.

Editor
Rainer Neumann
Rainer Neumann

Editorial contributor · SurgePV

Rainer Neumann is credited as an editorial contributor on SurgePV content. This profile does not assert engineering credentials, project totals, software-testing experience, education, speaking engagements, or media citations because independent verification evidence is not retained in the publication record.

Get Solar Design Tips in Your Inbox

Join 2,000+ solar professionals. One email per week - no spam.

No spam · Unsubscribe anytime

Book Free Demo

Choose which optional technologies SurgePV may use. Essential storage remains active for security and requested features.