Solar CRM vs solar ERP: what an installer needs at each stage of a job

Usually a CRM with some ERP features bolted on, not a full ERP. A solar CRM records the sale: the enquiry, the survey, the system design and proposal, the finance, and the signed contract. What happens after the contract is where installers get stuck. Kit has to be ordered against a job, received and allocated, the install has to be scheduled around scaffolding, electricians and the grid paperwork, the job has to be costed against what was quoted, stage payments have to be invoiced, and the customer has to get a handover pack and service for the next twenty years. Those are purchase-order, stock, job-costing and project jobs. A full ERP would do them, and would also bring a general ledger, payroll and manufacturing modules that a ten-person installer does not need and will not maintain.

So the practical question is not CRM or ERP. It is which stages your current tools cover, where the record changes hands, and whether the gaps are ordinary enough for a product to fill. The rest of this article answers that stage by stage. It is not a list of the best solar CRMs. Vendors and review directories cover that ground, and we sell no product to rank.

The table follows one job from enquiry to aftercare. The last column says which kind of tool normally carries that stage. It is about where the work naturally sits, not what a vendor says its product does: most solar CRMs reach some way into the right-hand columns, and the useful test is how far.

Read down the right-hand column and the pattern is clear. A CRM carries the first five rows comfortably. The middle of the table is purchasing, inventory and scheduling, which CRMs do badly. The bottom is regulated paperwork and an asset register that has to survive for the life of the system. The decision is about who carries the middle and the bottom.

Four things, and none of them needs an ERP's general ledger. Your accounting package should stay the ledger. What it cannot do on its own is tie money and kit to a job.

• Purchase orders against the job. Who may spend how much, who approves above that, what was ordered for which job, what has arrived. Deliveries are often partial, and the supplier's invoice has to be matched against what was ordered and what was received.
• Stock and serial numbers. Panels, inverters and batteries are bought in bulk and allocated to jobs. Serial numbers matter later, for warranties and service, so they belong on the installed asset, not in a delivery note.
• Job costing. Quoted cost against actual cost per job, including labour and scaffolding, so you know which kinds of job make money. This only works if purchase orders and time are recorded against the job from the start.
• Cash. Deposits, stage payments struck as percentages of the contract, retentions on commercial work, and invoices raised at the right milestone. Raise the invoices from the job record and post them to the accounting package, rather than keying them twice.

Keep rules that change with a date in data, not in a template. VAT is the plain example. GOV.UK's VAT Notice 708/6 says installing energy-saving materials, solar panels included, in residential accommodation is zero-rated until 31 March 2027, with the reduced rate of 5% applying from 1 April 2027. The relief also covers buildings used solely for a relevant charitable purpose from 1 February 2024, so a commercial roof is treated differently. A proposal template with 0% typed into it will be wrong on 1 April 2027. A VAT treatment held as a dated setting, checked by your accountant, will not.

Because it has deadlines, it belongs to a building and a meter rather than a customer, and it continues after the sale is closed and the CRM has stopped paying attention. In the UK, the rules come from the Energy Networks Association's engineering recommendations and from MCS.

• G98 covers generation up to and including 16 A per phase, counted across all the units at one premises. For a single premises, the ENA's guide says the installer must notify the DNO within 28 days of commissioning, counting the commissioning day, and that this is a legal requirement.
• For planned G98 installations at multiple premises in a close geographic area, such as a housing estate, the installer applies to the DNO before installing, and each premises still needs its own installation documents.
• G99 covers generation above 16 A per phase. For the smaller Type A installations, the ENA's guide says the application goes to the DNO before installation starts, connection waits for the DNO's approval and any works it needs, and the installation document follows on the day of commissioning or within 28 days of it. The application asks for the address, the meter number, the capacity and the equipment's type-test reference. Larger types have further steps; check the ENA guide for yours.
• MCS says certified installers issue the MCS certificate to the customer within a set window of commissioning: 14 days, or 30 days for an installer certified to MCS's redeveloped installer scheme. Installers are moving to that scheme in phases until 31 March 2027, so check which window applies to you.
• For a domestic customer, that certificate matters after you have left. MCS says an MCS certified installation with a smart meter that records exports qualifies for a regulated Smart Export Guarantee tariff, and suppliers ask for the certificate at sign-up.

Each of those is a status, a date and a deadline per premises. A general CRM can hold them as custom fields, but it will not tell you that a commissioning date was set without a G99 approval behind it, or that a certificate is due in three days. If your installer software tracks these as dated items with reminders, it is earning its fee. If they live in a spreadsheet, that spreadsheet is the first thing to replace.

Outside the UK the steps have different names but the same shape. In the US, an installation generally needs a local permit and an interconnection application to the utility. In Australia, it generally needs network approval from the distributor. Names, thresholds and timings vary by utility, state and network, so treat this only as the shape: a record per site, with a status, dates and an owner.

