The split: winning the job, and then delivering it
A residential solar job has two distinct halves, and almost every tool an installer buys is built for one of them.
The first half ends when the homeowner signs. Everything before that point is a sales problem: generating and qualifying leads, producing a proposal, comparing financing options, and getting to a signature. This is what a CRM is designed around, and a general CRM like the ones used across many industries handles it competently because the shape of the work is the same everywhere: a pipeline of opportunities moving toward a close.
The second half starts the moment the contract is signed, and it looks nothing like the first. Nothing about it is a pipeline of opportunities. It is a sequence of dependencies, most of which are controlled by somebody outside your company: a utility that has to approve an interconnection, a city that has to issue a permit, a financier that has to accept a document package, an inspector who has to show up. Your team's job is not to persuade anyone. It is to know exactly what each job is waiting on, and to move the things that are actually movable.
Those two halves want different data structures, different daily views, and different definitions of "done". A CRM asks what stage of the sale a deal is at. Operations software asks what this installation is waiting on right now, and who owns it.
Why the post-sale work drifts into spreadsheets
Most installers do not decide to run operations in a spreadsheet. They arrive there.
It usually goes like this. The company already owns a CRM, because it needed one to sell. Post-sale tracking has to live somewhere, so it gets bolted onto the CRM as custom fields: a permit submitted date, an inspection date, a funder milestone, a field for whichever thing broke last quarter. That works at low volume. It keeps working just well enough that nobody stops to reconsider it.
Then the field count grows. Different people add fields over several years, the meaning ends up in the field's label rather than its name, and half of them quietly stop being filled in because the person who cared about that one left. The record is technically complete and practically unreadable, so somebody builds a spreadsheet to answer the question the CRM can no longer answer, and now there are two systems that disagree.
The thing worth noticing is that this is not a discipline failure, and hiring a more organized coordinator does not fix it. It is a structural mismatch. The work being tracked is a dependency graph with external actors in it, and it is being stored in a tool designed for a linear sales pipeline. The spreadsheet appears because the CRM genuinely cannot represent the problem.
What operations software has to do that a CRM does not
Four requirements separate the categories, and they are the ones to test any tool against.
It has to hold the work outside your walls. Most of the post-sale effort in residential solar happens in somebody else's system: a funder's portal, a utility's interconnection queue, a city's permitting site. A tool that only knows what your team typed into it does not know where the job actually is.
It has to make waiting visible. The most expensive state in solar delivery is a job that is stuck without anyone knowing it is stuck. Sales tooling has no concept of this, because in a pipeline a stalled deal simply ages. In delivery, a stalled job is usually waiting on a specific named thing, and the value is in surfacing that thing the day it happens rather than at the end of the month.
It has to survive people. Sales knowledge can live with a rep. Delivery knowledge cannot live with a coordinator, because when that person is out, jobs stop. What a job is waiting on has to be written on the job.
And it has to be honest about money. Funding milestones should be recorded as the financier reports them, not inferred from how far along the install looks. A system that marks a milestone complete because the install is complete will tell you a project is funded when it is not, which is the one error a contractor cannot afford to trust.
How to tell which one you actually need
If your sales team is losing track of leads, proposals, or follow-ups, that is a CRM problem, and adding operations software will not help.
If your sales numbers are fine but the office cannot answer where a specific installation is without asking two people and opening a spreadsheet, that is an operations problem, and buying a better CRM will not help either.
A practical test: pick a job that was sold six weeks ago and ask what it is waiting on right now. If the answer takes more than a few seconds, or if two people give different answers, or if the real answer lives in a spreadsheet somebody maintains by hand, the delivery side of your business has outgrown the tools it is running on. The volume at which this usually becomes acute is lower than most owners expect, because the cost is not linear: each additional concurrent job adds more places to check, not just more rows.