Back to Blog
solar business22 min read

Solar Marketing Qualification Checklist

Qualify solar inquiries by address, usage, timing, and service fit without turning a short marketing form into a design-ready intake.

Keyur Rakholiya

Written by

Keyur Rakholiya

CEO & Co-Founder · SurgePV

Rainer Neumann

Edited by

Rainer Neumann

Editorial contributor · SurgePV

Published ·Updated

Answer

A solar marketing qualification form should establish the requested next step, serviceable location, available electricity-use context, decision timing, and basic service fit. Collect the smallest useful record, distinguish supplied facts from unchecked entries, explain why each field matters, and route incomplete inquiries to education or discovery instead of inventing feasibility.

A homeowner clicks an assessment ad and enters a postal address. A facilities manager downloads the same form for three buildings. One wants a call this month; the other is assembling next year’s capital plan. If both submissions receive the same “qualified lead” tag, the tag has hidden the work instead of doing it.

Marketing qualification should make the next conversation appropriate. It should identify the request, establish enough project context to route it, and preserve what is still unknown. It should not announce whether a roof works, estimate a system from a utility-cost guess, or decide how likely a person is to buy.

This checklist owns the campaign and first-form boundary. The broader solar lead qualification guide owns later discovery, authority, evidence, and opportunity routing. The solar deal-expansion checklist owns additional scope after discovery. The solar project intake process owns the design-ready record. Keeping those jobs separate allows the first exchange to stay short without making it careless.

What should a solar marketing qualification checklist check?

A solar marketing qualification checklist should check the visitor’s requested action, possible service location, available electricity-use context, decision event or time horizon, and fit with the company’s documented service boundary. It should also preserve source, consent, missing information, exceptions, and the route selected. These checks support routing, not project feasibility or buyer scoring.

The four headline fields are easy to misunderstand. “Address” sounds like a site check. “Usage” sounds like a system calculation. “Timing” sounds like purchase intent. “Fit” sounds like a judgment about the person. Give each term a narrower operational meaning.

Check What it may establish at marketing stage What it does not establish
Address A raw location entry, candidate property, market or service-area route Ownership, roof identity, condition, solar access, structural or electrical feasibility
Usage The visitor’s stated concern, availability of bills, known consumption change, or evidence route Accepted load profile, suitable system size, production, savings, price, or finance outcome
Timing The decision event, planning horizon, dependencies, and requested response Guaranteed installation date, urgency, readiness to contract, or close probability
Fit Whether the requested next action matches a documented market, project class, and available service Personal worth, creditworthiness, protected traits, technical approval, or a final sales decision

Add two cross-cutting checks. First, identify what the visitor has actually authorized: sending the requested resource, contacting them about the inquiry, arranging a meeting, or another specific action. Second, record the state of each answer. “Visitor supplied,” “normalized,” “unconfirmed,” “conflicting,” and “reviewed” are not interchangeable.

The first decision is not “Is this a good lead?” It is “What can we responsibly do next with this record?” Possible answers include deliver education, ask for one missing item, arrange discovery, send a service question to a specialist, or close the request with a clear explanation. Each route can be useful when it matches the customer’s request.

Treat the address as identity and routing data

Keep the address exactly as entered. A lookup service may return a standardized version, coordinates, parcel candidates, or nearby structures, but those are transformations or third-party observations. Store them separately and ask the visitor to resolve ambiguity when a site-specific next step depends on it.

An address should usually answer three early questions: which market might apply, which property does the visitor mean, and whether the company has a documented route for that project class in that place. It should not silently trigger a “solar-ready” label. The U.S. Department of Energy’s homeowner solar guide says there is no universal solar solution and discusses roof age, tree cover, roof shape and slope, utility context, energy use, and ownership considerations. Those dependencies require more than a locator.

Make uncertainty visible. Unit missing, new construction, multiple buildings, rural parcel, non-postal location, and different billing and installation addresses are ordinary exceptions. A form that rejects them as invalid may remove legitimate projects. A form that guesses may send the team to the wrong property.

Treat usage as an evidence state

