Post-sale / job execution
Scheduling, dispatch, installation, inspection, and invoice. This is the FSM's core competency. Treehouse's role here is primarily providing the permit package and scope documentation the tech needs in the field.
Contractor needs a smooth installation that matches the proposal scope. Homeowner needs the work completed on time, to spec, and with a passing inspection.Hypothesis
Treehouse is not a field tool. The tech arrives on site with a Treehouse-generated permit package, not a Treehouse app. The post-sale step is where Treehouse's output is consumed, not where Treehouse is used. The open question is how on-site scope changes flow back into the Treehouse project record.Hypothesis
How competitors approach this
No companies mapped to this flow yet.
No companies mapped to this flow yet.
Treehouse read
What Treehouse owns, orchestrates, and defers to the FSM — plus six supporting questions that shape architecture decisions. All entries are hypothesis until validated internally.
The permit package (panel schedule, single-line diagram, load calculation, code citations) that the tech carries to the job and presents to the inspector.Treehouse internal
Permit application status tracking. As-built data collection for accuracy feedback.Hypothesis
Everything else: scheduling, dispatch, work order, completion, invoicing, payment, job lifecycle status.Hypothesis
A permit package generated from the Edison scope and Panel IQ data — not manually drafted. If the permit package is accurate, the tech spends less time with the inspector.Treehouse internal
Document delivery to the field. Work-order management.Hypothesis
The as-built record — how the job was actually completed vs. the scope — is a data asset for property intelligence and future scoping accuracy. Whether Treehouse captures this is an open design question.Hypothesis
In their FSM: the work order. In Treehouse (if they return): the permit package and job record.Hypothesis
Permit package delivery to the FSM job record. Job status update from the FSM to Treehouse.Hypothesis
Everything in the field. Treehouse is not a field tool.Hypothesis
Research detail11-field structured template: contractor workflow, information flows, product outputs, FSM read/write
Contractor needs a smooth installation that matches the proposal scope. Homeowner needs the work completed on time, to spec, and with a passing inspection.Hypothesis
Tech arrives on site with the work order. Completes the installation per the scope. Calls the inspector. Collects final payment. Updates the FSM with job completion.Hypothesis
From Treehouse: scope of work, permit package, equipment specifications, panel schedule, single-line diagram. From FSM: work order, customer address, materials list.Hypothesis
FSMs (HCP, ServiceTitan, Jobber) own this step entirely. Treehouse's contribution is the permit-ready documentation that travels with the job.Hypothesis
Schedule the job. Order materials. Dispatch the tech. Complete the installation. Call and pass inspection. Collect final payment. Close the job in the FSM.Hypothesis
On-site deviations from the scope — unexpected conditions the photos didn't reveal. Inspector feedback that requires additional work. Material substitutions due to availability.Hypothesis
A completed, invoiced job. An inspection approval. A closed job record in the FSM.Hypothesis
FSM owns this step. Treehouse reads job status to track whether a scoped job was completed. Any on-site scope change may need to update the Treehouse project record.Hypothesis
FSMs handle job execution well — HCP, ServiceTitan, and Jobber all have mature dispatch, work-order, and invoicing workflows. This is the FSM's home territory.Company claimSource
On-site scope changes require re-estimating and re-proposing — a workflow that crosses Treehouse and the FSM. How to handle a job that deviates from the Treehouse scope is an open design question.Hypothesis
Treehouse is not a field tool. The tech arrives on site with a Treehouse-generated permit package, not a Treehouse app. The post-sale step is where Treehouse's output is consumed, not where Treehouse is used. The open question is how on-site scope changes flow back into the Treehouse project record.Hypothesis
Open questions
- 01How does Treehouse track whether a job was completed as scoped — or how does it learn about on-site deviations?
- 02What happens to the Treehouse project record after job completion — is it archived, or does it accumulate as property intelligence?
- 03Is there a post-job touchpoint where Treehouse collects 'as-built' information to improve future scoping accuracy?
- 04Does Treehouse's permit package support the AHJ inspection process, or does the contractor still need to prepare separate documentation?