Graphs are passive. Service is the product.
Most solar monitoring stops at charts. Someone still has to look at them, spot the problem, and decide to act. On a handful of sites that's fine. Across a fleet it doesn't scale — and it's exactly the work owners are happy to pay someone else to do.
That "someone else" is an operations-and-maintenance (O&M) service, and it's recurring revenue. The whole point of the pipeline above is to do the looking, the spotting and the acting automatically, so the installer can sell the outcome — a watched, guaranteed site — instead of selling their evenings staring at dashboards.
Step 1 — Notice the right thing
First, the system checks each site on a schedule. Two kinds of fault matter most:
- Offline — a site that has simply stopped reporting.
- Underperforming — a site that's running, but producing less than it should for the day.
Two small details are what make this reliable instead of noisy:
- Watch the clock, not just the meter. A solar site producing zero watts at night isn't broken — it's asleep. The health check only runs during daylight hours, so dusk doesn't trip a hundred false alarms.
- "No data" isn't the same as "no power." The signal that actually means trouble is "we haven't heard from this site" — its last-seen time going stale — not "power is zero." Alerting on lost communication instead of zero power is the single difference between a system people trust and one they mute.
One practical note on the plumbing: cloud monitoring APIs, SolarEdge's included, don't phone you when something breaks. There are no push alerts, and there's a daily limit on how often you can ask. So the health check is a polite, scheduled poll — spaced out, batched across sites, and backed off when the API says "slow down" — not a live feed.
Step 2 — Open exactly one ticket
When a new fault appears, the system opens a single service ticket, linked to the site, the customer and the project. The important word is single. A site that's been down for six hours shouldn't produce six hours of duplicate tickets. While a fault is open it owns one ticket, and only one: a new fault makes a ticket; the same fault, still there, makes nothing.
Step 3 — The ticket becomes a work order
A ticket on its own is just a note. It earns its keep when it turns into a work order — a job assigned to a technician, with the site details, the history and the customer already attached. They go out, fix it, sign it off. And because it all lives in one system, the repair is recorded against the very same site you were monitoring. No re-keying, no separate spreadsheet, no "which job was that again?"
Step 4 — Recovery closes the loop
When the site starts reporting normally again, the system spots it the same way it spotted the fault — and closes the ticket itself. Nobody has to remember to tick it off. That's the dashed line looping back in the diagram: the cycle closes on its own, so your list of open tickets only ever shows real, current problems.
Why this is a business case, not just a feature
A generic CRM can store a customer. A generic ERP can raise an invoice. Neither one watches a solar site and opens its own repair job. That gap is exactly where an installer turns a one-off sale into an ongoing O&M contract — monitored sites, a guaranteed response, a recurring fee. The pipeline above is what makes that promise keepable without hiring someone to watch screens all day.
Where this sits in SolarERP
This is the thinking behind our monitoring and service work. The same data that powers the dashboards also feeds the fault-to-ticket flow on the roadmap, and it's the backbone of the service & warranty story. Monitoring you can look at is table stakes. Monitoring that opens its own work orders is the part worth paying for.