Operations software that lets one rollout cover many buildings
CRM, site records, surveys, quotes, consents and delivery in one system, modelled so a single deal can cover as many buildings as the negotiation does.
Commercial solar is sold to a company and installed on a building, and the two do not map one to one. A rollout across six depots is one negotiation, one decision and one forecast, but six roofs, six grid connections and six surveys. The platform this installer was using was built around one site per deal, which is where the trouble started, and it is worth checking whether yours is too.
We have built this once, for one commercial solar installer, and the case studies are anonymised. That is the whole of our solar track record: one client, no product you can buy, no installed base and no claim about the sector at large. This page draws on the multi-building deep dive; a second case study covers the wider system built for the same client. What it gives is a worked answer to the multi-building problem, and the rest of this page is that answer.
If your sales are one deal to one site, the multi-building modelling will matter much less to you and a standard CRM shape fits. Say so early; it saves both of us time.
What goes wrong when the deal is the record
The platform the installer was using allowed one site per deal. So the team either raised six deals for a negotiation that had happened once, which breaks the forecast, or recorded one and left five buildings off the system, which breaks everything downstream.
Grid, planning and structural applications inherited the same flaw. They were filed against a deal rather than a building, so on a multi-site deal there was no reliable answer to which roof an application was for, and the historic records could not tell anyone after the fact.
Getting to a building was slow in its own right. The sidebar was twenty unlabelled siblings, and a site's address, supply detail, surveys, deals and consents sat on screens that did not reference each other.
The building is the record
A deal that covers as many buildings as the negotiation does
One building is marked primary, and each site shows every deal covering it. The quote stays per deal, because it is one negotiation and one quote, but it names the buildings it prices, and a multi-building quote states what winning it will do. Nothing about how a sale is run changed; what changed is the number of roofs one sale can describe.
One project per building, on winning
Winning a deal opens a project per building, each named for its building and each with its own delivery board, tasks, milestones and procurement starters. Contract value is split across the buildings in scope with the remainder on the primary, and a test pins that the parts always sum back to the contract exactly. Re-running a win is safe: a building linked afterwards gets its project on the next run, with nothing duplicated.
Consents scoped to the roof they belong to
Grid, planning and structural applications are scoped to the building, and project adoption is scoped to each project's own building. Without that second scope, whichever project was created first would swallow the other five buildings' applications, which reads as working software right up to the point somebody checks which roof an application is for.
A site record that says what is missing
The site record is seven tabs, opening on a data-readiness overview that names what is missing and which stage it blocks, then location and access, meter and supply, surveys, deals and quotes, grid and planning, and the customer. The current tab lives in the URL so it survives a refresh and can be linked to.
A migration that refuses to guess, and four things found on the way
- 01
File history only where it is provable
Historic consents recorded only their deal. The migration filed them against a building only where the answer is unambiguous, meaning the deal covers exactly one site. Deals covering several were deliberately left alone, because which of six depots a grid application belongs to is not something a migration can know, and a guess puts an application on the wrong roof.
- 02
Make the unfiled visible
The records the backfill did not file surface in a panel on the site that explains how to file them. That limit is visible rather than hidden, and the backfill guessed no consents at all.
- 03
A query that dropped records while appearing to merge them
A deal page's query dropped every consent filed against the site while appearing to merge them. It was one of four failures that had been quiet, and quiet ones do not announce themselves: the page looked right while consents were missing from it.
- 04
Three more that had been silent
A migration with no twin for the deployed database, so production would never have received the table. A documented column that no route could write and nothing rendered. A sandbox fallback that changed a deal's primary site every time a building was added. Each had been silent until it was found.
What the work costs, and what we cannot say
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, and the case study states neither a duration nor a price, so the range is not attributed to it. Our build-versus-buy article says a full application typically runs eight to twelve weeks and a focused automation or integration two to four; those are typical ranges, not a quote for this.
For a platform like this, the number that moves most is the historic data. Records that must be migrated and reconciled, as the consents were, are the part most likely to move the estimate. If your existing records link consents to deals and not buildings, the honest position is that some of them cannot be filed automatically, and the estimate should include a way for a person to file the rest.
Where this is the wrong answer, and what is not in it
Buy a CRM if every deal is one site. The multi-building model is the whole reason to build, and without it you are paying for a custom system to do what a product already does. Building is also the wrong call when you would only be replacing a tool that fits, and the build-versus-buy arithmetic should come first. A common right answer is to keep the sales tool and build the operational record that sits behind it.
And be clear about scope. The multi-building case study covers CRM, site records, surveys, quotes, consents and delivery. It does not cover yield modelling or monitoring after installation, and we make no claim about either. The wider case study for the same client mentions a solar design studio, but we make no claim about the engineering behind it. If those are the problem, this is not the page that solves it.
Related projects that were not this job
Here for the argument rather than as evidence of this exact work. Each one bears on a decision above, and the note says which.
The disciplines behind it
Platforms that bear on it
Related reading
Solar operations software, specifically
The installer's platform was built around one site per deal, and yours may be too. When a negotiation covers six depots you end up raising six deals, which splits the forecast, or recording one and leaving five buildings off the system. Consents then get filed against the deal instead of the roof, and nobody can say afterwards which building an application was for. The fix is a model where the building is the record and a deal can cover as many of them as the negotiation does.
No. This was a client engagement for a commercial solar installer, and it is anonymised. We have no product, no installed base and no claim about the solar sector in general, and we do not claim yield modelling or post-installation monitoring. What we can offer is the worked answer to the multi-building problem, adapted to your business.
By filing only what can be proved. On the installer's build, historic consents were filed against a building only where the deal covered exactly one site. Those on multi-site deals were left alone and listed in a panel explaining how to file them, because a guess puts an application on the wrong roof. We would do the same with yours and show you what was left.
Often, yes. Our platform pages make the argument that a CRM should keep the selling and the operational record should live elsewhere when the thing you manage is a building, not a deal. What causes pain is not deciding which system owns each entity, so both are edited and they diverge.
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, and the case study carries neither a price nor a duration. Our build-versus-buy article says a full application typically runs eight to twelve weeks, as a typical range and not a quote. What moves the number is the exception count, how many systems believe they own the same data, and the historic data that must be reconciled.
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no