8 Solar Site Questions Teams Forget to Resolve

An unresolved question can become harder to answer after the team leaves the property. The team measured the roof, photographed the service equipment, and spoke with the customer. Back at the office, nobody can say whether the detached garage was in scope, whether the customer ruled out an equipment location, or whether the locked side yard was inaccessible or simply overlooked.

Another site visit is not automatically required. A customer call, document request, designer review, or qualified technical assessment may be the right next action. The failure is leaving without deciding which action is needed. Once the people, property, and physical context are no longer together, a small ambiguity can turn into a chain of partial messages.

Use a departure gate before anyone packs up. It is a short review of questions that physical presence makes easier to settle or classify. “Resolved” does not mean the sales rep has issued an engineering conclusion. It means the team has a usable answer, a captured record for the proper reviewer, or a named exception with a next action.

The solar site survey checklist covers roof, shade, electrical, measurement, access, and logistics subjects. The nine solar site-visit tasks beyond measurements covers the broader visit agenda. This guide owns the last few minutes: the resolution test that stops an observed detail, customer preference, access limit, or evidence failure from leaving the property without a status and owner.

This is a desk-research operating guide for multi-jurisdiction solar teams. It is not site, safety, structural, electrical, engineering, permitting, utility, code, financial, contract, legal, or tax advice. Each live project still needs the responsible people, safe methods, permissions, source records, and external approvals appropriate to its location and deliverable.

Why do solar teams forget questions while they are on site?

One failure mode to inspect is a visit organized around capture tasks without a departure decision record. A checklist can show that someone took a photo or discussed a subject without showing what was concluded, what remains uncertain, or who acts next. Time pressure and split roles then hide gaps until design or proposal work tests the package.

A site visit compresses several jobs into one appointment. Someone manages the customer conversation. Someone photographs and measures. Another person may inspect only a limited area. The customer introduces a future load, reroof plan, or access condition halfway through the visit. Each person can finish their assigned task while the project as a whole remains unresolved.

The U.S. Department of Energy’s photovoltaic system design overview explains that a PV system may include modules, mounting structures, power electronics, and storage. That broad system context matters because a site conversation can affect more than the visible roof. Equipment, energy, electrical, and documentation questions can belong to different reviewers. The DOE page is general information, not a site-visit rule or project conclusion.

The departure gate should use four resolution states:

These are authored operating states, not an industry standard. Their value is behavioral. If “captured for review” and “resolved” produce identical customer language or let the same downstream work proceed, the labels are not controlling anything.

Inspect these three potential failure patterns.

First, a capture field gets mistaken for a decision. A photo confirms that an image exists. It does not necessarily show the needed subject, establish permission, or answer what the customer wants.

Second, the team tries to close a controlled question to appear helpful. A rep sees a physical condition and offers a conclusion that belongs to a responsible technical or external authority. The departure gate should make escalation feel like completion of the right task, not a failure to know everything.

Third, the open item has no owner. “We will check” sounds reassuring at the property and becomes useless at the office. A real record names who will check, what they need, what cannot proceed, and when the customer will hear an update.

Which eight questions should be resolved before departure?

Resolve eight questions before leaving: the exact project boundary, access and permission limits, differences from pre-visit records, planned site changes, customer location preferences, evidence usability, questions requiring qualified review, and ownership of the next customer update. Each answer should end in a resolution state, not a vague note that someone will follow up.

1. Which property, structures, service, and account are actually in scope?

Confirm the physical and record identity before discussing conclusions. Name the address or controlled site ID, included structures, relevant meter or service, and energy account or customer record where applicable. If the customer mentions a detached building, shared service, accessory unit, tenant account, or future structure, record whether it belongs to the current request.

Do not infer ownership, legal rights, or electrical relationships from proximity. A meter near a building may not answer which account or project it serves. A customer statement can be recorded as stated information, but a responsible role may still need documentation or external confirmation.

