How to Build a See-Solar-on-Your-Roof Experience

The worst version of “see solar on your roof” is a magic trick. A visitor types an address, panels appear, and the page jumps straight to a savings claim. The image feels specific while the inputs remain mostly unknown.

The useful version does something quieter. It helps the prospect identify the right property, see a preliminary array concept, correct missing context, and understand what evidence is needed for a real proposal. The business receives a cleaner handoff instead of a name attached to an unexplained panel count.

This guide is for solar marketing, sales, design, and product teams. It covers experience design and evidence handling, not a claim that any property is suitable for solar. Privacy, consent, advertising, accessibility, consumer, contract, technical, and local legal requirements need review for the markets where the experience operates.

Choose the next decision before designing the interface

An interactive roof view can support several jobs. A homeowner may want to see whether panels can be placed away from a street-facing roof. A facilities contact may need a simple image to start an internal conversation. A salesperson may need the correct building and current bill before requesting preliminary design.

Choose one primary decision:

• confirm the property and relevant roof;
• explore a preliminary array placement;
• collect current evidence for a design conversation;
• book a qualified assessment;
• save and share an early concept with another stakeholder.

Do not make the first screen serve all five equally. The interaction becomes long, and every field starts to look mandatory. A visitor asking for visual orientation should not have to complete a financing application before seeing the roof.

The U.S. Department of Energy’s Homeowner’s Guide to Going Solar describes considerations such as home suitability, electricity needs, bids, and financing at an educational level. It reinforces that a solar decision has more inputs than roof area. A lead experience should reveal the next evidence step without pretending it has completed all of them.

What should visitors receive before a solar roof preview asks for contact details?

Visitors should receive enough value to confirm that the experience understands their property and request before contact becomes necessary. Show the located site, imagery status, selected roof area, preliminary nature of any array concept, and the evidence needed for a deeper review. Ask for contact details only when the visitor chooses to save, send, discuss, or continue that specific output.

This value exchange changes the first screen from a disguised lead form into a useful orientation step. The visitor can catch a wrong building before a salesperson inherits the error. They can also decide whether the offered workflow matches their question. A person looking at a detached garage needs a different path from a facilities manager identifying several buildings.

The page should make three types of information visually distinct. User statements include the selected property, marked roof, project objective, and planned changes. System observations include imagery availability, automated geometry, and any preliminary placement. Unresolved evidence includes roof condition, structural capacity, electrical service, current consumption, equipment choice, site access, and external requirements. Do not blend these into one confident-looking result card.

Use a first-value contract during product review:

Contact collection can happen earlier when the service genuinely requires it, but the reason must be visible. A commercial portfolio intake may need an authorized contact so the team can identify private site records. A file upload may require an authenticated session under the approved security design. Those are operational needs, not permission to hide all useful output behind an email field.

The screen after property confirmation should answer four reader questions in plain language: Which property did the system find? How current and suitable is the imagery? What does the visual represent? What can the visitor do next? If any answer is missing, adding more animation will not repair the trust gap.

Preserve the no-contact path. A visitor who only wants to understand the process should be able to leave with a short evidence checklist or an educational link. Do not store partially entered contact data for follow-up unless the approved consent process permits it. The interaction should respect the decision to stop as clearly as it respects the decision to continue.

Before shipping, ask a tester to describe what they received before the form appeared. If their answer is only “a picture with panels,” the page has not explained property confidence, preliminary status, or the next evidence step. Fix the explanation before adding another qualification field.

Let the visitor confirm the property

Address lookup can select the wrong building, parcel entrance, unit, or roof on a multi-building site. Show enough context for the user to confirm what they mean. Allow map movement or pin correction where the implementation supports it. Ask a plain question such as “Is this the building you want us to review?”

Record the original lookup, user correction, selected roof area, imagery source, and observation date where available. Keep confidence labels internal if they are not meaningful to the visitor, but do not hide a weak match behind a polished image.

For multi-building commercial sites, let the visitor name the building or draw a broad area rather than forcing one address-level result. The lead record should preserve that selection so sales does not ask the prospect to repeat it on a call.

Never imply property ownership from address entry. Ask the visitor’s relationship to the site only when it affects routing, and offer accurate choices such as owner, tenant, facilities representative, developer, advisor, or exploring for someone else.

Make imagery age visible without derailing the task

