Quick Answer
Handle a solar customer change request by recording the request in the customer's own terms, identifying the project revision and decision it affects, separating a question from an approved change, assessing the relevant scope and technical implications through the right owners, and returning with a clear written outcome. Do not promise a price, schedule, or performance result before the change has been reviewed.
A customer change request is a moment of trust, not a reason to defend the original proposal. People reconsider equipment, aesthetics, timing, access, budget, backup needs, or site priorities as a solar project becomes more real. The operational problem begins when a casual request is treated as an instruction before the team knows what it changes—or when the request disappears between sales, design, purchasing, and the customer.
This desk-research guide is for installers and EPCs. It does not determine contractual rights, technical suitability, code compliance, equipment compatibility, financial outcomes, or approval requirements. Those depend on the project, agreement, current requirements, and appropriate review. It describes a communication and record method that keeps a customer request connected to the project decision it may affect.
Direct Answer
Receive the request without promising the outcome. Record what the customer wants, why it matters to them, when it was made, and which current project record it may change. Then route the request for the right scope, technical, schedule, and commercial review. Communicate an approved, declined, or information-needed outcome in writing, with the new revision and next action clear.
Why Small Requests Can Move a Large Project Basis
“Can we move the panels?” may mean a visual preference, but it can also affect available area, shading treatment, quantities, access, mounting approach, electrical configuration, customer expectation, or site process. “Can we add a battery?” may be an exploratory question rather than an instruction. “Can we install next month instead?” may depend on equipment, site access, utility, and crew availability.
The right response is not to make every question feel difficult. It is to separate acknowledgment from commitment. Thank the customer, restate the request accurately, explain what the team will review, and give a realistic next update. That approach avoids both an instant refusal and an unsupported promise.
The U.S. Department of Energy Solar Energy Technologies Office offers broad solar information, but it cannot decide a project-specific change. An individual request needs the current project basis, relevant documents, and the people responsible for the affected decision.
Capture the Request in the Customer’s Words
Begin with a record that preserves what the customer actually asked for. Do not translate it immediately into an internal solution. A customer may say they want “more backup,” while the project team needs to clarify whether they mean a different critical-load objective, longer duration, a broader outage scenario, or a concern about a particular appliance. The clarification is part of the work.
| Record field | Why it matters |
|---|---|
| Customer request | Prevents internal interpretation from replacing the original need |
| Reason or objective | Helps the team evaluate options, not only the first stated solution |
| Current project revision | Identifies the proposal, design, or scope being changed |
| Timing | Shows whether the request affects a pending activity or customer decision |
| Source | Email, meeting note, call summary, or other identifiable record |
| Requested response | Clarification, option, revised proposal, timing discussion, or technical review |
Send a short confirmation after a phone conversation. “You asked us to assess moving the proposed array away from the front roof; we will review the effect on the current layout and proposal before confirming options.” This gives the customer a transparent expectation and gives the team a controlled starting point.
Sort the Request Before Routing It
Not every request is the same type of work. A simple classification prevents sales, design, and operations from treating every item as urgent in the same way.
| Request type | First question |
|---|---|
| Clarification | Is the customer asking what the current proposal already includes? |
| Information request | Can the team answer from the current approved record? |
| Configuration request | Would location, equipment, capacity, or operating objective change? |
| Scope request | Is the customer asking for work, service, or responsibility outside the current basis? |
| Schedule or access request | Does the timing change affect site, equipment, crew, or other dependencies? |
| Commercial request | Does the customer need a revised price, assumptions, or decision document? |
One request can fit several categories. That is useful information, not a failure of the form. It signals that the answer requires coordinated review rather than a single-person response.
Keep Customer Decisions Connected to the Current Project Record
See how SurgePV supports teams as they connect Solar Designing, Shadow Analysis, generation and financial modeling, and customer-facing Solar Proposals.
Book a DemoUse an active project question in a live walkthrough.
Identify What the Request Can Change
The review should be proportionate to the request, but it must consider the project record rather than only the customer message. Ask whether the change could affect the following.
- The current layout, equipment selection, quantities, or technical basis.
- Modeling inputs, production estimates, financial scenarios, or assumptions shown to the customer.
- Proposal scope, exclusions, price, timing, or customer responsibilities.
- Procurement, equipment availability, site access, crew planning, or field package.
- Existing approvals, submissions, documents, or the need for qualified review.
Do not answer these questions through a generic checklist alone. The project context controls. A request that is purely visual in one project can affect a material constraint in another. The record should name the potential effect and the person who will determine it.
Give Each Team a Clear Role
Customer change handling becomes frustrating when everyone assumes someone else will respond. A sales or customer owner may acknowledge the request and explain the next update. A designer may assess layout or input changes. Procurement may confirm availability and commercial implications. A project manager may coordinate schedule and document distribution. Technical or qualified review may be needed for questions outside the normal workflow.
The customer should not need to understand this internal map. They need one accountable contact and a clear response time. Internally, the record should identify the decision owner and the reviewers required. “Design is looking at it” is not enough when the request also changes quoted scope or procurement timing.
Separate an Option From an Approved Change
Teams often generate options to help a customer decide. An option is not automatically the new project basis. Label it clearly: indicative alternative, subject to listed inputs, proposal revision for review, or approved change under the relevant process. The label should match the evidence and decision stage.
The National Renewable Energy Laboratory’s photovoltaics resources reinforce a basic modeling lesson: outputs depend on defined inputs. Customer-facing scenarios should therefore show the relevant assumptions rather than presenting a revised number or layout as a promise detached from its basis.
When the customer selects an option, record what they selected, which revision it relates to, which conditions remain, and what changes next. Then update the artifacts that need the new basis. A customer confirmation by email is not a substitute for design, procurement, or field updates where those updates are required.
Communicate Timing and Price With Care
Customers often ask whether a change will be “quick” or “free.” Give a helpful answer without committing beyond the review. Explain the dependency: the team will assess availability, project effects, or scope and return with a revision if needed. If the change is accepted, state the result in a controlled customer communication rather than relying on a verbal summary.
Avoid presenting estimated production, savings, approval, equipment availability, or installation timing as guaranteed outcomes. A good update names what is known, what is being confirmed, and the next expected decision. That is more credible than a fast answer that later needs to be reversed.
Distribute the Outcome to Everyone Who Can Act on It
After the decision, check the affected project artifacts. The design record, BOM, procurement instruction, schedule, field package, customer proposal, and closeout plan may not all need change, but the team should decide that intentionally. Record who received the current direction and which former version is superseded or remains reference-only.
A connected Solar Proposals workflow can make it easier to keep customer-facing output tied to the project basis. The team still needs to control the revision and make sure a request accepted in a customer conversation is not lost before it reaches delivery.
Review Patterns Without Blaming Customers
Repeated requests can reveal a useful process insight. Customers may keep asking for battery options because early discovery did not clarify resilience objectives. They may ask to move an array because the proposal does not make the roof plan easy to understand. They may ask for schedule changes because the installation communication arrives too late.
Track categories, not personal judgments. Use the pattern to improve questions, proposal visuals, expectation setting, and review timing. Do not treat a customer who asks a question as a source of scope creep by default. Good change handling is a way to surface the decision the project needed to make anyway.
Keep the request record linked to the project even when the answer is “no change.” A clarification that confirms the original scope is still useful context for the next customer conversation. It shows that the question was heard and that the team deliberately retained the current basis rather than overlooking the request.
Practical Next Steps
- Acknowledge every material request in writing, with the customer objective and current project revision stated.
- Route the request by its potential design, scope, schedule, commercial, and documentation effects.
- Issue a clear outcome: information provided, option for review, approved revision, declined request, or evidence still needed.
Make Customer Choices Easier to Carry Through the Solar Workflow
Book a free SurgePV demo to explore connected Solar Designing, Shadow Analysis, generation and financial modeling, and Solar Proposals.
Book a Free DemoExplore Solar ProposalsFrequently Asked Questions
What counts as a solar customer change request?
It is a request that may alter the agreed project basis, including equipment preference, array location, battery objective, timing, site access, financial assumption, or an additional service. A question is not a change until the team understands its effect and approval path.
When should a solar installer provide a revised proposal?
Provide a revised proposal when an approved customer request changes the commercial basis or information the customer needs to rely on. The new version should state what changed, its assumptions and conditions, and how it relates to the earlier proposal.
Can a sales representative approve a requested solar change on a call?
Only within the authority and defined project process applicable to that decision. A representative can acknowledge the request and set the next step, but should not promise a technical, price, schedule, approval, or performance outcome before responsible review establishes the current basis.