Ask first what the person is trying to understand: current bill exposure, future load, backup needs, an existing proposal, a facility target, or general solar options. Then ask what usage evidence exists. A bill may be available now, available later, split across meters, incomplete, changing, or controlled by another stakeholder.

The FTC’s U.S. solar consumer guidance says system size depends on average energy usage plus home characteristics and location. It also identifies roof and environmental factors. That supports a dependency boundary, not a marketing-form calculation. A monthly cost or one bill image does not by itself establish consumption, rate structure, future load, or suitable system size.

For a first form, a useful usage record can be modest: concern selected, evidence available, number of relevant accounts if known, broad change expected, and preferred way to continue. Detailed interval data, bill parsing, meter mapping, tariff validation, and scenario modeling belong later when the promised work needs them.

Treat timing as a decision event

“Immediately,” “one to three months,” and “just researching” may fit a reporting dashboard, but they do not explain what controls the schedule. Ask for the event behind the answer. A reroof, lease decision, budget approval, facility renovation, expected vehicle, planned move, expiring quote, or desire to understand options creates a more useful handoff.

Allow “no fixed date” and an open note. Do not punish the answer by dropping the inquiry into an unowned nurture queue. The appropriate route may be an educational guide with a stated re-entry trigger. The FTC solar page warns consumers against pressure for a quick decision. It does not decide campaign wording, but it is a strong reason to keep timing questions informational rather than manufacturing urgency.

Define fit against the service, not the person

Service fit needs a written reference. Define active markets, project categories, property relationships the team can support, service types, necessary specialist routes, language support, and known exclusions. Record the rule version that produced the route. Otherwise “not a fit” becomes a salesperson’s memory or a demographic proxy.

Use the least consequential conclusion available. “Requested battery-only retrofit needs specialist review” is better than “unqualified.” “Site is outside the currently documented installation area” is better than “bad location.” “Commercial account needs the commercial discovery route” is better than asking a residential representative to improvise.

The fit check belongs to the request as it exists today. A company may not serve a particular market or project type, but that says nothing about the person’s seriousness. It also does not prove the site is unsuitable. Let the record say exactly which service rule matched and offer correction when the underlying entry may be wrong.

How should a solar form collect the minimum useful record?

Begin with the action the visitor requested, then reveal only fields needed to deliver or route that action. Mark required and optional inputs, explain their purpose, retain the original response, and offer a lower-evidence path. Add files and detailed project questions only when they change a named deliverable or specialist decision, not merely because the CRM has empty fields.

Progressive collection is a promise-control method. The first screen should not pretend to be universal. A person asking for a general guide may need only a delivery choice. A person asking for a site-specific conversation may need a possible site and contact route. A person requesting a preliminary scenario may be offered a separate evidence step after the company explains what it will produce.

W3C’s form-instructions tutorial advises form authors to identify required and optional inputs, formats, and other relevant information, and to make instructions available to assistive technology. It also says placeholder text is not a replacement for labels. Apply that as accessibility guidance, with qualified testing for the actual site and users.

Use this field test before adding a question:

  1. Name the customer-facing action or internal route the answer changes.
  2. State whether the field is required now, optional now, or belongs in a later step.
  3. Explain the purpose beside the field in ordinary language.
  4. Define the permitted answer states, including unknown, not applicable, and prefer to discuss.
  5. Preserve raw input separately from normalization, inference, enrichment, and review.
  6. Define what the visitor receives when the field is unavailable.
  7. Assign retention, access, correction, deletion, security, and market-specific review outside the copy deck.

If the team cannot complete the first step, remove the field. “Sales may want it” is not a route. If one answer changes only message personalization, say so and assess whether that personalization is necessary. Do not collect household composition, age, income proxies, property value, or other sensitive or demographic information to predict motivation without a separately justified, reviewed purpose.

NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk while protecting individuals’ privacy. It is not a law, certification, or permission to collect information. Use it to structure the company’s risk discussion, then obtain qualified privacy, consent, communications, retention, vendor, and security review for every applicable market.