Remote imagery may predate roof replacement, extensions, new mechanical equipment, tree growth, demolition, or neighboring construction. Its resolution and capture conditions may not support precise roof edges or obstruction dimensions. Put a short limitation near the visual, then offer a useful correction path.

The correction path can include:

• “This image is outdated” with a brief reason;
• upload of current roof photographs or plans under clear consent and file controls;
• a note about planned reroofing or construction;
• selection of a different building;
• request for a site assessment rather than continued self-service layout.

Do not burden the visitor with remote-sensing terminology. Say what could be wrong and what happens next. “Imagery may not show recent roof or tree changes; a site review is required before final design” is understandable and actionable.

Carry the limitation into the output. A disclaimer that disappears after the panels render does not protect the customer conversation.

How should a roof visualization handle missing or uncertain property evidence?

A roof visualization should expose missing or uncertain property evidence at the moment it affects the concept, then offer a correction or escalation path. Identify stale or unavailable imagery, uncertain building selection, user-added obstructions, and unverified roof changes separately. Preserve each limitation in the saved output and handoff so later screens cannot present a preliminary visual as verified site evidence.

Do not reduce uncertainty to one confidence badge. A high property-match confidence says nothing about imagery age, roof condition, obstruction completeness, or technical suitability. Give each uncertainty a name that helps the visitor decide what to do. “Building match needs confirmation” and “imagery may predate recent roof work” lead to different actions.

Use an evidence-state table behind the interface:

Illustrative workflow example, not a customer result: A visitor confirms the address but reports that the roof was replaced after the displayed image was captured. The experience keeps the old image visible for orientation, adds a “roof changed since imagery” state, and asks whether current photographs or a roof plan are available. It does not infer the new roof shape or reuse the old outline as verified geometry. The saved concept carries the note into sales and design, where a reviewer chooses the appropriate evidence request.

The example is useful because it preserves progress without pretending the gap disappeared. Throwing away the session would force the visitor to repeat the address and project objective. Ignoring the note would let an attractive but stale concept move toward a proposal. The evidence state provides a middle path: retain orientation, restrict claims, and route the unresolved item.

Create explicit UI states for “unknown,” “user reported,” “system inferred,” “source observed,” and “reviewed.” The exact labels can be simplified for visitors, but the underlying record must remain distinct. A later designer should be able to tell whether a roof edge came from imagery, the visitor, an automated model, or a retained survey.

File uploads need an equally clear state. Receiving a photograph does not mean the organization has verified its capture date, location, scale, or completeness. Record it as user-provided evidence until the assigned reviewer accepts it for a stated purpose. Explain what the reviewer may still need instead of showing a green check that implies technical approval.

When evidence cannot support the intended interaction, stop the affected feature. A missing image can lead to a document upload or assessment request instead of a blank map. An uncertain multi-building match can lead to a site-selection screen instead of automatic module placement. Unsupported technical conditions can lead to a question for a qualified reviewer. The fallback should advance the decision, not merely apologize.

Carry evidence states into analytics carefully. An “outdated imagery” report is not a failed lead, and a request for manual review is not proof of high purchase intent. Measure whether the visitor reached an honest next action and whether staff received usable context. Commercial outcomes require the organization’s own retained evidence and approved analysis.

Show a concept, not a disguised approval

A preliminary array visualization should identify what it represents. State whether panel placement is automatic, user-adjusted, or prepared by a designer. Show the module type as representative when no product has been selected. Avoid language such as “perfect fit,” “approved layout,” “permit ready,” or “guaranteed production.”

DOE’s PV system design basics describe modules, mounting, inverters, storage, and other parts of a solar system. A roof visualization represents only part of that system. Structural, electrical, access, fire, roofing, utility, authority, and manufacturer considerations remain.

Give the prospect meaningful controls rather than fake precision:

If the experience cannot model a condition responsibly, ask for it instead of inventing a visual. A battery, canopy, or ground-mount request may need a different workflow.

Ask for data only when it changes the next screen

Long forms create friction, but the deeper problem is unexplained collection. A visitor should know why the site asks for an electricity bill, phone number, roof photo, or project timing. Use progressive steps and let people understand what they will receive.

The web.dev course on forms covers labels, input types, validation, and accessible form design. W3C’s Web Content Accessibility Guidelines provide a standards framework for accessible web content. Apply the current technical requirements with accessibility expertise; do not treat a checklist as proof of conformance.

Design fields around decisions:

1. location, to find and confirm the property;
2. project goal, to choose the next explanation or specialist;
3. electricity evidence, when an energy or financial scenario is requested;
4. property role and stakeholder context, to route commercial or residential follow-up;
5. timing or roof work, to avoid presenting an obsolete path;
6. contact and consent, to save, send, or discuss the result.

Avoid collecting financing, legal, identity, or sensitive household information merely because the CRM has fields for it. Data minimization, retention, security, and user rights need a documented policy and jurisdiction review.

Explain consent at the moment it matters

Contact consent should not be bundled into a vague button. Tell visitors whether they are saving a concept, requesting an assessment, subscribing to marketing, or authorizing contact through a particular channel. The exact legal requirements vary, so obtain jurisdiction-specific review.

Link to a readable privacy notice and summarize the relevant data use near collection. Google’s public privacy policy is first-party documentation about Google’s practices, not a template for a solar installer. Your notice must describe your actual organization, vendors, purposes, retention, and rights.

File uploads deserve special treatment. State accepted formats and size, explain how the file will be used, scan and store it through the organization’s approved controls, and avoid displaying account information unnecessarily in shared views. Give sales and design only the access their work requires.

If the visitor exits before submitting, do not assume permission to contact them from partially entered data. Follow the site’s consent design and applicable law.

Keep production and savings behind an evidence gate

A panel count on an image cannot establish annual production, bill savings, payback, or system price. Production needs weather, geometry, shading, equipment, losses, and model choices. Financial output needs current consumption, tariff, export treatment, price, financing, incentives, taxes, and contract inputs where applicable.

Use progressive output states:

• Roof preview: property and preliminary panel placement, no financial claim.
• Energy scenario: model basis and assumptions visible, tied to a specific layout.
• Financial scenario: current tariff and commercial inputs documented, with sensitivity and limitations.
• Reviewed proposal: human review, scope, evidence, and customer choices reconciled.

Google’s advertising policy on misrepresentation describes prohibited misleading presentation in Google Ads. A solar business also needs to review the consumer-protection and advertising rules that apply to its market. Independently of ad-platform rules, the experience should not hide qualifications or imply unavailable results.

If the data gate is not met, tell the visitor what is missing and offer the next action. “Upload a recent bill so we can prepare a separate consumption-based scenario” is more useful than filling blank inputs with invisible defaults.

Return value before asking for a call

The experience should deliver something useful without pretending to finish the project. A confirmed property image, saved roof preference, list of evidence gaps, and explanation of next review can justify the visitor’s effort. Do not lock the only result behind a calendar form after the person has supplied data.

Give a choice:

• save or email the preliminary concept under the site’s consent process;
• correct the building or roof selection;
• upload current evidence;
• request a human assessment;
• leave with a checklist of what to gather.

Accessibility belongs in the output too. Section508.gov provides public guidance on creating accessible web content in the U.S. federal context. Private sites may face different obligations, but semantic structure, keyboard access, labels, contrast, error messages, and nonvisual descriptions are practical starting points.

A roof visual needs a text alternative that communicates purpose rather than every pixel. Provide the selected address or site label, preliminary status, module count only if supported by the displayed concept, and any important user-marked exclusions in accessible text.

Hand sales an evidence packet, not a novelty lead

The lead record should tell sales what the visitor did and what the system inferred. Keep those separate. User-confirmed property, selected roof, stated project goal, uploaded bill, and requested contact are direct inputs. Automated roof edge, module placement, or lead score is an inferred output with its own confidence and limitations.

Create a handoff packet:

1. property selection and correction history;
2. imagery source and date where available;
3. saved preliminary layout and version;
4. user-provided goals, preferences, and known changes;
5. uploaded evidence with access controls;
6. model assumptions and unresolved conditions;
7. consent record and requested contact method;
8. recommended next action with an owner.

Solar Designing, PV shade analysis, the Generation and Financial Tool, and Solar Proposals can support later workflow stages. The handoff should keep the same property and scenario identity as information moves.

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.

How should a roof-preview handoff preserve context for sales and design?

A roof-preview handoff should preserve the visitor’s confirmed facts, system inferences, evidence sources, unresolved conditions, consent, and requested decision as separate fields tied to one scenario. Sales needs a useful opening action, while design needs the origin and status of each input. Neither team should reconstruct the session from a screenshot, marketing summary, or unlabelled panel count during any transfer.

