The Before-and-After Solar Project Story Checklist

A “before” roof photo and an “after” array photo show that something changed. They do not explain what the customer needed, what the installer promised, which work was included, why the design changed, whether the project reached its intended status, or where a savings number came from.

When the story includes a customer-facing document, the Solar Proposals page provides SurgePV product context. The project record, rather than the product page, must substantiate the story’s scope and outcome.

A useful project story is a traceable decision record written for a future buyer. It gives enough context to understand the problem, enough evidence to believe the described work occurred, and enough qualification to avoid turning one project’s circumstances into a universal promise.

Use this checklist before capture, during delivery, and before publication. If the marketing team begins only after installation, many of the permissions, baseline records, and decision notes will already be missing.

Check 1: define the story’s decision and audience

Start with what the reader should learn, not with the most dramatic image. A homeowner replacing a roof has a different question from a facility manager coordinating solar with operating constraints. A sales leader may care about proposal clarity; a designer may care about how site evidence changed the layout.

Write a job statement: “When a reader faces ______, this story helps them decide ______ by showing ______.” Then identify the evidence needed to prove that narrow lesson.

Avoid using one project to support every marketing claim. A story about coordinating roof work should not become proof of energy savings, installation speed, financing value, workmanship, and customer satisfaction unless each separate claim has retained support and permission.

The Department of Energy homeowner solar guide covers site suitability, bids, financing, contracts, and installer evaluation. Choose the project decision that maps to the reader’s actual stage. Do not force an early educational story into a purchase testimonial.

Name the commercial relationship. The subject may be a customer, partner, employee, demonstration property, or composite illustration. Those categories carry different implications. A reader should not have to infer who paid whom or who controlled the publication.

Check 2: obtain permission for the intended use

Permission needs scope. A customer may agree to an internal photograph and not to a homepage advertisement. A facility may permit roof images but not its name, production data, address, or operating details. A person may agree to a quote but not to paid social advertising.

The release should address the subject, assets, identifiable people and property, claims, channels, territories, duration, edits, withdrawal process, and any consideration. Obtain qualified legal and privacy review for the company’s actual form and jurisdictions.

Keep consent separate from project delivery. A customer should not be surprised that routine project photographs became marketing. If publication permission is optional, present it as optional. Record who granted it and whether that person had authority over the property, people, and information involved.

Plan for change. Staff leave, sites are renovated, equipment is replaced, and customers withdraw permission where applicable. Attach an expiry or review date and a contact route. The content owner should be able to locate every live use of an asset.

Do not assume that removing a name makes a project anonymous. A recognizable building, precise roof view, signage, metadata, address fragment, utility account, or unusual operating detail can identify the subject. Review the assembled story, not each asset in isolation.

What evidence must be captured before a solar project story begins?

Before work begins, capture the customer’s decision in their words, the project’s starting status, dated source assets, agreed scope, known constraints, responsible parties, publication permissions, and the claims the story may later examine. Record viewpoints and asset provenance now. Without a true baseline, marketers can describe the completed project, but they cannot honestly reconstruct a before-and-after comparison from memory later.

The baseline should match the intended lesson. A roof-coordination story needs the planned roof work, current design basis, and decision owner. A usage story needs identified periods, units, meter scope, and known operational changes. A proposal-clarity story needs the actual document version and the question the customer was trying to resolve.

Copy-ready pre-project evidence record

STORY CANDIDATE AND READER DECISION:
CUSTOMER OR SUBJECT RELATIONSHIP:
CUSTOMER'S QUESTION IN THEIR WORDS:
PROJECT STATUS AND DATE:
AGREED SCOPE AND EXCLUSIONS:
KNOWN CONSTRAINTS AND OPEN REVIEWS:
BASELINE PHOTOGRAPHS OR DOCUMENTS:
ASSET SOURCE, VIEWPOINT, AND ORIGINAL FILE:
DESIGN, PROPOSAL, OR MODEL REVISION:
PERMISSION GRANTED AND PERMITTED CHANNELS:
CLAIMS THE RECORD MAY SUPPORT:
CLAIMS THE RECORD DOES NOT SUPPORT:
CHANGE-LOG OWNER:
FINAL CAPTURE TRIGGER:
PUBLICATION REVIEW DATE:

