Why Beautiful Solar Proposals Fail on Hidden Assumptions

A proposal can be gorgeous and still leave the buyer unable to answer a basic question: what has to be true for these numbers to mean what the document says they mean?

That gap is easy to miss because design quality creates a feeling of completeness. The roof rendering is clean. Charts line up. The payback graphic lands on an exact point. Yet the consumption period, shade basis, tariff treatment, equipment choice, financing terms, or site status may be invisible. The reader receives a conclusion without its conditions.

The remedy is not an ugly proposal. Good visual design helps people find and compare information. The remedy is to design the assumptions into the decision, instead of sending them to a tiny footer after the persuasive work is done.

This article is a communication framework, not financial, tax, legal, engineering, or investment advice. Project outcomes depend on current evidence and project-specific review. In the United States, the FTC’s truth-in-advertising guidance is a primary reference for advertising claims; other markets and regulated offers require their own current review.

A polished output can hide an unfinished basis

Proposal software naturally emphasizes outputs: capacity, energy, savings, price, environmental equivalents, financing, and images. The inputs live elsewhere because they are less attractive. That separation is a design choice, and it can make an early scenario look more settled than it is.

The distinction to preserve is preliminary versus final, modeled versus measured, and supported versus assumed. A satellite-based layout may be appropriate for an early conversation. It should not silently inherit the status of a verified field design. A modeled production value can support scenario comparison. It is not a guarantee of future output.

The public PVWatts Calculator from the National Laboratory of the Rockies (NLR, formerly the National Renewable Energy Laboratory/NREL) makes inputs visible and describes results as estimates. That posture is useful for proposal teams: show enough of the model basis that a reader can understand why a value may change. Do not borrow a public tool’s authority to validate an unrelated project model.

Seven assumption families behind a solar proposal

The exact register depends on project type, market, and release stage, but seven families capture the main commercial dependencies.

Do not force every proposal to display every possible field. Show what is material to the claims on that page. A cash proposal without a payback claim may need less financing detail than a loan comparison. A commercial project with interval data needs a clearer account of the period and meter relationship than a generic educational example.

Site assumptions change the physical story

The roof image looks like evidence because it is a picture of the site. Its capture date, angle, resolution, and visibility still limit what it can support. Small obstructions, parapet height, access zones, roof condition, electrical details, and planned works may remain unknown.

Label the layout status beside the image: conceptual, preliminary from stated imagery, updated after survey, or reviewed for a named release. Define those statuses internally so sales, design, and delivery use them consistently. Add a short line naming the major unresolved condition.

The missed-obstruction checklist helps teams audit the physical evidence before an early model becomes a customer expectation. When new evidence changes the layout, revise every dependent output rather than swapping only the picture.

Proposal language should explain the effect without pretending to know its magnitude. “Final array area depends on site verification and the treatment of identified roof equipment” is useful. “Minor changes may apply” hides the actual decision.

Production assumptions need a visible chain

An annual energy number is the end of a chain: resource data, geometry, equipment, configuration, shade treatment, loss assumptions, operating choices, and model behavior. The proposal should let a reviewer trace that chain at the level appropriate to the decision.

Use a compact model-basis card with the design revision, equipment set, resource source, shade method, material loss categories, and run date. Link or attach a fuller register for technical review. If the proposal compares scenarios, state exactly what changed between them.

NLR’s System Advisor Model is a public performance and financial modeling tool with extensive documentation. It demonstrates that modeled outputs arise from defined technical and financial inputs. It does not prove that a particular proposal’s inputs are correct or that another tool will produce the same result.

Avoid false precision in the visual. A chart can display the model output at the resolution needed for the workflow, but the surrounding language should not imply certainty beyond the evidence. Rounding policy, uncertainty treatment, and scenario labels should be consistent across the proposal.

Consumption assumptions decide whether energy becomes savings

Production and consumption answer different questions. A system may produce energy when a building is not using it. The financial effect depends on load timing, rate structure, export treatment, and other project terms. Annual consumption alone can hide that relationship.