Start by buying. Software built for installers already assumes surveys, proposals and installs, and many products reach into scheduling and paperwork. For a residential installer selling one system to one home, with a survey on every job and an accountant on the other end, that is usually the right answer, and building would mean paying for a system to do what a product already does.

The second and third rows are often combined: HubSpot before the win and monday.com after it, with a one-way handover. That agrees with our comparison of monday.com and HubSpot, and it works as long as each record has one owner. What fails is two tools that both edit the customer or the job, because they will disagree within a month and nobody will know which is right.

Test a product against your own jobs, not its demo. Take a real job from last quarter and walk it through. Can the system say which roof a grid application is for when one deal covers two sites? Will it refuse to book an install when the G99 approval is missing, or only show a checklist someone can skip? Does a signed proposal keep the prices and VAT it was signed with when your price list changes? Can purchase orders and deliveries be recorded against the job, and does the cost reach the accounting package without being retyped? A product that passes those tests is probably enough.

The most common mistake is making the deal the centre of everything. A deal is a negotiation. The roof, the meter, the grid application, the certificate and twenty years of service belong to a building. If your software lets one deal hold one site, every commercial customer with more than one building forces a choice between duplicate deals, which break the forecast, and missing buildings, which break everything downstream. Our page on operations software for solar installers covers that model in detail. Here is the full list of records.

Two rules matter more than any field. First, the pipeline should save partial data but gate the stage: a deal cannot move to won without the data the next stage needs, and the refusal should name what is missing. Second, any rule that changes, such as prices, VAT treatment, scheme amounts or copy, should be held as dated data someone owns, not typed into a template.

Our first-hand evidence is a small set of anonymised client write-ups. Here is each one with its status as we publish it.

• Operating system for a UK commercial solar installer, live with the client team. The business had been running on a CRM, a monday.com workspace, spreadsheets and several small no-code apps for purchase orders, quotes and marketing, and deals were re-keyed between them. It now runs on one system covering leads, opportunities, sites, quotes, projects, purchase orders, outreach and a customer portal. The pipeline refuses to advance a deal until the data the next stage needs exists, such as a meter number, bills, a signed-off survey, half-hourly data or a quote. An override needs its own permission and records a reason. Purchase orders check a per-person spend policy, route over-limit orders to finance, a director or operations, record deliveries line by line including partial ones, and match invoices against what was ordered and received. Projects have a programme view with critical path and baselines. The team has shaped it through sixty-one feedback tickets. No usage or time-saved figures are claimed, because none have been measured.
• The multi-building model, built for the same installer according to our solutions page. A deal covers as many buildings as the negotiation does. Winning it opens one project per building, with the contract value split so that the parts always sum back to the total. Grid, planning and structural applications are scoped to the building. The write-up gives no status of its own, so we claim none. Its migration filed historic applications against a building only where the deal covered exactly one site, and listed the rest for a person to file.
• A marketing operations platform for a UK commercial solar installer, live. It is not a CRM. It is relevant here for one rule: project posts use only installs flagged as consented for publicity. That flag is a field on the installation record, which is one more reason the site has to be a record of its own.
• A regulated sales platform for a UK heat-pump installer, in build, with nothing yet in front of customers. It is a neighbouring trade with the same structure: compliance gates enforced in code, prices and grant figures held as validated settings, and an audit log that refuses to be rewritten. Our article on heat pump quote automation covers it.

Outside solar, we have also built CRM and project-management tools and accounting workflows and integrations for other clients. Those projects have no published write-ups, so we make no claim about their results.

The limits matter as much. None of this covers yield modelling or performance monitoring after installation, and we make no claim about either. The operating system's write-up mentions a solar design studio, but we make no claim about the engineering behind it. Several of its integrations switch on only when credentials are present, so which ones are live depends on the client's configuration.

The expensive failures are quiet. The screen looks right, and the gap only shows when a customer, a DNO or an auditor asks a question nobody can answer.

Several of those rows come straight from our solar operating system work. The original quote tool had the same arithmetic written out six times and the copies had drifted, and its imports dry-run first and treat a blank cell as nobody having answered, never as an instruction to erase. Our article on why automations break covers the general pattern.

1. 01Walk one recent job through the stage table and mark where it left your system: a spreadsheet, an inbox, someone's memory.
2. 02Decide which system owns each record: customer, site, deal, project, purchase order, certificate. Write it down.
3. 03Make the site a record, with its meter and supply details, if it is not one already.
4. 04Put the post-sale deadlines on dates with owners: the DNO notification or application, the MCS certificate, the handover pack.
5. 05Connect purchase orders and invoices to the job and to your accounting package before buying anything bigger.
6. 06Only then decide between installer software, a configured general CRM or a build, using the real-job test above.

If your business is commercial and one deal regularly covers several buildings, our page on operations software for solar installers covers that model and what a build involves. If you want a second opinion on where your records leak, we are happy to look at the process as it runs today.