Removal & reinstall
Take the array down, wait for the roofer, put it back. That is one job with two visits — different crews, different forms, different months — and software that models it as a single appointment gets your reporting wrong every time.
Removal and reinstall work is a large share of solar service revenue, and almost no field service platform models it. A takedown happens in one month, the roofer takes however long they take, and the putback happens in another — sometimes another quarter. Treat that as one appointment and the reporting is wrong: the work shows in the month it was scheduled rather than the month it was worked, and a job that is genuinely waiting on somebody else looks stalled.
SolarProjeX treats a reroof as one work order with distinct visits. Each visit keeps its own crew, its own inspection form, its own dispatch notes and its own date. A closed trip keeps the words it was closed under, so history does not get rewritten by whatever the ticket says today. Completion follows the visits, not one flag on the work order. A putback shows in the month it was actually worked.
Billing works the way the trade works. The roofing company is frequently the payer, and the roofer's identity is stripped server-side before it ever reaches a technician's device — the field sees that a roofing account is being billed, the office sees which one. Who pays travels separately from who they are, because a tech does not need the payer's name to do the work and a competitor does not need it at all.
How it works
Takedown and putback are separate visits on the same work order — separate crews, separate forms, separate dates.
A putback counts in the month it was worked, so revenue and volume land where the work actually happened.
Techs see that a roofing account is being billed. Which roofing account is office information, removed before the data leaves the server.
Open one roofing account and see every invoice attached to it, and what is actually still outstanding.
Because they are one commitment to one customer at one address, and splitting them loses the link. Two jobs means two histories, duplicate customer records, and no single place that answers whether the array is back on the roof yet.
Because which builders and roofers send you work is commercially sensitive, a technician does not need it to complete the job, and a device in the field is the easiest place for it to leak. The field is told that a roofing account pays; the office is told which one.
Reporting knows the difference between a job nobody has touched and a job sitting on the calendar waiting for a third party. The second is normal reroof work, not a problem to escalate.
Yes. A takedown and a putback need different checklists, so each visit picks its own form and keeps it, even after the ticket moves on.
One platform from the first lead to the last warranty claim. Every capability below is part of it.
Start free in 30 seconds. No credit card. Cancel anytime.
Start your free trial →