Show the consumption source, meter or account coverage, period, resolution, completeness, and known operating changes. If interval data is unavailable, state what proxy or annual approach was used and what decision remains preliminary. Do not label customer-supplied information “verified” unless the team defines and performs that verification.

Commercial buildings add complications: tenants change, operating hours move, equipment is added, and multiple meters may serve one site. A proposal should name which loads are inside the scenario. The 15-minute interval load data guide provides deeper context for project teams working with time-series consumption.

The customer does not need every row of source data in the proposal. They do need to know what the savings story assumes about how the site uses energy.

Tariff assumptions can turn one energy result into different financial stories

Rates, fixed charges, demand charges, time periods, export treatment, taxes, fees, and escalation choices can influence a financial model. Applicability varies by utility, account, tariff, jurisdiction, and date. Use current primary documents for the actual project and record the effective date.

Place the tariff name or source, observation date, key modeled treatment, and unresolved eligibility question near the savings output. Do not call a tariff “confirmed” merely because it appeared on a bill if the model depends on future eligibility or a different post-solar structure.

Avoid a single broad disclosure such as “utility rates may change.” It is true but not useful. Name which rate input the scenario uses and which future change would trigger a rerun. For highly volatile or jurisdiction-sensitive inputs, link to the live authority and shorten the review window.

If the sales team cannot explain how the tariff entered the model, the savings chart is not ready to carry the conversation.

Financing assumptions belong beside payment and return claims

Cash, loan, lease, power-purchase, and other structures assign costs, ownership, risk, maintenance, incentives, and timing differently. A side-by-side graph becomes misleading when those differences are reduced to one monthly figure.

Show the provider or source, product date, cash price basis, financed amount, fees, rate type, term, payment changes, prepayment treatment, security interest where applicable, ownership, maintenance responsibility, and assumptions used in any return metric. The required disclosures depend on offer and jurisdiction, so route the document through qualified review.

The U.S. Consumer Financial Protection Bureau maintains consumer tools for mortgages that demonstrate a broader principle: payment figures need terms and standardized context to become comparable. Solar financing is not a mortgage by default, and proposal teams should use the disclosures required for the actual product rather than borrowing labels loosely.

Never place the least favorable term in a footnote while the headline promotes only the first payment. Visual hierarchy is part of the claim.

Scope assumptions decide what the price includes

A proposal price is hard to evaluate without scope. Equipment, design work, permitting responsibility, interconnection work, structural or electrical upgrades, roofing, trenching, monitoring, storage, taxes, fees, owner work, site access, and change handling may be included, excluded, provisional, or pending.

Use a scope table with four states: included, excluded, allowance or provisional, and owner responsibility. Avoid a miscellaneous exclusions paragraph that forces the buyer to infer the project boundary. Link each allowance to the event that converts it into a confirmed amount.

Keep proposal, contract, work order, bill of materials, and installation documents consistent. If the proposal promises an item that later records omit, the visual quality of the proposal becomes evidence of a broken handoff.

The solar change-order management guide explains how to carry new evidence into commercial documentation. Change is normal. Invisible change is the failure.

Timing assumptions should name dependencies

Schedule claims attract attention because buyers need planning certainty. A date often depends on site access, customer decisions, equipment, design review, permits, utility steps, financing, weather, inspections, and subcontractors. The relevant list differs by project.

Do not turn a target into a guarantee. Show the current schedule status, observation date, prerequisites, owner of the next event, and how a delay will be communicated. Distinguish internal work duration from external elapsed time.

The DOE’s homeowner guide describes permitting, installation, inspection, and utility connection as separate steps in a United States context. That solar project overview is not a schedule promise for an individual project, but it shows why one headline installation date may omit several dependencies.

Use a milestone view only when the milestones have operational owners. Decorative timelines create confidence without control.

Put assumptions where the buyer interprets the claim

Three layers work well for readability:

1. A short qualification immediately beside the number, chart, rendering, price, or schedule.
2. A decision panel with the material source, status, date, and trigger.
3. A detailed register or appendix for reviewers who need the full basis.

