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.
Contractor needs a job record in their system with enough information to estimate, schedule, and dispatch. Homeowner needs to not repeat themselves.Hypothesis
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.
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
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
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
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
Customer record deduplication, address validation, job-type taxonomy.Hypothesis
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
A pre-populated Treehouse project brief when they open the job — not a blank form.Hypothesis
FSM writeback of any data captured at intake. Address geocoding and validation. Returning-customer detection.Hypothesis
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
Contractor needs a job record in their system with enough information to estimate, schedule, and dispatch. Homeowner needs to not repeat themselves.Hypothesis
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
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
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
Verify the new record is complete. Assign service type and technician. Confirm the address. Add any internal notes not captured during lead intake.Hypothesis
Deduplication — is this a returning customer? Is this the same job as a previous visit? What service type maps to this job description?Hypothesis
A job record in the FSM with customer, address, job type, and assigned technician.Hypothesis
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
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
Contractors without an FSM create jobs in spreadsheets, notes apps, or memory. For them, this step is where disorganization begins.Hypothesis
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?