Capture original assets before creating crops, annotations, or marketing captions. Store the source and publication derivative with a traceable relationship. The solar stock-photo replacement guide explains why provenance, permission, truth status, captions, and accessibility treatment need one asset record.

Do not ask field staff to create marketing evidence during unsafe or sensitive work. The planned viewpoint must respect site access, working-at-height rules, electrical boundaries, customer operations, privacy, and the competence of the person capturing it. A missed photograph is preferable to a staged hazard.

Record what “before” means. It may be before design review, before roof work, before installation, or before a corrected proposal. Those are different baselines. A story that switches baselines between its title, photographs, and outcome can create a false impression even when every image is genuine.

The project may never become a story. Permission can change, evidence may remain incomplete, or the lesson may duplicate existing material. The record still helps project operations, but marketing should not treat early capture as a promise to publish.

Check 3: capture a dated and honest baseline

The “before” state should describe the decision condition, not make the site look worse for drama. Record the date, source, viewpoint, project stage, known limitations, and relevant facts. Preserve original files and hashes or identifiers under the company’s evidence policy.

A baseline may include:

Do not stage a false “before.” Removing normal context, choosing a misleading angle, or comparing different seasons can create an exaggerated improvement. Match viewpoints when visual comparison matters and disclose material differences.

Capture why the baseline mattered. “The customer wanted solar” is thin. “The project team needed to determine whether planned roof work should occur before a later design release” identifies a decision without inventing an outcome.

Check 4: document the actual scope and change trail

List what the company contracted or agreed to do, what another party did, what remained excluded, and which work changed. Marketing language should not take credit for engineering, roofing, utility, financing, or other services provided by separate parties.

Maintain a change record with the original assumption, new evidence, decision, owner, date, and affected outputs. If a survey changes geometry, identify whether layout, shading, electrical work, bill of materials, energy model, proposal, and schedule were reviewed.

This is where a project story can offer real information gain. Readers learn how a decision moved, not merely that panels appeared. Explain one meaningful conflict: remote imagery versus site observation, proposed equipment versus available equipment, customer objective versus roof use, or initial usage record versus a later load change.

Do not invent smoothness. If the record shows a pause or revision, explain it calmly. A credible story can say that the first concept was replaced after better evidence arrived. That demonstrates control more honestly than claiming a flawless process.

Use a solar design review checklist to identify which release decisions belong in the retained record. The story should quote the project evidence accurately, not reconstruct the sequence from memory after completion.

Check 5: match the “after” assets to the released project

The final photograph, design, equipment schedule, and customer document must refer to the same configuration and stage. A beautiful completed image paired with the original proposal quantity creates a quiet mismatch.

Record capture date, project status, viewpoint, configuration identifier, and any visible conditions that changed after the baseline. If commissioning, interconnection, operation, or another milestone is material, retain its actual evidence and name only the milestone the record supports.

Do not call an installed array “operational” merely because the modules are mounted. Do not call a submitted package “approved.” Do not call a concept “as built.” These words belong to different project states.

If the final image is a rendering, label it. If it is an actual project photograph, retain permission and provenance. If it is an anonymized detail from another project, do not place it inside a story in a way that implies it depicts the subject project.

Provide meaningful text alternatives and captions. The W3C image tutorial explains how informative, decorative, and complex images need different treatments. A comparison may need visible text describing the changed roof zone or layout, not only two photographs.

Check 6: classify every outcome as measured, modeled, or stated

Outcome language carries the greatest claim risk. Separate three categories:

• Measured: taken from an identified tool, record, or observation over a defined period.
• Modeled: calculated from disclosed sources and assumptions using validated code.
• Customer-stated: a real statement used with permission, attributed as the customer’s view.

