Ben Clarke, Account Executive at Payaca with 10+ years in field service management, explains why solar businesses keep abandoning Salesforce and generic CRMs - and what actually works instead.
Ben Clarke
In 10+ years of working in field service management software, the most common conversation I have is with solar businesses who have already tried a generic CRM. Not ones who are considering it. Ones who tried it, spent months setting it up, and are now looking for something else.
The pattern is remarkably consistent. A growing solar company hits 15-20 installs a month, recognises they need proper software, and picks a name they know: Salesforce, HubSpot, Zoho. Six months later, the system is half-built, the field team refuses to use it, and the ops manager is running a parallel spreadsheet just to keep jobs moving.
This is not a post about why Salesforce is bad software. It is not. It is a post about why it is the wrong software for solar installation businesses, and what the experience of discovering that actually looks like from the inside.
After hundreds of conversations with solar businesses at every stage of growth, the same three personas show up in almost every failed CRM story.
The MD with expensive shelfware. They approved a Salesforce or HubSpot licence 12 months ago. The implementation partner charged five figures. The system technically works, but adoption is at maybe 40%. The MD is still making decisions based on gut feel because the data in the CRM is incomplete. They are paying for a system that tells them less than the spreadsheet it replaced.
The ops manager running a hybrid. They are the one who actually tried to make it work. They built custom objects, wrote process documentation, ran training sessions. But the CRM cannot handle multi-option quoting, does not understand installation stages, and has no concept of compliance workflows. So they run the CRM for customer records and a spreadsheet for everything else. Two systems, double entry, constant reconciliation.
The admin team doing manual compliance. Grid applications, permit submissions, commissioning forms - none of this exists in a generic CRM. So the admin team maintains a separate folder structure, manually tracks submission dates, and spends hours each week on work that should be automated. Every compliance task is a copy-paste job from the CRM into a separate system.
If you recognise yourself in any of these, you are not alone. It is one of the most common stories I hear.
The core problem is not features. It is data model. Salesforce was built around the concept of an Opportunity that moves through a sales pipeline and ends at Closed Won. Solar installations are not opportunities. They are multi-stage projects that involve design, compliance, procurement, scheduling, installation, commissioning, and ongoing service.
When you force that process into a sales CRM, specific things break.
Solar quoting is fundamentally different from generic sales quoting. A homeowner wants to see options: a 10-panel system versus a 14-panel system, with or without battery storage, with different payment structures. They want to compare, pick, and sign off digitally.
In Salesforce, you get one quote per opportunity. Multi-option proposals require custom development. Equipment specifications, energy production estimates, payment staging with deposit collection - all custom. I have seen businesses spend thousands on a Salesforce consultant just to build a quoting flow that still does not match what their customers expect.
Whether you are dealing with grid connection applications, permit submissions, or regulatory commissioning documents, compliance is not optional for solar installers. It is the foundation of your business. These are not edge cases. They happen on every single job.
Generic CRMs have no concept of this. You can build custom objects and workflows to track it, but you are essentially building compliance software from scratch inside a platform that was never designed for it. And when regulations change, you have to rebuild.
Every region has its own requirements. In the UK, that means grid connection submissions and certification body documentation. In the US, every Authority Having Jurisdiction has different permit requirements, inspection processes, and documentation standards. Either way, a CRM that does not understand this forces your team to manage it all manually.
This is the one that kills most implementations. Your engineers and installers are on-site, working from a mobile device. They need to complete site surveys, fill in commissioning forms, take photos, update job status, and check what is next on their schedule.
Salesforce's mobile app is built for sales reps logging calls and updating opportunity stages. It is not built for an engineer standing on a roof who needs to submit a commissioning checklist. The disconnect between what the system expects and what the field team actually needs to do is so large that most engineers simply stop using it within weeks.
The licence fee is the smallest cost. The real expense is everything that goes into trying to make a generic platform behave like an industry-specific one.
Consultant fees. Most solar businesses cannot configure Salesforce themselves. They hire an implementation partner or consultant, typically at a day rate somewhere around that of a specialist. The initial build takes weeks. Then there are change requests, bug fixes, and the inevitable rebuild when you realise the original architecture does not scale.
Maintenance of custom objects. Every custom object, workflow rule, and automation you build is something you have to maintain. When Salesforce pushes an update, your customisations can break. When a team member leaves, the knowledge of how those customisations work often leaves with them.
Team workarounds. When the system does not fit, people work around it. Spreadsheets reappear. WhatsApp becomes the real job management tool. Data quality degrades because people enter the minimum required rather than what is actually useful. You end up with a CRM that has data in it but cannot be trusted.
Slow quoting. This is where it hits revenue directly. If your team takes twice as long to produce a quote because they are fighting the system, you are losing deals. Speed to quote is one of the strongest predictors of close rate in residential solar. Every extra day between site survey and proposal is a chance for the customer to go elsewhere.
After years of watching this pattern repeat, the businesses that get it right share a few common characteristics in the platform they choose.
The pipeline matches the installation lifecycle. Not a sales pipeline with extra stages bolted on, but a genuine project pipeline that covers lead, survey, design, proposal, acceptance, installation, commissioning, and handover. Each stage has the fields, automations, and actions that make sense for that point in the process.
Multi-option proposals are native. Your sales team should be able to build a proposal with multiple system configurations, different equipment options, and staged payment plans in minutes, not hours. The customer should be able to review, compare, select, and sign off digitally, with deposit payment at the point of acceptance.
Compliance is built in, not bolted on. Permit applications, grid connection submissions, commissioning forms, handover packs - these should be part of the workflow, not a separate system. When an engineer completes a job, the compliance documentation should be generated from the data already in the system, not copied from somewhere else.
Design tool integration connects the workflow. When your team creates a system design in OpenSolar or a similar tool, that design should flow into your quoting and procurement process. Panel layouts, equipment lists, energy production estimates - imported, not re-entered.
Mobile works for site work. The mobile experience should be built around what engineers actually do on-site: site surveys, photo capture, form completion, job status updates, schedule visibility. Not a shrunk-down version of a desktop sales interface.
Weeks, not months. Implementation should take weeks, not months, because the platform already understands your industry. You are configuring it to match your specific process, not building an industry-specific tool from scratch.
What to ask in a demo
Ask the vendor to show you a complete workflow: lead comes in, site survey is booked, system is designed, multi-option proposal is sent, customer accepts and pays a deposit, job is scheduled, engineer completes installation and commissioning, compliance documents are generated, and the customer receives their handover pack. If any step requires leaving the platform, that is a gap you will feel every day.
The most common objection I hear is: "We have already invested so much in our current system - switching will be painful." In practice, switching to a platform built for your industry is significantly less painful than continuing to maintain one that was not.
Data migration is simpler than you think. Your customer records, project history, and pipeline data can typically be exported from your existing CRM and imported into a new platform. The data that matters (customer details, site information, project status) transfers cleanly. The custom objects and workarounds you built? Those do not need to come across because the new platform already handles those workflows natively.
Process mapping reveals how much you were working around. When you map your actual process against a purpose-built platform, you often discover that half of what your team was doing was compensating for the system rather than doing productive work. The compliance tracking spreadsheet, the quoting workaround, the manual scheduling board - all of that goes away.
Team adoption is faster. When a system actually matches how your team works, adoption is not a battle. Engineers use the mobile app because it does what they need. The admin team uses the compliance workflow because it saves them hours. The ops manager uses the pipeline view because it shows them what is actually happening. You do not need a change management programme. You need software that fits.
2-4 weeks, not 2-4 months. A purpose-built platform that already understands solar installation workflows can be configured and live in 2-4 weeks. That includes data import, process configuration, team training, and go-live support. Compare that to the 3-6 month implementation timeline of a generic CRM, and the decision becomes straightforward.
If you are reading this and recognising your own situation, here is a simple test: ask your ops manager how many systems they use to manage a single installation from lead to completion. If the answer is more than two, your CRM is not doing its job.
The solar businesses that are scaling successfully, doing 30, 50, 100+ installs a month, are not doing it on Salesforce. They are using platforms built for the way solar installation businesses actually work.
See how Payaca helps clean tech installers save time and grow their business.
Book a demo
A comprehensive guide to the software solar installation businesses use, from CRMs and field service tools to design platforms and compliance systems. Covers what to look for at every stage of growth.
The US is adding a record 86 GW of new power capacity in 2026, led by solar and battery storage. But the residential market is restructuring fast. Here's where demand is headed, which states are hottest, and what growing installers need to do now.
The solar companies that thrive in 2026 won't just install panels. Here's how leading installers are diversifying into home energy companies with recurring revenue, adjacent services, and new business models.