Solar Customer Management Software: Lifecycle Guide

Solar customer management software should preserve accountability from first enquiry through long-term service. It must show who the customer is, which site is involved, and what happened.

A long contact timeline alone is insufficient. Solar work links people, premises, technical designs, contracts, installed equipment, warranties, service cases, and changing ownership.

This guide uses regulator and vendor-owned evidence checked on 10 August 2026. We did not conduct hands-on product tests and make no product ranking.

Public feature documentation proves only what that page states. It does not prove configuration, edition, limits, support, security, integrations, or suitability for your company.

In this guide:

• Customer, contact, household, company, site, project, system, asset, contract, and case records
• Enquiry, consent, qualification, survey, design, quote, contract, installation, and commissioning handoffs
• Equipment, serials, warranties, service, complaints, escalation, O&M, AMC, CMC, renewals, and referrals
• Authoritative systems, integrations, errors, retries, reconciliation, roles, privacy, retention, and audit
• Reports, mobile use, migration, administration, support, pilot failures, total cost, renewal, export, and exit
• QuickEstimate disclosure and the SurgePV non-CRM boundary

Solar Customer Management Software Decision Boundary

This page owns customer-lifecycle record architecture and procurement. It connects sales, delivery, installed equipment, service, retention, and exit without collapsing them into one record.

The solar lead management software guide owns pre-sale intake, qualification, follow-up, and conversion. The solar sales pipeline guide owns stage design.

The CRM for solar companies guide owns category-wide CRM evaluation. The India solar CRM guide owns India-market selection.

The solar CRM pricing guide owns price and ownership-cost comparison. The dealer management guide owns channel relationships and dealer controls.

The warranty claims guide owns claim execution. This page defines how customer, system, equipment, warranty, and case records stay connected.

These boundaries prevent competing advice. They also prevent the CRM from becoming an uncontrolled copy of every specialist system.

Define Customer Management Before Comparing Products

Begin with the lifecycle and system map. Do not begin with a vendor menu.

Customer management should answer these questions:

1. Which person, household, company, or public entity has the relationship?
2. Which contact can act for that entity, purpose, site, and period?
3. Which physical site, meter, premise, or portfolio is involved?
4. Which enquiry, opportunity, contract, project, and installed system relate to the site?
5. Which equipment, serial, warranty, monitoring account, and service history belong to that system?
6. Which case, complaint, field visit, or maintenance commitment is open?
7. Which system owns each fact, document, approval, and status?
8. Who may view, edit, share, export, retain, or delete each record?

A product may cover only part of this chain. That can be acceptable if interfaces and accountability are explicit.

Enterprise vendors illustrate the separation. Salesforce documents accounts and contacts as related concepts.

Its service documentation separately describes case fields. Microsoft separately documents field-service work orders, assets, technicians, inventory, and service history.

Those examples do not recommend either product. They show why a vague “360-degree customer view” needs a precise data model.

Build One Identity Graph, Not One Giant Record

One customer record should not mean one overloaded row. Use linked identities that match the real relationships.

Do not use phone number as the only identity. Phones can be shared, reassigned, mistyped, or used by different household members.

Do not use site address as the only identity. Addresses change format, buildings have multiple meters, and customers can own several sites.

Assign durable internal identifiers. Preserve source identifiers and historical relationships beside them.

Preserve Enquiry, Consent, Qualification, and Preferences

The customer lifecycle begins with source context. Keep original enquiry identity, time, source, request, available notice, and captured fields.

Separate consent and communication controls from the contact record. A phone number does not describe the approved purpose, channel, evidence, or current preference.

Store these elements separately:

• Source event and capture method
• Notice or consent evidence available at capture
• Intended response and assessed purpose
• Approved communication channel by purpose
• Marketing preference by channel
• Opt-out or revocation status and time
• Legal or policy review where required
• Evidence source, version, and retention rule

The TRAI TCCCPR overview describes commercial communication, preferences, and consent controls. Apply current requirements to each communication programme.

MeitY publishes the Digital Personal Data Protection Rules, 2025 and linked commencement material. Commencement is phased.

Obtain legal advice for actual processing, messages, retention, and customer-rights handling. This guide does not decide whether a particular use is lawful.

Qualification should preserve evidence, not guesses. Record consumer type, site, requirement, decision role, project timing, budget context, and next step only when known.

Unknown is a valid state. Do not infer ownership, income, eligibility, sanctioned load, capacity, or decision authority from a source label.

Control Survey, Design, Quote, and Contract Versions

The CRM should connect commercial decisions to controlled evidence. It should not become a second engineering system.

