6 Shading Communication Mistakes That Cost Trust

A customer sees one proposal labeled “no shade,” then receives a revised layout after a site visit identifies a tree. That is an illustrative communication problem, not a reported customer case. The issue is the unexplained change between the earlier claim and the current evidence.

Shading is hard to communicate because the physical event is visible while its modeled energy effect is not. A buyer can see a shadow in a photograph. They cannot see the resource data, time steps, geometry, electrical configuration, or model assumptions behind an annual result. The project team must build that bridge without hiding uncertainty or drowning the buyer in settings.

This guide gives solar sales, design, and customer-experience teams a shared method. It is not an engineering standard or a promise about any site.

Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

Trust starts with one shared shade record

Before polishing customer language, establish one project record that design and sales both use. It should contain the imagery and observation dates, current site photographs, roof and obstruction geometry, vegetation treatment, array revision, model inputs, equipment configuration, output version, and unresolved questions.

Google’s documentation for Solar API data layers separates imagery, surface models, building masks, and solar-flux information. That separation is a useful reminder: a roof picture and a modeled solar result are not the same evidence. Identify which records support each customer statement.

Use status labels that survive handoff:

When those labels exist only in the designer’s private notes, sales communication will drift.

1. Saying “no shade” when the evidence supports less

“No shade” is attractive because it sounds definitive and takes no time to explain. It is also broader than most remote or model-based conclusions. Shade varies with solar position, roof geometry, nearby objects, vegetation, and the defined analysis period. Small objects or distant horizon features may be absent from the available source.

Replace binary wording with an evidence-bound statement. For example: “The preliminary remote model did not identify a material shading constraint on the proposed array area; current field evidence and final geometry remain subject to review.” The exact words should match the work completed. Do not copy the sentence into every project.

A clear boundary tells the customer what the team has established and what the next check will resolve.

Set a sales rule: nobody may say “shade-free,” “fully clear,” or “guaranteed production” unless a current, retained claim record explicitly supports the exact language and responsible review permits it. In most projects, a narrower explanation will be more accurate.

2. Showing a color map without explaining what it represents

Shade graphics look authoritative because they turn a complex model into a surface the customer can scan. The problem begins when the legend, period, units, geometry, and interpretation are absent. Red may mean low solar access, a relative score, a selected-time shadow, or another metric. The customer sees severity without knowing the definition.

Every customer-facing shade visual needs a small interpretation card:

• What the colors or contours represent
• Which dates or period the model covers
• Which roof and surrounding objects are included
• Which source records define their geometry
• Whether vegetation is present, altered, or excluded
• Which design decision the visual supports
• Which limitation remains material

Sandia’s PV Performance Modeling Collaborative discusses shading, soiling, and reflection losses as distinct mechanisms within PV performance modeling. A color map should not encourage the customer to collapse every visible loss into “shade.”

Use the broader shading analysis workflow to keep the visual connected to the current roof and array model. Then give the buyer a sentence they can repeat accurately.

Wording examples for the proposal review

These are illustrative communication patterns, not customer testimonials or measured conversion results. Use a statement only when its evidence exists.

For a specific example of metric definition, Aurora’s shade-report documentation defines solar access using incident solar energy with and without shade. That vendor-defined resource metric is not automatically the percentage of AC electricity lost in a different system. Read the actual report legend and method instead of transferring a label across tools.

3. Translating visible shade directly into annual energy loss

A photograph of a shadow proves that shade existed at the place and time observed. It does not by itself establish an annual energy percentage. That outcome also depends on solar resource, duration, receiving-plane geometry, array placement, equipment behavior, electrical configuration, and the selected performance model.

Review the chain in order:

1. Confirm the physical obstruction and its geometry.
2. Confirm solar position and analysis period.
3. Confirm the current module layout.
4. Confirm equipment and electrical configuration.
5. Confirm resource and performance-model inputs.
6. Validate the calculation and bind the displayed result to the controlled run.

