6 Ways a Solar Proposal Can Drift After a Site Visit

Illustrative scenario, not a customer case: The customer remembers the property they walked with the sales rep. They remember pointing at the clean roof plane, asking where the inverter might go, and hearing what would happen next. Days later, the proposal arrives with a polished layout and precise-looking figures. It can still feel like a different project.

That mismatch is not always an error. Design review may reveal an obstruction that was hard to see from the ground. Equipment availability may change. A production model may use a better source than the preliminary conversation. The trust problem begins when a legitimate change arrives without its reason, while the proposal silently presents the new state as though it were the one everyone discussed on site.

Call this site-to-proposal drift: an unexplained difference between the property, preferences, constraints, assumptions, or next steps discussed during a visit and the later customer document. It is different from proposal version control. The solar proposal version-control guide owns document identity, revision labels, change summaries, and the status of older copies. This guide owns the reconciliation that should happen before the first post-visit proposal, and again whenever site-derived information changes.

The goal is not to force field notes onto every proposal page. It is to make sure the proposal neither contradicts what the customer saw nor quietly discards a material condition. A sales rep should be able to explain what carried forward, what changed, why it changed, which item remains open, and what the customer is being asked to decide now.

Use this operating guide with the approvals, disclosures and qualified review appropriate to your location, project, customer and document. The reconciliation record explains a change; it does not approve the technical design or contract.

Why does a solar proposal drift after the site visit?

A proposal drifts because the site conversation, field evidence, design model, equipment decision, commercial scenario, and customer document are produced at different times by different people. Each handoff can simplify an observation, replace an input, or close an open question. Without a reconciliation step, the polished document hides that translation path. The missing translation is where buyer expectations can diverge.

The site visit produces several kinds of information at once. Some items are observed facts, such as an identifiable obstruction in a dated photo. Some are customer statements, such as a preferred equipment location. Some are early ideas, such as a possible module arrangement discussed while looking at the roof. Others are questions for a designer, electrician, engineer, roofer, utility, authority, lender, insurer, or another responsible party.

Those categories should not travel downstream as though they have equal authority. “Customer prefers the east wall” is a valid preference record. It is not proof that the location is suitable. “Rep showed panels on the south plane” records what the customer saw. It is not an approved layout. A useful workflow preserves both the original statement and its decision status.

The U.S. Department of Energy’s homeowner solar guide notes that roof age, tree cover, roof size, shape, and slope can affect rooftop-solar suitability, and it tells readers to work with an installer for a custom production estimate. DOE’s separate PV system design overview explains that a complete PV system involves more than modules. Mounting and power electronics are part of the system context, with storage in some systems. These are general educational sources, not findings about a particular property.

Before the proposal is built, classify every material site item:

The solar project intake process helps a team define a usable project request before work starts. Site-to-proposal reconciliation is a later control. It asks whether the document being sent still represents that request after field evidence and downstream review have changed it.

What are the six ways a proposal can differ from what the customer saw?

Six drift modes deserve a deliberate check: observations become design assumptions, the array layout changes, equipment changes, production or financial inputs change, scope conditions disappear, and tentative timing hardens into a promise. Each can reflect responsible project development. The failure is sending the difference without a traceable reason and buyer-facing explanation.

1. Field observations become cleaner design assumptions

Field notes are usually messy because physical sites are messy. A photo may show part of an obstruction but not its full height. A rep may write “roof looks newer” without a document or qualified assessment. An access area may be locked. When the design request is created, those limitations can disappear. The model then looks more complete than the evidence behind it.

Keep observed, measured, supplied, modeled, and unknown conditions distinct. Do not convert “not seen” into “not present.” Do not convert a customer’s plan to trim a tree into a post-trimming condition without recording that scenario choice. If a dimension came from imagery rather than a field measurement, keep the source attached to the model or project record.

Sandia National Laboratories’ PVPMC modeling guide describes a performance-modeling process that moves through weather, irradiance, module, and system design inputs before calculated output. The narrow lesson for a sales rep is that an output inherits its inputs. The source does not validate any proposal, input set, or project result.

Ask: Which site evidence supports this proposal condition, and what limitation remains? If the answer is “the designer probably handled it,” the handoff is not inspectable.

2. The layout changes without a customer-facing explanation