The departure test is simple: could someone who never visited distinguish the intended property, structures, service context, and records from nearby alternatives? If not, the team has an identity exception rather than a complete visit.

2. What access and permission boundaries applied today?

Record where the team could and could not go, what it had permission to photograph or inspect, who controlled access, and whether any safe-access or privacy condition limited capture. “Not photographed” is ambiguous. It could mean inaccessible, unsafe, prohibited, irrelevant to the stage, or forgotten.

Never use a departure gate to pressure someone into unsafe work or access beyond permission, training, policy, or legal authority. When a subject could not be captured, record the reason and route the gap. The next action may be a scheduled revisit with the proper people and controls, a document request, an alternate evidence source, or a change to the requested output.

Permission from a property contact does not establish safe access or competence to inspect electrical equipment. OSHA’s electrical hazard overview describes serious electrical hazards in its U.S. workplace context. Do not open equipment, approach exposed energized parts or enter a roof area merely to complete this form; route capture through the employer’s applicable safe-work process and qualified people. Other jurisdictions have their own requirements.

Access also includes future project work. A customer may have strong preferences about driveways, gates, interior rooms, landscaping, pets, operating hours, tenant areas, or sensitive business spaces. A sales rep should capture these constraints without declaring how installation will solve them.

3. What differs from the pre-visit project record?

Compare the live property with the remote imagery, customer record, preliminary layout, notes, and assumptions that shaped the appointment. Look for differences in structure identity, roof condition or use, obstructions, shade context, equipment, building work, energy records, occupancy, and customer objective.

Do not edit the pre-visit record silently. State the observed difference and attach its source. “Roof changed” is weak. “South addition visible during the 2026-08-30 visit is not shown in the linked imagery; current dimensions and roof status require review” tells the office what changed without claiming a technical implication the rep cannot establish.

The six site-visit findings that should change the sales conversation explains how material findings alter customer language. This question comes one step earlier. It asks the team to identify the discrepancy and its evidence before choosing the sales response.

NASA’s requirements-management guidance applies to NASA programs rather than solar projects. It discusses identifying, tracing, controlling, and managing changes to requirements. The narrow analogy is useful: when the requested project or governing input changes, the record should show the change and the affected work instead of relying on memory.

4. What is expected to change at the site before installation?

Ask about planned reroofing, repairs, additions, demolition, tree work, service changes, renovations, new loads, occupancy changes, equipment purchases, landscaping, or other site work that could affect the current request. Record who stated the plan, the expected event, and whether it is confirmed, tentative, or merely being considered.

The question is not “Will this definitely happen?” A sales rep may have no basis to verify that. Ask what the team should treat as existing, proposed, or unknown in the next design or proposal scenario. Then assign a verification trigger before affected work is released or represented as current.

Keep current and proposed conditions separate. If a customer is considering tree removal, do not let one model quietly assume removal while a proposal describes the present site. If a reroof decision is unresolved, record how that uncertainty limits the next output and who must review it.

5. Which location preferences or no-go areas could change the proposed scope?

Physical presence makes location conversations concrete. Ask the customer to identify visible preferences or prohibitions for array appearance, equipment areas, routing corridors, storage placement, parking, landscaping, access paths, or spaces used by occupants. Photograph or map the subject only with permission and within the team’s safe process.

Treat preferences as inputs, not engineering decisions. “Customer prefers equipment on east wall” does not establish suitability, clearances, code compliance, utility acceptance, structural support, constructability, or final cost. The record should preserve the preference, reason where volunteered, affected area, and the reviewers who must test it.

Also distinguish “preferred,” “acceptable alternative,” and “not permitted by customer.” These labels change option design. A single pin on a photo cannot show whether the customer offered a first choice or imposed a hard boundary.

The seven homeowner questions for a solar site inspection covers the customer conversation itself. This departure question checks whether location answers were converted into an inspectable constraint record rather than left as spoken context.

6. Is the captured evidence usable by someone who was not here?