Sandia PVPMC’s mismatch guide explains that series-connected devices share current and parallel paths share voltage. Those electrical interactions help explain why visible shaded area and energy loss are different quantities. A customer-facing annual value needs the actual geometry, irradiance and electrical model, not a ratio of dark pixels in a photograph.

In customer language, distinguish “we observed,” “we modeled,” and “the model estimates.” Those verbs carry real status.

4. Hiding a preliminary assumption until the site visit

A remote proposal may be appropriate before field work. Presenting the remote output as settled can make a later site correction look like an unexplained reversal. State the planned verification before the customer relies on the preliminary result.

Tell the buyer what the remote stage can and cannot establish. Name the likely decision-changing items: roof dimensions, small obstructions, parapet or tree heights, access, roof condition, electrical details, surrounding horizon, or planned site changes. The actual list should come from the project, not a generic disclaimer.

The satellite-image shading guide explains why overhead imagery remains incomplete. Use that boundary early. “This image supports a preliminary array discussion; the site assessment will verify the marked roof and vegetation questions” gives the customer a predictable process.

The Department of Energy’s homeowner solar guide describes evaluation and site work within a broader United States solar process. Local and project-specific requirements still need their own current authority.

5. Letting sales and design use different definitions

Design may use “solar access” for a defined modeled metric while sales uses it as a synonym for “good roof.” One person may describe shade loss as a physical obstruction effect, while another folds in soiling and mismatch. A customer who hears both versions will reasonably question the entire analysis.

Create a small project vocabulary, not a giant corporate glossary. Define the terms that appear in the output:

Then reconcile scripts, proposal labels, CRM notes, and review records. The solar sales and design handoff is where these definitions should travel. A handoff that moves only the roof image leaves the interpretation behind.

6. Correcting the layout without explaining the change

New evidence can move modules, reduce usable area, alter the shade model, or change expected energy. Teams sometimes replace the proposal silently because they fear that explaining a correction will look incompetent. A silent replacement leaves the buyer without a reason for the changed layout. Keep the earlier record and explain which evidence or assumption changed.

Use a correction note with five elements:

1. New evidence: what arrived and when.
2. Prior basis: which assumption or record it replaces.
3. Design effect: what changed in geometry, array, or configuration.
4. Output effect: which energy, materials, price, or proposal values were rerun.
5. Next status: what is now supported and what remains open.

Do not over-dramatize a normal design refinement. Do not minimize a material one. “The site photographs confirmed a taller parapet than the remote model represented, so the array and production scenario were revised” is factual. Add the project-specific consequence only when the controlled output supports it.

The customer should receive one current revision and a plain explanation of why it supersedes the previous file.

Use proximity instead of disclaimer volume

Teams often respond to uncertainty by adding a page of legal-looking text. That page may be necessary for other reasons, but it does not help the buyer interpret a roof graphic or annual-energy figure if the relevant condition appears far away.

Put the material qualification beside the claim. A preliminary roof image should carry its source and status. A shade percentage should carry its metric, model run, and interpretation. A production value should state that it is modeled and identify the current project basis. A planned tree removal should be marked as planned, with responsibility and approval visible.

The FTC’s advertising FAQ says advertisers need evidence for express and implied claims and that qualifying information should be clear and close to the relevant claim. Fine print cannot contradict the main promise. This is United States guidance; obtain appropriate legal review for the actual offer and jurisdiction.

Use the plain-language guide to organize around the reader’s task. Plain language does not mean deleting technical conditions. It means choosing understandable words, defining the necessary terms, and placing information where the reader needs it.

What should a customer-facing shade explanation contain?

A customer-facing shade explanation should name the current evidence, distinguish observations from modeled conclusions, define any displayed metric, state the design decision it supports, expose unresolved items, and name the next verification step. It should also identify the current revision so the customer, salesperson, and designer are discussing the same roof, array, assumptions, and output together at the same time.

