Quick Answer
After a solar proposal is accepted, hand over the accepted revision, customer decision, price and scope basis, open conditions, evidence sources, requested dates, and ownership of the next checks. Acceptance authorizes the agreed next stage; it does not turn preliminary assumptions into field-ready facts.
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.
Direct Answer
After acceptance, transfer the exact accepted revision, the chosen option, all commercial and technical assumptions, evidence sources, open conditions, requested dates, and named next owners. Treat the proposal as a record of the customer decision, then verify what must be verified before procurement, permitting, technical release, or field work.
Acceptance Answers One Question Clearly
The project team should first state what acceptance means in the organisation’s process. Usually it means the customer has agreed to proceed with a described option and its stated terms. 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.
| Item | What delivery needs to know | Why it belongs in the handoff |
|---|---|---|
| Accepted proposal | Revision, date, and the option selected | Confirms the customer decision |
| Commercial basis | Price, included work, exclusions, and conditions | Stops scope being inferred from a sales discussion |
| Design basis | Linked layout/model revision and confidence level | Shows what technical output supported the proposal |
| Evidence register | Source materials and their status | Tells the team what was verified or assumed |
| Open-condition list | Required checks, owner, due date, release boundary | Converts conditions into managed work |
| Customer commitments | Requested timing, access notes, decision objectives | Gives operations relevant context without treating it as proof |
| Change route | How new evidence or substitution reaches the customer and project records | Prevents silent divergence |
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.
| Proposal condition | Delivery handoff action |
|---|---|
| Preliminary roof layout | Schedule and define survey checks before final layout release |
| Estimated consumption basis | Request current records or interval data before final financial discussion where relevant |
| Equipment subject to availability | Confirm availability; route any substitute through design and customer-change review |
| Electrical work assumed | Obtain site evidence and appropriate review before final configuration or scope confirmation |
| Utility process pending | Identify current project instruction, owner, and deadline before committing an operating or schedule assumption |
Clear conditions do not weaken a sale. They give the customer a predictable next step and give delivery an honest record. Avoid messaging that turns an indicative production estimate, completion date, or approval expectation into a promise.
Connect the Customer Proposal to the Next Project Stage
Explore how SurgePV brings solar design, Shadow Analysis, generation and financial modeling, and Solar Proposals into a connected workflow while your team controls handoffs and release decisions.
Book a DemoUse an active sales-to-delivery question in a live walkthrough.
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.
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 detail reduces two kinds of delay. 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. A connected Solar Proposals workflow can make the customer-facing version easier to locate; 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:
- What did the customer accept, and which revision is controlling?
- What can proceed immediately, and what is conditional?
- Which project facts are confirmed, which are assumptions, and which require evidence?
- Who owns each open action and when does it need to be complete?
- 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. It is much easier to change a schedule or ask for information at kickoff than after materials, crews, and customer expectations have moved ahead.
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
- Define what proposal acceptance authorizes in your workflow and what it does not.
- Require the accepted revision, open conditions, evidence status, and next owners in every delivery handoff.
- Reconcile material changes before a customer decision becomes a procurement or field instruction.
Ready to Connect Solar Sales and Delivery Work?
Book a free SurgePV demo to explore connected Solar Designing, Shadow Analysis, generation and financial modeling, and Solar Proposals.
Book a Free DemoFrequently Asked Questions
What should happen after a solar proposal is accepted?
Preserve the accepted revision and customer decision, then assign the open conditions, evidence requests, and reviews required for the next project stage. Acceptance should be connected to an accountable delivery handoff rather than treated as a complete technical release.
Does proposal acceptance mean the design is ready for installation?
Not necessarily. The project may still require survey, technical, utility, authority, procurement, or field checks. The proposal and handoff record should identify the conditions that control later releases.
Who owns the handoff after solar proposal acceptance?
A named delivery, project, or operations owner should coordinate the handoff. Sales, design, procurement, field teams, and qualified reviewers retain ownership of decisions within their responsibilities.
