10 Questions to Ask Before Sending a Solar Proposal

Answer: Before sending a solar proposal, ask whether it supports a defined customer decision, represents the correct project and version, keeps system scope and modeled outputs consistent, uses accepted energy and financial inputs, exposes material assumptions, assigns responsibilities, survives a reader test, identifies the active artifact, and gives the customer an honest next action and correction path.

A proposal can open correctly while still showing a layout from one design revision, savings from another usage record and a price from an expired scenario. Use the ten questions below to identify the active candidate and the evidence behind its customer-facing claims before release.

The ten questions in this guide are a manager’s release interview. They do not replace the solar proposal pre-send checklist, which owns the broader quality workflow. They do not repeat the projected savings readiness questions, which go deeper into financial evidence. Each question here requires a record or creates a stop.

This is not engineering, finance, tax, legal, utility, contract, permitting, or investment advice. A software output, completed form, or manager’s confidence does not replace current project evidence and review by the responsible qualified people.

What decision does the release interview make?

The release interview decides whether one fixed proposal candidate may reach one named recipient for one declared purpose under recorded conditions. It verifies that the customer-visible artifact matches accepted project, design, production, financial, scope, content, and review states. It does not certify the project, guarantee results, or grant any technical, commercial, legal, utility, or external approval.

Use five answer states rather than yes or no:

“Looks fine” is not an answer state. “The designer checked it” is incomplete unless the record identifies what the designer reviewed, against which version and evidence, and whether later changes reopened that review.

Define the exact candidate before the interview. Include project id, proposal class, intended recipient, design revision, production model, financial scenario, scope version, content version, rendered artifact, and review state. If any changes during the interview, create a successor candidate and restart affected questions.

Which records must exist before the interview begins?

Prepare the proposal brief, project identity, accepted source register, current design and equipment state, production model, consumption and utility context, cost and financial scenario, assumption and unknown register, scope and responsibility map, required reviews, content and claim inventory, rendered candidate, version graph, recipient, and release owner. Missing records must be visible blocks, not facts reconstructed from memory.

AHRQ describes flowcharts as visual process-step representations useful for examining handoffs, responsible people, problem sources, and improvement areas. Use that healthcare workflow tool only as an analogy. Map the route from accepted input to customer artifact and mark each owner.

Do not require records that do not serve the proposal class. A preliminary concept and a detailed commercial proposal need different evidence. The release brief must define the difference before the team uses absence as a reason to guess.

Set the interview up so evidence is available without a scavenger hunt. Link the active source register, design candidate, model run, financial scenario, assumption record, scope, and reviewer dispositions from the candidate. Keep superseded files visible as history but unmistakably inactive. A reviewer should not have to infer which attachment a salesperson considered current.

Name decision authority before the meeting. The release owner coordinates the complete artifact, but that role does not absorb every specialist decision. If production review belongs to an energy-model owner, utility treatment to a market-qualified reviewer, and customer wording to a sales or compliance owner, preserve those boundaries. The interview is a reconciliation point, not a transfer of professional responsibility to whoever chairs it.

What ten questions should the release owner ask?

Ask what decision the proposal supports, whether it represents the correct project, whether system and scope agree, whether production and financial claims trace to accepted inputs, whether assumptions are visible, whether responsibilities and approvals are accurate, whether a skeptical reader can interpret it, and whether the exact version and next action are controlled.

1. What customer decision is this proposal allowed to support?

Require the proposal class, intended reader, decision, release stage, and limits. A preliminary concept may support whether to continue assessment. It must not look like final engineering, firm price, utility approval, guaranteed production, or construction authorization.

Evidence: release brief and customer-visible status. Owner: proposal owner. Stop: the document has no bounded job or its CTA asks for a later-stage commitment.

2. Does every field belong to the same customer and project state?

Compare customer or account, site, building, meter or usage context, project option, and selected revision. Check images, filenames, charts, and attachments, not only frontmatter. Plausible data attached to the wrong project is still wrong.

Evidence: stable project id and source bindings. Owner: project owner. Stop: conflicting or ambiguous identity. Re-entry: confirmed project state and rebuilt candidate.

3. Do the system image, equipment, scope, and BOM context agree?

Trace the visible layout, capacity or quantity, equipment, inclusions, exclusions, allowances, customer work, and materials context to one design revision. A changed module or layout can affect more than the picture.

Evidence: design, equipment, scope, and dependency versions. Owner: responsible design and commercial reviewers. Stop: stale consumer, unresolved substitution, or mismatched scope.

4. Can the modeled production be reconstructed from accepted inputs?

