7 Solar Offer Questions Marketing Must Ask Design

A solar campaign can become inaccurate without anyone writing a false sentence. Marketing may reuse a clean array image after the equipment set changes. A calculator may keep an old tariff assumption. A landing page may promise a personalized result while the intake form collects too little information to support one. The proposal eventually tells a narrower story than the advertisement.

The fix is a short, evidence-controlled conversation before promotion begins. Marketing should not ask design whether the campaign “looks right.” It should ask seven questions that expose the offer boundary, source records, model assumptions, visual meaning, personalization limit, change triggers, and approval owner.

This article gives teams that handoff. It does not approve a particular advertising claim, technical model, disclosure, contract, incentive, tariff, or jurisdiction. Qualified reviewers must decide what a specific audience needs to see.

The campaign-to-proposal consistency checklist covers the full downstream chain. The solar proposal scope map focuses on proposal boundaries. This page owns the seven questions marketing should resolve with design before an offer enters a campaign.

What should marketing bring to the design review?

Marketing should bring the exact offer statement, intended audience and jurisdiction, campaign channel, proposed visual and calculator behavior, intake fields, landing-page and sales-script copy, promised deliverable, fulfillment timing language, proposal destination, and evidence currently supporting each claim. Design cannot review an idea in the abstract. Every asset needs an owner, version, purpose, and decision request.

Do not begin with a mood board or a headline alone. Assemble an offer packet that lets reviewers see what a prospect will encounter from first impression through proposal. Include variants, mobile states, form branches, automated emails, call scripts, downloadable assets, and retargeting messages when they repeat or extend the claim.

The FTC’s advertising FAQ for small businesses says United States advertising must be truthful and non-deceptive and that advertisers need evidence for objective claims before dissemination. It also discusses express and implied claims. This is not worldwide legal advice, but it supports a practical rule: review the meaning a prospect can reasonably take from the complete experience, not only the literal headline.

Marketing should label the requested decision. Design may be asked to verify a diagram, accept a set of technical assumptions, define which properties qualify, or review whether an intake form can support a preliminary output. Those are different tasks. A vague “approved by design” label makes later responsibility impossible to reconstruct.

Which seven questions should marketing ask design?

Ask seven questions in order: what exactly is offered, which records support it, which assumptions and exclusions govern the output, what may be personalized before site review, what each visual represents, which changes invalidate the message, and who approves the final claim set. Capture answers as controlled records. An unanswered question narrows or delays promotion rather than becoming copy.

Set the review depth by claim, not by asset type. A social post that repeats an objective performance statement can need the same evidence as a landing page. A long technical guide may need no new design approval when it accurately summarizes an already accepted source. Record which spans carry technical meaning, which visual elements imply site specificity, and which links or form states alter the promised deliverable.

Design should also distinguish verification from consultation. A designer can explain what inputs affect an output without approving the marketing interpretation. The design owner can confirm that a layout screenshot comes from a named version without granting permission to use it for every property class. Each answer should state the decision made, evidence considered, questions outside that owner’s authority, and the event that reopens review.

When a question crosses domains, split it. Equipment compatibility can belong to design and product owners. A savings headline can require financial, legal, consumer, and technical review. Image permission can involve the customer, privacy owner, and marketing. This prevents “design approved” from becoming a vague substitute for several missing decisions.

1. What exactly is the offer?

Write one fulfillment sentence: “A qualified prospect who provides these accepted inputs receives this named output at this review state.” Define whether the output is educational, illustrative, preliminary, modeled, reviewed, permit-related, financial, or another controlled state. Name what it is not.

Avoid elastic words such as assessment, design, estimate, savings analysis, or proposal until the teams define them. A roof image plus panel count may be a preliminary concept. It is not automatically an engineered design. A financial scenario is not a guarantee. A fast response is not approval from a utility, authority, lender, insurer, or customer.

Record service area, project type, equipment boundary, customer eligibility, required inputs, fulfillment owner, normal workflow, exception route, expiry, and prohibited interpretations. If the company cannot deliver the same defined object consistently, marketing does not yet have a stable offer.

2. Which current records support the claim?

Bind every load-bearing statement to a first-party fact, accepted technical source, current program rule, validated calculation, or other reviewable evidence. Record the source URL or repository file, observation date, jurisdiction, claim span, owner, limitations, and refresh trigger.

The DOE homeowner solar guide says no universal solar solution exists, discusses roof factors such as age and shading, and tells consumers to work with an installer for a custom production estimate. Its United States consumer framing does not validate a private offer. It demonstrates why a generalized campaign output needs a clear boundary from property-specific analysis.

