Solar Lead Management Software: Buyer Control Guide

Solar lead management software should preserve every valid enquiry, source, consent record, owner, next action, deadline, activity, handoff, and closure reason. Select it through synthetic failure tests, not rankings. Verify duplicate rules, assignment, permissions, integrations, reconciliation, pricing, renewal, export, deletion, and exit before operational use.

Software cannot create a disciplined sales process by itself. It can enforce agreed records, decisions, deadlines, and evidence. It can also spread duplicates, incorrect assignments, or unauthorized messages when controls are weak.

This guide begins after controlled lead capture. It covers the lifecycle from an accepted enquiry through closure and exit. Use the solar lead capture software guide for form and source-connector depth.

Solar lead management software needs 17 control gates

Require evidence for these gates before comparing prices:

1. One controlled object model with stable identifiers
2. Source and consent evidence that survives every change
3. Deterministic duplicate review without silent deletion
4. Named ownership, backup, due dates, and escalation
5. Written stage entry, transition, exit, and reopen rules
6. Necessary solar qualification without automated promises
7. Controlled survey, design, proposal, and project handoffs
8. Purpose, channel, opt-out, and suppression controls
9. Individual roles, least privilege, and access review
10. Documented integrations with failure handling
11. Reconciliation between source, CRM, and downstream systems
12. Metrics that distinguish activity from outcomes
13. Synthetic normal, exception, privacy, and exit tests
14. Complete three-year cost with every dependency
15. Current contract, support, renewal, and price-change terms
16. Owner-controlled export, archive, deletion, and migration
17. Passed acceptance limits with auditable evidence

A broad CRM label proves none of these controls. A live demonstration can show a user interface. It cannot establish production behavior across failures, employee changes, integrations, and contract exit.

Define objects before configuring a pipeline

Teams often overload one lead record with several meanings. One person may represent a household, company, site, opportunity, and future customer. Those relationships must remain visible.

Define the required objects:

Document cardinality. One account can have several contacts and sites. One site can have separate opportunities over time. A shared phone may not mean the same person.

Every object needs a stable identifier. Do not use a mutable phone number or email as the only key. Preserve raw source identifiers during merges, imports, exports, and migrations.

Keep lifecycle states separate

A lead stage should not replace task, activity, proposal, project, or customer state. Otherwise, reporting can show work that never happened.

A controlled lead lifecycle may include:

1. Accepted
2. Validated
3. Duplicate review
4. Assigned
5. Acknowledged
6. First action due
7. Contacted
8. Connected
9. Qualified or disqualified
10. Survey needed, booked, or completed
11. Design needed or returned
12. Proposal draft, approved, or sent
13. Follow-up due
14. Negotiation or hold
15. Won, lost, or dormant
16. Reopened
17. Archived or deleted

These are design examples, not mandatory labels. Each organization should use names its team can apply consistently.

For every stage, define entry criteria, required fields, acceptable evidence, allowed transitions, approvals, automations, exit conditions, and reporting treatment. Define backward movement and reopening too.

A proposal-sent stage needs a controlled proposal version, authorized sender, recipient, delivery evidence, and send time. A salesperson selecting the stage is not enough.

The solar sales pipeline software guide covers pipeline design in more depth. This page keeps pipeline stages inside the wider lead-control system.

Use the solar pipeline stages guide when teams need entry and exit rules for each commercial stage.

Assign every lead through deterministic rules

An accepted lead needs a primary owner and backup owner. It also needs a dated next action, due date, stage-entry timestamp, last meaningful activity, ageing threshold, and escalation.

Assignment rules may consider geography, project type, customer type, expected capacity, product, language, source, partner, named account, skill, or workload. Rules need a documented priority order.

For example, a named commercial account rule might precede territory. A serviceability exclusion might precede round robin. A language requirement might limit the eligible queue.

Define treatment for:

