Quick Answer
Choose solar sales pipeline software only after defining each route, stage, entry and exit evidence, owner, next action, clock, and permission. Add allowed transitions, automation stop rules, amounts, forecast categories, and handoffs. Test invalid moves, stale technical sources, failed automations, history, reconciliation, migration, restore, offboarding, and export in the exact production-like tenant.
Solar sales pipeline software should make every opportunity’s route, stage, owner, next action, time state, amount, forecast category, exception, and history explicit. A colored board alone cannot do that.
Quick Answer
Choose solar sales pipeline software only after defining each route, stage, entry and exit evidence, owner, next action, clock, and permission. Add allowed transitions, automation stop rules, amounts, forecast categories, and handoffs. Test invalid moves, stale technical sources, failed automations, history, reconciliation, migration, restore, offboarding, and export in the exact production-like tenant.
Pipeline acceptance rule
Every movement must be explainable, permissioned, reversible where appropriate, and auditable. Missing evidence stays unresolved instead of becoming a stage label.
This guide does not rank products or promise conversion, response, velocity, revenue, forecast accuracy, implementation time, support, or customer outcomes.
Keep this page’s pipeline boundary clear
This page owns stage configuration and opportunity movement. It does not own the complete CRM architecture or every reporting definition.
The solar sales CRM guide covers residential and C&I data architecture. The sales reporting guide owns metric and dashboard definitions.
Use the sales team management guide for territory and administration. Use the India CRM guide for broader requirements-led selection.
Lead intake, follow-up, quotations, proposals, and channels also have dedicated pages. A pipeline should link those states without collapsing them.
Select the route before the first stage
Residential homeowner, society, small commercial, C&I CAPEX, RESCO or PPA, tender, captive or open access, storage, retrofit, service, and partner routes can differ.
Create separate pipelines only when stage sequence, required evidence, approvals, ownership, clocks, or handoffs materially differ.
Do not create separate boards only for regions, reps, or reporting labels. Use controlled fields and teams when the process is the same.
Define a route-selection rule before opportunity entry. Record customer type, site, project model, evidence, decision owner, and date.
A route change needs reason, approver, affected fields, probability, amount, clock, and audit event. It may also require stage remapping.
Test an incorrect route. The system should block or safely correct mismatched required fields and automations.
Separate opportunity state from other states
One stage should not impersonate several operational systems.
| State family | Examples |
|---|---|
| Opportunity | Qualified, survey, solution, negotiation, won, lost |
| Technical | Evidence pending, survey complete, design requested, technically approved |
| Quotation or proposal | Draft, approved, sent, delivered, viewed, accepted, expired, withdrawn |
| Customer response | No response, question, objection, decision pending, accepted, rejected |
| Forecast | Pipeline, best case, commit, excluded, or buyer-defined categories |
| Contract | Draft, review, signed, conditions pending, effective, terminated |
| Finance and payment | Application, approved, rejected, invoice, due, paid, credit |
| Project | Handoff, planned, installed, commissioned, closed |
| Service | Ticket, diagnosis, dispatch, repair, closure |
Opportunity stage, technical state, quote state, customer response, forecast category, contract, invoice, payment, project, installation, commissioning, and service remain separate.
Use stable IDs and relationships. Do not overwrite a technical state when a rep moves an opportunity.
Build the solar sales pipeline software stage dictionary
Names such as new, contacted, qualified, survey, proposal, negotiation, won, and lost are insufficient without objective definitions.
For every stage, define:
| Stage field | Required control |
|---|---|
| Stable ID and label | Unchanging identifier and user-facing name |
| Route and position | Applicable pipeline and sequence |
| Entry | Objective criteria and source evidence |
| Exit | Required fields, documents, and approval |
| Ownership | Record owner and accountable role |
| Permissions | Editors, movers, approvers, and exceptions |
| Next action | Required action, owner, due time, and escalation |
| Clock | Start, pause, restart, stop, and exception |
| Commercial | Amount basis, currency, probability method, forecast, close-date basis |
| Transitions | Allowed incoming, outgoing, backward, skip, and reopen moves |
| Automation | Triggers, branches, delays, actions, and stop rules |
| Exceptions | Rollback, lost, disqualified, nurture, defer, archive, deletion |
| Handoff | Receiving system, owner, data, acknowledgement, and rejection |
| History | Audit, snapshots, retention, export, and reconciliation |
Store the dictionary outside configuration too. Give it an owner, revision, approval, and effective date.
Changing a label should not rewrite historical meaning. Changing criteria needs migration and reporting treatment.
Maintain a configuration register beside the dictionary. Record tenant, environment, route, object, field, automation, role, report effect, requester, tester, approver, release date, rollback, and evidence.
Separate draft configuration from production configuration. Use a controlled sandbox with synthetic data for changes where the product supports it.
Before release, test affected transitions, permissions, automations, clocks, reports, integrations, exports, and history. Record the release result and unresolved risk.
After release, reconcile representative records and watch error queues. A successful save in the administrator screen does not prove correct production behavior.
Retire unused stages and fields through a controlled migration. Preserve historical labels, IDs, mappings, reports, and audit evidence.
Model a residential route
A residential route may use these controlled stages:
- received
- duplicate review
- accepted
- contacted
- qualified
- appointment set
- bill or site evidence pending
- survey scheduled
- survey completed
- design requested
- technical package returned
- quote or proposal pending
- commercially approved
- sent
- customer review
- follow-up
- finance or scheme review
- contract pending
- contracted
- handoff acknowledged
Lost, disqualified, nurture, deferred, archived, and deleted are controlled outcomes, not hidden columns.
Each stage should have evidence. A scheduled survey is not a completed survey. A returned design is not technical approval.
Keep consumer eligibility, scheme or portal state, utility state, equipment compliance, finance decision, quote acceptance, contract, installation, inspection, commissioning, and payment separate.
Do not advance from a response, appointment, design, quote, or handoff based on an unverified vendor outcome claim.
The lead management software guide covers source intake and qualification before pipeline movement.
Model a C&I route
C&I work often needs account and site relationships beyond one contact.
Possible stages include target account, stakeholder mapping, discovery, confidentiality, data request, load review, site qualification, feasibility, survey, and technical solution. Add commercial model, internal review, customer technical review, procurement, tender, negotiation, management approval, finance or legal review, contract, conditions precedent, and acknowledged handoff.
Map sponsor, user, technical, facility, operations, EHS, finance, procurement, legal, consultant, lender, management, board, and signatory roles where applicable.
Preserve account, site, opportunity, option, tender round, design, proposal, quotation, commercial model, and contract relationships.
A tender round is not a new customer. A revised option should not duplicate the full opportunity amount.
C&I forecast evidence may include documented buyer process, dated next action, decision-date basis, amount basis, risks, exclusions, and reviewer.
Stage probability alone is not evidence. A management review can still have unresolved technical or legal conditions.
Control fields and freshness
Use stable record IDs. Required fields can include route, account, site, contact, owner, team, source, consent, qualification, stage, stage-entered time, and next action. Add due date, technical source, document version, amount, currency, probability method, close-date basis, risk, loss reason, and handoff evidence.
Define conditional fields by route and stage. For each field, set data type, unit, valid range, source, freshness, dependency, error, override, and audit rules.
A bill date can become stale. A quote can expire. A technical design can be superseded.
Block advancement when mandatory evidence is missing or stale. Allow documented exceptions only through authorized review.
Bulk edit, import, automation, API, administrator, and integration actions need the same field and transition rules as manual actions.
Test invalid units, dates, values, and relationship IDs. Do not let imports bypass validation.
Control transitions and permissions
Define allowed forward, backward, skip, reopen, clone, split, merge, relate, route-change, lost, disqualified, deferred, nurture, archive, delete, and restore actions.
Require a reason and evidence for skipped, reversed, reopened, route-changed, amount-changed, date-changed, owner-changed, and lost transitions.
Use least privilege and segregation for record creation, stage movement, amount, probability, price, discount, technical approval, quote issue, contract, reassignment, export, deletion, configuration, and audit access.
Sales users should not approve technical facts through a stage move. A system administrator should not receive automatic commercial approval authority.
Test API and bulk actions under low-privilege credentials. Check audit logs for original and new values, actor, time, source, and reason.
Define ownership and acceptance
Person, queue, team, territory, partner, account, site, opportunity, task, and handoff ownership are different.
Define acceptance, rejection, reassignment, absence, holiday, workload, skill, conflict, territory, serviceability, escalation, and orphan-record paths.
An assigned opportunity should require acceptance when ownership matters. A rejected assignment needs a controlled reason and fallback.
Test absent and offboarded owners. No active record should remain owned by a disabled user without a documented queue.
For partner routes, distinguish internal owner, partner owner, data access, task responsibility, and customer contact authority.
Territory rules should not overwrite account ownership silently. Record conflicts and approved exceptions.
Make next actions measurable
Every next action needs owner, due timestamp, timezone, purpose, channel, dependency, priority, status, outcome, evidence, reassignment, escalation, and follow-on action.
“Follow up” is too vague. State what evidence or customer decision the action seeks.
Separate task creation from message sending. A task can exist without an authorized communication.
When an action completes, require outcome and next step. Do not leave an opportunity active without a dated action or controlled hold.
The follow-up software guide covers deeper cadence and communication logic.
Define each clock
Lead response, contact attempt, appointment, survey, design, proposal, customer decision, inactivity, handoff, and support clocks have different start and stop events.
For each clock, define working calendar, timezone, start, pause, restart, stop, exclusions, warning, breach, escalation, report, and historical calculation.
Do not pause a clock by moving the stage unless the stage dictionary permits it. Record who paused it and why.
A corrected due date should preserve the former value and change reason. A route change may restart some clocks and preserve others.
CRM clocks are internal controls unless a customer or vendor contract makes them external obligations.
Do not publish a universal response or stage-duration promise.
Build automation stop rules first
Define automation trigger, condition, branch, delay, schedule, action, owner, channel, template, permission, cap, retry, idempotency, dependency, stop rule, suppression, exception, alert, audit, and rollback.
Stop automation after opt-out, loss, disqualification, contract, deletion, owner conflict, stale technical source, expired quote, failed prerequisite, or unsupported channel state.
Do not let automation create consent, approve technical facts, determine tax or scheme eligibility, recognize revenue, sign a contract, or certify customer intent.
Separate task creation, message sending, stage movement, owner change, forecast change, quote issue, customer response, project handoff, and accounting effects.
Test duplicate triggers, delayed events, out-of-order events, missing fields, invalid values, expired tokens, rate limits, timeouts, and partial success. Add provider rejection, loops, conflicting manual changes, deleted records, schema changes, and replay.
Every failure needs an error queue, owner, alert, retry rule, correction, reconciliation, and close-out evidence.
The CRM workflow automation guide covers automation design in greater depth.
Define forecast evidence
Separate pipeline amount, expected amount, contract amount, forecast amount, weighted amount, tax inclusion, currency, exchange basis, one-time value, recurring value, and options.
Prevent double counting across alternatives, sites, tender rounds, and commercial models.
Forecast category can differ from stage. Define probability source, reviewer, date, evidence, override, and history.
Close date can mean buyer target, rep estimate, tender deadline, approval date, contract date, or project date. Store its basis and change reason.
Preserve snapshots of stage, owner, amount, probability, close date, next action, risk, and forecast. Current labels must not rewrite past reports.
Do not claim forecast accuracy without a controlled definition, eligible population, evidence period, and backtest.
The sales reporting software guide owns reporting calculations and dashboard definitions.
Control loss, defer, and reopen
Loss and disqualification need controlled reason codes. Separate competitor, no decision, budget, technical, serviceability, duplicate, invalid, and withdrawn cases when evidenced.
Limit free text to context. Do not put sensitive or unsupported claims into notes.
Define reopen criteria, owner, evidence, stage, clock, amount, forecast, and audit. Do not silently reuse an expired quote or stale design.
Deferred and nurture records need next review date, owner, reason, consent or channel state, and suppression rules.
Archive and deletion remain separate. Archived records may remain reportable, while deletion follows legal and contract controls.
Preserve technical and document boundaries
A pipeline stage can request design. It does not approve capacity, equipment, energy, BOM, engineering, utility, authority, tax, subsidy, finance, or warranty facts.
A controlled technical return should identify source system, record ID, project, revision, date, owner, checker, approver, scope, assumptions, limitations, and validity.
Preserve quote and proposal number, version, source snapshot, approval, recipient, delivery, response, expiry, withdrawal, and supersession separately from opportunity stage.
Won should require a defined acceptance or contract event. It is not synonymous with sent, viewed, verbally positive, or finance review.
The CRM quotation guide covers the complete quotation lifecycle. The proposal app guide covers device presentation.
Make handoff acknowledged
Won is not the end of responsibility. Define the receiving system, project owner, data, documents, timestamp, acknowledgement, rejection, correction, reconciliation, and completion evidence.
The handoff pack may include customer, site, contract, accepted commercial document, technical source, scope, exclusions, schedule assumptions, approvals, contacts, risks, and open conditions.
The receiver should accept or reject the pack against defined criteria. A rejected handoff returns to a named owner without losing history.
Do not move installation or commissioning states into sales pipeline columns merely to close reporting gaps.
Control integration and reconciliation
For each connection, define system of record, IDs, field ownership, direction, event, timing, API or file, authentication, version, rate limit, and retry. Add idempotency, conflict, error queue, alert, replay, correction, deletion, and reconciliation.
Test missing records, duplicate records, changed schemas, partial writes, late events, deleted records, and replay.
Reconcile counts and values by route, stage, owner, amount, document version, and handoff state. Investigate orphaned relationships.
Do not infer a connector from a logo or vendor statement. Reproduce exact object, field, direction, trigger, error, and recovery behavior.
Apply privacy and communication controls
MeitY’s DPDP Rules page provides current final rules, corrections, Board, and phased enforcement material.
TRAI’s commercial-communication regulation page provides the current regulation and amendment route.
Qualified review should map notice, purpose, consent, channel, preference, suppression, retention, deletion, grievance, sender, template, and current duties for the exact workflow.
Automation should respect opt-out, suppression, unsupported channel, and deleted-record states. A pipeline stage does not create communication permission.
Define authentication, MFA, sessions, least privilege, exports, mobile storage, sharing, logs, backups, restore, incidents, subprocessors, hosting regions, transfers, retention, deletion, and offboarding.
Migrate without rewriting history
Migrate stable IDs, relationships, routes, stages, owners, timestamps, amount, currency, probability, close-date basis, activities, documents, consent, suppression, loss reason, history, and audit evidence.
Build a source-to-target mapping. Identify transformed, dropped, merged, derived, and unsupported values.
Do not silently map several old stages to one new meaning. Preserve the source stage and transformation rule.
Test record counts, relationship counts, amount totals, histories, files, permissions, and representative edge cases before cutover.
Define freeze, delta migration, cutover, rollback, archive, access, and issue ownership. Keep the source available under controlled read-only terms until acceptance.
Run a failure-led synthetic pilot
Use synthetic people, accounts, sites, documents, messages, and amounts. Test both residential and C&I routes.
Cases should include:
- duplicate people, accounts, and sites
- valid and invalid transitions
- required-field block
- bulk and API movement
- wrong or absent owner
- overdue action
- clock pause and restart
- route change
- stale design
- revised proposal and expired quote
- opt-out and automation stop
- duplicate and out-of-order event
- forecast amount and date change
- loss and reopen
- handoff rejection
- role access and export
- restore, offboarding, retention, deletion, and exit
For each case, define input, role, expected stage, related states, allowed edit, blocked edit, output, audit evidence, pass limit, reconciliation, fallback, and owner.
Record defects, severity, owner, correction, retest, and acceptance. Test failure recovery, not only the expected path.
Compare total ownership cost
Build a three-year scenario using current buyer-entered values. Do not invent a universal product or implementation price.
Normalize plan, seats, pipelines, stages, fields, records, storage, automations, messages, templates, reports, integrations, API, setup, and migration. Add cleansing, configuration, training, administration, support, backup, security, overages, taxes, renewal, export, archive, deletion, and exit.
Include internal process ownership, configuration review, data quality, release regression, integration reconciliation, security review, and user support.
The contract should cover data and document ownership, intellectual property, security, availability, change, support, subprocessors, privacy, export, termination, deletion, audit, and exit assistance.
Test a complete export before purchase and renewal. Verify relationships, stage history, activities, documents, audit, consent, suppression, configuration, and code lists.
Plan restore, offboarding, and exit
Test restore against defined recovery evidence. A backup statement does not prove usable restoration.
Offboarding should revoke sessions, reassign records, preserve activities, close open tasks, transfer approvals, and remove exports or local data where required.
The exit pack should contain stable IDs, relationships, routes, stage dictionary, owners, timestamps, amounts, currencies, probabilities, and close-date basis. Add activities, documents, consent, suppression, loss reasons, history, and audit.
Define formats, relationships, timestamps, timezones, retention, deletion, certification, and exit assistance. A flat contact export is not a complete pipeline export.
Evaluate QuickEstimate under identical gates
Disclosure: SurgePV and QuickEstimate have a commercial relationship. QuickEstimate is a related-party candidate in this guide.
The QuickEstimate pipeline page contains first-party stage, automation, task, forecast, and handoff claims. It does not prove exact configuration or outcomes.
Review current pricing, security, privacy, and terms. Resolve feature, entity, retention, geography, support, and document-priority questions.
Do not rank QuickEstimate. Apply identical stage, object, transition, permission, automation, integration, security, pilot, cost, contract, support, export, and exit gates.
Keep SurgePV in its verified scope
SurgePV publishes first-party pages for solar design and proposal output. Use them only for the documented technical design, shading, generation and financial modeling, BOM, and proposal scope.
Do not describe SurgePV as native pipeline CRM, routing, messaging, forecasting, accounting, or a QuickEstimate integration.
A handoff from technical software to CRM requires a separately evidenced system-of-record and reconciliation process.
Keep related pages distinct
This page owns stage configuration and opportunity movement. Use focused guides for adjacent work:
- solar sales CRM for data architecture
- solar sales reporting for metric definitions
- sales team management for team administration
- solar CRM software India for broad selection
- lead management software for intake
- follow-up software for cadence logic
- CRM with quotation software for quotation lifecycle
- solar CRM workflow automation for automation design
Frequently asked questions
What is solar sales pipeline software?
It controls how solar opportunities move through defined routes and stages. Each stage should identify objective entry and exit evidence, owner, next action, clock, permission, transitions, automation, amount, forecast category, handoff, history, and exceptions. A colored board without those controls is not enough.
What stages should a residential solar pipeline use?
Use stages matching the verified process. They may include received, duplicate review, accepted, contacted, qualified, evidence pending, survey, design, quotation, customer review, finance or scheme review, contract, and acknowledged handoff. Keep portal, utility, technical, quote, payment, installation, and commissioning states separate.
Should residential and C&I solar use one pipeline?
Use separate pipelines only when sequence, evidence, approvals, ownership, clocks, or handoffs materially differ. C&I often needs account stakeholders, confidentiality, interval data, feasibility, procurement, finance, legal, conditions precedent, and portfolio relationships. Do not create separate boards only for regions, reps, or reporting labels.
Can pipeline software move opportunities automatically?
Only through tested triggers, conditions, prerequisites, permissions, retries, idempotency, and stop rules. Automation must stop after opt-out, loss, disqualification, contract, deletion, owner conflict, stale technical source, expired quote, failed prerequisite, or unsupported channel state. Every move needs audit evidence.
How should next actions and pipeline clocks work?
Every next action needs an owner, due timestamp, timezone, purpose, channel, dependency, priority, status, outcome, evidence, escalation, and follow-on action. Define each clock’s calendar, start, pause, restart, stop, exclusions, warning, breach, escalation, reporting, and historical calculation.
Does a pipeline stage probability prove forecast accuracy?
No. Define forecast category separately when needed. Record amount basis, currency, probability source, buyer process, close-date basis, dated next action, risks, exclusions, reviewer, override, and history. Stage probability alone cannot prove customer intent, contract, revenue, timing, or forecast accuracy.
When should a solar opportunity be marked won?
Use a defined customer acceptance or contract event with evidence. Sent, delivered, viewed, verbally positive, under finance review, or technically approved are not automatically won. Preserve the accepted quote or proposal, contract state, amount basis, conditions, and acknowledged project handoff separately.
Is QuickEstimate ranked as the best pipeline software?
No. SurgePV and QuickEstimate have a commercial relationship. QuickEstimate publishes first-party pipeline and CRM claims that require exact-plan verification. Apply the same stage, transition, permission, automation, integration, security, pilot, cost, contract, export, and exit gates to QuickEstimate and every unrelated candidate.
Is SurgePV native sales pipeline CRM software?
No verified evidence supports that description here. SurgePV has first-party evidence for solar design, shading, generation and financial modeling, BOM, and proposal output. Keep it separate from native pipeline stages, routing, messaging, forecasting, accounting, CRM administration, and QuickEstimate integration.