Put the decision and its material limits on the main proposal page, then retain supporting settings and source records for review. The customer should be able to distinguish an observed object, an assumed change, and a modeled consequence without reading every internal setting.

Use this blank record as a project template; the field descriptions are instructions, not unresolved article claims:

Customer-facing shade explanation record

Project and current revision: record the project identifier and revision

Evidence reviewed: list imagery, photographs, measurements, drawings, and dates

Current observation: describe what the evidence visibly establishes

Current modeled conclusion: describe what the controlled model supports

Metric shown: record the name, definition, period, and units

Design decision: state placement, exclusion, configuration, or evidence request

Assumptions still open: list each unresolved item

Planned site change: state none, or owner, permission status, and timing

Next verification step: name the specific record or review needed

Customer wording approved by: name the technical reviewer and presenter

Complete every applicable field before the proposal leaves the team. Write “none identified” only when someone checked; do not use a blank field to imply that no issue exists. If a statement cannot be traced to the technical record, remove it from the customer version or send it back for review.

Keep the record short enough to use during a call. The presenter should be able to point from each visible claim to one field, not hunt across chat messages and old files. If the customer asks for more detail, open the supporting model record rather than improvising an explanation. A disciplined project handoff meeting can make that review part of the normal release path.

The record is also a listening tool. Add a customer statement when it could change the analysis, such as planned vegetation work, a roof alteration, or an object missing from the imagery. Mark it as customer-provided until the team verifies it. The label prevents a useful conversation detail from silently becoming a modeled fact.

Before ending the discussion, ask the customer to describe the decision in their own words. This is not a test. It is a quick way to notice whether “preliminary,” “modeled,” or the displayed shade metric meant something different to them. Correct the misunderstanding in the current record while everyone is looking at the same revision.

How should sales explain a shading change after site verification?

Sales should explain a shading change by showing the new evidence, naming the earlier assumption it replaces, and tracing the supported effect into the layout, energy model, and proposal. Acknowledge any earlier communication gap. Give the customer one current revision, with unresolved effects marked for review rather than estimated during the conversation.

Design and the responsible reviewers should identify dependent outputs before sales presents the change. Release the updated layout, energy results, commercial values where affected, and customer files together. Keep the previous version in the history and remove it from active proposal links, meeting decks, and CRM attachments.

Illustrative workflow example, not a customer result: Site evidence identifies a parapet taller than the preliminary remote model assumed. Design revises the geometry and affected layout, then reviews the model outputs. Sales explains the new evidence and revised placement. Any production or price consequence remains pending until its calculation and required review are complete.

If a previous document presented an assumption as settled, acknowledge that error. Do not add a retroactive disclaimer or blame the customer for the difference. If the field check was an expected stage, point to the earlier preliminary status and show what the check resolved.

How can sales and design prevent their shading language from drifting?

Sales and design can prevent shading language from drifting by maintaining a short approved vocabulary, attaching customer statements to the current shade record, and reviewing every changed output before release. The designer owns the technical boundary, the presenter owns faithful explanation, and a named project owner reconciles conflicts before a proposal, email, or meeting introduces another version of the story.

Use a reconciliation table whenever a customer-facing shade statement changes:

Check the actual roof visual, caption, savings wording, attachments, and meeting notes against the same revision. When a customer asks about safety, code compliance, structural acceptance, equipment approval, finance, or a contractual guarantee, record the question and route it to the responsible qualified party. An approved vocabulary helps communication; it does not transfer professional authority.

Give the customer a comparison they can inspect

When shade drives a layout tradeoff, compare real options on a common basis. For example, one design may avoid a roof area and reduce array size, while another uses more area with a different modeled shade profile. Hold equipment, resource, tariff, and other relevant inputs consistently if the purpose is to isolate the layout decision.