This layered design avoids two bad extremes. One hides everything in legal text. The other floods the main page with fields until the decision disappears. The first layer protects interpretation, the second supports discussion, and the third supports review.

Use plain labels. “Modeled annual energy using the listed design and assumptions” is clearer than “estimated yield subject to terms.” “Customer-provided bills from January through December; interval data not supplied” is clearer than “based on historical usage.”

Which assumptions must appear beside a solar proposal claim?

Place every decision-changing assumption beside the proposal claim it governs. For design, show site and geometry status. For production, show model basis and losses. For savings, show consumption, tariff, export, and scenario status. For price and payment, show scope, financing, incentives, and timing. Each panel should name the source, date, owner, unresolved condition, and revision trigger for that output explicitly.

Begin with the claim, not the appendix. Mark each prominent number, chart, layout, price, payment, schedule, equipment statement, approval term, and comparison. Ask what a buyer would need to know before relying on it. The answer determines the nearby assumption panel. A general disclosure that “results vary” cannot perform this mapping because it names neither the controlling input nor the decision effect.

Use this claim-to-assumption worksheet:

Keep the panel concise by choosing only decision-changing fields, then provide a stable reference to the fuller register. “Tariff source and observation date” is useful when a savings claim depends on that tariff. An obscure internal setting that cannot alter the buyer’s decision may remain in the technical record. Concision comes from materiality, not from hiding the model basis.

Match visual weight to claim weight. If a payment dominates the page, a condition that changes that payment cannot appear in faint text several screens away. If a photorealistic roof image uses unverified geometry, the preliminary status belongs beside the image. If an “approved” badge refers only to one review, name the approving party and scope there.

Illustrative workflow example, not a customer result: A proposal page shows modeled annual energy and a utility-charge scenario. The nearby card identifies the design revision, resource source, shade treatment, consumption period, tariff source, scenario status, and pending interval-data review. When the buyer questions the result, the team can discuss a named input instead of defending the chart as a single finished truth.

Test every delivery format. A panel that sits beside a chart on desktop may fall below the CTA on mobile or move to the next PDF page. Review the actual exported document, customer portal, email preview, and print format. Proximity is a property of the released experience, not the design canvas.

Make every material assumption an owned record

An assumption needs more than a sentence. Give it structure:

The solar production estimate assumption register gives a detailed method for production forecasts. Extend the same control to price, scope, financing, and timing where they carry material customer claims.

How should teams build a proposal assumption register?

A proposal assumption register should record one material input or assumption per row, with a stable identifier, current value or treatment, source, observation date, evidence status, jurisdiction, owner, affected claim and output, customer wording, required reviewer, expiry, and rerun trigger. It should separate customer-supplied facts, measured evidence, documented terms, model defaults, planning assumptions, pending decisions, conflicts, and superseded values clearly.

Create the register before layout work starts. If it is assembled from footnotes after the proposal is designed, teams tend to record only what the template already exposes. Starting early lets the project team decide which outputs are mature enough to show, which open items need a visible qualification, and which claims should wait for better evidence.

Use a copy-ready assumption row:

1. Assumption identifier and family:
2. Project, scenario, design, and proposal revision:
3. Input, value, treatment, unit, period, or scope:
4. Source, provider, observation date, retrieval date, and jurisdiction:
5. Status: measured, customer-supplied, documented, modeled, default, assumed, pending, conflicting, or superseded:
6. Purpose and the claim or output that consumes it:
7. Material effect if the value changes:
8. Decision owner and qualified reviewer where required:
9. Customer-facing wording and nearby panel location:
10. Evidence still required, due event, expiry, and rerun trigger:
11. Downstream layout, energy, financial, material, electrical, scope, schedule, proposal, and contract references:
12. Change history, replacement row, and withdrawal state:

Do not let “assumption” become a category for every uncertain thing. A customer-supplied bill is a sourced input whose completeness and coverage may remain open. A model default is a software value selected under a method. A planning assumption is a temporary project treatment. A pending decision lacks an accepted answer. The statuses require different owners and release effects.