Before leaving, open the critical photos, sketches, measurements, recordings, and notes. Check identity, readability, orientation, units, endpoints, date, subject, and project association. Make sure the same site feature uses the same identifier across the roof map, photo index, measurement record, and exception list.

This is not a full design acceptance review. The receiving designer still decides whether the package supports the requested work. The on-site check catches defects that are easiest to repair while the subject and capture conditions remain available: a blurred label, missing measurement endpoint, blocked view, unmatched roof plane, or note that says “left side” without an orientation.

NASA’s technical-data management guidance discusses planning how technical data are acquired, identified, accessed, managed, protected, and used in NASA work. Solar teams need their own security, privacy, retention, and evidence policies. The transferable point is limited: a file’s existence does not establish its identity or proper use.

Use the seven controls for missing solar site data when the receiving design team needs a complete acceptance rule. The departure gate owns field repair while the team is present. The receiving rule owns whether the final package may enter the requested design stage.

7. Which open questions require qualified or external review?

Separate a missing fact from a controlled judgment. A customer may answer who owns a document or whether an area is off limits. A designer, engineer, electrician, structural reviewer, roofer, utility, authority, lender, insurer, or other responsible role may need to decide what an observed condition means for a particular deliverable.

Write the question in decision form. “Panel?” is not routable. “Which responsible reviewer must determine whether the documented service condition supports the requested electrical workflow, and what additional evidence do they require?” makes the boundary explicit without asking the sales rep to perform the review.

NASA’s interface-management guidance concerns NASA interfaces, responsibilities, and interactions, not solar-site practice. As a cross-domain analogy, it supports naming what crosses a role boundary, who receives it, and how an unresolved interaction is controlled.

Do not promise that a reviewer, authority, or utility will accept a condition. Record the source evidence, jurisdiction where relevant, requested decision, responsible party, and blocked or limited work. Escalation is a completed on-site outcome when the team has captured what the reviewer needs and made no unauthorized conclusion.

8. Who owns every open item, and what may the customer expect next?

End the visit by reading back the open items, owners, and next communication event. “The office will follow up soon” lacks an actor and a trigger. A useful record says who will request the missing document, who will review the site evidence, what output remains limited, and when the customer will receive a status update even if the underlying decision is still pending.

Separate the communication event from the final answer. A rep can commit to an update after an internal review meeting without promising that the design, price, schedule, equipment, or approval will take a particular form. If the timing depends on a customer document or external authority, say so.

The clear proposal plan after a solar site visit owns the full path to a proposal decision. This question is narrower. It closes the visit with accountable next actions whether the outcome is design work, evidence collection, alternate scope, qualified review, or a decision not to advance yet.

Use this question map during the gate:

How should a sales rep run the departure gate?

Run the gate after capture but before equipment is packed away. Gather the visit participants, open the project record, and test each of the eight questions. Record one resolution state per question, repair easy evidence defects, assign controlled decisions, identify blocked work, and give the customer a bounded recap with a named next communication event.

Use this numbered process:

1. Pause new discussion. Tell the customer and team that the visit is entering a short closure review. New scope can still be recorded, but it must not disappear into packing-up conversation.
2. Open the current project identity. Confirm the site, customer record, structures, service context, and visit purpose before reviewing files.
3. Walk the eight questions in order. Start with identity and access, then compare records, capture future changes and preferences, inspect evidence, route controlled questions, and close ownership.
4. Assign one state to each question. Choose resolved on site, captured for review, assigned open item, or deliberately out of scope. Do not use a generic “done” state.
5. Repair what can be repaired safely. Reopen a blurred photo, clarify a measurement label, identify a roof plane, or attribute a customer statement while the source remains available. Stay within permission, training, role, and safety limits.
6. Convert every remaining gap into a decision record. Name the question, evidence, owner, next action, due event, and the work it blocks or limits.
7. Read back the customer-facing recap. Separate confirmed facts, recorded preferences, questions under review, customer actions, team actions, and the next communication event.
8. Freeze and hand off the visit version. Timestamp the package, identify its contributors, and send it through the team’s receiving workflow. Later changes should create a visible new version or exception update.