Use one stable handoff identity across the browser session, CRM record, design workspace, and proposal workflow. The identity should point to the selected property, current concept version, imagery record, visitor corrections, and offer shown. If a salesperson creates a new opportunity, retain the original experience identifier instead of copying a few fields into a disconnected record.

Structure the handoff in four layers:

1. Visitor-confirmed context: property selection, roof preference, project objective, stakeholder role, planned changes, available evidence, and requested channel.
2. System-generated context: lookup candidates, imagery metadata, inferred geometry, preliminary layout, and internal confidence or limitation signals.
3. Open evidence: site facts, technical reviews, electricity records, equipment decisions, or external requirements still needed for the promised next step.
4. Action and permission: the specific follow-up requested, consent wording and version, assigned owner, and any access restrictions on uploaded material.

Do not flatten those layers into “qualified” or “unqualified.” A prospect can be ready for a property review while lacking the inputs for production or savings. Another prospect may provide a bill but select the wrong building. Route each to the next supported action and make the missing evidence visible.

Give sales a conversation opener generated from confirmed context, not an automated persuasion script. It might say that the visitor selected a warehouse roof, marked recent construction, and requested an evidence review. Sales can then confirm the request and explain what the reviewer needs. The record must avoid claiming the system proved suitability, savings, or approval.

Give design a source-aware intake. Each geometry, image, document, and user statement needs its origin, date where available, revision, and review status. Design should also see what the visitor saw, including preliminary labels and any choice presented as representative. That prevents a draft concept from silently becoming the design brief.

Use this handoff acceptance checklist:

PROPERTY AND BUILDING CONFIRMED OR FLAGGED:
VISITOR OBJECTIVE RECORDED IN THEIR TERMS:
OFFER AND PAGE VERSION PRESERVED:
IMAGERY SOURCE, DATE, AND LIMITATION PRESERVED:
USER CORRECTIONS SEPARATED FROM SYSTEM INFERENCES:
CURRENT CONCEPT VERSION IDENTIFIED:
UPLOADED EVIDENCE ACCESS CONTROLLED:
OPEN TECHNICAL AND COMMERCIAL INPUTS LISTED:
CONTACT REQUEST AND CONSENT VERSION RECORDED:
NEXT ACTION, OWNER, AND HANDOFF STATUS NAMED:
CUSTOMER-FACING LIMITATIONS MATCH THE RECORD:

Run a handoff drill with marketing, sales, and design. Marketing submits a labelled fictional session containing one property correction and one missing evidence item. Sales explains the request without private coaching, then passes it to design. Design identifies which inputs are usable, which remain preliminary, and what must be collected next. Any information supplied verbally during the drill belongs in the record or interface.

Review handoffs after the first conversation. Record repeated questions, unused fields, lost corrections, inaccessible files, and mismatched promises. A field earns its place when it improves routing or the requested deliverable. If nobody uses it, remove it or explain the overlooked decision. If staff repeatedly ask for missing information, decide whether the page should collect it or clearly assign it to follow-up.

The handoff is complete when the next person can continue the visitor’s task with the same evidence boundaries. It is not complete merely because a CRM contact exists. Keeping the scenario intact reduces repetition for the visitor and makes it harder for an attractive preview to outrun the facts supporting it.

Qualify by next action, not by imagined close probability

A visitor is qualified when the team has enough evidence and consent to choose a responsible next step. They may need a site assessment, a bill review, a commercial stakeholder call, a reroof conversation, a technical screen, or a polite explanation that current scope does not fit.

Do not claim that a particular interaction predicts close rate without retained data and a defined method. Use operational routing fields: site confirmed, relevant decision identified, electricity evidence available, roof work known, timeline source stated, authority to engage understood, and consent captured.

Review abandonment and error data with care. A high exit rate at bill upload may indicate effort, privacy concern, unclear value, or visitors who wanted only a roof image. Test explanations through ethical research rather than assuming reluctance means low intent.

The best see-solar-on-your-roof experience earns the right to continue the conversation. It shows enough to make the project tangible, labels what remains preliminary, and transfers every useful choice into the next review instead of asking the prospect to begin again.

Prototype the difficult states before the happy path

A design team can make the ideal address look impressive and still fail on the moments that determine trust. Prototype the wrong building, no imagery, low-resolution imagery, a large multi-roof site, a shaded roof, an apartment unit, a renter, a planned reroof, an unsupported region, a keyboard-only user, and a visitor who declines contact.

