9 Solar Proposal Elements Buyers Can Verify

A solar proposal can look complete while leaving the buyer unable to answer three ordinary questions: What exactly is being proposed? Which inputs make the numbers mean what they say? What still has to be confirmed before anybody can rely on the scope?

Visual polish does not answer those questions. A crisp roof model, exact production figure, smooth savings chart, and confident next-step button can make an early scenario feel final. If project identity, source dates, assumptions, responsibilities, and release status are missing, the follow-up call begins with reconstruction rather than decision-making.

No proposal element can guarantee trust. Trust is a person’s response, shaped by experience and conditions outside a document. A proposal can do something more concrete: make important claims and boundaries inspectable. The buyer can see where information came from, what is modeled, what is assumed, who owns an open question, and what would cause the proposal to change.

This page stops at that pre-follow-up verification job. The solar proposal tracking guide explains delivery stages, view signals, follow-up actions and post-send version tracking. The hidden proposal assumptions guide provides the deeper assumption register. The pre-send proposal checklist provides final failure checks.

This article is not engineering, financial, investment, tax, legal, utility, contract, permitting, or sales advice. Project claims require current evidence and qualified review for the customer, market, release stage, and decision involved.

What can a proposal legitimately accomplish before follow-up?

A proposal can give the buyer a verifiable description of the decision, project, system, evidence, scenarios, responsibilities, open conditions, current version, and next step. It can prepare better questions and expose mismatches before a call. It cannot guarantee trust, understanding, performance, savings, approval, eligibility, price stability, schedule, acceptance, or a commercial outcome.

Treat every important proposal statement as one of five states:

The proposal does not need to expose every internal record. It needs enough context for the intended reader to understand the offer and find the decision basis. Digital.gov describes plain language as clear and easy to understand and says content should be created, designed, and tested for its specific audience. That government content guidance is an analogy, not evidence that a solar buyer understood a document.

Write for the actual decision. A homeowner comparing a cash and financed path needs different context from a facilities team reviewing a preliminary commercial option. Test with representative readers where possible. Ask them to explain what is proposed, what the important number means, what could change, who must act, and what happens next. Their answers are stronger evidence than an internal opinion that the page “looks clear.”

Which inputs must exist before the nine elements are assembled?

Begin with a declared proposal class, customer and project identity, decision purpose, accepted site and energy evidence, selected system state, current commercial inputs, model and scenario versions, reviewer map, customer-claim boundary, open-item register, and release owner. Missing information must have an owner and consequence instead of becoming a favorable default or invisible omission.

FTC solar consumer guidance identifies site, system, energy, bid, contract, finance, and pressure-related questions consumers should examine. The page is a United States consumer resource. It does not approve a particular project, proposal, financing path, or product.

Use an entry record:

Do not confuse a complete form with accepted evidence. A value can be present and still belong to the wrong site, billing period, equipment version, tariff context, finance scenario, or project stage. Acceptance means a named owner reviewed it for the intended use and recorded any limitation.

The broad solar proposal best-practices guide explains the upstream workflow. This page assumes those records exist and asks how the customer-facing document exposes the parts needed for verification.

What are the nine customer-verifiable proposal elements?

Include nine elements: decision identity, project identity, system and scope, production basis, consumption and utility context, financial scenario, assumptions and unknowns, responsibility and approval boundaries, and a versioned next action. Each needs a source, status, owner, limitation, and change rule. Suppress unsupported content rather than letting design polish imply that it is settled.

1. Decision identity

State what the document is and which decision it supports. “Preliminary residential concept for system-scope discussion” is more useful than “your solar solution.” “Budgetary commercial option for internal feasibility review” prevents a different inference than “construction proposal.”

Show the intended reader, proposal class, issue date, and release status near the beginning. Name what the proposal does not decide. A preliminary proposal may support whether to continue site and commercial review. It should not silently claim engineering, permitting, utility, financing, incentive, tax, schedule, or construction approval.

Verification question: What decision may I make from this document, and which decisions remain outside it?

2. Project and site identity

Identify the customer or account, site, relevant meter or usage context, building or project segment, and current project revision. A correct-looking roof image can still belong to a neighboring building, an older condition, or a different project option.

Preserve customer corrections. If the buyer reports a roof change, different meter, future load, or wrong building, mark affected fields pending and create a successor. Do not overwrite the original without an audit trail.

Verification question: Does every image, input, scope statement, and number represent the same site and project state?

3. Proposed system and scope boundary

Describe the selected system candidate and what the quoted scope includes and excludes. Use equipment identity, capacity or quantity where supported, layout or configuration status, delivery boundaries, allowances, customer-provided work, and unresolved choices. Match the text, image, BOM context, and price basis.

Avoid using “complete” when the scope still depends on survey, structural, electrical, equipment, utility, permitting, or contract review. Put the most decision-critical exclusion beside the scope it qualifies, not only in a generic footer.

Verification question: What is included, excluded, provisional, customer-provided, or controlled by another party?

4. Production basis