Identify the project design, equipment, weather or resource basis, shading treatment, loss assumptions, model version, run date, scenario, output, and reviewer. State what field evidence remains pending and what would trigger recalculation.

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 approve the private model.

Add the modeled period, units and output boundary to the visible production figure. A system capacity in kW is different from estimated energy in kWh over a named period. If a proposal shows an uncertainty percentile or a production guarantee, retain the method or contract that establishes that specific meaning; do not attach either label to an ordinary simulation result without evidence. See the solar-yield prediction guide for model and uncertainty boundaries.

5. Does the consumption and utility context match the customer claim?

Confirm the usage source, period, completeness, transformations, future-load assumptions, meter relationship, utility source, service context, treatment, effective date, and reviewer. Separate observed consumption from modeled future changes.

Evidence: accepted energy and utility register. Stop: old bill, wrong meter, unreviewed rate context, or missing input presented as certain. Re-entry: current evidence and named disposition.

6. Do financial figures mean what the proposal says they mean?

Name the cost boundary, cash or financing scenario, production dependency, utility treatment, metric definition, timing convention, recurring items, tax or incentive state, and customer-specific limitations. Keep separate options separate.

The deep savings readiness guide owns this review. The release manager’s job is to verify that its accepted output matches the proposal, not redo financial analysis from memory.

A useful arithmetic check separates an energy comparison from a bill claim. In a hypothetical example, estimated annual production of 18,000 kWh divided by observed annual use of 20,000 kWh is 90%. That is an annual energy ratio, not proof of 90% lower bills, 90% self-consumption or off-grid operation. Generation and demand can occur at different times, and export credits and remaining charges require the applicable tariff and customer model. DOE’s homeowner guide identifies consumption, purchase or lease, utility rates and export compensation as savings inputs; its discussion is not a current tax-rate source. DOE’s savings and net-metering context.

Before release, reconcile these distinct outputs:

This table is an editorial review aid, not a tariff calculation or financial recommendation. The responsible reviewer should correct or suppress a claim whose supporting scenario is missing.

7. Are material assumptions, unknowns, and exclusions visible where they matter?

Ask which claims would change if an assumption proves wrong. Put decision-critical conditions beside affected system, production, savings, price, scope, or timing content, then link to a readable register. A generic footer cannot carry every qualification.

Evidence: assumption register with source or rationale, owner, state, affected outputs, and confirmation path. Stop: an unresolved material input is hidden or ownerless.

8. Are responsibilities, reviews, and external approvals represented accurately?

Separate company work, qualified professional review, customer decisions, partner roles, utility action, permitting, lender decisions, tax treatment, and other external authority. Name what has and has not occurred.

FTC business guidance says advertising must be truthful and non-deceptive, objective claims require prior evidence, and words, images, context, omissions, and implied claims can affect meaning. This is general United States guidance, not a private legal conclusion.

9. Can a skeptical reader interpret the exact rendered proposal?

Give the candidate to a representative reader who did not build it. Ask the reader to state the decision, project, selected option, production basis, financial scenario, important assumption, responsibility boundary, and next action without coaching.

Digital.gov describes plain language as clear and easy to understand and calls for content created, designed, and tested for its audience. That guidance does not prove customer comprehension. Record actual task findings and correct the component that failed.

10. Is this the exact version that will be sent, tracked, and corrected?

Match project, design, production, financial, scope, content, review, and rendered versions. Confirm recipient, channel, release owner, issue time, active link or attachment, next decision, support route, and correction path. Mark earlier versions superseded.

The proposal tracking guide owns post-send stages and view-signal limits. The release interview ensures tracking begins with the right artifact.

How should the release interview be documented?

Use one record for the fixed candidate. For each question, capture the answer state, evidence, version, reviewer scope, condition, stop reason, affected output, and re-entry requirement. Record the final release owner, recipient, channel, artifact, and time. Preserve blocked and superseded candidates so correction does not depend on memory or overwrite what a customer received.

Run the interview in this sequence:

1. Freeze and identify the candidate.
2. Confirm proposal class, recipient, and permitted decision.
3. Ask all ten questions without skipping conditional fields.
4. Record answer states and exact evidence, not only initials.
5. Route blocks or escalations to named owners.
6. Create a successor after material changes.
7. Reopen only affected questions, while checking complete impression.
8. Render and test the exact delivery surface.
9. Authorize one recipient, channel, purpose, and version.
10. Preserve delivery, correction, withdrawal, and successor records.

Copy-ready solar proposal release interview record

Illustrative example: usage changes after financial review

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

A proposal candidate passed financial review using an accepted usage record. Before release, sales receives a newer usage file and adds it to the CRM without reopening the proposal. The layout and production model have not changed, but consumption-dependent savings content may no longer represent the accepted scenario.

