Solar Proposal Acceptance Handoff: What Must Move From Sales to Delivery

A signed solar proposal is a transition point, not proof that every project condition has been verified. It tells the team that a customer has chosen an option under the stated commercial basis. It does not by itself confirm a roof, electrical service, authority route, material availability, installation date, or final system configuration. When the distinction is lost, accepted proposals become the source of expensive assumptions.

The handoff after acceptance should therefore preserve two things at once: the customer’s decision and the conditions attached to it. This guide is desk research for installers and EPCs. It does not replace contracts, engineering review, local regulation, utility procedures, site safety controls, manufacturer requirements, or qualified technical judgment.

Acceptance Answers One Question Clearly

The project team should first state what acceptance means in the organisation’s process. Identify the actual evidence of the customer’s decision and the agreement or reviewed process that governs its effect. A CRM status, unsigned option, silence or receipt of an email is not automatically contractual acceptance or authorization to mobilize. It may authorize survey planning, detailed design, document collection, an interconnection application, or another controlled next step. It does not mean every later action is authorized without review.

That simple boundary prevents a common delivery problem. Sales hears “yes” and communicates a start date. Operations reads the proposal as fixed scope. Design discovers that a preliminary input needs a different configuration. The customer then experiences a necessary review as a surprise because nobody carried forward the condition that was present in the proposal.

The U.S. Department of Energy Solar Energy Technologies Office provides broad resources on solar deployment. Those resources do not establish a particular project’s requirements. The accepted project record should separate public information from the actual bills, survey findings, drawings, correspondence, approvals, and reviews that control the next decision.

Build an Acceptance Packet, Not an Email Thread

An acceptance packet can be a controlled project record rather than a physical packet. Its purpose is to give delivery a reliable starting point. It should contain links to current documents, not a pile of attachments that may be superseded.

This packet must make clear whether the accepted configuration is preliminary, proposal-ready, or ready for a specific release. A PDF with a signature does not change the status of its underlying inputs.

Capture the Customer’s Choice in Plain Language

Write one sentence that the sales lead, designer, project manager, and customer would all recognize. For example: “The customer accepted the presented grid-connected PV option under proposal revision 3, subject to the listed survey, electrical, utility, and equipment conditions.” The precise wording will vary, but the record should not require a reader to infer the choice from a price table.

Include customer priorities where they affect the delivery path. A request for backup power, a planned re-roof, a tenant deadline, a facility operating restriction, or a specific equipment preference can matter. Record it as a customer objective or request, not as a technical conclusion. The project still needs the evidence and review appropriate to the next stage.

Keep Conditions Visible After the Sale

Accepted proposals frequently contain conditions in fine print or general caveats. Delivery needs an actionable version. Replace “subject to survey” with the exact verification work, responsible role, and release boundary. Replace “utility approval required” with the known route, current source, owner, and condition that blocks the next commitment.

Make conditions actionable so the customer and delivery owner can identify the next evidence request without assuming a resolved result. Avoid messaging that turns an indicative production estimate, completion date, or approval expectation into a promise.

Assign the Next Owner Before the Handoff Ends

An open issue with no owner is not a managed condition. Assign a role or person, a due date linked to the next milestone, and a stated output. Examples include: site assessor to verify listed roof features before layout release; technical reviewer to assess a service condition before final configuration; project coordinator to obtain current utility correspondence before application work; procurement owner to confirm whether a substitution affects the controlling design.

NASA’s interface-management guidance describes identifying responsibilities and controlled interfaces. Adapt those handoff principles to the packet; this cross-domain reference establishes no solar contract or release rule.

The delivery lead can coordinate the list, but should not be expected to make electrical, structural, authority, safety, or other decisions outside the relevant process. Escalate those questions with source evidence and a decision statement. This prevents vague “please review” handoffs that leave the reviewer to reconstruct the project.

Give Every Owner a Deliverable, Not Only a Deadline

The phrase “follow up with customer” does not produce a usable handoff. State the output expected from the owner. A sales coordinator might obtain the missing consumption record and attach it to the project. A surveyor might return dated photographs and notes addressing named layout questions. A technical reviewer might confirm whether the current configuration can progress to the stated release or list the remaining conditions. A procurement owner might confirm that a proposed substitute has been compared with the controlling configuration.

This assignment should distinguish two incomplete outcomes: The first is a closed task that did not answer the project question. The second is a completed review whose result never reaches the proposal, material list, or customer communication. When the outcome is named at assignment, the delivery lead can tell whether the project has truly moved forward.

Reconcile What Changed Since the Proposal Was Sent

Acceptance can happen days or weeks after a proposal is issued. Before the handoff, check whether inputs changed: price basis, equipment availability, roof condition, consumption information, utility treatment, customer objective, or scope request. The answer may be “nothing material,” but it should be visible rather than assumed.

If something did change, decide whether the customer needs an updated proposal, a clarified condition, or a formal change path. Do not allow a later document to quietly replace the accepted decision. Evaluate Solar Proposals for the required customer-facing outputs and revision references in the offered configuration; the project team still has to decide whether the change is material and how it should be communicated.

Hold a Short, Structured Delivery Kickoff

The first internal meeting after acceptance should not be a general status call. Use the packet to resolve five questions:

1. What did the customer accept, and which revision is controlling?
2. What can proceed immediately, and what is conditional?
3. Which project facts are confirmed, which are assumptions, and which require evidence?
4. Who owns each open action and when does it need to be complete?
5. What event requires the team to return to the customer or revise downstream records?

This review need not be long. Its value is that each role hears the same boundary before separate tasks begin. Record changes before dependent commitments are issued and identify the owner who can authorize those commitments.

Learn From Post-Acceptance Surprises

Track why accepted projects require material revision. Common reasons may include stale customer records, unverified roof conditions, unclear service information, equipment changes, customer scope expansion, or a utility process identified too late. Look for an upstream improvement: a better proposal field, a focused evidence request, a named release boundary, or a different handoff owner.

Do not use internal returns to claim a universal solar-industry benchmark. The right lesson is local: what information or communication would have made the next similar handoff safer and clearer?

Practical Next Steps

1. Define what proposal acceptance authorizes in your workflow and what it does not.
2. Require the accepted revision, open conditions, evidence status, and next owners in every delivery handoff.
3. Reconcile material changes before a customer decision becomes a procurement or field instruction.

Frequently Asked Questions

What should happen after a solar proposal is accepted?

The team should preserve the accepted revision, confirm what the customer chose, assign open conditions, and route the evidence and reviews required before the next project release.

Does proposal acceptance mean the design is ready for installation?

Not necessarily. Acceptance may permit the next stage, but site, technical, utility, authority, procurement, and field checks still depend on the project and its stated conditions.

Who owns the handoff after solar proposal acceptance?

A named delivery, project, or operations owner should coordinate it, while sales, design, procurement, field, and qualified reviewers retain ownership of their respective decisions.