Label modeled energy in kWh with its period and output boundary, and distinguish system DC capacity from inverter AC capacity in kW. Show that production is a model output, then give the project and model context required to interpret it: system revision, equipment, resource or weather source, shade treatment, material loss assumptions, run date, scenario, reviewer, and limitations. Do not turn an annual modeled figure into a guarantee.

DOE explains that suitability, production, and savings depend on site, system, energy use, purchase or lease, utility rates, and excess-generation compensation and recommends a custom estimate. DOE does not validate the output in a private proposal.

Verification question: Which accepted design and inputs produced this result, and what site or model changes require a new result?

5. Consumption and utility context

Explain which customer energy record and period shaped the proposal, how missing or abnormal data was handled, which load changes are included, and which utility or export context applies. Separate observed usage from future-load assumptions. A future EV, equipment expansion, occupancy change or efficiency project is a scenario input, not current consumption. Separate imported, exported and self-consumed energy; bill savings depend on tariff and timing, not simply annual PV generation multiplied by a retail rate. Where billed demand applies, identify the tariff’s kW peak and billing-period rules separately from kWh energy.

Utility treatment needs source identity, service context, effective date, responsible reviewer, and refresh trigger. Avoid copying one rate assumption into all projects in a territory. Do not imply that a proposal establishes future utility action.

Verification question: Which usage and utility facts are current, which are transformed or assumed, and who accepted them?

6. Financial scenario and metric meaning

Name the scenario and define each displayed metric. Show included cost scope, timing convention, production dependency, utility treatment, cash or finance context, recurring or future items, and the status of tax or incentive assumptions. Keep cash economics separate from financing terms and customer-specific eligibility. Label simple payback as an undiscounted shortcut and keep it distinct from discounted payback, NPV and annualized IRR. State the upfront-cost and annual-net-benefit boundary rather than treating every metric as “ROI.”

For current United States federal tax information, the IRS maintains an official Home Energy Tax Credits resource. Direct reviewers to the current official material. Do not copy a value into a reusable template, promise eligibility, or offer tax advice.

The payback explanation guide explains the live discussion. This element makes sure the proposal preserves the scenario the representative is expected to explain.

Verification question: What does this metric mean, which scenario produced it, and which customer-specific decisions remain unresolved?

7. Material assumptions, unknowns, and sensitivities

Put decision-critical assumptions close to the output they affect. For each, show source or rationale, status, owner, date, affected proposal fields, what confirms it, and what happens if it changes. Use a linked register for detail without forcing a buyer to hunt through an internal model.

Do not bury unknown roof condition beside a confident layout, unverified rate treatment beside a savings headline, or tentative equipment beside a fixed scope. A disclaimer is not a substitute for correcting a mismatch between the main impression and the actual evidence.

Verification question: Which material conclusions depend on something not yet documented, and what is the next verification step?

8. Responsibilities, reviews, and external approvals

Show who owns the next customer action, company review, technical decision, commercial decision, and external dependency. Separate the software output, company review, qualified professional judgment, customer choice, utility action, permitting decision, lender action, and tax or incentive determination.

Use specific language. “Subject to approval” is weak when it does not name the authority, scope, evidence, or stage. “Utility interconnection decision remains external; current proposal does not establish approval” is bounded. Qualified reviewers must adapt the language to the actual market and project.

Verification question: Who is authorized to decide each open item, and which approval has not occurred?

9. Active version, correction route, and next decision

Give the proposal a stable version linked to the project, design, model, scenario, scope, content and review states that produced it. Each artifact may retain its own revision identifier; the links should identify one accepted project basis rather than require identical revision labels. State the next decision, required information, responsible person, and how the customer can correct a project fact or ask for a revised option.

The follow-up should begin from an agreed question, not from whether a tracking pixel fired. The proposal tracking guide explains post-delivery states and view-signal limits. Before delivery, make sure the tracking record refers to the exact version the customer receives.

Verification question: Is this the active proposal, what should I decide next, and how will a correction create a visible successor?

How should a team test the proposal before delivery?

Test the exact rendered proposal with a skeptical reader who did not build it. Ask the reader to identify the decision, project, scope, model basis, financial scenario, important assumptions, responsibilities, current version, and next action. Trace every answer to accepted evidence. Block release when the reader must guess or when visual hierarchy contradicts a material limitation.

Use this test:

1. Freeze the candidate and link all project, model, scenario, content, and review versions.
2. Render every intended surface, including downloaded and mobile views where relevant.
3. Give a representative reader a task, not a tour of the document.
4. Ask the nine verification questions without coaching.
5. Record the reader’s answer, page or field used, uncertainty, and missing context.
6. Trace each load-bearing statement to its source, state, owner, and review.
7. Check the complete impression created by headlines, charts, images, footnotes, CTA, and order.
8. Correct, suppress, or route every unsupported or confusing field.
9. Release only the accepted successor and retain the tested record.

Copy-ready proposal verification record

Use one record for the exact customer-facing version. This is not a universal engineering, finance, tax, legal, utility, contract, or compliance standard.