• Missing or invalid assignment fields
• Conflicting territory and named-account rules
• Owner absence, leave, or working calendar
• Queue overload and assignment ceilings
• Business hours, holidays, and pause states
• Territory or organization changes
• Employee role changes and exit
• Manual override and manager intervention
• Reassignment after acknowledgement
• Linked contacts, accounts, sites, and opportunities

Manual override should record the previous owner, new owner, reason, approver, time, open tasks, and notifications. Reassignment must not erase activity or consent evidence.

Test owner deletion. Open records, tasks, scheduled messages, dashboards, and approvals should move through a controlled process. They should not silently disappear or stay assigned to an inactive user.

Review duplicates without destroying context

Duplicate prevention can stop two representatives contacting one person. Aggressive merging can also combine separate people, sites, or opportunities.

Create deterministic candidate rules using selected fields. Send uncertain matches to review. Do not auto-delete the newer record simply because one field matches.

Test these cases:

• Same person from two advertising sources
• Same phone with different email spelling
• Family members sharing one phone
• Company branches using one central contact
• One owner considering multiple sites
• Repeat enquiry for a later project
• Referral and direct inquiry from the same person
• Recycled phone number belonging to a new user
• Imported record matching an active opportunity
• Opted-out contact appearing through another source

Before merging, preserve both raw source records, campaign fields, timestamps, consent evidence, activities, owners, sites, and opportunities. Keep a merge audit and reversal method.

A merge should never revive a suppressed channel. It should not make one source claim credit for another. Reporting rules must explain attribution after a merge.

Qualify solar enquiries without making promises

Qualification should collect only facts needed for the next decision. It should not turn unverified customer statements into technical conclusions.

Useful fields may include:

• Location, pincode, and serviceability
• Customer and property route
• Electricity bill or demand status
• Roof or land access and ownership authority
• Supply phase and connection information when known
• Outage or backup requirement
• Intended timing and decision roles
• Finance route under consideration
• Preferred contact channel and permission state
• Open technical, commercial, or authority questions

Do not automatically promise system capacity, subsidy, generation, savings, approval, finance, or price. Those results need controlled technical, commercial, or authority evidence.

Use reason codes for invalid, duplicate, disqualified, no response, unserviceable, finance, price, technical, timing, competitor, withdrawn, spam, and lost. Free text can add context. It should not replace controlled categories.

Closure requires an authorized owner, reason, evidence, date, open-task treatment, communication state, retention state, and reopen rule. Dormant and lost may need different follow-up permissions.

Control survey, design, and proposal handoffs

Lead management succeeds only when downstream teams receive controlled inputs and return controlled evidence.

Survey request

A survey request should name the site, scope, access contact, safety notes, requested evidence, schedule, owner, and completion criteria. Returned deliverables need version and reviewer status.

Rejected or incomplete surveys should return through a defined state. Record missing inputs, responsible role, due date, and customer communication decision.

Design request

A design request should reference the approved survey version, bill or loads, equipment assumptions, tariff and scheme basis, project route, open questions, due date, and approver.

Design revision needs a new version and change reason. Do not overwrite the technical basis used by an earlier proposal.

The survey-to-proposal workflow explains that interface. A handoff may be manual and still controlled.

Proposal handoff

The proposal record should reference the approved technical version, price book, tax basis, discount authority, terms, validity, assumptions, exclusions, and document version. Record sender, recipient, delivery evidence, and acceptance state.

Use the solar CRM with quotation software guide for quotation-system boundaries. A CRM button does not prove that technical and commercial versions agree.

Won handoff

Winning should create or link a project record. It must preserve source, consent, proposal, promises, payment evidence, approvals, and responsibilities.

Do not let project creation overwrite the lead. Future disputes may require the exact proposal and communication history that existed at acceptance.

Separate communication purpose and permission

Create separate records for data-processing notice, channel permission, marketing consent, service communication, task reminder, manual message, automated sequence, withdrawal, opt-out, complaint, and suppression.