Link rows to claims and dependencies. A roof dimension may affect layout, quantity, energy, price, and proposal imagery. A tariff input may affect financial outputs without changing physical design. A financing term may affect payment copy but not energy. Dependency mapping prevents a changed value from triggering blind full-project edits or leaving one affected output behind.

Set claim-level review events. An equipment selection changes on procurement. A tariff may change at an effective date or utility event. A site assumption expires at survey or field discovery. A financing term expires with the offer. An evergreen model definition may remain stable longer. One annual proposal-review date is too blunt for inputs that move on different clocks.

Give the customer-facing wording its own field. Internal labels such as “default load profile” or “loss factor set B” may not explain the decision. The external sentence should name status, relevance, and next action without implying approval. Technical reviewers still retain the detailed method and source needed to assess the model.

Use scenarios only for real uncertainty or choice

Scenario design can make assumptions visible when each case corresponds to a genuine decision. Compare two roof layouts when site treatment differs. Compare consumption cases when a documented operational change is under consideration. Compare financing offers with their actual terms.

Do not manufacture three cases because a proposal template has three columns. An optimistic and conservative range without a method can create the appearance of analysis while hiding where the endpoints came from. If probability language such as P50 or P90 is used, the method must support that technical meaning.

For each scenario, state what changes, what remains fixed, and why the comparison matters. Keep colors and ordering neutral enough that design does not steer the buyer toward the case with the least visible uncertainty.

What should happen when an assumption changes after a proposal is sent?

When an assumption changes after a proposal is sent, freeze the affected claim, preserve the issued version, identify every dependent design, energy, financial, scope, schedule, and customer output, rerun models or calculations, obtain the required reviews, issue a traceable revision, explain the material change, and withdraw superseded copies. Do not silently replace one number while pages retain the old basis.

Start by recording the event. Name the input, old value or treatment, new source, observation date, reporter, affected project and proposal versions, and reason the change is credible. A customer comment, survey, utility document, equipment substitution, financing update, authority response, or internal correction may require different review before acceptance.

Map dependencies before regenerating documents:

1. Freeze the affected proposal output and prevent reuse while its basis is under review.
2. Preserve the sent proposal, model inputs, claim panels, and customer communications.
3. Update the assumption row with the new evidence and keep the prior row superseded, not erased.
4. Identify every consuming design, calculation, scenario, table, chart, scope, schedule, and document.
5. Route technical, financial, tax, legal, contract, utility, authority, or other decisions to the qualified reviewer that owns them.
6. Rerun validated models or calculations through the approved workflow and record the versions.
7. Compare old and new outputs, then identify which customer decisions or commitments may be affected.
8. Issue a new proposal revision with changed inputs, outputs, open items, and controlling date stated.
9. Explain the material change in plain language and give the buyer a route to ask questions.
10. Mark old portal files, downloads, CRM attachments, emails, and sales copies superseded or withdraw them through the controlled process.

The explanation should separate cause from consequence. “New survey evidence changed the usable roof area” names the source change. “The current layout and dependent modeled outputs were revised” names the consequence. Avoid language that promises the new scenario is final when engineering, authority, utility, commercial, or site decisions remain open.

Do not compare outputs until their bases are comparable. If several inputs changed together, list them. A new energy result and financing offer cannot be attributed to one roof change when the equipment, tariff, or commercial terms also moved. Preserve the customer’s ability to see what the revision does and does not establish.

Close the change only after distribution is reconciled. A corrected portal does not update a downloaded PDF. A revised proposal does not withdraw an automated email, salesperson screenshot, partner copy, or contract exhibit. Register placements and recipients so the owner can verify that the old basis no longer directs a decision.

Review the proposal as a skeptical buyer

Assign a reviewer who did not build the model to read only the customer-facing proposal. Ask them to mark every number, date, superlative, approval statement, equipment fact, and outcome claim. For each mark, can they find the source, qualifier, status, and owner without opening an internal design application?

Then ask five questions:

• Which outputs look final even though the evidence remains preliminary?
• Which chart compares unlike scopes or terms?
• Which assumption appears only after the claim has already shaped the decision?
• Which word changes meaning between the proposal and the contract?
• Which project change would invalidate more than one page?