The customer may have seen a preliminary sketch, tablet view, annotated aerial image, or panels gestured onto a roof plane. The developed layout can differ for sound reasons: a clearer obstruction record, spacing, equipment configuration, shade context, roof use, or a responsible review. Still, the customer’s reference point is the earlier visual.

Compare the two states explicitly. Record which roof planes changed, whether the module count or visible arrangement changed, what evidence or review triggered the difference, and which related outputs were refreshed. Then decide what the customer needs to hear. “The design team updated it” is weaker than “The proposal uses the west plane rather than the area we discussed because the review record identified an unresolved obstruction on that area; here is what remains subject to review.”

The final layout still needs the applicable design, engineering, code, utility, authority, and constructability review. Reconciliation explains the change; it does not authorize the design.

3. The equipment shown or discussed is replaced

On site, a rep might show a module type, discuss an inverter approach, point to a possible equipment location, or talk through storage. The proposal may later use a different model, configuration, capacity, location, or option. Availability, compatibility, procurement policy, design decisions, and commercial choices can all affect that result.

Separate a product example from a proposed project component. The site record should say whether equipment was merely illustrative, preferred by the customer, assumed for modeling, or offered subject to confirmation. The proposal review should compare equipment names and configuration across the site notes, design output, bill of materials where available, financial scenario, and customer-facing text.

When the proposal changes the option, explain the buyer-relevant difference without inventing equivalence. Do not call equipment “the same” or “better” unless the team has an appropriate basis for that claim. Route technical compatibility and approval questions to the responsible reviewers.

4. Production or financial scenarios use different inputs

A site conversation often uses preliminary language: an approximate consumption pattern, a recent bill the customer summarizes verbally, a rate assumption, a tentative system size, or a rough discussion of financing. The proposal can later display precise-looking annual production, offset, payment, savings, or payback figures based on inputs the customer never saw.

Precision does not remove uncertainty. Compare the proposal scenario to the conversation record and source files. Name the consumption period, modeled configuration, weather or irradiance source where relevant, loss assumptions, tariff or rate inputs, escalation or degradation assumptions if used, incentives, financing terms, and scenario date. Which fields matter depends on the proposal, but each material figure should lead back to its actual input set.

If the new scenario is better supported than the on-site estimate, use it. Then say what changed. Do not preserve a weak input simply to stay consistent, and do not hide a stronger replacement because the customer might ask a question. The solar design review checklist provides the technical review boundary; reconciliation focuses on the customer-facing difference after that work.

5. Scope, exclusions, and site conditions disappear

The customer may have discussed reroofing, service work, tree work, an inaccessible area, trenching, a detached structure, interior access, an equipment-location preference, or restoration expectations. The proposal might display the array and price while leaving the condition outside the visible scope. The buyer may reasonably read silence as inclusion, resolution, or irrelevance.

Not every field note belongs in the proposal. The test is whether the item could materially change the customer’s understanding of what is included, excluded, assumed, pending, or supplied by someone else. If yes, represent it in the appropriate proposal language or an attached explanation. If a qualified reviewer has not decided the effect, state the dependency rather than filling the gap with a sales conclusion.

The questions teams should resolve before leaving a site covers departure states and owners. This review checks whether those recorded exceptions survived into the proposal instead of vanishing during design and pricing.

6. Timing, approval, or next-step language hardens into a promise

At the property, “we should have an update after design review” can become “installation in six weeks” in a proposal or follow-up. “We will submit it” can sound like “it will be approved.” An illustrative equipment location can sound settled. Tentative language often hardens because the proposal template expects a clean next step.

Record the difference between an internal target, a customer communication event, an external dependency, and a guaranteed commitment. Name who controls the next decision. A sales rep may be able to promise a status update on a particular event without promising design acceptance, permit approval, utility action, financing approval, equipment availability, installation timing, or system performance.

The U.S. Federal Trade Commission’s advertising guidance for small businesses says advertising claims should be truthful, non-deceptive, and supported, and explains that context and omitted information can affect what a message conveys. The page is U.S. general guidance, not a legal conclusion about a specific solar proposal. Have qualified reviewers assess the actual document and jurisdiction.

Use this release table to turn the six modes into actions:

How should a sales rep reconcile the site visit with the proposal?