Field group Minimal first-step form Reveal when the route requires more Avoid at this stage
Requested action One clear selection plus open clarification Artifact type, meeting purpose, or specialist question Vague “tell me more” with no delivery contract
Location Address or location description needed for the route Building confirmation, service address, additional sites Treating autocomplete as site verification
Usage context Goal, bill availability, known change File upload, periods, meters, interval data, reviewer questions Estimating consumption from cost without accepted inputs
Timing Decision event and open time horizon Dependency dates and stakeholders Countdown pressure or promised completion
Service fit Project category and requested service Scope detail needed by the receiving specialist Hidden personality, wealth, or close-probability score
Contact and permission Delivery or response route chosen by visitor Separate choices for additional communications Bundled consent or preselected unrelated promotion

Validation should help people recover, not force messy projects into a clean-looking record. W3C’s input-validation tutorial recommends clear required-field identification, accommodating reasonable input formats, accessible error notification, and server-side validation as well as client-side checks. Test international addresses, unit numbers, screen readers, keyboard-only use, zoom, mobile entry, timeouts, upload failure, and correction flows.

Avoid “invalid project” when the syntax is the problem. Say what the form could not accept and how to continue. For example: “We could not match this address automatically. Check the entry, describe the location, or continue so a person can review it.” That preserves access without claiming the site exists or fits.

Carry qualified context into the proposal workflow

See how SurgePV supports solar design and proposal outputs while your team controls intake states, assumptions, specialist review, and release decisions.

Explore Solar Proposals

How can teams build a campaign-to-routing sequence?

Use one versioned route contract from campaign promise through receiver acceptance. Define the visitor action, minimum fields, evidence states, branch rules, owner, response, stop conditions, and correction path before launch. Test ordinary and exception submissions end to end. A form is complete only when each permitted answer reaches an owned next step with its context intact.

The route contract keeps a landing page from promising one exchange while the CRM implements another. It also lets marketing test a shorter form without deleting information the receiving team genuinely needs. The question becomes whether that information can be collected later, not whether it should disappear.

1. Write the next-step contract

Name the output in plain language. Examples include “send the commercial solar preparation guide,” “request a residential discovery call,” “ask whether this property falls within the active service area,” or “prepare for a usage-evidence review.” State what the action is not. A discovery request is not a design order, and an assessment request is not a feasibility conclusion.

Record campaign ID and version, audience, market, active dates, page and form versions, promised response, service owner, and escalation owner. Review the complete customer impression. FTC advertising guidance says U.S. advertising must be truthful and non-deceptive, objective claims need evidence, and omitted information can be material. That is general guidance, not a campaign-specific legal conclusion.

2. Define the evidence floor for every branch

For each action, list what must be present before it can occur. A guide delivery may require no site. A service-area question may need a possible location. A usage review may require a matched account or bill at the later acceptance step. A preliminary roof conversation may need the visitor to confirm the target structure.

Separate input presence from acceptance. “File uploaded” means a file arrived. It does not mean the file covers the relevant meter, date range, units, or property. Keep the initial route moving where possible, but do not elevate the evidence state simply because the system can extract text.

3. Configure progressive branches and plain-language errors

Reveal follow-up fields based on the selected action and earlier answers. Explain why the next field appears. Provide “not sure” or “discuss this with me” where that is a legitimate state. If an answer blocks the selected service, explain the boundary and offer the closest owned alternative.

Do not use hidden enrichment to replace a question when the answer is consequential. Third-party property, demographic, credit, or behavioral data can be wrong, stale, inapplicable, or sensitive. If the company uses enrichment at all, govern its purpose, source, access, correction, retention, and decision effect through qualified review. Never present an inferred answer as something the visitor said.

4. Preserve a small qualification record

The CRM record needs more than field values. Keep the request, raw answers, normalized values, source and state, consent or permission event as applicable, campaign and form versions, route rule version, route result, exception, owner, time, and next action. That is enough to reconstruct why the inquiry moved without turning marketing intake into a technical project file.

Do not overwrite. If a visitor corrects the building or timing event, append the correction and rerun affected route logic. Notify the current owner when the correction changes service, specialist, language, or response priority. A quiet edit can leave the old email or sales task active.

5. Require receiver acceptance

The receiving queue should accept, return, narrow, or reroute the record. “Assigned” is not acceptance. Sales may accept a discovery request but return a design request that lacks the required project identity. A commercial specialist may accept a multi-site inquiry that a residential queue cannot serve.

