A solar sale can look finished in the sales pipeline while the operations team is still searching for the accepted scope, site details and the person who owns the next decision. Adding another dashboard will not resolve that gap unless the underlying records and handovers are designed properly.
A custom solar CRM can bring those moving parts into an agreed workflow. The useful starting point is the journey from enquiry to an installation handover your team can trust.
Nexus's AI Launch Kit combines custom software and AI setup with options for training and operational support. Our in-house software engineers and coders can scope a system around how your business works. Here is what to decide before a build begins.
Define the solar workflow before drawing the dashboard
Walk through a recent straightforward job and a difficult one. Identify the events that actually move work forward: a customer supplies information, accepts a particular proposal, receives an approved scheduling decision or provides a missing document.
The following is an illustrative pipeline, not a technical or regulatory checklist:
| Working stage | Useful evidence in the CRM | Next responsible person |
|---|---|---|
| Enquiry received | Customer request, source and assigned follow-up | Sales coordinator |
| Scope being prepared | Current requirements and unresolved questions | Authorised sales or technical reviewer |
| Proposal accepted | Accepted version and outstanding conditions | Operations coordinator |
| Handover in preparation | Required records, exceptions and decision owners | Scheduling or operations lead |
| Ready for the agreed next step | Recorded release decision and remaining actions | Named delivery owner |
Define what each stage means for your business and who can change it. Keep “waiting for customer”, “waiting for technical review” and “missing internal information” distinguishable. They need different actions.
Our solar sales handover checklist helps identify what operations needs from the sale before that workflow becomes software.
Build records that survive a change of scope
Separate the customer, property, proposal and job records where the work requires it. One customer may have more than one site; one site may have several proposal versions. A single notes field makes those relationships difficult to follow.
Give important records stable references. Link the accepted proposal to the job, preserve the current equipment details and record who approved a subsequent change. The build brief should explain which system owns each fact.
Consider a fictional job where a customer requests a battery after accepting a solar proposal. The coordinator records the request and sends it to the authorised reviewer. The CRM should keep the accepted scope visible while the new proposal is considered. It should not overwrite the original equipment record and imply that the change is already agreed.
Design the screen around that distinction: current approved information, proposed changes and unresolved decisions. An administrator can coordinate the evidence while qualified and authorised people retain their professional and commercial responsibilities.
Connect systems through a clear data agreement
List the tools the team already uses for enquiries, proposals, scheduling, files and accounting. For each proposed connection, specify the event, fields, direction, record identifier and owner of a failed transfer.
For example: when an authorised person records an accepted proposal, create one operations job with the proposal reference and assigned coordinator. If the event arrives twice, the intended result is still one job. If a required field is absent, the transfer should enter a visible exception queue rather than quietly creating an incomplete record.
Integration scope depends on the other product's available API or export method, subscription, account permissions and permitted use. Discovery should confirm those details before promising a connection. Where a supported connection is unavailable, agree a controlled import or manual handover.
Also decide how corrections travel. If the phone number changes in the CRM, which other records should update? If two systems disagree, a person needs an authoritative source and a resolution procedure.
Know what the software foundations do
GitHub, Vercel and Supabase have different jobs in a possible custom build. The final architecture should follow the agreed requirements.
GitHub hosts the source code and its Git history, helping engineers trace changes. That history is about the software; it does not replace backups of live customer records. GitHub: about Git.
Vercel can deploy the application, providing preview and production environments. A preview lets the team examine a proposed release before it reaches the live site. Agree preview access and test-data handling explicitly. Vercel: deployments.
Supabase provides a Postgres database and authentication tools. Signing in and being permitted to access a record are separate questions; permissions need to match each role. Supabase: database, Supabase: Auth.
Ask the engineer to demonstrate permissions with ordinary user accounts. A salesperson, coordinator and administrator should each see and change only what the design permits. Supabase documents database grants and row-level policies as separate access controls; configuration and testing remain necessary. Supabase: securing your API.
Give AI a narrow job and a named reviewer
A fixed rule can detect an empty required field or a follow-up date that has passed. Use AI where interpreting or drafting language is useful: preparing an internal summary, suggesting a reply or organising approved notes.
Keep the source beside the suggestion and identify who accepts it. A generated summary must not turn “customer requested Friday” into “installation confirmed Friday”. A missing attachment flag also does not establish whether the eventual document is adequate.
Approve which information may enter the chosen AI service, then test with fictional or appropriately authorised records. Our AI solar administration guide explains how to organise drafting, checking and escalation around those limits.
Launch with trained operators and an acceptance test
Before launch, run the ordinary job and the battery-change example through the proposed system. Include a duplicate event, missing field, failed connection and user without approval authority. Check what the operator sees and who receives the exception.
Agree a migration plan, record checks, recovery arrangements and the person who approves release. Train the daily operator to maintain the queue and escalate faults. Nexus VA support can be scoped around those responsibilities, while engineers maintain the software and business owners retain decision authority.
Bring your current tools, one example job and its most awkward handover to an AI Launch Kit discussion. Those details turn a broad request for a solar CRM into a build brief your team can review and operate.