Do not turn one category into another. A modeled annual energy figure is not measured production. A customer’s belief that a bill improved is not a verified savings calculation. A current monitoring screenshot does not automatically represent a full year.

The PVWatts Calculator from the National Laboratory of the Rockies (NLR, formerly the National Renewable Energy Laboratory/NREL) is an example of production estimation from inputs. If a project story includes a modeled figure, identify the actual model used, design version, weather or irradiance data, shading treatment, equipment, losses, and date. Do not cite PVWatts as support for a result from another unexplained method.

Financial outcomes need the billing periods, usage changes, tariff and export treatment, system status, price and scope, finance, incentives, taxes, operating costs, and calculation boundary relevant to the claim. Use qualified review. If the record cannot support the claim, tell the operational story without the number.

The FTC small-business advertising FAQ explains U.S. substantiation principles. Review requirements in every applicable market. Claims about time, approval, accuracy, savings, production, conversion, or customer results need claim-specific evidence.

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.

Check 7: handle the quote and endorsement as evidence

A strong quote names a decision or experience only the customer could describe. “They were great” adds little. Ask what information helped, what changed in their understanding, or which part of the process mattered, without steering the person toward an outcome.

Record the question, full response, date, speaker identity, relationship, permission, compensation or benefit, and approved edit. Preserve the original. Do not manufacture grammar so polished that it changes meaning. Do not combine words from different customers into one attributed quote.

The FTC endorsement guidance addresses endorsements and disclosures in U.S. advertising. Apply relevant jurisdictional rules and disclose material connections clearly. A free upgrade, discount, referral payment, employment relationship, contest entry, or other benefit may matter.

Do not use a testimonial to carry an objective claim the company cannot substantiate. “Our bills fell by half” still needs the evidence and qualification appropriate to that result. A disclaimer that “results vary” does not create substantiation.

Give the subject a final contextual review, especially when edits, charts, and images are assembled. Permission for individual pieces is not proof that the complete story reflects the person’s experience fairly.

Check 8: package sources and assign a refresh trigger

Create a story ledger with every public claim, source, permission, asset, date, owner, expiry, and live URL. Keep personal and sensitive records in controlled storage, not inside the public content repository.

The NIST Privacy Framework offers a structure for privacy-risk management. Map collection, storage, access, vendors, publication, correction, retention, deletion, and incidents. Apply qualified review to the actual project and jurisdiction.

Set refresh triggers by claim. Permission expiry, customer request, equipment change, new measured period, corrected data, company relationship change, or a volatile tariff and incentive source may require revision. A generic annual reminder is not enough for a claim that changed yesterday.

At refresh, inspect every reuse: website, landing page, proposal library, social post, advertisement, sales deck, email, and partner portal. Update or remove derivative assets. Do not correct the article while leaving the old claim in paid media.

Preserve a public last-reviewed date and internal audit trail. Readers should see when the story was checked; reviewers should see what changed and why.

Turn the checklist into a production sequence

Assign story work across the project rather than at the end:

1. During intake, identify the possible reader lesson and permission needs.
2. Before work, capture a dated baseline and original customer objective.
3. During design and delivery, record material changes and source decisions.
4. At the appropriate project milestone, capture final assets and exact status.
5. Before drafting, classify outcomes and bind evidence.
6. During editorial review, check claims, endorsement, privacy, accessibility, and complete impression.
7. Before publication, verify links, permissions, current facts, and mobile rendering.
8. After publication, register expiry and all distribution uses.

This sequence also makes it acceptable to stop. A project may be operationally successful but unsuitable for public storytelling because permission is limited, sources are incomplete, or the lesson duplicates an existing story. Do not fill evidence gaps with confident prose.

Build a matched capture plan before anyone visits the site

Visual comparison becomes far more useful when the capture plan holds viewpoint and purpose steady. Write a shot list tied to the story decision, then let site-safety and permission requirements control whether each shot can be made.

For the baseline and final views, record the camera position or safe ground reference, direction, lens or zoom where practical, framing, date, time, weather context, and the project feature the image is meant to explain. Exact replication is not always possible or desirable, but unexplained differences in season, foliage, roof access, cropping, or lighting can exaggerate change.