Give returns reason codes and a note. Useful codes include property ambiguous, service boundary unresolved, usage evidence unavailable, requested action unclear, language route needed, duplicate, consent or contact issue, or specialist scope needed. Codes describe the work, not the person’s character.

6. Test the full path before activation

Use synthetic records, not real customer data, for routine tests. Include one clean case and exceptions: no fixed address, unit number, multiple buildings, bill unavailable, changing load, long time horizon, outside current service, unsupported project category, correction after submission, assistive-technology use, and failed upload.

Verify the page response, confirmation, CRM state, notifications, queue, owner, follow-up copy, correction route, and closure. A branch that ends in a technically successful API call but no human or customer-facing next step is an unowned route.

7. Review outcomes without converting them into personality scores

Measure route completion, return reasons, unresolved exceptions, corrections, time to receiver acceptance, and whether the promised response was delivered. Segment by form and route version. Read a sample of records before changing questions.

Do not label people “high intent” because they uploaded a bill or “low intent” because they declined. The file may have been easy for one visitor and impossible for another. The operational fact is narrower: evidence available now, evidence unavailable, or evidence route requested.

Where should each qualification outcome route?

Route each inquiry to the least advanced owned step that can honor the request: immediate education, one focused evidence request, sales discovery, specialist review, or respectful close or referral. Include the reason, owner, response, and re-entry condition. Missing data should narrow the next output, while contradictory or consequential information should trigger review rather than a favorable assumption.

The route is part of the customer experience. A visitor should not have to guess whether an automated email means the company accepted a project. Say what happened: resource sent, request received for review, clarification needed, conversation offered, or current service unavailable.

Route Use when Customer receives Receiver accepts when Re-entry trigger
Education Question is early, broad, or does not need site review Named resource and optional next choices Delivery works and content matches request Visitor selects a more specific action
Focused evidence request One item determines the appropriate next branch Reason for request, safe submission route, and no-file alternative Evidence arrives or visitor chooses another path Required item or substitute is available
Discovery Request and basic service context support a conversation Purpose, preparation, scheduling or contact expectation Owner can see request, source states, and open questions Discovery creates a documented successor
Specialist review Service boundary, multi-site scope, retrofit, technical question, or exception needs expertise Review status, expected next communication, and limits Named specialist owns the decision Specialist accepts, narrows, returns, or closes
Close or referral Documented service does not match the request Specific boundary, correction route, and approved alternative if available Closure reason is accurate and communication is sent Service changes or visitor corrects key information

Respectful closure is useful. It prevents the visitor from waiting for a call that will never come and keeps internal queues honest. Do not make a technical claim when the only fact is service scope. “We do not currently offer this service in the location entered” is bounded. “Your property cannot use solar” is not.

Referrals require ownership too. Confirm that the referral route is current and that the company is permitted to share the relevant information. A public resource link is different from sending a person’s record to another business. Obtain appropriate qualified review and visitor choice for the actual practice.

Copy-ready solar marketing qualification worksheet

Use this operating record for one campaign and one promised next step. Duplicate it for each materially different route instead of hiding several services under a generic submit button.

Record field Entry
Campaign, page, form, and rule version
Audience, market, language, and active dates
Visitor’s requested action
Exact response promised and boundary
Minimum required fields and reason for each
Optional fields and value returned for each
Address input, normalized candidate, and confirmation state
Usage question, evidence availability, and known change
Timing event, horizon, dependency, and uncertainty
Service-fit rule, version, result, and limitation
Contact or delivery choice and applicable permission record
Missing, conflicting, corrected, or exceptional information
Selected route, reason code, owner, and response target
Customer-facing confirmation and correction path
Receiver acceptance, return, narrow, or reroute decision
Re-entry event and record-retention owner
Privacy, security, accessibility, communications, and legal review references

Keep the worksheet beside the live configuration. Reviewers should be able to compare each field and branch with the record without reverse-engineering a form builder. When copy, service territory, staffing, vendors, or specialist criteria change, issue a new version and decide how open submissions will be handled.

Illustrative example: two requests at one commercial address