Question five blocks release because two usage sources are active. Question six also reopens because the displayed financial figures depend on the earlier usage context. The project owner records the new source, qualified reviewers decide applicability, a successor scenario and proposal are created where required, and unaffected technical review remains preserved.

No change magnitude or outcome is claimed. The release interview succeeds because it locates the dependency before delivery.

What should happen when an answer is blocked or disputed?

Pause the candidate, preserve the disputed values and sources, identify affected customer claims, assign the authorized decision owner, state what may continue, and require explicit re-entry evidence. Do not choose the more favorable value or let an old approval follow a changed input. Create a linked successor, retest affected surfaces, and notify prior recipients when qualified review requires correction.

NASA systems-engineering guidance describes configuration management through identification, change control, status, and verification to keep attributes and documentation consistent. Use that only as a cross-domain analogy.

An exception can permit a narrower proposal only when the company’s qualified rules define what that output means, which fields are suppressed, what remains visible, and what the customer may do with it. “Preliminary” is not permission to show every unsupported number with a disclaimer.

Where can SurgePV support this review, 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 accept external evidence, decide local rules, approve customer claims, grant professional judgment, determine tax or utility treatment, control every delivery channel, or replace the authorized release owner and external authorities.

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

Use connected context to reduce version reconstruction where supported. Keep human authority visible for project identity, evidence acceptance, technical decisions, financial and customer claims, review scope, release conditions, delivery, and correction.

Useful measures include blocked candidates by question, missing evidence by owner, changes after review, reader-test failures, version mismatches, preventable post-send corrections, and exact-artifact reconstruction. None proves accuracy, trust, conversion, or customer harm. Use them to improve the release interview without turning internal observations into unsupported marketing claims.

Review patterns by comparable proposal class. A repeated block at project identity points to a different upstream control than a repeated block at reader interpretation. A high count of post-review changes may indicate that the interview happens before the candidate is stable. A version mismatch may reveal uncontrolled exports rather than a model problem. Keep the observed mechanism attached to the metric so management does not prescribe one remedy for every failure.

Do not reward reviewers for answering every question “accept.” A responsible interview will sometimes stop delivery, narrow the output, or request current evidence. Track whether the block had a clear owner and re-entry path. The purpose is a defensible release decision, not a green dashboard.

Frequently Asked Questions

Who should approve a solar proposal before it is sent?

Approval should come from the people authorized for the proposal class and claims involved. A release owner can coordinate the decision, but technical, production, financial, utility, tax, contract, legal, customer, and external-authority questions may require different qualified reviewers. Record each review’s exact scope. Do not treat silence, software output, or one narrow comment as blanket approval.

Can a preliminary solar proposal be sent with missing information?

Sometimes a clearly preliminary output can be appropriate under a company’s approved rules, but its permitted purpose, missing evidence, suppressed fields, assumptions, limitations, next action, and prohibited interpretations must be explicit. Some gaps should block delivery entirely. A qualified owner must decide the path; a generic disclaimer should not rescue unsupported production, savings, price, eligibility, or approval content.

How long should a solar proposal review take?

There is no responsible universal duration. Review depth depends on proposal class, project evidence, changes, exceptions, customer claims, market, and required specialist decisions. Measure internal review states for comparable work, but do not shorten review merely to meet a public speed target. Remove preventable waiting and clarification while preserving the evidence and authority the release actually requires.

Should the customer receive the proposal assumptions?

The customer should see material assumptions in readable context near the claims they affect, with enough detail to understand source or rationale, status, owner, consequence, and confirmation path. A fuller register can support review. Do not expose irrelevant internal noise, but do not hide decision-critical production, usage, utility, cost, financing, tax, scope, timing, or responsibility assumptions in a distant footer.

Can SurgePV approve a solar proposal for release?

SurgePV can support modeling and proposal generation; the company’s authorized reviewers decide release. Outputs depend on source data, assumptions, equipment models, configuration and review. Qualified people and applicable external parties remain responsible for technical, financial, utility, customer, permitting and other approvals.

Make ready-to-send reconstructable

The ten questions should not make release ceremonial. They should make it possible to explain why one proposal candidate was sent. The manager can point to the customer decision, project, design, production, financials, assumptions, responsibilities, reader test, versions, recipient, and next action without rebuilding the story from chat.

If an answer depends on “probably,” “latest,” “the reviewer saw it,” or “the customer will ask if it matters,” the record is not ready. Block, narrow, escalate, or correct the affected content.

A proposal is ready to send when its evidence, meaning, authority, and artifact identity survive the questions before the customer has to ask them.