Add evidence shots that make the process legible. A roof-coordination story may need the dated drawing that showed planned work, the review note that changed the sequence, and a final image from the same roof zone. A proposal story may need anonymized versions of the original assumption register and the corrected customer-facing output. A commercial stakeholder story may need a responsibility map rather than a dramatic roof photograph.

Do not ask field staff to create marketing material while performing safety-sensitive tasks. The shot plan must respect site rules, working-at-height controls, electrical boundaries, customer operations, and the competence of the person capturing it. A missing photograph can be replaced with a diagram or text record. An unsafe photograph should never be taken.

At upload, connect each asset to the project and stage before filenames and message threads lose the context. Preserve the original separately from edited versions. Record crops, redactions, annotations, color changes, and composite construction. An editor should be able to determine whether a visible arrow was added for explanation or appeared in the source.

Write the comparison as a chain of supported changes

“Before versus after” invites a binary story, while solar projects usually move through several decisions. Use a change table to prevent the draft from skipping from problem to triumph.

Write one paragraph per link in the chain. This makes omissions obvious. If there is no evidence for an outcome, the story can end with the delivered scope and lesson. If the final status is installation rather than operation, say installation. If a third party controlled the decision, credit that role.

How can marketers compare solar before-and-after evidence without exaggerating?

Marketers can compare before-and-after evidence by holding the project, viewpoint, period, scope, and claim definition steady, then explaining every material difference that remains. Use matched sources, preserve intervening decisions, and label measured, modeled, and customer-stated outcomes separately. If seasons, tariffs, occupancy, equipment, project status, or image treatment differ, disclose the change instead of attributing everything to solar for future readers.

Start with the two source records, not the most dramatic visual pair. Confirm that both belong to the same project and intended comparison. A proposed layout should not be compared with an installed photograph as though geometry alone explains every change. A partial billing period should not be compared with a different season and called annual savings.

Use a comparison control table:

Illustrative workflow example, not a customer result: A story has an early layout, a later site note, and a final installation photograph. The writer explains that the site note changed one roof-zone decision and ties the final image to the released configuration. The early layout remains visible as a dated planning artifact. The story does not call the difference an optimization result or claim the change improved production unless retained model evidence supports that separate statement.

Compare the causal chain conservatively. A change occurred, a decision was recorded, and a later configuration was released. That sequence can support an operational lesson. It does not automatically prove that the decision caused a financial or performance outcome. Bind any outcome independently.

Visual comparisons need text. Describe the relevant roof zone, project stage, and source limitation so a reader who cannot see the images receives the same lesson. Use the solar visualization guide when a diagram or change map explains the decision more accurately than photographs.

The right conclusion is conditional. Explain what another reader should inspect when facing the same constraint. Do not promise they will reproduce the same project, schedule, bill, approval, or customer experience.

Keep alternatives visible. The project team may have considered several layouts, equipment choices, schedules, or commercial structures. Explain why the chosen option fit the stated constraint without calling it universally superior. Another reader may have a different roof, tariff, objective, contract, or review requirement.

The closing lesson should be conditional: “For projects where planned roof work can change the array basis, resolve the roof sequence before releasing later-stage customer documents.” That is more useful than “solar transformed this customer’s future,” and the record can actually support it.

Prepare derivatives without stripping their qualifications

A long article may become a homepage tile, social post, sales slide, email, video caption, or partner asset. Each derivative creates a new advertising impression. Register them and keep the claim, status, disclosure, and date attached.

Do not crop a chart to the favorable period, remove “modeled” from a figure, or use the completed image beside a different claim. Do not shorten a conditional quote until it becomes absolute. If the qualification cannot fit the format, choose a narrower claim or do not use that format.

Partners need an approved package rather than access to loose assets. Include permitted copy, image, caption, required disclosure, expiry, prohibited edits, and a correction channel. When a source or permission changes, notify the derivative owners and document removal.