This is an illustrative workflow, not a customer case or measured performance result.

A campaign offers a “commercial solar planning conversation.” The first visitor enters a warehouse address, selects “understand a future project,” says bills are controlled by a finance colleague, and identifies next year’s budget cycle. The route sends a preparation guide and offers discovery focused on stakeholders, meters, and decision sequence. It does not demand a bill before giving value.

The second visitor enters the same address, selects “review an existing solar proposal,” says a recent bill is available, and wants a conversation before an internal meeting. The form requests the proposal and bill through the reviewed evidence route, but it also provides a no-upload path. The commercial queue receives the visitor’s stated question, raw address, file states, meeting event, and open items.

Neither submission proves ownership, authority, technical feasibility, system size, or economics. The shared address also does not prove the visitors represent the same account. The first route respects a longer planning horizon. The second prepares a comparison conversation. Both are qualified for an appropriate next action because qualification describes the work the company can accept, not a hidden score for the person.

If address normalization points to several structures, the route asks which building is intended. If the company does not serve that market, the confirmation states the service boundary and offers correction. If a specialist later accepts design work, the record moves into the project-intake process with sources and gaps intact rather than treating marketing fields as reviewed design inputs.

Which qualification failures should teams catch before launch?

Catch any rule that converts a locator into feasibility, a cost into consumption, a date into urgency, or a service mismatch into a judgment about the person. Also catch bundled permission, inaccessible fields, silent enrichment, unowned exceptions, overwritten corrections, and branches that promise a response nobody accepts. Test failures with synthetic records before exposing the form.

Most problems are not exotic. They arise when the meaning of a field grows as it travels. A postal address starts as routing data, becomes a “verified property” in the CRM, and reaches a salesperson as “qualified roof.” A timing dropdown becomes a hotness score. A bill upload becomes evidence of purchase intent. Stop the semantic promotion at each handoff.

Failure Why it is unsafe or unhelpful Better control
“Address accepted” becomes “site suitable” Identity and technical evidence are different Preserve address state and require the relevant site review
Monthly cost becomes estimated consumption without accepted rate inputs Cost, usage, fixed charges, rate structure, and period may differ Ask for evidence availability and defer calculations
Near-term date becomes pressure language Timing context does not authorize urgency Capture the decision event and explain dependencies
Long horizon becomes “low quality” A future planning job may still deserve an owned route Deliver preparation and record a re-entry event
Upload becomes reviewed evidence Presence does not prove relevance or completeness Keep received, extracted, matched, accepted, and superseded states
Hidden data decides service Source and accuracy may be unknown; sensitive inference may be involved Ask consequential questions directly or route to human review
“Other” reaches nobody Form completion masks an unowned exception Assign an exception owner and response
Error message deletes the record The visitor cannot correct or explain legitimate complexity Preserve input, explain the issue, and offer another path
Marketing permission is bundled with delivery The visitor cannot distinguish requested service from promotion Separate choices and retain the applicable event record
Closed lead has no reason or re-entry rule Teams cannot audit whether the service boundary was applied Use a specific reason, correction route, and change trigger

Review the words attached to each state. “Verified,” “eligible,” “approved,” “accurate,” and “solar-ready” are high-meaning labels. Use them only when a named process and responsible role actually support that meaning. Often “visitor confirmed,” “within documented service area,” “received,” or “pending specialist review” is more accurate.

Review what the form implies visually. A satellite image, panel overlay, savings figure, countdown, green badge, or preselected appointment can make the experience feel more conclusive than the text. FTC guidance evaluates advertising in context, including implied claims. Qualified reviewers should assess the actual rendered path, jurisdiction, audience, and offer rather than relying on an internal field dictionary.

Audit exceptions after launch. Sample records from every route, including abandoned, returned, corrected, closed, and manually overridden submissions. Check whether people received the stated response and whether receivers could act without guessing. An increase in exceptions may mean the control is finding complexity earlier; a decrease may mean staff stopped recording it. Read the underlying cases before drawing a conclusion.

Where can software support qualification, and where does it stop?

