Flow 11·Company claim·airship, broccoli, cactus, leadtruffle, housecallpro, servicetitan

FSM handoff / system of record

What gets written back to the FSM, what stays in Treehouse, and where the system of record for each data type lives. This is the boundary question for every Treehouse integration.

Install readyFSM execution

User goal

Contractor needs one system of record — not two places to look for the same information. The FSM should have everything the tech needs to do the job. Treehouse should have everything needed to manage the project and produce the permit package.Hypothesis

Treehouse implication

Treehouse's boundary must be explicit: Treehouse owns the project record (Panel IQ data, Edison scope, BOM, proposal, permit package). The FSM owns the job record (scheduling, dispatch, invoicing, payment). The handoff at proposal acceptance must write the right summary to the FSM without requiring double-entry. What gets written back is the key design question.Treehouse internal

How competitors approach this

2 companies mapped. Click a company's "View flow" link to see their captured screens.

Company	What they do	What they automate	Contractor control	FSM relationship	Key strength	Key weakness	Treehouse implication
Airship View flow →	Proposal layer that reads from ServiceTitan and writes accepted proposals back. 'No double entry' — the proposal acceptance automatically updates the FSM job record with option selection, equipment, and pricing.Company claimSource	Proposal writeback on acceptance. Equipment and pricing update on the FSM job record. No manual re-entry.Company claimSource	Owner configures what data writes back. Tech presentation triggers the writeback on acceptance.Company claimSource	ServiceTitan: read+write, workflow-native. 'Plays Well in the Sandbox.' Non-disruptive by design.Company claimSource	The FSM remains the system of record. Airship adds a sales layer without changing how the contractor operates their business.Company claimSource	Product interior gated — the writeback behavior is a company claim, not observed. Whether the FSM job record receives the full scope or just the accepted option price is unresearched.Hypothesis	Airship's writeback model is the template. What Treehouse writes back should be at minimum what Airship writes back — plus the permit-package attachment and the Edison scope summary.Hypothesis
Broccoli View flow →	Writes new jobs and appointments to ServiceTitan dispatch board after a successful qualification conversation. Reads customer records and ACP (automated capacity planning) for availability.Company claimSource	Job creation in ServiceTitan on booking. On-call escalation via call and SMS.Company claimSource	Owner configures what data writes to ServiceTitan. AI generates the job record from the conversation transcript.Company claimSource	ServiceTitan: read+write, dispatch depth. Reads ACP and customer records. Writes new jobs.Company claimSource	Deep ServiceTitan integration at dispatch depth.Company claimSource	Only writes new leads and appointments — no scope, no technical data, no proposal writeback. The FSM job created by Broccoli is a booking placeholder, not a scoped project.Hypothesis	Broccoli creates the FSM job. Treehouse needs to annotate it — attaching the scope, the panel data, and the permit package to the job Broccoli created. That requires Treehouse to read the job Broccoli wrote.Hypothesis

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 record: Panel IQ panel data, Edison scope, BOM, proposal, permit package. These live in Treehouse's data model, not in the FSM.Treehouse internal

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

The FSM writeback on acceptance — what summary, option selection, and attachments get written to the FSM job record. The tech-facing work order summary that the FSM surfaces to the dispatcher and technician.Hypothesis

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

Scheduling, dispatch, invoicing, payment, customer history, job lifecycle status. The FSM is the system of record for everything that happens after Treehouse's proposal is accepted.Hypothesis

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

A permit-ready package (panel schedule, single-line diagram, load calculation) that attaches to the FSM job and eliminates manual permit-prep. No other proposal-layer tool produces this.Treehouse internal

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

FSM API integration. Document attachment. Calendar read for scheduling.Hypothesis

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

The Treehouse project ID that links the FSM job to the Treehouse project record. This linkage must be maintained throughout the job lifecycle so the permit package and scope are always accessible from the FSM job view.Hypothesis

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

In their FSM: a job record with scope summary, accepted option, equipment, and a Treehouse link. In Treehouse: the full project record with all technical detail.Hypothesis

Happens automaticallyWorkflow events that fire without a contractor action.

FSM job creation or update on booking. FSM writeback on proposal acceptance. Permit package attachment to the FSM job.Hypothesis

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

FSM object model mismatches. Jobs where the contractor needs to modify the scope after site visit. Permit application submission (requires licensed-contractor credentials).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 workflowHow contractors handle this step today, with or without software.

After proposal acceptance: job is scheduled in the FSM, tech is dispatched, materials are ordered. Scope of work, permit package, and equipment specs flow from Treehouse to the job. Invoice is generated in the FSM at job completion.Hypothesis

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

Airship: accepted proposal, option selection, equipment, pricing. Broccoli: new job/appointment. Cactus: new booking. All read from the FSM's customer record and write back a job or proposal.Company claimSource

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

Airship: 'proposals write back automatically, no double entry.' Broccoli: writes new job to ServiceTitan dispatch board. Cactus: writes booking to HCP or Jobber. All claim bidirectional integration — reading to populate the proposal and writing back on acceptance.Company claimSource

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

Verify the writeback is complete. Confirm the job record in the FSM has the right scope summary, equipment, and pricing. Assign the tech and schedule the job.Hypothesis

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

FSM object model mismatch — when the accepted scope doesn't map cleanly to FSM job types or line items. Material ordering decisions based on lead time. Tech assignment based on skill and availability.Hypothesis

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

A complete FSM job record with scope summary, equipment selection, pricing, and customer info. A permit package (Treehouse-native) ready for AHJ submission. A work order with the tech's task list.Hypothesis

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

Reads: customer record, calendar, price book. Writes: job/appointment, accepted option, equipment selection, pricing, scope summary. In all cases the FSM remains the system of record for scheduling, dispatch, and invoicing.Company claimSource

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

'Plays Well in the Sandbox' (Airship) — no rip and replace. 'One system of record' maintained in the FSM while Treehouse adds sales/scoping/design value. Bidirectional integration reduces re-entry.Company claimSource

Product weaknessesWhere current products fall short or create new problems.

FSM API depth varies — ServiceTitan's API is well-documented; Housecall Pro's is less so; smaller FSMs may have no API. The FSM object model may not have fields for permit application status, AHJ requirements, or panel-schedule attachments.Hypothesis

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

Open questions

01What Treehouse data currently writes back to the FSM on proposal acceptance?
02What FSM APIs does Treehouse currently support — ServiceTitan, HCP, Jobber, others?
03What fields in the FSM job record matter most for the tech doing the job — does the tech need the load calculation, or just the equipment list?
04How does Treehouse handle contractors with no FSM — does Treehouse own the scheduling and dispatch surface for them?
05What is the read/write depth of the ServiceTitan integration — is it workflow-native or data-import/export?