Quick Answer
A solar project is ready for design when the team has named the decision, attached the evidence that controls it, recorded gaps, and agreed who will resolve them. A lead record alone is not a design brief.
A good solar project intake does not collect every available fact. It collects the evidence needed to decide whether the next piece of work is justified and safe to start. For an installer or EPC, that may mean deciding whether to schedule a survey, prepare an indicative layout, request interval data, involve an engineer, or explain that a proposal must wait. It does not mean treating an enthusiastic enquiry as a confirmed project scope.
This article is desk research for solar professionals. It is a process guide, not a substitute for field inspection, local code, utility rules, engineering judgment, manufacturer documentation, or a contract. Its central discipline is simple: distinguish what the customer has said from what the project team has verified.
Direct Answer
Build intake around the next decision. Capture the request, attach its source material, identify conditions that could change the answer, and assign each open question to a person and date. Only then choose whether the project can enter preliminary design, survey planning, or a different review path.
Intake Is a Decision Filter, Not a Data Dump
An inbox, CRM, and shared drive can hold plenty of project information while still leaving the design team unable to act. A contact name and roof photo do not establish the customer’s electricity objective. An annual consumption total does not describe when a commercial facility consumes power. A property address does not confirm access, roof condition, electrical capacity, setbacks, or authority requirements.
Start by writing one sentence that describes the decision the team is being asked to support. Examples include: “Determine whether a preliminary residential layout is worth presenting,” “prepare a commercial screening scenario from interval data,” or “identify information needed before a battery-backup conversation.” That sentence changes the intake. It tells the team which evidence is decision-changing and which information can wait.
The U.S. Department of Energy Solar Energy Technologies Office publishes broad information on solar technologies and deployment. It provides useful background, but it does not confirm conditions for a particular customer. The live project record should link to current bills, site materials, utility correspondence, equipment documents, authority instructions, and survey evidence.
Build a Brief That Another Person Can Use
The person answering the enquiry may not be the person designing the project. A brief therefore has to work without a verbal handoff. It should contain enough context for the recipient to understand the requested output, the evidence behind it, and the limits of that evidence.
| Brief element | What to record | Why it matters |
|---|---|---|
| Project objective | The customer’s stated reason for considering solar | Prevents a generic design from being mistaken for decision support |
| Site identifier | Address, facility name, or portfolio reference | Connects documents to the correct location |
| Requested deliverable | Screening, concept, proposal, survey, technical review | Sets a proportionate work level |
| Source materials | Bills, interval data, photos, drawings, notes, documents | Lets the reviewer assess evidence quality |
| Known conditions | Access limits, roof work, operating hours, deadlines | Shows constraints early |
| Open questions | Missing or conflicting details, with owner and due date | Stops assumptions becoming silent facts |
The “requested deliverable” field is frequently overlooked. A customer can ask for a quote when the responsible next output is actually a survey plan or an evidence request. The team should say that plainly. A clear explanation of what must be checked builds more trust than an early number presented with hidden qualifications.
Ask Questions in the Order They Change Work
An intake questionnaire becomes frustrating when it asks for everything at once. Prioritize questions by the decisions they unlock. The following sequence is useful because it separates commercial context from technical verification.
First: What Is the Customer Trying to Decide?
Ask whether the conversation concerns bill reduction, energy-cost exposure, operational resilience, a development requirement, emissions reporting, available roof use, or another stated objective. A battery conversation requires different follow-up from a grid-tied PV screening. A commercial project with a demand-charge question may need interval data before any financial scenario is meaningful.
Do not rewrite a customer objective as a guaranteed result. “Reduce bills” is a decision objective; it is not evidence that a specific system will deliver a specified saving. Record the objective in the customer’s language, then identify the data required to examine it.
Second: What Evidence Already Exists?
List the source files and their dates. For consumption, note the billing period, whether the record is a full bill or summary, and whether the site has changed since the period shown. For a drawing, note who produced it and whether it represents existing conditions. For photos, note who took them and when. This is not pedantry: an old site photo can conceal a major condition, and a partial bill can be misread as annual use.
NREL’s photovoltaic research collection is a useful technical reference point. It does not validate a project input. A file becomes usable project evidence only when its relevance, date, and source are clear to the reviewer.
Third: What Could Invalidate a Preliminary Output?
Make a short “stop or verify” list. It might include a planned re-roof, uncertain tenancy, restricted roof access, a service upgrade question, lack of electrical data, conflicting customer expectations, unusual operating loads, or a jurisdictional issue. These conditions do not always stop work. They decide what type of work is responsible next.
For example, a design team may create an initial layout from available imagery while labeling roof dimensions, obstructions, and access as provisional. That is very different from releasing a construction package. The record should name the boundary clearly.
Turn Intake Evidence Into a Connected Design Record
Explore how SurgePV supports solar teams as they move from project inputs through design, analysis, and a customer-facing proposal.
Book a DemoDiscuss the workflow around an active project in a live walkthrough.
Use Three Statuses for Every Important Input
A mature intake does not pretend that information is either present or absent. Use three statuses:
- Confirmed: supported by an identifiable source that is current enough for the decision.
- Planning assumption: used to explore a scenario but not yet verified.
- Required before release: an item that must be resolved before the specified output can be relied on.
This notation has practical value in a proposal. A salesperson can explain that a preliminary layout was prepared from available information while a survey is still required. A designer can see that a tariff is assumed rather than supplied. A project manager can tell whether a construction date depends on an unresolved authority or access condition.
Avoid the catch-all label “TBC.” It says that something is incomplete but not who will resolve it, which source is needed, or whether work can continue. A better entry says: “Electrical service rating: required before final inverter selection; owner: site assessor; evidence: panel photograph and qualified review.”
Route Work With an Explicit Outcome
At the end of intake, choose one outcome. A project can proceed to a preliminary concept, proceed to a site assessment, wait for customer evidence, require specialist or engineering review, or be closed as outside current scope. Every outcome should state the next owner and the next customer communication.
| Outcome | Appropriate when | Next action |
|---|---|---|
| Preliminary concept | Major assumptions are visible and acceptable for discussion | Produce an indicative, qualified scenario |
| Site assessment | Physical conditions control the next answer | Schedule survey and define questions to resolve |
| Evidence request | A missing bill, data set, drawing, or authority answer blocks the decision | Ask for the specific document and explain why |
| Specialist review | The issue exceeds the intended workflow or authority | Route with the evidence and unresolved question attached |
| Close or defer | The project does not currently meet the team’s criteria | Record the reason and communicate it respectfully |
This routing step is where Solar Designing can be helpful. A connected platform can keep design inputs, analysis, and outputs together. It cannot decide whether an input is truthful, whether a roof can be accessed safely, or whether a local rule has been met. Those remain responsibilities of the appropriate people and evidence.
Keep the Customer Conversation Honest
Intake affects conversion because it shapes the first technical promise. Resist phrases such as “this will fit,” “your savings will be,” or “we can install by” when the underlying condition is still open. Better wording is specific: “We can prepare an indicative option once we receive the latest bill,” or “The layout is preliminary until the site assessment confirms roof features and access.”
Specific qualification is not weak selling. It tells the customer what they can expect next and what they can do to help. It also prevents a later survey finding from being framed as a surprise when the team never had the evidence to rule it out.
Audit Intake Quality With Returned Work
Every time a designer, surveyor, engineer, or project manager returns work because a brief is missing something material, log the reason. Over time, the reasons show which intake question, file request, or ownership rule needs improvement. A company may discover that commercial enquiries repeatedly lack interval data, that roof photos omit the electrical service, or that sales notes do not record the customer’s actual decision date.
Do not turn that internal learning into a universal benchmark. Project types and markets differ. Use it to improve the next brief: add a targeted request, define a better evidence example, or change the route for a class of project.
Practical Next Steps
- Replace “new lead” with a decision statement and requested deliverable.
- Mark every important input confirmed, assumed, or required before release.
- Assign an owner and date to each question that can change the next output.
Give Your Solar Design Team a Better Starting Point
Book a free SurgePV demo to see connected project design, Shadow Analysis, generation modeling, and Solar Proposals.
Book a Free DemoFrequently Asked Questions
What information is needed before a solar design begins?
Start with the purpose of the output, a reliable site identifier, available consumption or operating evidence where relevant, stated scope, known constraints, and a list of questions still open. The exact requirements depend on whether the team is preparing a screening concept, proposal, permit package, or construction release.
Can a customer conversation replace a site survey?
No. A customer conversation can create a useful first brief, but it cannot verify roof condition, geometry, access, electrical service, structural matters, authority requirements, or utility conditions. The record should state what field work or qualified review remains.
Who owns missing intake information?
Assign each material gap to a named role or person. The owner may request a document, conduct a survey, ask a technical question, or route the issue for specialist review. A shared label such as “sales” or “design” does not establish accountability.
