Treehouse — Competitive Analysis
Flow 12·Unresearched·housecallpro, servicetitan

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.

Install readyFSM execution
User goal

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 implication

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.

Treehouse ownsCore IP or data that Treehouse controls and no partner provides.

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

Treehouse orchestratesThird-party capabilities Treehouse coordinates but does not own.

Permit application status tracking. As-built data collection for accuracy feedback.Hypothesis

Stays in the FSMWorkflow or data that belongs in the contractor's system of record.

Everything else: scheduling, dispatch, work order, completion, invoicing, payment, job lifecycle status.Hypothesis

Differentiated intelligenceWhat Treehouse knows or computes that competitors cannot easily replicate.

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

Commodity infrastructureCapabilities that are table stakes — others have them too.

Document delivery to the field. Work-order management.Hypothesis

Persists across the journeyData or state from this step that must travel to later steps without re-entry.

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

Contractor seesWhat the contractor-facing UI surfaces from this step.

In their FSM: the work order. In Treehouse (if they return): the permit package and job record.Hypothesis

Happens automaticallyWorkflow events that fire without a contractor action.

Permit package delivery to the FSM job record. Job status update from the FSM to Treehouse.Hypothesis

Human takeoverConditions that require a contractor or Treehouse team member to intervene.

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
User goalWhat the homeowner and contractor each need from this step.

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

Contractor workflowHow contractors handle this step today, with or without software.

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

Information entersWhat data flows in — from the homeowner, the FSM, prior steps.

From Treehouse: scope of work, permit package, equipment specifications, panel schedule, single-line diagram. From FSM: work order, customer address, materials list.Hypothesis

What the product doesWhat the software handles — based on evidence, not assumptions.

FSMs (HCP, ServiceTitan, Jobber) own this step entirely. Treehouse's contribution is the permit-ready documentation that travels with the job.Hypothesis

Contractor must doSteps that always require a human decision or action.

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

Requires judgmentWhere automation breaks down and a licensed trade professional is needed.

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

Product outputsWhat the step produces — data, documents, FSM records.

A completed, invoiced job. An inspection approval. A closed job record in the FSM.Hypothesis

FSM read / writeWhat the tool reads from and writes to the contractor's system of record.

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

Product strengthsWhat the best products in this step do unusually well.

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

Product weaknessesWhere current products fall short or create new problems.

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 implicationWhat this step means for Treehouse's product positioning and architecture.

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?