Solar Project Data Request Pack: Ask for the Right Evidence Before Design

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. Explain why a bill, site photograph, roof plan or operating schedule matters and how it will be used. Whether that improves response or proposal quality should be evaluated from actual project records, not assumed.

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.

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.

This desk-research worksheet does not establish a site survey, engineering approval, tariff determination, permission to obtain utility records or a jurisdiction’s privacy requirements. Keep collection and review responsibilities with the appropriate project roles.

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.

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.

PVWatts estimates generation from site and system inputs and publishes limitations on how site-specific conditions are represented. Its generation estimate is distinct from a customer’s load and tariff analysis. A financial scenario should record its consumption source and tariff basis separately; a bill is not a physical generation-model input by default. If only an annual total is available, say that the load shape and other conditions remain to be checked where they matter.

Explain which bill fields are needed: period, units, relevant consumption and tariff information, and enough permitted context to match the correct meter or site. Request a full bill only when needed for that analysis and use the organization’s suitable transfer process. Explain what unnecessary personal or payment information can be redacted without removing needed fields. Do not request passwords or unrestricted utility-account access. 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 climb onto roofs, open electrical enclosures, remove covers, approach exposed conductors, enter unsafe areas or make technical determinations. Collection must be limited to what can be obtained safely and appropriately; the responsible professional gathers specialist evidence. 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.

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.

When evaluating generation and financial modeling, ask how your team would identify the source, period and revision behind an actual scenario. Confirm current capabilities rather than assuming automatic document validation or tariff lookup. The team must assess whether the source is appropriate for the decision.

Use the project evidence register to record the received source and its permitted decision use. 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:

1. State the decision and the customer goal.
2. Request the smallest essential evidence set.
3. Explain what each item will help the team assess.
4. Identify optional material that can improve the next stage.
5. State what remains subject to verification.
6. Name the next action after review and who will own it.

Treat this as a proposed sequence. Check which requests remain unclear or repeatedly produce unusable evidence, then revise the pack accordingly.

For an actual product evaluation, bring a representative intake and missing-evidence question to a guided demo. Keep your team’s collection, technical review and release responsibilities explicit.

Frequently Asked Questions

What data should an installer request before a solar proposal?

Request the customer objective, usable consumption and tariff information, site and roof evidence available at that stage, electrical details relevant to the concept, ownership or approval context, and timing constraints.

Should a solar team wait for every document before starting?

A screening discussion may use clearly labeled preliminary inputs when appropriate for its purpose. Required evidence and qualified review still govern later pricing, technical, procurement, permit and field decisions. A deadline or disclaimer does not turn missing evidence into a confirmed fact.

What should be in a solar data request pack?

Include 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 and record its status.

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. Bills alone do not validate a layout or electrical configuration.

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 stage by which it is required. Do not present an assumption as confirmed because a document is unavailable.