Create a site record before commissioning survey or design work. Link the authorized requester, access contact, survey scope, appointment, consent, and safety instructions.

Store the survey record in its approved system. CRM can hold status, owner, completion time, controlled link, version, and exception summary.

Keep authoritative geometry, shading, electrical configuration, structural inputs, equipment selection, calculations, drawings, and revisions in the technical system.

CRM should hold the approved technical revision reference. It can also store a commercial summary that is traceable to that revision.

For every proposal, preserve:

• Proposal identifier and version
• Created and expiry dates
• Customer, site, and opportunity identifiers
• Technical revision reference
• Equipment and scope summary
• Assumptions, exclusions, options, and dependencies
• Price, tax treatment, payment schedule, and finance status
• Delivery method and recipient
• Customer comments, approvals, and rejection reason
• Superseded status and replacement version

The accepted proposal does not automatically equal the signed contract. Store each as a separate controlled record and link the acceptance trail.

The CRM with quotation software guide covers this interface in detail. The proposal page explains SurgePV proposal output without redefining CRM ownership.

Handoff Sold Work Into Project Delivery

Conversion should create a structured project handoff, not a notification saying “deal won.” The delivery team needs verified scope and commitments.

Create a handoff checklist covering:

• Contracting and billing parties
• Site, access, and authorized contacts
• Signed contract and approved commercial version
• Approved technical reference and unresolved assumptions
• Payment, finance, subsidy, permit, and utility dependencies
• Equipment scope and allowed substitutions
• Customer-promised dates and communication commitments
• Safety, roof, civil, electrical, and access constraints
• Change-order process and approval authority
• Sales owner, project owner, and escalation contacts

The project system should own schedules, tasks, dependencies, procurement, construction evidence, quality checks, and delivery approvals where configured.

CRM can display controlled project status. It should not let sales users overwrite authoritative milestones or completion evidence.

Define every status. “Installation started” might mean material delivery, crew arrival, mounting start, or electrical work. Reporting needs one approved definition.

Track handoff rejection and correction. An incomplete project packet should return to a named owner with a reason and due date.

Create the Commissioned System Record

Commissioning should produce an installed-system record that survives employee, customer, and software changes. Do not leave this evidence in chat threads.

The record should link:

• Customer, site, project, and contract
• Commissioning and handover dates
• Approved as-built technical document set
• Installed capacity and configuration summary
• Panel, inverter, battery, meter, protection, and other equipment records
• Manufacturer, model, serial number, quantity, and installation location
• Installer, subcontractor, verifier, and responsible technician
• Test, inspection, permission, and commissioning references
• Monitoring account and data-access owner
• Customer training and handover acknowledgement
• Warranty, guarantee, insurance, and service commitments
• Open defects, exclusions, or punch-list items

Use individual equipment records when serial-level warranty or service matters. A single free-text equipment field cannot support reliable claims.

Salesforce documents assets linked to accounts, contacts, products, and parent assets. That model does not prove solar suitability.

A buyer must still test solar serials, component hierarchies, substitutions, warranty dates, files, permissions, imports, exports, and service links.

Separate Warranties, Guarantees, and Service Commitments

Do not store “25-year warranty” as one undifferentiated value. Solar systems can carry several commitments from different legal parties.

Separate at least:

• Manufacturer product warranty
• Manufacturer performance warranty
• Inverter or battery warranty
• Installer workmanship warranty
• EPC performance guarantee if contractually provided
• Monitoring, O&M, AMC, or CMC commitment
• Extended warranty or insurance product
• Statutory or contractual remedy tracked by legal review

For each commitment, record provider, beneficiary, covered item, start event, duration, exclusions, required maintenance, claim route, evidence, transferability, and status.

Do not calculate end dates until the start event is defined. Delivery, installation, commissioning, registration, and invoice dates can differ.

Link every claim to the exact equipment, warranty, customer, site, case, and evidence. Preserve the decision, parts, labour, shipping, downtime, customer communication, and closure.

Run Cases and Complaints as Accountable Records

A customer complaint should become a case even when it arrives through a salesperson’s phone. Personal messaging must not remain the only service history.

The case record should include:

• Case number, source, opened time, and customer acknowledgement
• Customer, site, installed system, equipment, and contract links
• Issue description in the customer’s words
• Category, severity, safety flag, and service entitlement
• Owner, queue, response target, and resolution target
• Communications, diagnostic steps, and evidence
• Escalations, handoffs, decisions, and approvals
• Field-work reference, parts, technician notes, and completion evidence
• Resolution code, customer confirmation, closure time, and reopen history
• Related problem, repeated failure, or prior case link