Illustrative example: two options look comparable but are not

This illustrative example is not a customer case, proposal, quote, production result, savings result, price, finance recommendation, trust result, conversion result, approval, or product claim.

A proposal candidate displays two options in matching cards. The first uses the current design and a cash scenario. The second uses a different equipment candidate and a finance discussion. The visual design makes the options look directly comparable, but the production, cost timing, and responsibility bases differ.

The verification test catches the problem when the reader cannot explain what changed. The proposal owner either rebuilds a controlled comparison under consistent shared inputs or presents the options as distinct decision paths with visible differences. The record preserves which equipment, model, cost treatment, finance context, assumptions, and next review belong to each.

In this hypothetical correction, the intended result is to make each option’s basis visible. Test the revised cards with a reader; the edit alone does not establish understanding.

What happens when an element is missing or changes?

Mark the affected element blocked, pending, paused, withdrawn, or superseded; identify every dependent claim and customer surface; assign an owner and required evidence; preserve the prior version; and release a linked successor only after applicable review. Tell affected recipients what changed without inventing legal conclusions. Never let an old proposal remain active merely because its PDF still opens.

NASA systems-engineering guidance describes configuration management as keeping attributes and documentation consistent through identification, change control, status, and verification. Use that only as a cross-domain analogy. It is not a solar proposal rule or endorsement.

Use a successor rather than silently editing the live artifact. Record who received the old version and whether correction or withdrawal is required under the company’s qualified process. A new file does not by itself resolve an old email attachment, download, CRM copy, or spoken explanation.

Where does SurgePV support proposal verification, and where does it stop?

SurgePV can support roof modeling, array layout, shading, energy-yield and financial modeling, electrical workflow, BOM output, and proposal generation in connected project context. It does not verify customer trust or understanding, accept external inputs, decide tax or utility treatment, approve claims, replace professional judgment, control every delivery channel, or grant any external approval.

Evaluate the financial modeling workflow using a sanitized proposal and a changed input. Ask how its layout, production, bill and financial outputs identify the scenario basis, which affected outputs are flagged in your configuration, and which checks remain manual. Results depend on data, assumptions, equipment models and responsible review.

Connected context can help a team preserve relationships among the selected project, design, production model, financial scenario, and proposal. The organization still owns customer research, input acceptance, scope definition, domain review, content design, proposal delivery, correction, and every external system or authority.

Measure the verification process without promising trust:

Do not translate these measures into a trust, conversion, revenue, or performance claim without controlled evidence for that exact conclusion. They test whether the proposal is inspectable, not how a person will decide.

Adversarial cases expose weak boundaries:

• Can the buyer tell that the roof layout is preliminary?
• Does a savings chart identify the matched usage, utility, and scenario context?
• Can two options be compared without hidden input changes?
• Does an incentive disappear cleanly when eligibility is unresolved?
• Does a changed design invalidate production, financial, BOM, and proposal fields?
• Can a reviewer distinguish company responsibility from utility or permitting authority?
• Does the downloaded file show which version it is?
• Can the buyer correct the site or assumption before the follow-up?

If the proposal fails one case, improve the specific element. More decorative detail will not repair a missing decision boundary.

Frequently Asked Questions

What should every solar proposal include?

The exact content depends on project type and proposal stage, but the buyer should be able to identify the decision, project, proposed system and scope, production basis, energy and utility context, financial scenario, material assumptions and unknowns, responsibility and approval boundaries, active version, and next step. Unsupported fields should be omitted or clearly marked pending.

Does a detailed solar proposal automatically build trust?

No. Length, visual polish, and detail do not prove that a buyer understands or trusts a proposal. Useful detail is traceable, relevant to the decision, clearly written, and honest about status and limits. The company should test comprehension with real readers and correct unsupported or confusing content rather than claim a guaranteed trust or conversion result.

Where should solar proposal assumptions appear?

Put decision-critical assumptions beside the figures, images, or scope statements they qualify, then link to a readable register for more detail. A distant footer should not carry the entire burden. Show the source, date, status, owner, affected output, and what happens if the assumption changes, especially for production, savings, price, financing, and timing.

How should a customer compare two solar proposal options?

Keep shared inputs constant where appropriate, label the one or more factors that differ, and show how scope, equipment, production basis, cost treatment, customer responsibilities, assumptions, and next steps change. Do not imply that options are comparable when they use different utility, finance, tax, incentive, usage, or timing bases without making those differences explicit.

Can SurgePV verify that a customer trusts a proposal?

This article establishes no SurgePV measure or guarantee of customer trust, understanding, acceptance or conversion. SurgePV can support connected roof modeling, layout, shading, energy-yield and financial modeling, electrical workflow, BOM output, and proposal generation. The company remains responsible for evidence, customer language, review, delivery, correction, and every external approval.

Resolve failed checks before follow-up

If the proposal cannot answer a verification question, add context, narrow the claim, request evidence, route review or suppress the affected field. Retain the corrected artifact and the reader-test record; visual polish does not supply missing evidence.