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

Customer / job creation

The contractor creates or imports a customer record and a job. Usually happens inside the FSM. For Treehouse, the question is what it inherits from the lead-intake step and what must be re-entered.

Inbound lead
User goal

Contractor needs a job record in their system with enough information to estimate, schedule, and dispatch. Homeowner needs to not repeat themselves.Hypothesis

Treehouse implication

Treehouse should inherit the job record from the lead-intake step — the homeowner should never repeat themselves. The question is whether Treehouse creates its own job object (a Treehouse project) that lives alongside the FSM job, or whether it annotates the FSM job directly.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 Treehouse project object — a richer record than the FSM job, carrying scoping data, photos, BOM, and proposal state that the FSM does not model.Hypothesis

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

The FSM job record — Treehouse reads from and writes to it but does not own it. The contractor's FSM remains the system of record for scheduling and dispatch.Hypothesis

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

The canonical job record, customer history, technician assignment, scheduling, dispatch, invoice, and payment. Treehouse adds to the FSM record; it does not replace it.Hypothesis

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

Treehouse can pre-classify job type with higher specificity than generic FSM job types — distinguishing 'panel upgrade 100A to 200A' from 'EV charger install on existing 200A service' from 'whole-home rewire' in ways that drive different scoping paths.Hypothesis

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

Customer record deduplication, address validation, job-type taxonomy.Hypothesis

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

Homeowner identity, contact info, address, job type, lead source, and any qualifying data collected at intake. This is the spine of the Treehouse project object.Hypothesis

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

A pre-populated Treehouse project brief when they open the job — not a blank form.Hypothesis

Happens automaticallyWorkflow events that fire without a contractor action.

FSM writeback of any data captured at intake. Address geocoding and validation. Returning-customer detection.Hypothesis

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

Deduplication decisions where the system is uncertain. Job-type classification where the homeowner's description is ambiguous.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 job record in their system with enough information to estimate, schedule, and dispatch. Homeowner needs to not repeat themselves.Hypothesis

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

New customer: manually enter contact info, address, job type. Returning customer: look up existing record and create a new job linked to it. In FSMs, this is a core workflow that most contractors do dozens of times per week.Hypothesis

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

From lead intake (if captured): name, phone, email, address, job type, urgency, any technical notes. From the contractor: internal job notes, service type classification, assigned technician, target completion date.Hypothesis

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

FSMs auto-populate returning customer records from history. Some tools (Broccoli) write a new job record when the AI completes a booking, pre-populating the FSM from the call transcript. Most creation is still manual.Hypothesis

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

Verify the new record is complete. Assign service type and technician. Confirm the address. Add any internal notes not captured during lead intake.Hypothesis

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

Deduplication — is this a returning customer? Is this the same job as a previous visit? What service type maps to this job description?Hypothesis

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

A job record in the FSM with customer, address, job type, and assigned technician.Hypothesis

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

Writes: new job record, customer record if new. Reads: existing customer history, address records. This is core FSM behavior — Treehouse reads from it, does not own it.Hypothesis

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

FSMs handle this well — HCP, ServiceTitan, and Jobber all support rapid job creation. The step is largely solved for contractors who have an FSM.Hypothesis

Product weaknessesWhere current products fall short or create new problems.

Contractors without an FSM create jobs in spreadsheets, notes apps, or memory. For them, this step is where disorganization begins.Hypothesis

Treehouse implicationWhat this step means for Treehouse's product positioning and architecture.

Treehouse should inherit the job record from the lead-intake step — the homeowner should never repeat themselves. The question is whether Treehouse creates its own job object (a Treehouse project) that lives alongside the FSM job, or whether it annotates the FSM job directly.Hypothesis

Open questions

  • 01What percentage of Treehouse's contractors have an FSM with API access?
  • 02What information does the FSM job record need that Treehouse's scoping step adds later?
  • 03Should Treehouse maintain its own project object, or annotate the FSM job record directly?
  • 04How does Treehouse behave for a contractor with no FSM?