Test search previews and open-graph images. A headline that is careful in the article can become an unsupported outcome when the description or image circulates alone. The public title should describe the lesson, not promise that readers will reproduce the subject’s result.

Audit the story from a skeptical reader’s position

Read the headline alone. Does it imply a performance result the body cannot support? Look at the before-and-after images without captions. Could a reader mistake an illustration for the subject project? Read every number and date. Can another reviewer find the source?

Check the starting and final configurations. Confirm that design, bill of materials, proposal, and outcome refer to the intended versions. Inspect whether weather, usage, tariff, finance, occupancy, or operating changes complicate any comparison.

Check disclosures on mobile and in social crops. Check alt text and visible explanations. Remove address, account, metadata, signage, faces, or business information not covered by permission and purpose.

Ask a colleague unfamiliar with the project to state what changed, what the company did, what the evidence proves, and what remains uncertain. If they infer a guarantee or universal result, revise the story.

When should a solar before-and-after story not be published?

A solar project story should not be published when permission is missing, the baseline was reconstructed, before-and-after assets refer to different projects or stages, scope cannot be verified, outcome claims lack evidence, a testimonial is unsupported, privacy risk remains, or qualifications disappear in derivatives. Defer publication until the defect is resolved, or publish a narrower lesson without the project claim.

Not every defect is patchable with a disclaimer. Missing permission requires permission or removal. An unsupported savings number requires evidence or deletion. Mismatched project versions require reconciliation. A customer quote whose source and approved edit cannot be located should not remain because it sounds plausible.

Use a publication hold record:

Hold status needs an owner and next action. “Legal review” is too vague. Name the permission field, outcome claim, privacy concern, project mismatch, or derivative at issue. Assign the qualified reviewer and evidence required. Do not keep revising wording around a source problem.

When only one claim fails, remove or narrow that claim and audit the complete impression again. A project story can remain valuable without a savings figure or superlative. It may explain how the team reconciled a roof change, kept revisions connected, or prepared a clearer customer handoff.

Check every reuse before release. The article may preserve “modeled” while a social crop removes it. A caption may disclose the customer relationship while a sales deck shows only the quote. Register each derivative and withdraw it when the controlling permission or evidence changes.

Publication readiness means a skeptical reviewer can find the permission, project trail, source for every claim, commercial disclosure, accessible explanation, and refresh trigger. If any of those is missing, the story is still a draft, regardless of how compelling the photo pair looks.

A good before-and-after solar story gives the “after” less magic and more provenance. The transformation becomes believable because the reader can see the decision trail.

Frequently Asked Questions

What belongs in a solar before-and-after story?

Include the customer’s original decision, dated starting evidence, verified project scope, material changes, final project status, clearly sourced outcomes, unresolved limitations, and a useful lesson for a similar reader. Obtain permission and disclose the commercial relationship. A pair of roof photographs without dates, context, and scope is not a complete project story.

Can an installer publish a customer’s solar savings?

Only publish a savings claim with suitable permission and retained evidence that defines the bill periods, tariff, usage changes, export, finance, incentives, system status, and calculation boundary. Distinguish measured billing history from modeled projections. Do not imply that another customer will receive the same outcome, and obtain qualified review for financial and advertising claims.

How should solar project photographs be labeled?

Identify whether each image is an actual project, illustrative example, design visualization, or progress record. Add capture date or stage, relevant viewpoint, and permission status in the asset record. Captions should explain the project fact shown without exposing personal information or implying that an unverified image proves production, safety, compliance, or approval.

What if the project changed after the proposal?

Preserve the proposal version and explain the material change, its source, decision owner, and affected outputs. The final story should use the installed or current configuration rather than the original sales image. If production or financial scenarios changed, update them from the applicable design and assumptions or omit the stale result.

How long should project-story evidence be retained?

Set retention through the company’s contracts, consent terms, privacy duties, claim-risk policy, and applicable law. Keep enough evidence to substantiate every live claim and honor the permissions granted. Assign expiry dates to volatile facts and remove or revise the story when permission ends or the retained record no longer supports publication.