Answer
A weekly solar pipeline review should verify opportunity identity, stage evidence, current proposal and source records, customer-owned next events, company-owned work, design and operations capacity, commercial and compliance risks, forecast treatment, and explicit action ownership. The meeting should produce decisions, not narration: advance, hold, return, reroute, revise, close, or escalate each selected opportunity with dated evidence.
Illustrative meeting scenario, not a real team result: The meeting begins with thirty open opportunities and ends with thirty spoken updates. One proposal is waiting for a design nobody requested correctly. Another is marked “verbal yes” even though the customer asked for a new option. A third still carries an old price. The pipeline moved across the screen, but no work changed ownership.
A weekly review earns its place when it resolves decisions the ordinary workflow cannot. The manager verifies evidence, exposes blocked interfaces, reconciles demand with capacity, separates customer action from company action, and chooses a controlled disposition. Everything else belongs in the pre-read or the responsible system.
Adapt this proposed agenda to your actual stages, customer records and responsible systems. Professional approval, contact permissions and forecast policy remain with their designated owners; a pipeline meeting does not authorize a technical or contractual decision.
The solar sales KPI guide owns the broad metric catalog. Use this page to prepare and run the weekly decision meeting. The solar leadership scorecard covers cross-functional leadership reporting.
What should be true before a weekly solar pipeline review starts?
Before a weekly solar pipeline review starts, selected opportunities should have verified identity, a current stage basis, faithful customer wording, the released proposal version, material project changes, company-owned obligations, the next decision event, responsible owners, and known blockers. The pre-read should distinguish facts, interpretations, and unknowns. Return routine records with missing admission evidence for correction. Keep urgent safety, customer or other material escalations on the agenda even if the packet is incomplete; record the missing evidence and assign its owner.
The pipeline is not a list of potential revenue. It is a set of changing customer and project states that compete for sales, design, engineering, commercial, and operations attention. A stage can look current while the underlying design, price, customer direction, or proposal is stale.
DOE says in its homeowner solar guide that there is not a universal solar energy solution and discusses site, energy use, providers, costs, financing, utilities, and other decision context. The guide does not validate a deal or stage. It demonstrates why two opportunities carrying the same label may require different evidence and owners.
Use a meeting admission gate:
| Admission field | Evidence required | Return condition |
|---|---|---|
| Opportunity identity | Customer, property, market, branch, source, duplicates, responsible rep | Conflicting or duplicate identity |
| Stage basis | Defined entry event, observation date, source, required fields | Stage rests on a rep’s feeling or old activity |
| Customer state | Last faithful statement, requested help, decision participants, contact direction | Inferred objection replaces customer evidence |
| Current proposal | Released version, source versions, status, owner, material expiry | Missing, superseded, or privately changed artifact |
| Company-owned work | Answers, corrections, options, designs, documents, reviews, handoffs | Nobody owns work promised to the customer |
| Next event | Observable event, actor, dependency, date or trigger, exit | Generic “follow up” task with no decision job |
| Cross-team demand | Requested work, intake quality, queue, owner, return state | Resource request is incomplete or duplicated |
| Risk and exception | Technical, commercial, finance, authority, privacy, contact, contract state | Material issue is hidden inside notes |
Selection should be intentional. Bring records that need a decision, resource, escalation, material correction, forecast change, or closure. Do not make every representative recite every open item. A prepared exception view respects attention and makes it harder for important work to hide behind volume.
Freeze definitions before viewing the results
Define stages, age, inactivity, next event, qualified, committed, at risk, closed, returned, and forecast categories before the meeting. Record the definition owner and version. Otherwise the team can improve the chart by moving labels rather than changing evidence.
If a rule changes, preserve both the old and new cohort. Do not compare periods as though definitions stayed constant. Historical restatement may be useful, but it must be explicit and reproducible.
What should a sales manager review before the meeting?
Before the meeting, the sales manager should review ten items: data completeness, duplicate and identity conflicts, stage-entry evidence, proposal currency, customer-owned events, company-owned work, design and operations queues, commercial and professional risks, forecast-category exceptions, and overdue actions from the prior review. The manager should package only decisions that require shared attention, with sources and possible dispositions visible.
Preparation is not secret scoring. The manager is building a decision packet so the team can resolve the right interface. A private spreadsheet that introduces new stages or risk labels during the meeting creates another uncontrolled pipeline.
Use this pre-meeting checklist:
-
Validate the selected cohort. Apply the declared selection rule and record why each opportunity entered the review. Exclude records that need routine owner action rather than management attention.
-
Resolve identity and duplicates. Confirm customer, property, market, project, branch, referral source, and related opportunities. Decide which record is authoritative before comparing values or activity.
-
Test stage entry. Match the current stage to its required event and evidence. Return a record when the event is missing, expired, contradicted, or based only on an interpretation.
-
Verify the released proposal. Record the customer-facing version, source states, release date, owner, material assumptions, and any superseded link. The proposal version-control guide explains the broader artifact discipline.
-
Separate customer and company actions. A customer reviewing a proposal differs from a designer preparing a correction. Make the actor, dependency, and stop condition visible for each.
-
Inspect cross-team requests. Check design, engineering, electrical, site, finance, commercial, permitting, procurement, and operations work for complete intake, acceptance, return, queue, and ownership states.
-
Surface material changes. Identify changes in site, roof, usage, layout, equipment, shade, loss, yield, electrical, materials, price, finance, scope, schedule, incentive, authority, or customer requirement.
-
Review commercial and risk exceptions. Show discounts, nonstandard scope, finance questions, unsupported claims, contract issues, privacy or contact direction, approval conditions, and unresolved professional decisions to their responsible owners.
-
Compare forecast treatment with evidence. Show current category, entry basis, override, uncertainty, scenario, and changed facts without converting confidence into a guaranteed result.
-
Reconcile prior actions. Close, return, reroute, or escalate decisions from the previous meeting. Investigate repeatedly carried unowned tasks and assign the missing decision or evidence owner.
NASA’s configuration-management guidance discusses identification, change management, status accounting, and verification in NASA programs. It is not a sales method. The useful analogy is that a manager should identify the current opportunity and proposal state, material changes, status, and verification evidence without reconstructing them from conversations.
The Department of Energy explains that a module is one of many parts in a complete photovoltaic system. That general context does not validate a project. It supports checking dependencies when a seemingly small layout or equipment change affects modeled, electrical, material, commercial, and customer-facing records.
Which decisions belong in the weekly pipeline meeting?
Nine decisions belong in the weekly pipeline meeting: correct the record, validate or change the stage, assign company-owned work, secure a customer-owned next event, accept or return cross-team demand, resolve a material risk, change forecast treatment, close or pause the opportunity, and escalate a recurring interface failure. Each decision needs one owner, evidence, a clearing event, and a recorded disposition.
A meeting should not approve work outside the participants’ authority. It can identify the responsible decision and route a review packet. Sales managers coordinate the commercial workflow; they do not become engineers, electricians, lenders, tax advisers, privacy officers, contract reviewers, utilities, permitting authorities, or customers.
Use this decision matrix:
| Decision | Evidence on screen | Allowed disposition | Meeting must not do |
|---|---|---|---|
| Record correction | Conflicting field, authoritative source, affected systems | Correct, request source, hold, escalate | Pick the convenient value |
| Stage | Definition, entry event, customer state, required fields | Retain, advance, return, pause, close | Advance from optimism alone |
| Company work | Promised output, intake, owner, queue, dependency | Accept, return, reroute, schedule, stop | Ask the customer again while work is owed |
| Customer event | Customer wording, actor, trigger, contact direction | Record, clarify, pause, close | Invent a deadline or motive |
| Capacity | Accepted demand, responsible queue, capability, constraints | Prioritize, reroute, negotiate, reject | Promise unsupported delivery |
| Risk | Source, jurisdiction, owner, impact, options | Accept within authority, condition, escalate, stop | Treat silence as approval |
| Forecast | Category rule, evidence, scenario, override, uncertainty | Retain, move, remove, mark unknown | Turn a judgment into fact |
| Closure | Open obligations, customer state, suppression, stale links | Close, archive, reopen on event | Leave parallel tasks active |
| Systemic issue | Repeated return or escape pattern, owners, affected work | Assign corrective review and test | Blame one person from weak counts |
NASA’s technical-assessment guidance discusses measures, evidence, status, trends, variances, risks, and corrective actions in technical work. It does not prescribe sales reviews. The analogy supports a disciplined agenda: compare observed state with declared expectations, expose variance, decide action, and retain what changed.
Review constraints across the pipeline, not just deals
If many opportunities wait for the same missing site field, review the intake rule. If design returns cluster around one request type, inspect that interface. If proposals repeatedly carry stale prices after layout changes, repair the dependency and release process.
Deal-by-deal coaching cannot solve a shared system defect. The meeting should route recurring patterns to an improvement owner with an observation period and test. Do not announce a causal conclusion from a few visible examples.
Control the discussion with decision packets
Give each admitted opportunity a compact packet before the meeting. Include the decision requested, current evidence, conflicting evidence, responsible owners, affected customer promise, available dispositions, and the consequence of waiting. The packet should link to controlled records rather than copy sensitive data into another presentation.
The presenting representative should not need to retell the entire relationship. Start with the current decision and show the source that makes it necessary. If essential context is missing, return the item with a named requirement. Distinguish recollection from documented evidence and assign verification of any material gap.
Time boxes can protect attention, but the exit rule matters more than the clock. When the group cannot decide within the available evidence and authority, assign the evidence request or qualified owner and move on. “Discuss again next week” is not a disposition unless the record names what will be different.
Keep coaching separate when it does not change the current opportunity decision. A separate role-appropriate session can address discovery technique, note quality, customer communication or process use. The pipeline meeting should retain only the operational decision and evidence needed by responsible participants.
End each item by reading back four fields: disposition, owner, clearing event, and customer update. The record owner confirms every connected system that must change. If a proposal link becomes stale, a cross-team task closes, or communication pauses, those controls should not wait for someone to interpret the meeting notes later.
Keep pipeline decisions tied to current project and proposal evidence. Connect roof, layout, shade, yield, financial, electrical, material, and proposal versions while responsible sales systems control stages, forecasts, and communication.
Explore connected proposal workflowsHow should weekly pipeline health and forecasts be measured?
Measure weekly pipeline health with controlled events and declared cohorts: stage entries and exits, returned work, current next events, accepted cross-team demand, proposal changes, risk dispositions, action closure, pauses, archives, and valid reopenings. Keep counts, values, timing, and forecast categories separate. Do not invent universal targets, probabilities, conversion rates, velocity standards, or employee rankings from unvalidated fields.
The general solar sales KPI guide can help teams choose measures. The weekly meeting should use only definitions the team can trace. A dashboard number without a cohort, source, observation period, owner, and missing-data rule is a prompt for investigation, not a management fact.
Separate these states:
- Customer state: what the customer said, requested, corrected, authorized, paused, or declined.
- Project state: which site, design, model, electrical, material, commercial, and authority records are current.
- Work state: what the company owes, who accepted it, where it waits, and which event clears it.
- Opportunity state: the controlled sales stage and its entry evidence.
- Forecast state: the company’s governed scenario or category for a declared period.
- Communication state: recipient, purpose, channel, permission or approved basis, suppression, and next contact boundary.
One state should not silently stand in for another. A current proposal does not prove buying intent. A scheduled customer call does not prove technical readiness. A high forecast category does not approve a discount. A document view does not establish permission or understanding.
NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk while protecting individuals’ privacy. It does not establish employment or privacy compliance. It supports deliberate controls around access, collection, monitoring, retention, sharing, correction, deletion, and interpretation of customer and employee-linked data.
Do not rank representatives from raw activity, age, return, or conversion counts without qualified analysis. Territory, channel, project mix, customer mix, lead source, stage definition, data quality, capacity, season, and responsible declines can differ. Employment and compensation decisions need approved evidence, policy, and human review.
Treat forecast changes as versioned decisions
Record who changed a forecast state, what evidence changed, which definition applied, what uncertainty remains, and whether an override was used. Preserve the prior state for analysis rather than overwriting history.
Do not make arithmetic claims from mental estimates during the meeting. If the company calculates values, probabilities, weighted pipelines, capacity, or scenarios, use validated formulas with declared units and controlled inputs. This article supplies no universal formula or benchmark.
What copy-ready weekly pipeline review agenda can managers use?
Use a weekly agenda that joins cohort selection, definition changes, prior-action closure, deal exceptions, customer and company events, cross-team capacity, material risk, forecast treatment, systemic blockers, and a decision log. Each item should end with an allowed disposition, owner, clearing event, and update path. The record should survive after the conversation instead of becoming another set of private notes.
Copy-ready weekly solar pipeline review record
| Agenda field | Entry |
|---|---|
| Review id, observation date, market, branch, portfolio, chair, participants, and record owner | |
| Stage, age, next-event, risk, forecast, value, and cohort definitions with version and owner | |
| Selection rule and opportunities admitted, returned, or excluded with reason | |
| Prior decisions closed, overdue, returned, superseded, or escalated | |
| Customer identity, last faithful statement, decision participants, contact direction, and next event | |
| Current proposal, source versions, material assumptions, changes, expiry, and release state | |
| Company-owned answers, corrections, options, design, documents, reviews, and handoffs | |
| Sales, design, engineering, electrical, site, finance, commercial, permitting, procurement, and operations demand | |
| Accepted queues, capacity constraints, returns, substitutes, escalations, and prohibited promises | |
| Technical, commercial, finance, tax, contract, authority, privacy, employment, and consumer-claim risks | |
| Forecast category, evidence, scenario, uncertainty, override, reviewer, and change reason | |
| Decision: correct, retain, advance, return, reroute, hold, revise, close, archive, or escalate | |
| Owner, source, next event, clearing condition, due state, customer update, and connected systems | |
| Recurring interface issue, corrective owner, observation period, test, and follow-up review |
Digital.gov’s plain-language guidance describes creating, designing, and testing content so a specific audience can understand it. That principle does not prove a team interprets a record consistently. It supports using explicit actors, states, dates, dispositions, and next events instead of labels such as “good,” “hot,” or “needs push.”
Illustrative example, not a real customer, employee, company, pipeline, proposal, value, forecast, timeline, or result. An opportunity enters the review because a proposal-stage record has no current customer event and an open design correction.
The manager does not ask the representative for a close prediction. The record shows that the customer identified a roof-area concern and the company promised a revised option. The design request was returned because the intended outcome and current roof evidence were missing.
The meeting returns the opportunity to a company-owned correction state, assigns the intake owner, holds forecast treatment under the approved rule, and blocks another persuasion message until the owed option is reviewed. The next meeting inspects closure evidence rather than hearing the same update again.
The example claims no improvement in speed, forecast accuracy, conversion, revenue, employee performance, savings, production, approval, or customer satisfaction. It demonstrates only a traceable management decision.
Use a SurgePV proposal workflow demonstration to inspect the available project and proposal outputs for your review packet. Bring one representative revision and check which sources, versions and exported fields your team can actually inspect. Keep opportunity stages, forecasts, communication permissions and commercial approvals in the responsible systems; confirm any required integration rather than assuming it exists.
Frequently Asked Questions
What is a weekly solar pipeline review?
A weekly solar pipeline review is a decision meeting that compares selected opportunities with current customer, project, proposal, capacity, risk, and ownership evidence. It is not a line-by-line recital of CRM stages. The review should decide what advances, holds, returns, reroutes, changes, closes, or escalates, then record the owner, next event, evidence, and due state.
Which solar deals should a manager review each week?
Review opportunities that require a management decision, cross-team resource, risk disposition, material correction, forecast change, customer escalation, or closure. Do not force every open record into the meeting. Use declared selection rules such as stage entry, age by company definition, exception, value band, changed evidence, missed owned action, or blocked design and operations work.
How long should a weekly pipeline meeting take?
No universal duration fits every team, portfolio, project type, branch, risk profile, or decision load. Control scope through a prepared exception list, evidence-ready records, and time-bounded decisions. Measure useful decisions, unresolved returns, repeated blockers, and action closure rather than treating a shorter meeting as proof of better management or a longer one as proof of rigor.
Should sales managers assign closing probabilities in the meeting?
Use forecast categories and probability methods only when the company has defined, validated, and governed them for the relevant cohort. A manager’s confidence should not silently become a mathematical fact. Preserve inputs, definitions, observation periods, overrides, uncertainty, and scenario boundaries. Keep technical readiness, customer intent, commercial approval, and forecast treatment as separate states.
Can SurgePV replace a solar CRM or forecast tool?
SurgePV provides solar design and proposal workflows. If the review needs CRM stages, revenue forecasts, customer-contact controls or commercial approval records, identify the responsible systems and confirm any required integration during evaluation. A project or proposal output does not itself establish those management controls.
The strongest weekly meeting may remove work. It can close a stale opportunity, return an incomplete request, retire a false next step, or stop a forecast assumption that has no evidence. Those are not empty outcomes. Record their reasons and any remaining customer obligation, rather than counting them automatically as successful outcomes.
When the same blocker returns, inspect the handoff and source records, assign a corrective owner, and test the proposed change. Retain the observation period and evidence instead of assuming one cause from repeated labels.
Bring current project evidence into the review
Bring a sanitized agenda, stage definitions and exception list to a guided session. Confirm current features, access, integrations, pricing, implementation scope, and contract terms in writing.
Request a guided demoSources
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.