Keep the gate short by doing evidence organization throughout the visit. A departure review should catch and classify, not force the team to label dozens of anonymous files from scratch. If the gate routinely becomes a second survey, the capture workflow needs attention.

NASA’s configuration-management guidance discusses identifying configurations, controlling changes, tracking status, and auditing configuration information for NASA programs. It is not a solar rule. The practical analogy is that a departure package should have a recognizable version when later design and proposal work depends on it.

Copy-ready on-site resolution board

Copy this asset into a mobile form, project ticket, or visit record. Adapt the fields to your project types, roles, permissions, and jurisdictions.

ON-SITE RESOLUTION BOARD

Project ID:
Site or controlled property ID:
Visit date:
Visit purpose:
Visit lead:
Customer or property contact present:
Other contributors:

QUESTION 1: PROJECT BOUNDARY
Structures in scope:
Service, meter, or account reference:
Resolution state:
Source and evidence:
Open item and owner:

QUESTION 2: ACCESS AND PERMISSION
Areas accessed:
Areas not accessed:
Reason and access controller:
Resolution state:
Safe and authorized next route:

QUESTION 3: PRE-VISIT DIFFERENCES
Prior record or assumption:
Observed difference:
Evidence reference:
Affected work:
Resolution state and owner:

QUESTION 4: PLANNED SITE CHANGES
Stated future change:
Speaker and date:
Status: confirmed / tentative / considered / unknown
Affected scenario or task:
Verification trigger and owner:

QUESTION 5: LOCATION PREFERENCES
Preferred area:
Acceptable alternative:
Customer no-go area:
Reason, if volunteered:
Required reviewer:

QUESTION 6: EVIDENCE USABILITY
Critical files opened and checked:
Unreadable or unidentifiable item:
Repair completed on site:
Recapture ticket and owner:

QUESTION 7: CONTROLLED REVIEW
Decision-shaped question:
Indexed evidence attached:
Responsible reviewer or authority:
Work blocked or limited:
Escalation event:

QUESTION 8: OWNERSHIP AND CUSTOMER UPDATE
Customer action:
Team action:
Open-item owners:
Next communication event:
Language the team must not promise:

DEPARTURE RELEASE
Confirmed facts read back:
Preferences read back as preferences:
Items under review named:
Package version and timestamp:
Visit lead sign-off:

Do not make every field mandatory for every visit. The requested stage should determine which subjects apply. The board works when an unanswered field changes the resolution state or routes a real exception, not when staff learn to enter “N/A” everywhere.

What if a question cannot be resolved while on site?

Classify it before leaving. Capture available evidence safely and with permission, name the decision that remains, assign the person or authority able to act, and record what work is blocked or limited. Give the customer a communication event rather than an unsupported answer. An explicit unresolved state is useful; an invisible assumption is not.

Choose the next route based on what is missing:

Illustrative example, not a customer case

A sales rep and site assessor visit a home for a survey-driven proposal update. The project record identifies the main house, but the customer asks whether a future workshop can be included. The workshop has not been built. The customer also prefers equipment behind a locked side gate, and the assessor’s photo of one equipment label is unreadable.

At the departure gate, the team keeps the current house as the confirmed project boundary and records the workshop as proposed scope requiring a separate input and acceptance decision. The customer preference for the gated area is mapped, along with the fact that the area was inaccessible during this visit. Nobody calls the location suitable.

The assessor recaptures the unreadable label because the subject is safely accessible and the customer has permitted the photo under the team’s process. The new file is checked and linked to the equipment ID. The location preference routes to the responsible design and technical reviewers, while the workshop question routes to the sales and intake owners.

The rep tells the customer that the team will first confirm whether the workshop belongs in the same request and will review location options using the accepted site evidence. The next communication event is scheduled after that internal review. The rep does not promise a final layout, equipment position, project price, schedule, production figure, or external approval.

