Mutual Action Plan Checklist for Complex Solar Deals

A complex solar deal can look active for months without becoming more decidable. The seller sends updates. Design produces another option. The facilities contact asks finance for feedback. Procurement waits for a scope it can compare. Every participant appears busy, yet no one can name the next decision, the evidence required, or the person authorized to make it.

A mutual action plan can help clarify that ambiguity when both sides review and accept their stated actions. It is not a seller’s close plan renamed for the customer. It is a shared record of the buyer’s decision process, seller deliverables, technical and commercial evidence, external dependencies, responsibilities, target events, and conditions that would pause or end the work.

This guide is operational, not legal, contract, accounting, finance, tax, lending, securities, procurement, engineering, safety, utility, permitting, insurance, or project-management advice. Qualified owners must approve the live plan, definitions, commitments, dates, and customer-facing claims.

The commercial opportunity ranking guide helps decide where to spend pre-sales resources. The multi-stakeholder proposal checklist focuses on the proposal itself. This page owns the shared path from qualified opportunity to a controlled buyer decision.

What is a mutual action plan for a solar deal?

A solar mutual action plan is a customer-visible record that connects one defined buying decision to the participants, evidence, technical and commercial gates, responsibilities, target events, external dependencies, risks, changes, and stop conditions needed to reach it. Each line should answer who does what, why it matters, what proves completion, and which decision becomes possible next.

Begin with the terminal decision. “Move forward” is too vague. The buyer may be deciding whether to authorize a site study, approve a preferred technical option, release a procurement process, accept commercial terms, select a financing route, authorize contract signature, or stop the opportunity. Those decisions require different evidence and participants.

Separate the plan from the seller’s CRM activity. “Follow up Friday” may be useful internally, but it does not describe a buyer milestone. “Facilities owner supplies accepted interval-data file so design can compare the approved load boundary” connects an owner, record, purpose, and next decision.

NASA’s technical-planning guidance applies to NASA systems work, not commercial solar selling. It describes defining technical effort within cost, schedule, and risk constraints, identifying roles and resources, and synchronizing technical plans with project plans. The transferable discipline is to connect work, owners, constraints, and evidence instead of treating a date as the plan.

The mutual action plan should distinguish four clocks. The buyer’s internal decision path may have board, finance, legal, facilities, or procurement gates. The seller’s technical path may require site, design, modeling, estimating, and review work. External organizations such as utilities, authorities, lenders, or insurers control their own events. A later delivery plan begins after different commitments. Do not collapse the clocks into one optimistic timeline.

What evidence is needed before the plan becomes mutual?

Before calling the plan mutual, confirm the intended decision, customer sponsor, decision authority, affected stakeholders, business and site context, accepted project identity, current technical and commercial records, decision criteria, procurement and approval path, external dependencies, meeting and document permissions, seller resource owner, and customer acceptance of the plan’s current scope. Missing authority or purpose keeps the plan preliminary.

The first conversation should test whether shared planning is useful. A prospect asking one educational question does not need a multi-page plan. A facilities leader coordinating finance, ownership, procurement, technical review, and executive approval may benefit from a controlled view of the work.

Collect only the records needed for the next decision. Useful inputs can include:

• legal customer entity, property or portfolio identity, and decision being considered;
• sponsor, economic or budget owner, facilities owner, finance, procurement, legal, sustainability, operations, executive approver, and other participants;
• current site, roof, land, electrical, load, tariff, equipment, access, and customer-supplied records;
• design, shading, yield, financial, bill-of-materials, proposal, contract, and revision states where applicable;
• decision criteria, comparison method, required approvals, procurement rules, and authorized signatory path;
• ownership, lease, lender, insurer, authority, utility, incentive, or other external questions requiring qualified review;
• seller resources, specialist needs, confidentiality and data-access limits, meeting cadence, and escalation route;
• known stop conditions such as absent authority, incompatible scope, unresolvable risk, unsupported claim, or no shared next decision.

The DOE’s homeowner solar guide is United States consumer guidance, not commercial procurement guidance. It says there is no universal solar solution and discusses property suitability, production estimates, installers, contracts, and financing questions. The useful lesson is limited: solar buying contains distinct decisions, and a plan should name which one the current evidence supports.

Decision authority must be evidenced, not inferred from enthusiasm. A sponsor can coordinate the process without being able to approve budget or sign. A facilities expert can validate site information without accepting financial terms. A procurement owner can control the selection route without approving engineering. Record the role each participant actually holds.

Use a plan-status boundary:

1. Seller draft. The seller has mapped a hypothesis but the customer has not accepted the participants, decision, or work.
2. Customer-reviewed. The customer has corrected the path and owners, with open questions visible.
3. Mutually accepted. The relevant parties accept the current actions, evidence, target events, and change rules.
4. Superseded or closed. A successor, deferral, stop, or final decision has replaced the active plan.

Do not label a seller draft as mutual in the CRM.

Record disagreement without forcing consensus

A shared plan does not require the customer and seller to agree about every option. It requires both sides to see which decision is open, what evidence each side accepts, where interpretations differ, and who has authority to resolve or preserve the difference.

Create a disagreement record when one party rejects an input, criterion, assumption, target event, or responsibility. Capture the exact statement, affected milestone, evidence offered, owner, permitted decision route, and next review trigger. Do not summarize a material objection as “customer concern” or “seller to clarify.” The wording should let a later reviewer understand the disputed point without reconstructing a meeting from memory.

Some disagreements should narrow the work. If the buyer will not authorize access to a required load record, the seller can propose a more limited output that does not depend on it. If the seller cannot substantiate a requested production, savings, schedule, or approval claim, the plan should show the unsupported request and the safe alternative. Do not convert an evidence gap into a vague assumption to keep a milestone green.

Other disagreements should stop the opportunity. The parties may discover incompatible commercial terms, absent decision authority, unacceptable data conditions, a project type outside competence, or a risk no responsible owner will accept. A stop condition protects both parties from performing more work merely because a plan exists.

Keep internal and shared risk views separate. The seller may have internal resource, margin, probability, or negotiation information that does not belong in the customer-visible record. The shared plan should contain only the risks and evidence needed for joint decisions, using reviewed permissions and confidentiality rules. Link internal controls without copying sensitive notes into the customer view.

The financial and technical gates for a commercial solar pipeline provide an adjacent internal-control view. Use those gates to inform seller readiness, then translate only the mutually relevant decisions and evidence into the shared plan.

How should the mutual action plan be built?

Build the plan by defining the terminal decision, mapping stakeholders and authority, working backward through decision gates, attaching required evidence, assigning one owner per action, separating controlled work from external events, agreeing target events and confidence, recording risks and stop conditions, approving the current version, and reviewing actual changes. Every milestone should enable a named next decision.

Use this ten-step workflow:

1. Name the terminal decision. State the entity deciding, exact authorization, permitted scope, evidence standard, and event that proves the decision.
2. Map participants and authority. Identify sponsor, technical, financial, procurement, legal, executive, signatory, seller, and external roles. Separate contributors from approvers.
3. Work backward through gates. Ask which decision must occur immediately before the terminal decision, then repeat until the current state is connected to it.
4. Attach evidence to every gate. Name the record, source, version, owner, acceptance rule, reviewer, and expiry or refresh trigger.
5. Assign actions at the interface. Identify the sender, receiver, required inputs, expected output, purpose, rejection rule, and customer-visible next step.
6. Classify dependencies. Mark seller-controlled, customer-controlled, shared, or external. Do not assign an external decision to a seller owner.
7. Set target events honestly. Record source, confidence boundary, assumptions, scheduling owner, and event that changes the date. Avoid unsupported guarantees.
8. Record risks, exceptions, and stop conditions. Name how missing evidence, changed scope, disagreement, inactivity, or external constraints alter the plan.
9. Obtain mutual acceptance. Review the current version with the people accountable for its near-term actions. Preserve disagreements and conditions.
10. Run the review loop. Compare planned and actual events, create successor versions for material changes, and decide whether to proceed, revise, defer, or stop.

NASA’s interface-management guidance discusses defining interface responsibilities and controlling information and changes across interfaces. It does not validate a sales method. The analogy helps identify the interfaces to inspect: sales to design, facilities to finance, buyer to procurement, or project team to an external reviewer.

Illustrative example: a commercial rooftop decision

Illustrative workflow, not a customer case, schedule, probability, forecast, savings result, contract, or project outcome. A facilities sponsor wants a commercial rooftop proposal for an executive capital review. Sales originally writes “proposal presentation” followed by “contract signature” in the plan.

Customer review reveals missing gates. Finance needs an accepted scenario and the source of utility inputs. Facilities must confirm the roof area and planned roof work. Procurement needs a comparison format and supplier records. Legal will review commercial terms only after a preferred scope exists. The authorized signatory is not the sponsor.

The plan is rebuilt around evidence. The near-term action is not signature. It is acceptance of the site and load record so design can produce a bounded comparison. Each later gate names its owner, evidence, dependency, and rejection condition. An external utility question appears as an external event rather than a seller promise.