A website, advertising form, marketplace inquiry, referral, or WhatsApp message does not authorize every sender, channel, purpose, or future campaign. Permission should state the source, language, version, time, purpose, and status.

Approved workflows should define:

• Business account and authorized sender
• Channel preference and purpose
• Approved content or template where required
• Quiet hours and frequency caps
• Human pause and override
• Stop conditions after replies or stage changes
• Opt-out recognition and processing deadline
• Suppression check before every send
• Activity and delivery evidence
• Complaint and escalation route

Personal phones, shared consumer accounts, spreadsheets, and uncontrolled inboxes should not be the sole production record. They weaken ownership, suppression, access, and exit controls.

For messaging workflow depth, use the solar CRM with WhatsApp guide. The solar follow-up software guide covers triggers, replies, delays, and automation failures.

Apply current India privacy and telecom review

Indian privacy duties depend on the actual parties, purposes, data, facts, dates, and phased commencement. Review current MeitY DPDP materials with qualified advisers.

The review should identify notice, consent or another reviewed basis, rights, security, breach response, retention, deletion, transfer, and grievance duties. Do not treat later-starting provisions as already operative.

TRAI publishes current consent guidance and advice to senders. Qualified review should determine applicability to each use of telecom resources.

One inquiry does not authorize every channel or sender. Marketing and service messages need separate purpose analysis. Suppression must operate before a message leaves the system.

Review current CERT-In directions against the deployed systems. Applicability, logs, time synchronization, retention, incidents, and reporting require fact-specific review.

This is a procurement framework, not legal advice. Record the review date, scope, reviewer, conclusions, and unresolved actions.

Map every integration and system of record

Map capture, CRM, telephony, email, WhatsApp, calendar, survey, design, proposal, accounting, installation, service, and reporting systems. Name the system of record for every shared field.

For each interface, record:

Google documents current lead form assets and webhook setup. A delivery or HTTP success state does not prove a correct CRM record, owner, task, consent state, or contact.

Meta describes lead ads with forms. Review the current Meta Lead Ad Terms for the exact account and use.

Platform documentation does not prove a specific connector. Test field mappings, permissions, delivery, duplicates, delayed events, errors, replay, and source reconciliation.

Reconcile counts instead of trusting dashboards

Run scheduled reconciliation across systems. A dashboard total is not enough when rejected, merged, delayed, or deleted records use different rules.

Reconcile:

1. Source accepted events
2. CRM records created, merged, rejected, or queued
3. Unassigned records and inactive owners
4. First-action tasks and overdue work
5. Suppressed contacts and attempted sends
6. Stage entries, exits, backward moves, and reopenings
7. Invalid, duplicate, disqualified, won, and lost totals
8. Survey, design, and proposal handoffs
9. Integration errors, retries, replays, and corrections
10. Project creations and source record preservation

Define a tolerance and investigation owner before launch. Do not change the tolerance after observing unexplained differences.

Keep an exception queue with error time, object, source ID, error code, owner, next action, due date, attempts, correction, and closure evidence.

Report activities and outcomes separately

Metrics need precise definitions. Response speed is not the same as a contact attempt. A contact attempt is not a connection. A connection is not qualification.

The solar lead response time guide covers response measurement and staffing boundaries. A timer alone does not prove meaningful contact.

Keep these measures separate:

• Source receipt and CRM creation time
• Assignment and owner acknowledgement time
• First approved action and first contact attempt
• Connection and qualification state
• Survey booking and completion
• Design request and accepted return
• Proposal approval, send, and acceptance
• Won or lost decision
• Contracted revenue and margin under finance controls
• Installation and customer outcome under project records

Do not claim that software increases conversion, revenue, response performance, or customer satisfaction without a controlled measurement basis. Reports show configured records, not objective truth.

Audit stage edits, owner changes, date changes, task completion, merges, deletions, imports, and bulk updates. Restrict who may alter historical reporting fields.