Reconcile the proposal in eight steps: freeze the site record, identify what the customer saw, map each material item to the proposal, compare sources and states, route exceptions, refresh affected outputs, write the customer explanation, and run a final release read. Sales owns clarity; responsible specialists retain their decision authority. The release owner records the result and any remaining dependency.

1. Freeze the visit record. Give the evidence package a project ID, visit date, property reference, participants, and source index. Preserve the preliminary visual or notes the customer saw. Do not silently rewrite a site statement after design work begins. Add a dated clarification instead.

2. Write the customer’s reference points. List the roof planes, equipment examples, locations, production or price scenarios, scope conditions, and next steps the rep actually showed or described. Include the strength of the language: example, preference, preliminary option, pending review, or commitment. Memory is not enough for this step.

3. Map material items to proposal locations. For each reference point, identify the design object, equipment field, scenario input, scope paragraph, exclusion, schedule statement, or delivery message that represents it. A site item can affect more than one output. A layout change may require refreshed production, pricing, visuals, and scope language.

4. Compare source, value, and status. Mark an item matched when the proposal faithfully carries the current supported state. Mark it changed when a better source or authorized decision replaced the site state. Mark it open when responsible review or evidence is missing. Mark it excluded only when it does not affect the current customer decision and the reason is recorded.

5. Route every exception to a real owner. Write the decision needed, evidence available, missing input, responsible role, and release effect. “Check electrical” is not a routable exception. “Electrical reviewer to determine what additional evidence is required before this service condition informs the proposed configuration” preserves the authority boundary.

6. Refresh connected outputs after a material change. Confirm that the current layout, equipment record, modeled production, financial scenario, price, scope, exclusions, visuals, and proposal text refer to the same project state. Do not manually edit one customer-facing figure to make it resemble the earlier conversation.

7. Write the buyer-facing explanation. Lead with what the customer will notice, then state why it changed, what else changed with it, and what remains open. Avoid “updated for accuracy,” which hides the actual difference and can cast doubt on every prior statement.

8. Run the release read from the customer’s viewpoint. The sales release owner compares the visit recap and proposal side by side. A separate design or technical reviewer confirms only the decisions within that role. The proposal is ready for customer discussion when material differences are matched, explained, or visibly held as dependencies.

NASA’s requirements-management guidance discusses tracing requirements and managing changes within NASA programs. Its configuration-management guidance discusses identifying configurations, controlling changes, tracking status, and keeping product information aligned with an approved configuration. These are cross-domain analogies, not solar standards. The transferable discipline is to preserve the baseline, change reason, current state, and approval owner rather than relying on recollection.

This process should remain proportional. A simple residential proposal does not need an aerospace configuration system. It does need enough evidence that a rep can answer the customer’s natural question: “Why is this different from what we discussed at my property?”

What should a site-to-proposal reconciliation record contain?

A useful reconciliation record contains the site item, what the customer saw or heard, its source and status, the current proposal representation, any difference, the reason, affected outputs, decision owner, release condition, and buyer-facing explanation. Keep it beside the project record so the proposal can be reviewed without reconstructing the visit from memory.

Copy this record into the team’s CRM, design request, controlled worksheet, or project platform. The labels are authored operating fields, not an industry standard.

SITE-TO-PROPOSAL RECONCILIATION RECORD

Project ID:
Site visit date:
Proposal ID / scenario:
Sales release owner:
Design or technical reviewer(s):
Customer decision this proposal supports:

For each material site item:
- Item ID and category:
- What the customer saw or heard:
- Exact source, date, and evidence reference:
- Site-state label: observed / customer-stated / discussed option / inferred / open
- Current proposal page, field, or object:
- Reconciliation state: matched / changed / open exception / excluded with reason
- Difference and reason:
- Connected outputs checked:
- Decision owner and authority boundary:
- Release condition or blocked work:
- Customer-facing explanation:
- Resolution date and approver:

Final release checks:
- Every material site item has a reconciliation state.
- Every changed item has a reason and affected-output review.
- Every open exception has an owner and release effect.
- Layout, equipment, modeled results, price, scope, visuals, and language use one current state.
- The customer explanation names differences without promising outcomes controlled by external parties or unresolved reviews.

Do not use “excluded with reason” as a bin for inconvenient information. The release owner should be able to show why the item does not affect this proposal’s customer decision. If the effect is uncertain, it belongs in the open-exception route.

Illustrative example, not a customer case