Software can preserve form versions, source states, routing rules, owner assignments, corrections, and the handoff into design and proposal work. It can validate configured fields and keep project outputs connected when accepted evidence arrives. It cannot establish truth, consent adequacy, service eligibility, engineering feasibility, utility acceptance, financial suitability, or legal compliance without responsible review.

SurgePV’s controlled product record supports claims for 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 approvals by responsible engineers, authorities, lenders, insurers, or utilities.

That scope begins after marketing has identified an appropriate project path and the organization has accepted the needed inputs. It can support a connected address-to-roof-model workflow or later proposal process. It does not turn an address into verified geometry or a campaign response into a design-ready request.

Keep the transition explicit. The marketing record may say “possible property, visitor confirmed target, bill available, discovery requested.” A successor intake may later say “site identity accepted for preliminary modeling, imagery source recorded, usage file matched, open electrical question assigned.” The second record should cite the first without inheriting stronger states automatically.

Configure permissions and visibility around real roles. Marketing may need campaign, route, and delivery information without access to every uploaded document. A designer may need accepted project evidence without unrelated campaign attributes. A specialist may need the exception and source. Privacy, security, legal, and governance owners should decide access and retention for the deployed systems.

The practical test is whether a receiving person can answer five questions without guessing: What did the visitor ask for? Which location and usage information came from them? What changed or was inferred? Which service rule selected this route? What remains unknown before the next output? If the system cannot show those answers, adding a score will make the gap harder to see.

See a Connected Solar Design and Proposal Workflow

Explore how SurgePV supports solar modeling and proposal generation while your team retains responsibility for qualification, evidence, assumptions, specialist review, and release.

Book a Guided Demo

Frequently Asked Questions

What should a solar marketing qualification form ask first?

Ask what the visitor wants to do next, then request only the location, electricity-use context, timing, and service-fit information needed to route that action. Explain why each required field matters. A first form should not demand every document needed for design, financing, permitting, engineering, or a final proposal.

Is a street address enough to qualify a solar lead?

No. An address can identify a possible property and support service-area routing, but it does not establish ownership, authority, roof condition, usable area, electrical fit, utility eligibility, project economics, or technical feasibility. Keep the raw entry, confirm the intended property when needed, and send site conclusions to the appropriate review.

Should a solar lead form require an electricity bill?

Only when the promised next step genuinely needs it and the company can explain how the file will be handled. A lower-effort route can ask whether a bill is available, which periods it covers, or whether usage is changing. File acceptance and detailed consumption review can occur later under a documented process.

How should timing be asked on a solar inquiry form?

Ask about the event shaping the decision, such as a planned roof project, facility budget cycle, move, vehicle purchase, or request to compare options. Include an open or research-stage choice. Do not turn an uncertain date into artificial urgency, a guaranteed completion date, or a conclusion that the person is unqualified.

What happens when a solar inquiry does not fit the current service?

Use a respectful route that explains the mismatch without making unsupported technical or personal judgments. The next step may be education, an evidence request, specialist review, a documented referral where appropriate, or closure. Preserve the reason code, avoid sensitive inference, and provide a correction path when the information may be wrong.

Sources

Primary research and reference material used for this desk-research article.

Where this fits

This article is part of SurgePV's Solar Business & Operations hub, which works through the topic from first principles to the decisions a project team actually has to make.

About the Contributors

Author
Keyur Rakholiya
Keyur Rakholiya

CEO & Co-Founder · SurgePV

Keyur Rakholiya is identified by SurgePV as its CEO and a company co-founder. His SurgePV author page lists only role information that can be tied to the public profile below; credentials, project totals, testing claims, media appearances, and speaking engagements are not asserted without retained evidence.

Editor
Rainer Neumann
Rainer Neumann

Editorial contributor · SurgePV

Rainer Neumann is credited as an editorial contributor on SurgePV content. This profile does not assert engineering credentials, project totals, software-testing experience, education, speaking engagements, or media citations because independent verification evidence is not retained in the publication record.

Get Solar Design Tips in Your Inbox

Join 2,000+ solar professionals. One email per week - no spam.

No spam · Unsubscribe anytime

Book Free Demo

Choose which optional technologies SurgePV may use. Essential storage remains active for security and requested features.