Run a synthetic failure pilot

Use synthetic records only. Do not contact real prospects during acceptance. Define input, expected state, owner, next action, deadline, escalation, interface effect, report effect, evidence, and pass limit for every case.

Test at least:

1. Normal intake from each approved source
2. Duplicate arrival through two sources
3. Household, company, and multi-site relationships
4. Invalid and missing required fields
5. Wrong territory and conflicting assignment rules
6. Absent owner, overload, and reassignment
7. Consent decline, opt-out, and suppression before send
8. Stage skip, backward movement, hold, and reopen
9. Survey rejection and corrected return
10. Design revision and approval
11. Proposal withdrawal and replacement
12. Won conversion with preserved evidence
13. Lost closure with controlled reason
14. Expired connector credentials
15. Duplicate, delayed, and out-of-order events
16. Schema change and partial update
17. Connector outage, restored service, and replay
18. Report and source reconciliation
19. Role change, access removal, and employee exit
20. Privacy access, correction, and applicable deletion
21. Complete export and system exit

Test idempotency. Replaying one accepted source event should not create another opportunity or send another message without a defined reason.

Record every failure and retest. A pilot passes only when agreed limits are met and critical exceptions are closed. Do not replace failed evidence with a vendor assurance.

Normalize cost, contract, renewal, and exit

Build a three-year cost model. Separate public, quoted, estimated, included, usage-based, pass-through, optional, and unknown values.

Include base plans, seats, contacts, records, storage, pipelines, fields, roles, territories, automations, messages, telephony, calendars, integrations, API, and audit. Add SSO, setup, migration, customization, training, support, sandbox, backup, tax, overages, renewal, export, archive, and exit.

Use at least three operating scenarios without inventing lead volumes, conversion, revenue, labour savings, or return on investment. State each input and sensitivity.

The contract should address plan limits, support milestones, service evidence, change notice, price changes, renewal, data ownership, export formats, deletion, termination, post-termination access, and exit assistance.

Test a complete export before signing. Verify identifiers, relationships, field definitions, users, timestamps, consent, suppression, activities, tasks, attachments, stages, audit history, and deleted-state treatment.

Evaluate QuickEstimate through identical gates

Related-party disclosure: SurgePV and QuickEstimate have a commercial relationship. QuickEstimate receives no automatic preference. Its claims face the same evidence, synthetic testing, contract, and acceptance gates as every other supplier.

The QuickEstimate pricing page observed on 10 August 2026 listed Free at ₹0. It listed one user and 10 proposals monthly.

The same page listed Pro at ₹6,999 per user yearly, with a three-user minimum and annual billing. It listed Enterprise as custom for 25 or more users. These are related-party first-party statements and may change.

Confirm currency, tax, limits, features, integrations, messages, support, setup, overages, and renewal in a current written quote. Do not infer CRM capacity from proposal limits.

The live pricing page stated a 30-day guarantee. The QuickEstimate refund policy described a 7-day implementation period and later eligibility conditions when observed. Preserve this conflict and obtain signed clarification before payment.

Review the QuickEstimate FAQ, privacy page, and terms. Broad claims remain unverified until exact-plan documents and production-like testing support them.

Apply the same object, ownership, consent, stage, integration, failure, reconciliation, security, support, price, export, and exit gates. Choose another product when it performs better against the common requirements.

Keep SurgePV at the design handoff boundary

No native lead management is within the currently verified SurgePV scope. Do not infer CRM, routing, messaging, pipeline, Meta, IndiaMART, telephony, or QuickEstimate integration.

A controlled design or proposal handoff may use documented files or another reviewed interface. That interface does not prove a native connection.

Use the best solar CRM for installers guide for broad CRM category comparison. Use the mobile CRM guide for field-device acceptance and offline behavior.

Use the solar CRM pricing guide for wider plan normalization. Recheck every price and limit on the final decision date.

Red flags that justify a pause

Pause selection when a supplier:

• Cannot define core objects and stable identifiers
• Deletes duplicates without preserving source evidence
• Allows accepted leads to remain ownerless
• Uses one stage as proof of every downstream action
• Cannot explain assignment priority or manual overrides
• Mixes marketing permission with service communication
• Sends through personal or uncontrolled accounts
• Cannot show connector errors, replay, and reconciliation
• Promises outcomes from task or dashboard features
• Hides plan limits, dependencies, or recurring costs
• Conflicts with its own refund or contract wording
• Cannot export relationships, consent, activities, and audit data
• Keeps production ownership with an employee or vendor

A short synthetic pilot can reveal these failures before migration. Contract acceptance should depend on evidence, not a feature checklist.

Buyer acceptance checklist

Before operational use, confirm:

• Objects, identifiers, relationships, and source preservation
• Ownership, backup, next action, due date, ageing, and escalation
• Duplicate review, merge audit, reversal, and attribution
• Stage rules, evidence, approvals, backward moves, and reopen
• Qualification limits and controlled closure reasons
• Survey, design, proposal, and project handoffs
• Purpose, channel, notice, consent, opt-out, and suppression
• Roles, access, security, privacy, incidents, and offboarding
• Integration IDs, errors, retries, replay, and reconciliation
• Metrics definitions and protected reporting fields
• Synthetic pilot results, deviations, corrections, and retests
• Three-year cost, contract, renewal, export, deletion, and exit

Lead management works when every accepted record has accountable next work. The system should preserve evidence when people, stages, integrations, or suppliers change.

Frequently asked questions

What does solar lead management software control?

It should control accepted enquiries through validation, assignment, qualification, survey, design, proposal, follow-up, closure, retention, and deletion. It should preserve source and consent evidence while keeping lead, task, activity, proposal, project, and customer states separate.

How does lead management software prevent lost enquiries?

It gives each accepted record a named owner, backup owner, dated next action, due date, stage-entry time, ageing rule, and escalation. This reduces process gaps only when teams monitor queues, exceptions, integrations, and overdue work.

What fields should a solar lead record include?

Capture necessary source, consent, contact, location, serviceability, customer route, bill, site access, authority, backup, timing, and finance facts. Preserve the owner, stage, next action, due date, and controlled handoff references.

How should duplicate solar leads be managed?

Use deterministic matching and a review queue. Preserve raw records, sources, consent, campaign data, activities, sites, and opportunities before merging. Test shared phones, family members, company branches, multiple sites, spelling differences, recycled numbers, and later enquiries.

How should Meta and Google leads reach the CRM?

Document the exact account, form, fields, identifiers, delivery method, authentication, timing, retries, errors, replay, and reconciliation. A platform or webhook success state does not prove correct CRM creation, assignment, consent, task creation, or contact.

Does a CRM stage prove that a salesperson contacted a lead?

No. Stage, task, activity, call, connection, qualification, appointment, proposal, conversion, revenue, installation, and customer outcome are different measures. Define evidence for each metric and prevent manual or automated stage changes from creating false performance claims.

How should consent and opt-outs be handled in India?

Separate notice, processing basis, channel permission, marketing consent, service communication, withdrawal, opt-out, complaint, and suppression. Review current phased Indian privacy duties, applicable telecom rules, source-platform terms, contracts, purposes, senders, channels, retention, rights, security, and grievances.

How should QuickEstimate lead management claims be evaluated?

Treat QuickEstimate pages as related-party first-party evidence. Verify the exact plan, objects, limits, routing, connectors, consent, failures, reports, security, and support. Check pricing, refund terms, export, and exit through written evidence and the same synthetic pilot used for every supplier.

Is SurgePV solar lead management software?

No native lead management is within the currently verified SurgePV scope. Treat a controlled design or proposal handoff as an interface boundary, not proof of CRM, routing, messaging, pipeline, Meta, IndiaMART, telephony, or QuickEstimate integration.