Ask design which inputs materially affect the statement. Address, imagery date, roof geometry, obstructions, equipment model, shading, consumption data, tariff, orientation, weather file, losses, degradation, and financial inputs may matter in different workflows. Do not list every possible variable as a disclaimer. Identify the variables that govern this offer and make missing data change the output state.

3. Which assumptions and exclusions must travel with the output?

An assumption hidden in design software does not help a prospect interpret a landing-page result. Decide which inputs must appear next to the claim, inside the experience, in the delivered asset, and in the proposal. Preserve measurement units, dates, scenario labels, source quality, unresolved conditions, and the responsible reviewer.

Separate measured, customer-provided, observed, modeled, estimated, illustrative, and unknown information. If the campaign uses a range or representative example, say what population or property class it describes and what it cannot predict. Never round an internal estimate into an external fact.

Do not rely on a footnote to repair a headline whose main impression is unsupported. Qualified legal and consumer-review owners should decide prominence, wording, language, accessibility, and jurisdictional requirements. Design owns technical meaning; it does not own every disclosure decision.

4. What may be personalized before qualified review?

Define a personalization ladder. A campaign may safely show an address confirmation before it can show a roof outline. It may show a clearly labelled initial concept before it can show a reviewed array. It may gather consumption information before it can calculate a financial scenario. Every step needs accepted inputs and a visible state.

The DOE’s consumer resource collection separates topics such as rooftop potential, community solar, fire safety, financing, and home transactions. That taxonomy does not endorse a funnel. It reminds marketing that “interested in solar” can lead to different decisions. The form should route the prospect’s actual job rather than force every address into one output.

Specify what happens when an image is stale, an address does not resolve, the building type is unsupported, load data is missing, roof rights are unclear, or the requested system falls outside the offer. A good exception state provides the next honest action. It does not generate a confident default to protect conversion.

5. What does each visual represent?

Create a visual ledger. For each roof image, layout, shading view, yield chart, bill comparison, electrical diagram, equipment image, and proposal screenshot, record whether it is sourced, illustrative, representative, or site-specific. Store the source, permission, version, assumptions, caption, alt text, prohibited use, and retirement trigger.

Do not let a representative layout appear beneath “your roof” unless the page makes the distinction unmistakable. Do not use a sample panel count as available capacity. Do not present a smooth curve as measured site production if it is a model. Visuals can imply precision more strongly than prose, so their labels belong in the approval record.

The design team should review technical meaning and compatibility. Marketing should review comprehension and channel presentation. Accessibility owners should review alternatives. Legal and privacy owners should review permission and use. One person clicking “approved” should not silently represent all four decisions.

6. Which changes invalidate the message?

Define change triggers before launch. Equipment substitutions, model updates, new service areas, tariff changes, incentive changes, revised intake fields, new project classes, altered outputs, updated proposal templates, and different fulfillment timing can affect approved claims.

NASA’s configuration-management guidance applies to NASA programs, not solar advertising. It describes baselines, control of changes, version distinction, and consistency between a product and its information. The useful analogy is simple: the offer and its evidence need compatible versions, and changes need impact review before old assets keep running.

Build a compatibility matrix between campaign, landing page, form, calculator, design basis, visual set, sales script, automated messages, and proposal. When one item changes, the matrix identifies which approvals reopen. Archive superseded assets without deleting the evidence trail.

7. Who approves the evidence-linked claim set?

Assign approval by domain. Marketing owns the intended audience, channel, message, and campaign version. Design owns the reviewed technical meaning and model boundary. Product owners verify current capabilities. Finance owners review financial inputs and presentation. Qualified legal, consumer, privacy, accessibility, utility, tax, and jurisdictional reviewers handle their applicable decisions.

Approval should identify the exact claim span, asset versions, evidence, permitted audience, conditions, expiry, and reopen triggers. Silence in a meeting is not approval. An approval for one jurisdiction or project class is not automatically portable.

NIST’s Baldrige self-assessment page describes evaluating organizational processes and their impact on results. It does not certify this workflow or a campaign. It supports a bounded operating habit: review whether the claim-control process works, not merely whether one asset passed review.

How should answers become a launch decision?

Turn the seven answers into one of four outcomes: approved for the stated scope, approved with visible conditions, held for named evidence, or rejected for this offer. Link the decision to exact asset and evidence versions. Define monitoring, complaint, correction, pause, and retirement owners before traffic begins. Never convert unresolved design questions into softer marketing language without review.

Use this seven-step approval sequence:

1. Freeze the offer packet. Assign version identifiers to every claim, visual, form, model boundary, script, message, and proposal destination.
2. Bind the evidence. Link objective statements and visuals to the exact sources, first-party facts, calculations, permissions, and model records that support them.
3. Run the seven-question review. Record accepted, conditional, rejected, and unknown answers with owners and due events.
4. Patch only affected assets. Reopen claim and technical review after a material change. Do not silently edit a disclaimer while leaving an incompatible headline or visual.
5. Approve the permitted scope. Name audience, jurisdiction, project class, channel, conditions, expiry, and prohibited reuse.
6. Test the full path. Submit representative valid, invalid, missing-data, unsupported-property, and changed-input cases through the experience and proposal handoff.
7. Monitor and retire. Review complaints, sales clarifications, design exceptions, proposal conflicts, source expiry, and product changes. Pause or replace affected assets through controlled versions.

Illustrative example: the “instant design” offer

Illustrative workflow, not a customer case, product result, conversion claim, design validation, or legal approval. Marketing proposes an “instant solar design” landing page. The form collects an address and email. Design explains that the first output can be an automated roof-based concept, but current imagery, obstructions, equipment assumptions, roof condition, and electrical information still require review.

The team changes the fulfillment sentence to name an initial concept and lists the accepted inputs and failure states. The sample layout receives an illustrative label. A site-specific production or savings statement is withheld until the required records and model review exist. The proposal template links to the same concept version and does not call it approved engineering.

The example does not prove that “instant” is acceptable in a real campaign. It shows how the seven questions reveal what the word could imply and which evidence must control it.

What belongs in the copy-ready review record?

The review record should preserve the offer, audience, assets, seven answers, evidence, assumptions, visual meanings, personalization states, incompatible versions, domain approvals, conditions, expiry, monitoring, and correction path. A reviewer should be able to reconstruct why the claim was permitted and which later change invalidated it. Blank evidence remains unknown, not implied approval.

Copy-ready solar offer design-review record

Use the proposal revision workflow when a design change reaches customer-facing output. Use the savings-language consistency guide when the offer makes financial claims. The review record should link to those controls without copying their entire job.

Where can SurgePV support the handoff?

SurgePV can keep accepted project inputs and customer-facing outputs closer together through verified roof, layout, shading, yield, financial, electrical, material, and proposal functions. It cannot decide what an advertisement implies, approve evidence, establish permissions, validate a jurisdictional rule, or guarantee a campaign result. Marketing and qualified reviewers retain claim and launch authority.

SurgePV’s repository-verified solar design workflow includes 3D roof modeling, solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, and review. Outputs do not replace approval by responsible engineers, authorities, lenders, insurers, utilities, or other applicable owners.

In a demonstration, use the offer packet rather than a polished sample alone. Change an equipment assumption, remove a required input, supersede a layout, and test whether the proposal and campaign record expose the incompatibility. Confirm user roles, version history, exports, review states, and implementation boundaries. A vendor-controlled demo cannot substantiate the customer’s marketing claim.

The useful outcome is not perfect agreement between marketing and design. It is a record of where they disagree, which evidence resolves the dispute, and who owns the decision. That is what keeps a campaign from becoming more specific as its evidence becomes less visible.

Frequently Asked Questions

When should solar design review a marketing offer?

Design should review the evidence-bearing parts before the claim, visual, calculator, landing page, form, or sales script is approved. Review again when equipment, service area, site assumptions, tariff inputs, workflow, output, audience, or qualification changes. Marketing and design owners should define the exact triggers rather than relying on an informal final look.

Can marketing show a representative solar layout?

Yes, when the visual is clearly identified as representative or illustrative and its source, purpose, assumptions, and limits are stated. Do not present a sample roof as the prospect’s design, imply that visible panel count is available, or carry production and savings from the sample into a specific property before current inputs and qualified review exist.

Which assumptions must appear near a solar claim?

Show the assumptions a reasonable reader needs to interpret the claim, including the modeled site or property class, source-data date, equipment basis, shading and load inputs, tariff context, exclusions, review state, and events that can change the result. Qualified legal and technical reviewers must decide the exact disclosure for the audience and jurisdiction.

How should campaign and proposal versions stay aligned?

Give the approved offer, claim set, visual set, intake form, design basis, calculator logic, sales script, and proposal template stable version identifiers. Record their compatibility and change triggers. When one controlled item changes, reopen the affected approvals and retire incompatible assets. Do not let an old advertisement promise what the current proposal no longer supports.

Where can SurgePV support offer consistency?

SurgePV can support 3D roof modeling, array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. Marketing, design, legal, finance, utility, and product owners must still approve claims, audiences, permissions, inputs, qualifiers, contracts, and campaign versions. Software does not substantiate a claim merely because it produced an output.