Never close a case merely because a field visit was booked. Separate acknowledgement, triage, dispatch, work completion, technical review, customer confirmation, and closure.

Case severity should use defined impact and urgency rules. A safety concern needs a different path from a reporting question.

Test complaint escalation outside normal hours. Define who can authorize emergency action, equipment isolation advice, site attendance, replacement, or executive communication.

Do not claim a CRM has case management because it has notes or tasks. Test case IDs, queues, statuses, timers, escalations, attachments, related assets, audit, reporting, and reopening.

Define the CRM and Field-Service Boundary

CRM can own customer relationship and case intake. A field-service system may own dispatch, technician work, parts, checklists, signatures, and completion evidence.

Microsoft’s Field Service overview names work orders, scheduling, mobile, customer assets, service history, inventory, and maintenance.

That documentation illustrates a distinct field-service scope. It does not prove that any CRM includes those functions or that this product fits a solar company.

Map the handoff:

1. CRM case reaches an approved dispatch state.
2. Integration creates a work order with stable customer, site, system, asset, case, and entitlement references.
3. Field system validates service location, skill, safety, parts, schedule, and technician.
4. Technician records work under controlled mobile and offline rules.
5. Supervisor reviews completion, parts, evidence, and exceptions.
6. Integration returns a controlled summary and completion reference to the CRM case.
7. Customer communication follows approved channel and preference controls.
8. Reconciliation confirms both systems agree on identity and state.

Test cancellation, rescheduling, partial work, wrong asset, missing parts, offline conflicts, reassignment, failed sync, and reopened cases.

Govern O&M, AMC, CMC, Renewals, and Referrals

Operational commitments need named contracts and schedules. Do not create recurring tasks from vague sales notes.

For O&M, annual maintenance contracts, and comprehensive maintenance contracts, record exact scope, covered assets, term, exclusions, response, visits, parts, reports, price, renewal, and termination.

Use the signed contract as authority. The CRM can track renewal opportunity and customer communication, while the service system may own recurring work.

Track scheduled versus completed maintenance separately. A calendar event does not prove field work occurred.

Renewals should start from verified contract dates and notice terms. Confirm customer, billing party, site ownership, asset status, open complaints, and pricing authority before outreach.

Referral tracking needs source, permission, referred party, relationship, date, reward terms, attribution, and outcome. Do not expose one customer’s information to another.

Record customer relocation, property sale, company restructuring, and system transfer as relationship changes. Do not overwrite historical ownership.

Create an Authoritative-System Map

List every record and name one authoritative owner. Other applications may cache summaries or references but should not create competing truths.

The actual owner depends on your architecture. Document creation, update, approval, synchronization, retention, and deletion for every interface.

The solar software API integration guide covers general interface design. Customer management adds lifecycle identity and customer-impact tests.

Test Integrations, Errors, and Reconciliation

For each integration, document source, target, direction, trigger, frequency, identity keys, fields, versions, permissions, limits, retries, and support owner.

Never synchronize records by display name alone. Use stable identifiers and relationship keys.

Preserve the source timestamp, acceptance timestamp, version, and correlation identifier. An integration must not replace an approved record with an older update.

Define idempotency. Retrying one event should not create another site, project, asset, case, task, message, or work order.

The error queue should show record identity, failure time, reason, retry count, owner, and next action. Restrict sensitive payload access.

Reconcile both count and content. Matching record counts can still hide wrong customers, sites, assets, statuses, owners, or versions.

Create daily checks for new customers, sites, converted projects, commissioned systems, assets, open cases, work orders, status changes, and failed events.

Investigate unexplained differences after an agreed lateness window. Preserve resolution evidence and repeat failures for root-cause review.

Handle Duplicates, Households, and Multi-Site Customers

Duplicate management must preserve relationships. Merging two contact records must not merge two separate sites, contracts, or installed systems.

Define match signals for people, companies, sites, meters, projects, assets, and cases. No single field should decide every merge.

Test these cases:

• Spouses or family members at one site
• Landlord, tenant, and property manager
• Company with many branches and billing contacts
• One contact representing several legal entities
• Same person using two phone numbers or emails
• Site sold to a new owner
• Customer moves while retaining another system
• Duplicate enquiry for an existing project
• Equipment replacement with a new serial
• Reopened issue versus new failure

Record the merge decision, reviewer, time, source records, retained values, relationships, and reversal method. Do not silently delete conflicting evidence.

Configure Roles, Security, Privacy, Retention, and Audit