At a fictional site visit, a rep shows a preliminary array on the south garage plane and records the customer’s preference to keep the main roof visually clear. A later photo review leaves the garage obstruction dimensions unresolved, so the designer prepares a scenario using part of the main roof.

The weak handoff sends the new image with no explanation. The reconciliation record instead says:

Item ID: LAYOUT-02
Customer reference point: Preliminary garage-plane visual shown during visit; main-roof visibility preference recorded.
Current proposal state: Mixed garage and main-roof scenario.
Reconciliation state: Changed, with one open exception.
Reason: Available evidence does not resolve the garage obstruction dimensions for the requested design stage.
Affected outputs checked: Layout, modeled production, equipment quantity, price, scope note, cover visual.
Owner: Design owner for scenario; field lead for missing evidence; sales owner for customer explanation.
Release condition: Present only as a preliminary comparison pending the recorded evidence decision.
Customer explanation: The proposal includes a main-roof portion that differs from the garage-focused view discussed on site. The team has not confirmed the garage obstruction dimensions for the requested stage, so this is a comparison scenario rather than a final location promise.

The example does not say which layout is technically suitable or likely to be approved. It demonstrates how to preserve the visible preference, evidence gap, current scenario, owners, and customer language without inventing a conclusion.

Use three exception routes:

The clear proposal plan after a site visit can help the team decide whether to design, clarify, revisit, or stop. The reconciliation record begins after that route is chosen and checks the proposal against what the buyer already experienced.

Where can software support reconciliation, and where must people decide?

Solar proposal software can connect project inputs to 3D roof models, layouts, shading, yield, financial scenarios, electrical workflow, bills of materials, and proposals. People must still validate sources, interpret site conditions, authorize changes, apply jurisdictional requirements, explain customer-facing differences, and obtain responsible approvals. Accountable people, not the platform, decide release.

SurgePV supports 3D roof modeling, solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. These connected objects can make a reconciliation review more inspectable: a reviewer can compare the current configuration, scenario, and proposal rather than reconciling unrelated files by filename alone.

The benefit depends on workflow discipline. Results depend on source data, assumptions, equipment models, configuration, and review. A connected proposal can still be consistently wrong if an unsupported site assumption enters the project and nobody challenges it. Software does not know that the customer interpreted a rooftop visual as final unless the team records that conversation and tests the later document against it.

Confirm which references, states, owners and linked outputs the configured software can retain, and record any gaps in the approved project system. Keep human responsibility for four decisions:

• whether site evidence is usable for the requested purpose;
• what an observed condition means for design, scope, cost, schedule, or compliance;
• which material difference the customer needs to understand; and
• whether the current proposal may be released for a defined decision.

SurgePV does not replace site verification, safe work practices, permissions, engineering judgment, code or contract review, or approval by the responsible engineer, authority, lender, insurer, or utility. A guided product review can show how the connected workflow operates; the project team must define and enforce its own reconciliation gate.

Frequently Asked Questions

What is site-to-proposal drift in solar sales?

Site-to-proposal drift is a difference between the property, preferences, conditions, or expectations discussed during a visit and the project presented in the later proposal. A difference may be justified. The risk appears when the team cannot trace it to evidence, review its effects, or explain it clearly to the customer before the proposal is sent.

Who should reconcile a solar proposal with the site visit?

The sales rep should own the customer-facing reconciliation, while design, estimating, finance, operations, and qualified reviewers own decisions within their authority. One release owner should verify that each material site item is matched, changed with a reason, routed as an open exception, or excluded with a clear customer explanation.

Does every difference require a new site visit?

No. A readable photo, customer clarification, source document, designer review, or qualified assessment may resolve the difference. A return visit is appropriate only when the missing evidence cannot be obtained responsibly another way or the required reviewer needs direct access. The record should state why the chosen route is sufficient for the current stage.

Should the proposal repeat every site note?

No. Internal field notes can be more detailed than a customer-facing proposal. The proposal should carry the conditions, assumptions, exclusions, choices, and open dependencies that materially affect the buyer’s decision. The reconciliation record should preserve the fuller trail and show why a site note was represented, routed, deferred, or judged irrelevant to this proposal.

How can SurgePV support site-to-proposal reconciliation?

SurgePV can support 3D roof modeling, array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, and review. The software does not replace site verification or approval by responsible engineers, authorities, lenders, insurers, or utilities.