Quick Answer
A solar project data request pack groups information by the decision it supports: consumption and tariff evidence for energy scenarios, site evidence for layout and access, electrical information for configuration, and ownership or timing details for delivery. Request only what the current stage needs, explain why, and record what remains unverified.
A strong solar data request is not a long list of documents. It is a clear explanation of which evidence will change the next decision. When customers understand why a bill, site photograph, roof plan, or operating schedule matters, they are more likely to send useful material and less likely to receive a proposal built on guesses.
Installers and EPCs need information at different times. An early feasibility discussion may only require an address, customer goal, and broad consumption picture. A detailed proposal may need more current tariff and site information. Technical, procurement, permit, and field decisions can require different evidence again. The error is not beginning with incomplete data; the error is failing to label the gap and its consequence.
Direct Answer
Build the request around the decision you are making next. Ask for consumption and tariff evidence, site and electrical information, ownership and timing details only to the level needed at that stage. Explain the purpose of each request, record its source and date, and route missing high-impact items before the project moves to a later release.
Ask for a Decision Before Asking for Documents
Begin with the customer’s objective. Are they exploring whether PV is plausible, comparing project options, preparing a budget, reviewing a facility investment, or moving toward delivery? The answer determines what to request now and what can wait. It also gives a sales conversation a useful centre: the team is not collecting paperwork for its own sake; it is preparing information for a specific choice.
The Solar Energy Technologies Office offers public material on solar technologies and deployment. It cannot supply the current operating, property, utility, or authority information needed for an individual project. Make that distinction clear in the request rather than implying that public data can resolve a site-specific question.
State the current purpose in the message: “To prepare an indicative option,” “to verify the consumption basis for the financial scenario,” or “to complete the technical review for the stated configuration.” The customer then sees which request is urgent and which is optional background.
Group Requests Into Four Evidence Families
Grouping reduces a scattered back-and-forth. It also helps the team spot what it has not requested.
| Evidence family | Examples | Decision supported |
|---|---|---|
| Energy and tariff | Bills, interval data where available, planned load change, current tariff information | Consumption basis and financial scenario |
| Site and physical | Address, photographs, roof plans, survey materials, access notes | Layout, shading treatment, access, scope |
| Electrical and technical | Service information, existing equipment details, single-line material where available | Configuration and review path |
| Ownership and delivery | Owner or tenant context, approval contacts, roof works, operating windows | Authority, schedule, and scope boundaries |
The categories do not mean every project needs every item at first contact. They give the requester a way to choose deliberately. For a homeowner exploring PV, the most useful first items may be a current bill, address, and note about planned roof works. For a commercial project, interval data, decision stakeholders, operating hours, and access constraints may be central much earlier.
Explain Why Electricity Information Matters
Bills and interval data are often requested with no explanation. Tell the customer that usage information helps the team understand the consumption basis behind an energy or financial scenario. It does not guarantee future bills or savings. Current and future consumption can change with occupancy, operating hours, electrification, equipment replacement, tariff revisions, export treatment, and many other factors.
NREL’s PVWatts tool illustrates the same wider principle: PV output is an estimate based on stated inputs and assumptions. A project scenario should record which consumption source and tariff basis were used. If only an annual total is available, say that the load shape and other conditions remain to be checked where they matter.
Ask for the billing period and the whole bill rather than a cropped total where possible. A customer may redact personal data if needed, but the team should be able to identify the period, units, tariff-related information, and account context relevant to the proposed analysis. If a business expects a major load change, request a short description and timing. That context may be more valuable than another month of historic bills.
Request Site Evidence in Layers
Public imagery and an address can support a quick conversation. Do not call them a survey. Explain that photographs, roof plans, access details, and field verification answer different questions. A photograph may show a visible vent or parapet; it may not establish a final dimension, hidden condition, structural suitability, or safe access approach.
Ask customers for simple, useful material: wide roof views from ground level where safe, photos of obstructions and electrical equipment, any existing roof plan, information about planned repairs, and known restrictions on access or working hours. Do not ask customers to enter unsafe areas or make technical determinations. If a question needs a site professional or qualified review, route it accordingly.
Record what the customer provided and when. A photograph from several years ago can be useful context but may not show current conditions. A site drawing may have an unknown revision. These are not reasons to discard all early evidence. They are reasons to match the confidence of the output to the evidence behind it.
Make Electrical Requests Proportionate
Electrical details are easy to request badly. “Send all electrical information” creates confusion. Instead, explain the decision: “To check the proposed configuration and identify what needs site verification, please share photographs of the service and existing equipment from a safe distance, plus any available drawings or recent electrical information.”
Do not ask the customer to diagnose service capacity, label conductors, or confirm compliance. If the project needs those answers, state that a suitable technical review or survey will be required. The data pack is a route to the right evidence, not a way to transfer specialist judgement to the buyer.
Where an existing PV or storage system is involved, request the equipment model information, monitoring records if relevant and permitted, original documentation if available, and the customer’s stated objective for the change. Keep clear that compatibility, safety, code, utility, and warranty questions may require separate review.
Keep Project Inputs Connected to Solar Design and Proposals
See how SurgePV brings solar design, Shadow Analysis, generation and financial scenarios, and customer proposals into one workflow.
Book a DemoBring an active intake or handoff question to the walkthrough.
Include Ownership, Access, and Timing Early
Many design rework problems originate outside a model. A tenant may not control the roof. A facility may have a shutdown period. A roof replacement may be planned. A buyer may need a landlord, lender, board, or procurement team involved. A data request pack should invite that context early, in plain language.
Ask: who needs to approve next steps; are there planned building works; are there access limits; is a construction window already known; and has the customer set a decision date? These questions do not predict an outcome. They help the installer avoid offering a sequence that ignores the customer’s real constraints.
If an answer creates a material condition, put it in the project’s constraint record rather than leaving it only in the request email. The solar project constraint register can track owner, impact, deadline, and closure evidence. This keeps the customer-facing question connected to the work it triggered.
Create a “Good Enough for This Stage” Rule
Teams can become paralysed if they wait for every requested item. Set a stage rule. For an early screen, a current address, stated objective, and broad usage picture may be adequate if the output is clearly indicative. For a detailed proposal, the team may need current consumption, a more defined site basis, and visible financial assumptions. For later releases, use the evidence and review needed for that specific action.
The rule should never be “we have enough because the customer is waiting.” It should be “we have enough for this named decision, and the remaining gaps are visible.” That language protects momentum without converting uncertainty into a hidden commitment.
Keep a short evidence-status list: received and reviewed, received but unclear, requested, not applicable, or required before the next release. The list is more useful than a folder full of attachments because it tells the next person what the materials actually support.
Make the Request Easy to Complete
Use a message that separates essential from helpful items. Explain alternatives: if interval data are unavailable, send recent bills; if a roof plan is unavailable, share safe ground-level photos and note planned building works; if the customer does not know a tariff detail, send the full bill or contact details for the relevant utility discussion where appropriate.
Tell the customer how to send material securely according to the organisation’s process. Avoid promising that any particular document will lead to a specific system size, price, approval, or outcome. The request is an input step, not a guarantee.
Make the response time expectation realistic. If the team will review the materials before proposing a next action, say that. If a survey is likely, explain what it will verify. A customer is more likely to help when the process is transparent.
Turn Received Data Into a Project Record
Receipt is not review. Once evidence arrives, log the source, date, scope, and limitations. Connect it to the appropriate design basis and proposal revision. If a bill conflicts with a prior value, record the discrepancy rather than overwriting the old number without explanation. If a site image introduces an obstruction, route the impact question before sending a revised layout.
This is where a connected Generation & Financial Tool workflow can help teams trace which inputs underpin a scenario. The tool does not validate customer documents or local tariffs by itself; the team must still assess whether the source is appropriate for the decision.
At handoff, include not just the documents but the evidence-status summary. Procurement, project management, and field teams need to know whether a file is current and whether an open condition can change the work. A folder name alone cannot communicate that.
Review and Improve the Pack
After a few projects, review which requests created value and which created friction. If designers routinely ask for information not included in the initial pack, add a clear reason to the next version. If customers routinely cannot provide an item, offer a practical alternative or move it to a later stage. The goal is not maximum data collection. It is reliable decision support.
Also watch for requests that are too technical for the customer. Reframe them around observations, documents, or contacts the buyer can reasonably supply. The request pack should reduce ambiguity, not make the customer responsible for technical validation.
A Ready-to-Use Request Sequence
Use this order in an intake email or portal:
- State the decision and the customer goal.
- Request the smallest essential evidence set.
- Explain what each item will help the team assess.
- Identify optional material that can improve the next stage.
- State what remains subject to verification.
- Name the next action after review and who will own it.
That sequence works because it makes the customer a participant in an understandable process, rather than a source of files for an unexplained internal workflow.
Ready to Turn Project Inputs Into a Clear Solar Proposal Process?
Book a free SurgePV demo to explore connected solar design, shadow analysis, generation and financial modeling, and Solar Proposals.
Book a Free DemoFrequently Asked Questions
What should be in a solar data request pack?
Include only the evidence needed for the next decision: customer objective, consumption and tariff basis, site and roof information, electrical context, and ownership or schedule details where relevant. Explain why each item is requested.
Is an annual electricity bill enough for solar design?
It can support an early consumption discussion, but its suitability for later design or financial decisions depends on the project. Load timing, future changes, tariff details, export treatment, and site evidence may also matter.
Can a customer’s roof photograph replace a survey?
No. It can provide useful early context, but it does not replace the appropriate field verification or qualified review for site-specific decisions.
How should missing documents be handled?
Record what is missing, how it could affect the next decision, who will obtain or verify it, and the latest stage by which it must be resolved. Do not present an assumption as confirmed just because a document is unavailable.