Build roles around job duties and data need. Sales, survey, engineering, project, finance, service, technician, manager, administrator, support, and auditor access should differ.

Test record-level and field-level access. A technician may need site instructions without needing all financial, referral, or marketing data.

Protect contracts, identity documents, financial records, site photographs, signatures, equipment credentials, and complaint evidence under documented internal controls.

Use individual accounts and strong authentication. Control session duration, device loss, downloads, exports, API access, support access, and employee offboarding.

Define retention by record type and purpose. Leads, contracts, tax records, technical documents, equipment history, cases, communications, logs, backups, and suppression evidence differ.

Deletion needs an approved workflow across CRM, integrations, files, exports, backups, messaging, project, and service systems. Do not erase suppression controls in a way that enables recontact.

Audit history should cover identity, relationships, consent, preferences, owner, status, commitments, documents, assets, cases, exports, merges, and privileged access.

Run an incident exercise. Test containment, credential revocation, evidence preservation, privacy escalation, customer communication, recovery, reconciliation, and corrective action.

Define Reports Before Automating Them

A dashboard is reliable only when each metric has a definition, owner, source, clock, exclusions, and data-quality test.

Define at least:

• Active customer and active site
• Sold, installed, commissioned, and handed-over project
• Installed system and active asset
• Open, acknowledged, assigned, dispatched, resolved, closed, and reopened case
• First response and resolution time
• Service-level pause and breach
• First-time completion and repeat visit
• Warranty claim acceptance and closure
• Planned and completed maintenance
• Renewal eligible, offered, accepted, and lapsed
• Referral requested, received, qualified, and converted
• Data-completeness and reconciliation error

Do not call a case resolved when only a task is closed. Do not call maintenance completed from an appointment status alone.

Segment carefully by customer, site, system, asset, case type, contract, branch, and owner. Preserve small-group privacy and access controls.

Test Mobile Work Separately

Mobile access can support sales, survey, installation handoff, case intake, and field work. Each role needs different tasks, permissions, and offline behavior.

Build a device matrix covering Android, iPhone, tablet, and browser where required. Confirm current app or web availability without assuming parity.

Test identity, sessions, camera, photos, location, files, notifications, local storage, offline queues, conflicts, retries, partial uploads, logout, device loss, and offboarding.

A mobile CRM may not equal a field-service application. Confirm work orders, parts, checklists, safety, signatures, and completion only when those tasks are required.

Use the solar CRM app guide for the full deployment assessment. Customer-lifecycle acceptance should still test its critical mobile jobs.

Plan Migration and Administration

Inventory spreadsheets, messaging groups, proposal folders, accounting customers, project tools, warranty sheets, monitoring portals, and service logs before migration.

Classify each source by owner, quality, identifiers, fields, duplicates, consent context, files, history, retention, and authority. Do not import everything blindly.

Create mapping, cleansing, exception, and approval rules. Preserve original identifiers and migration batch details.

Run trial migrations and reconcile records, relationships, files, owners, dates, versions, permissions, and counts. Test reversal before production cutover.

Name a product owner, data steward, administrator, integration owner, security owner, privacy owner, report owner, and service-process owner.

Administration time belongs in total cost. Include configuration, users, roles, workflows, fields, reports, releases, training, cleanup, audits, incidents, and vendor coordination.

Run a Failure-Led Pilot

Use representative test records with approved data. Agree pass thresholds before the pilot.

Test the normal lifecycle and the following failure cases.

1. Duplicate contact with a new site
2. Household members with different permissions
3. Multi-site commercial account
4. Missing or revoked communication permission
5. Superseded design or proposal version
6. Contract change after project handoff
7. Equipment substitution and serial correction
8. Complaint against the wrong site or asset
9. Case escalation during owner absence
10. Field-work sync failure and replay
11. Offline mobile conflict
12. Customer ownership transfer
13. Record merge and reversal
14. Export and replacement-system import
15. Deletion, connector removal, and account closure

Measure record completeness, relationship accuracy, version integrity, permissions, routing, service clocks, integration errors, reconciliation, operator effort, support, and export quality.

Do not approve from a polished demonstration. Require observed evidence on the intended configuration, roles, data model, edition, and integrations.

Compare Total Cost, Renewal, and Exit

Model licenses, editions, service modules, field tools, portals, implementation, customization, migration, integration, storage, messaging, support, training, administration, and audit.

Add the cost of exception handling, duplicate cleanup, reconciliation, release testing, privacy requests, incidents, exports, and vendor changes.

Separate required scope from optional convenience. A low CRM price can hide a second service product, integration platform, or substantial administration.