Do not show an optimistic option that assumes future tree work beside a current-condition option without flagging the difference. The table may look neat, but it compares a present fact with an uncommitted future event.

Train with objections that deserve real answers

Scripts become brittle when they teach staff to deflect. Use common customer questions as review exercises.

“Why are there no panels on this roof plane?” should lead to the geometry, shade, access, electrical, structural, scope, or customer objective that controls the decision. If the team does not know, say the item is under review.

“Will that tree reduce my savings?” requires more than yes or no. Explain whether the tree is observed and modeled, how the current energy scenario treats it, what financial inputs connect energy to savings, and whether any vegetation work is assumed.

“Why did the system size change after the visit?” should lead to the new evidence and controlled revision. Do not answer with “the software updated it” because software is not the source of the changed site fact.

The best response is often shorter after the evidence is organized.

Audit trust failures without inventing a metric

Review actual project records for signs that communication failed:

• The customer received two shade explanations for one revision
• A salesperson promised tree work outside the documented scope
• A proposal used “no shade” while the model contained obstructions
• The site visit changed the design without a revision note
• The shade visual lacked a legend or time basis
• Annual energy changed but the customer image did not
• A technical appendix defined a different metric from the sales page

For each event, record the source, project stage, document, owner, and corrective control. Do not publish a “trust improvement percentage” unless a valid measurement design supports it. Internal quality learning is valuable without being turned into a marketing statistic.

The control may be a better label, required field, release gate, shared definition, or automatic document reconciliation. Training alone will not fix a workflow that lets old outputs remain active.

Handle disagreement without staging certainty

Customers may bring another proposal with a different shade score, layout, or production result. Do not respond by calling the other output wrong from the number alone. First normalize the question. Ask what each metric means, which imagery and geometry were used, how vegetation and horizon objects were treated, which equipment and configuration were modeled, and whether the analysis periods match.

If the bases cannot be reconciled, say so. Offer a controlled comparison or identify the field evidence needed. Different tools can produce different results because inputs and methods differ, and choosing the higher production number is not a technical review.

This posture can feel slower in a sales conversation, but it gives the customer a decision they can inspect. The team earns credibility by showing where agreement exists, where assumptions differ, and which observation can resolve the gap. Certainty staged for one meeting rarely survives the project.

Keep the comparison record even when the customer chooses another provider. It gives the team an honest account of what was known at the time and prevents later staff from repeating an unsupported explanation. If better evidence arrives, update the technical conclusion before reusing any part of the earlier customer message.

Frequently Asked Questions

How much shading detail should a customer see?

Show enough detail to explain the design choice, modeled consequence, evidence quality, and open question. A customer rarely needs every technical setting on the main proposal page, but they should be able to locate the source date, major modeled objects, scenario basis, and reason a field check or design revision may still be required.

Should a salesperson say that a roof has no shade?

Avoid a universal no-shade statement. Name the evidence and time basis instead, such as no material obstruction identified in the current remote model for the proposed area, pending site verification. Shade changes with solar position and site conditions, so the claim should not extend beyond the observations and analysis actually completed.

How should a team explain a post-survey shade change?

Show the new evidence, identify which earlier assumption it replaces, explain the affected layout or model input, and issue a controlled revision across all dependent outputs. Do not blame the customer or pretend the prior estimate never existed. A visible correction process can preserve trust when the preliminary status was communicated from the start.

Can a shade percentage be shown without the model assumptions?

A percentage without a defined metric, period, geometry, resource basis, equipment configuration, and model is easy to misread. Put a plain-language interpretation beside it and retain the technical basis for review. If the team cannot trace the value to current project inputs and a validated calculation, do not present it as fact.

Who owns the customer-facing shading explanation?

Assign one project owner to reconcile the technical basis and customer wording, while keeping approval with the responsible specialists. Designers establish what the evidence and model support. Sales explains that conclusion without strengthening it. Changes should update the shared record before anyone presents a new roof image, energy value, or proposal.