When the buyer changes the preferred equipment basis, the seller creates a successor plan and reopens the affected layout, yield, materials, financial, and proposal reviews. The original target dates remain visible. No probability or outcome is invented.

How should decisions, dates, and changes be governed?

Govern the plan with stable identities, versioned records, explicit decision criteria, accepted owner changes, date confidence, predecessor evidence, and a complete revision history. Preserve missed and superseded events rather than rewriting them. A changed layout, equipment set, load boundary, tariff, financial input, commercial term, stakeholder, or approval path should reopen every affected milestone and customer-facing output.

NASA’s configuration-management guidance describes baselines, visibility and control of changes, version distinction, and consistency between a product and its information. The source applies to NASA work. The transferable control is to keep the deal plan compatible with the project records it references.

NASA’s decision-analysis guidance discusses identifying alternatives, decision criteria, evaluation methods, evidence, and recommended alternatives in a formal technical context. It does not approve a buyer’s procurement method. It supports the narrow principle that “choose an option” needs declared alternatives, criteria, evidence, and an authorized decision owner.

Do not turn the mutual action plan into a pressure device. The FTC’s advertising guidance says objective claims need evidence and advertising must be truthful and non-deceptive in the United States. The source does not regulate every deal-plan statement, but it supports a boundary: customer-facing claims about timing, performance, savings, price, or approval should not exceed available evidence.

Set a review cadence around events rather than a universal meeting frequency. A near-term technical handoff may need a short review after evidence arrives. A board decision may wait on a scheduled meeting. An external utility event may have no meaningful update until the authority acts. Record the next review trigger and avoid meetings that only produce “still waiting.”

Copy-ready mutual action plan checklist

The checklist should live where both parties can review the permitted parts without exposing internal notes, unrelated customer data, or confidential records. Keep seller strategy separate from the mutually accepted plan. A customer-visible record should not become a disguised forecast score.

Where can software support the action plan?

Software can connect current technical and customer-facing records to the milestones that depend on them. It can preserve project identity, versions, owners, and changes. It cannot establish decision authority, make customer actions binding, approve technical or financial evidence, control external organizations, create a contract, or guarantee timing. The people and institutions named in the plan retain their decisions.

Evaluate SurgePV design outputs and proposal preparation for the project evidence your milestones require. Confirm actual exported references, supported calculations and manual review steps. A design output does not create a native shared deal plan, mutual acceptance or an external approval.

Test whether a milestone links to the current record. Supersede a layout, change the equipment basis, remove an input, revise the proposal, or alter the financial scenario. Check the affected plan rows through your chosen process; do not assume the software marks them for review automatically. An old completed checkbox should not make an incompatible proposal current.

Also test access and exports. The buyer may need a shared milestone view but not the seller’s internal probability, margin, negotiation, or approval notes. Define roles, field visibility, download content, audit history, retention, and revocation. A shared spreadsheet is easy to create; a controlled shared record is harder and more useful.

The plan earns the word mutual when each side can correct it, accept its own actions, see the evidence boundary, and stop unsupported commitments from appearing as settled facts. Until then, it is a seller draft.

Frequently Asked Questions

When should a solar mutual action plan be created?

Create the plan after the buyer and seller can name the decision, intended outcome, main participants, known evidence, and next meaningful gate. Do not force one onto an early inquiry with no shared work. Start small, obtain customer agreement to the current version, and expand only as technical, financial, procurement, and approval paths become observable.

Is a mutual action plan a project schedule?

No. It is a shared decision and evidence plan for reaching a defined commercial outcome. A delivery schedule begins from different commitments and authority. The action plan may record target events and dependencies, but it should not promise permitting, interconnection, engineering, financing, procurement, installation, or approval dates that the parties cannot control or substantiate.

Who should own milestones in a complex solar deal?

Assign one accountable owner to each decision, record, or action, while naming required contributors and approvers separately. Use a real person or controlled role that can accept the obligation. Avoid “buyer,” “seller,” or “team” when several participants exist. External authorities, utilities, lenders, and insurers own their decisions and should not be assigned seller-controlled deadlines.

What happens when the solar project scope changes?

Create a controlled successor version. Record the change source, affected design and commercial records, decision owner, technical and financial revalidation, customer effect, approval, and revised dependencies. Preserve the original plan. Do not silently move dates or keep an obsolete proposal, equipment basis, production model, or savings scenario attached to the active decision path.

Where can SurgePV support a mutual action plan?

SurgePV can support 3D roof modeling, array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. Deal owners must still govern stakeholders, permissions, customer decisions, contracts, financing, procurement, engineering, authorities, utilities, schedules, and approvals. Software can support evidence; it cannot make the plan mutual or guarantee an outcome.