At renewal, verify price, tax, users, records, storage, APIs, automation, service functions, support, data location, terms, and notice periods.

Test export before purchase. Export customers, contacts, sites, relationships, projects, assets, serials, warranties, contracts, cases, activities, preferences, audit, files, and identifiers.

Validate the export in a neutral tool or replacement-system trial. A downloadable file is not a usable exit unless relationships and evidence survive.

Confirm contract termination, access period, credential revocation, connector removal, deletion certification, backups, and open-case cutover.

How to Evaluate QuickEstimate

QuickEstimate is a related-party sales CRM option. It receives the same evidence and acceptance gates as every unrelated product.

The QuickEstimate product page publishes sales CRM, lead, pipeline, quotation, and mobile statements. These are vendor claims, not independent test results.

Its privacy policy publishes data, deletion, backup, transfer, and support statements. Validate them through contract, architecture, configuration, and testing.

Do not infer case management, field service, work orders, asset history, warranty claims, O&M, AMC, CMC, portal, connector, security, or support depth.

Request current written scope for the intended account and edition. Then test identity, consent, lifecycle handoffs, permissions, integrations, failures, reporting, cost, export, and exit.

This guide makes no ranking and promises no customer, service, sales, or financial outcome.

Disclosure: SurgePV and QuickEstimate have a commercial relationship. QuickEstimate receives identical evidence, configuration, security, pilot, support, cost, and exit gates. Vendor publication does not establish independent validation.

SurgePV Is Not Customer or Service Management Software

SurgePV is not a CRM, customer-service desk, warranty system, asset-management system, or field-service platform. It should not own customer cases or service history.

It can provide approved technical and proposal artefacts within its verified scope. The customer system should store controlled links, version identifiers, statuses, owners, and approval context.

Do not copy editable engineering data into CRM fields and let it drift. Keep the technical system authoritative and reconcile controlled outputs.

The customer portal guide covers customer-facing access. The workflow automation guide covers general rules and automation.

Procurement Scorecard

Score observed evidence. Mark a required gate as failed when evidence is missing.

The decision record should name the accepted edition, modules, configuration, integrations, limits, owners, exceptions, and refresh date.

Frequently Asked Questions

What is the best solar customer management software in India?

There is no universal winner. Choose the configuration that passes your customer, site, project, asset, contract, case, consent, handoff, service, integration, security, reporting, support, cost, export, and exit tests. Verify every capability on the intended edition and account.

What is the difference between customer management and lead management?

Lead management controls enquiry intake, ownership, qualification, follow-up, and conversion. Customer management continues through contract, delivery, commissioning, equipment handover, warranty, cases, complaints, field work, maintenance, renewals, referrals, preferences, and ownership changes.

What records should solar customer management software keep?

Keep separate customer, household or company, contact, site, project, system, equipment, contract, warranty, case, work-order reference, communication, preference, and consent records. Connect them with stable identifiers, controlled roles, source evidence, and documented authoritative systems.

Should a solar CRM store technical design data?

Keep authoritative geometry, shading, strings, equipment selection, calculations, drawings, and revisions in the approved technical system. CRM should store a controlled reference, status, owner, approval, checksum or version, and approved commercial summary without becoming a competing design record.

Can one customer record cover several solar sites?

Yes, through explicit relationships rather than copied contacts. Give every site, project, installed system, contract, asset, warranty, and case its own identifier. Then link authorized contacts, roles, ownership periods, billing parties, service parties, and communication preferences.

Does a CRM replace solar field-service software?

Not automatically. CRM may intake and track customer cases, while field-service software may control work orders, dispatch, technicians, parts, checklists, safety evidence, signatures, and completion. Define the authoritative owner and reconciliation for each record and status.

How should a solar company manage customer complaints?

Create a case with source, time, customer, site, system, equipment, issue, severity, owner, response target, and communication history. Link diagnostics, escalation, field work, resolution evidence, customer confirmation, closure reason, and recurrence. Preserve every status change and reassignment.

Is QuickEstimate the top solar customer management software?

This guide makes no ranking. QuickEstimate is a disclosed related-party sales CRM option. Verify current customer, post-sale, case, asset, field-service, warranty, permission, integration, security, support, cost, export, and exit scope. Apply the same evidence and pilot gates used for every vendor.

Is SurgePV customer or service management software?

No. SurgePV is not a CRM, case-management, warranty, or field-service system. Keep customer identity, consent, communications, cases, work orders, assets, and service history in their accepted systems. Link only controlled technical and proposal artefacts where appropriate.