Record findings by section and revise the proposal once. Recheck the claims after editing because a design improvement can accidentally remove a qualifier.

Keep visual design in service of review

Good proposal design creates hierarchy, proximity, comparison, and readable density. Use those tools to expose assumptions. Place the source beneath the chart. Keep the scope state in the same row as the item. Put the revision beside the rendering. Use table headers that name the comparison basis.

Avoid decorative precision: fine-grained charts without readable axes, currency figures displayed to unnecessary decimals, or photorealistic roof images that imply surveyed geometry. Illustration style should match evidence status.

Accessibility matters as well. Do not rely on color alone to distinguish confirmed from assumed. Use text labels and readable contrast. Make tables usable on narrow screens and provide descriptive context for charts.

Treat footnotes as navigation, not storage. A short note can point to a named appendix field or current authority document. It should not contain the first disclosure that a payment changes, an incentive is conditional, or the roof layout has not been field-verified. Readers scan visual emphasis before fine print, so material conditions need comparable prominence.

Test the proposal in grayscale, on a phone-width viewport, and as a printed PDF if those are real delivery formats. Confirm that qualifiers remain adjacent to their claims after responsive tables stack or pages break. A technically correct note on the next printed page may fail the practical reading task. Record the tested format and revision so later template changes receive the same check.

The proposal should still look good. It should look good because the decision is easy to inspect.

Readability is evidence delivery, not decoration.

That principle should survive every export, screen size, and revision.

Keep product claims within the current record

SurgePV’s approved product scope covers 3D roof modeling, solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output, and proposal generation.

Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility. Software can connect project work, but it cannot turn an unverified input into a verified condition.

Avoid promising that software makes proposals accurate, compliant, approved, or more profitable without current claim-specific evidence. Describe the supported workflow and let the buyer evaluate fit.

A proposal earns trust when it survives questions

The SurgePV solar proposal page is the current product reference for the proposal-generation workflow, not evidence of a guaranteed customer outcome.

The purpose of a proposal is not to remove every uncertainty. It is to support a decision at the current stage. That requires the document to say what is known, what is modeled, what is assumed, what remains open, and what happens if the basis changes.

Make site, production, consumption, tariff, financing, scope, and timing assumptions visible near the claims they shape. Give each material item a source, date, status, owner, and trigger. Use visual hierarchy to connect evidence to output.

A buyer may still disagree with the scenario. That is healthy. The proposal has done its job when the disagreement can focus on an identifiable input rather than a beautiful page that leaves nobody sure what the number means.

Frequently Asked Questions

What assumptions should a solar proposal disclose?

Disclose the material assumptions behind system design, usable area, shading, energy production, consumption, tariffs, exports, financing, incentives, equipment, schedule, scope, and responsibilities. The relevant set varies by project. Each assumption should show its source, status, date, owner, and what must happen if it changes.

Where should proposal assumptions appear?

Put a short decision-critical assumption panel beside the output it qualifies, then provide a readable register or appendix for detail. Do not hide the basis of savings, production, price, or scope in a distant legal footer. The buyer should encounter the qualification while interpreting the claim.

Does an assumption disclaimer make a solar estimate reliable?

No. A disclaimer can identify limits, but reliability also depends on suitable source data, methods, equipment models, configuration, review, and current commercial terms. A broad statement that results may vary does not repair an incorrect input or tell the buyer which project condition could materially change the scenario.

How can sales teams explain uncertainty without losing confidence?

Separate what is documented, modeled, assumed, and pending. Explain why each open item matters and name the next verification step. This approach gives the buyer a route to a stronger answer. False precision may feel confident at first, but it creates a harder conversation when project evidence changes.

Should every proposal show multiple financial scenarios?

Only when the scenarios represent real, documented choices or uncertainties. Do not add optimistic, base, and conservative cases merely for appearance. Name the input that changes, hold other inputs consistently where appropriate, state the purpose, and avoid presenting a scenario range as a probability unless the method supports that interpretation.