The example demonstrates classification, not project suitability. A live project may require different evidence, safe-access rules, professional review, or authority involvement.

Audit whether the gate changes behavior

Count internal signals only after defining them. Useful observations include questions repaired on site, items captured for review, ownerless gaps found at handoff, customer recaps corrected, requests reopened after new scope, and downstream returns tied to departure-package defects.

Do not invent an external benchmark or assume fewer open items always means better work. A team may close more questions because it improved preparation, or because reps started overstepping their authority. Review a sample of “resolved” items for source quality and decision ownership.

Compare by question type. Repeated identity failures point to pre-visit intake. Repeated unreadable photos point to capture training or tooling. Repeated location surprises may require a better customer pre-brief. Repeated technical conclusions by sales require role-boundary correction, not a longer checklist.

The departure gate earns its place when the office can tell what happened without recreating the visit, while customer-facing language remains honest about what is still under review.

Where should software support the departure gate?

Evaluate whether the selected implementation can hold the visit identity, eight question states, indexed evidence, customer preferences, open-item owners, blocked work, next communication event, and package version. Field requirements and task routing need demonstration in the actual implementation; they are not asserted SurgePV capabilities. Software cannot grant site permission, make unsafe access acceptable, verify every statement, perform qualified review, or guarantee external approval.

Start with the resolution rule, then configure the form. A required photo field cannot tell a rep whether the image is readable. A status menu cannot decide whether a question belongs to the customer, designer, engineer, electrician, utility, or authority. Notifications cannot help if the “owner” is a generic department nobody controls.

The solar designing workspace belongs after the relevant project basis has been accepted for the requested work. A model can use site inputs, but opening the model does not verify their identity, repair a missing permission record, or turn a stated future change into a confirmed condition.

SurgePV supports 3D roof modeling, solar array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, and review. The software does not replace approval by the responsible engineer, authority, lender, insurer, or utility.

Keep a clean boundary between the departure record and the downstream output. The record says what the team resolved, captured, assigned, or excluded at the property. Design and technical roles decide how that basis affects their work. Customer-facing roles decide what can be communicated, subject to policy and review. External decision-makers retain their own authority.

The strongest departure gate is modest. It does not force a sales rep to solve every solar question beside the customer’s driveway. It stops the team from driving away without knowing which questions are solved, which evidence is ready, which decisions belong elsewhere, and who speaks to the customer next.

Frequently Asked Questions

What should a solar sales rep resolve before leaving a site visit?

The rep should confirm the project identity, access record, differences from pre-visit information, customer preferences that affect scope, usability of the evidence package, questions requiring qualified review, owners for open items, and the next customer communication. The rep does not need to answer controlled technical questions, but must keep them visible and assigned.

Does every solar site question need an answer while the team is there?

No. Some questions require design, engineering, structural, electrical, utility, authority, legal, financing, or other qualified review. The on-site requirement is to classify the question correctly, capture the evidence that can be gathered safely and with permission, assign an owner, state what work is blocked or limited, and avoid presenting an assumption as a conclusion.

Who should run the departure gate at a solar site visit?

Assign one visit lead to run it, even when several people collected information. The lead checks each question with the customer-facing and field participants, records its resolution state, and confirms owners before departure. The receiving designer or technical role still decides whether the package supports the requested downstream work; the visit lead does not approve design sufficiency.

Can photos prove that a solar site question is resolved?

Only when the question calls for visual evidence and the images are identifiable, readable, appropriately captured, and connected to the relevant site feature. A photo cannot by itself verify customer intent, establish legal permission, approve engineering, or resolve every hidden condition. Record what the image shows, its source and date, and any limitation that remains.

Where can SurgePV support the on-site-to-design workflow?

SurgePV can support 3D roof modeling, array layout, shading analysis, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, and review. The software does not replace safe site practices or approval by responsible engineers, authorities, utilities, lenders, or insurers.