For each state, decide what the page can support and the next honest action. No imagery may lead to a plan upload or human review. A multi-building commercial address may require site selection. A renter may receive a shareable information pack rather than an owner-specific proposal path. Unsupported geography should produce a clear limitation, not a broken map that looks like user error.

Test the wording with people who did not build the product. Ask them:

• What does the panel image prove?
• Which information came from you, and which did the system infer?
• Is the layout final or preliminary?
• What will happen after you submit?
• Which files or contact details will be stored?
• Can you correct the property or leave without requesting a call?

If participants interpret the preview as engineering approval, the label is not strong enough. If they expect an immediate price but the next step is a sales call, the offer is unclear. Fix the screen where the misunderstanding begins instead of adding another paragraph to the confirmation email.

Use a scenario ledger during prototyping:

Do not manufacture a roof result merely to avoid an empty state. A precise-looking failure is worse than an honest limit.

Test the handoff with a real sales workflow

Create a fictional, clearly labeled test property and complete the experience through every route. The sales user should receive the same property, roof selection, preliminary status, visitor goal, evidence list, consent state, and open questions shown at submission. Nothing important should survive only in analytics or a design tool.

Ask the salesperson to prepare the next customer conversation without watching the original session. They should be able to explain what the preview shows, what it does not show, which evidence is still needed, and why the recommended next step fits. Note every question that makes them return to the visitor for information the experience already collected.

Then ask a designer to inspect the same record. They should see the imagery source, user corrections, marked roof, current concept revision, and uploaded files. User annotations must remain clearly user supplied. The designer should not mistake a marketing visualization for verified geometry.

Test a revision as well. Change the selected roof or add a current photo after submission. The new evidence should create a visible version and notify the right owner. It should not silently alter a concept already discussed with the customer.

Finally, test deletion, access, and retention workflows under the organization’s policy. A lead experience that makes collection easy but cannot locate the person’s data for an approved rights request has a governance defect. Privacy counsel and security owners should review actual implementation for the jurisdictions and systems involved.

Measure task completion before lead volume

Count whether visitors reach a useful state: property confirmed, concept viewed, evidence request understood, saved result delivered, or assessment requested. Lead count alone can reward aggressive forms that collect contacts from people who did not understand the offer.

Pair funnel events with quality checks. Review a sample of handoffs for wrong properties, stale imagery reports, missing consent, inaccessible controls, mismatched concept versions, and repeat questions. Keep internal measures defined and dated. Do not publish a conversion or qualification claim without a retained dataset, denominator, observation window, and method.

Interview people who stop at different stages, with appropriate consent. Someone who leaves after seeing the roof may have received all the value they wanted. Someone who abandons at upload may not understand the request or may be unable to access a current bill. Those explanations require research; analytics alone cannot supply motive.

Use findings to adjust one part of the experience at a time. Changing the map, form, output, and follow-up together makes it difficult to know which relationship improved. Preserve versions so lead quality and customer feedback can be interpreted against the experience people actually saw.

Frequently Asked Questions

Is a roof preview the same as a solar design?

No. A roof preview can help a prospect identify the property and discuss array preferences, but its geometry, obstructions, roof condition, access, structure, electrical service, rules, equipment, production, and economics may remain unverified. Label the output as preliminary and state what survey and qualified review are still required.

What information should the experience ask for first?

Start with the minimum needed to find the property and return a useful next step, usually location and contact or save preference under the site’s consent design. Ask about electricity data, ownership, roof work, timing, and project goals only when each answer changes routing. Explain why sensitive or effortful information is requested.

Should a solar roof tool show estimated savings immediately?

Only when the site has sufficient consumption, tariff, system, price, financing, incentive, and model inputs, and the result is clearly qualified and supported. A roof image alone cannot establish savings. Many experiences should show an array concept first, then request the evidence needed for a separate financial scenario.

How should imagery limitations be disclosed?

Show the imagery provider or source where permitted, observation date when available, and a plain statement that the image may omit recent construction, roof changes, trees, equipment, or measurement detail. Let users correct the property or upload current evidence, and carry those corrections into the sales and design handoff.

What makes a roof-preview lead qualified?

Qualification means the business has enough supported information to choose a responsible next action, not that the project is guaranteed to close or install. Useful signals include confirmed property, customer objective, available electricity evidence, decision timing, known roof work, stakeholder role, and consent for the requested follow-up.