Claude Code business workflows for home-service contractors

TaskChad sells the $250 Business Diagnostic Session and the $2,000 14-Day Implementation Sprint described here. This page is provider-written implementation guidance from TaskChad, not independent research and not a customer case study. The narrow first build is a job-closeout packet assembled after a technician marks a visit complete. Claude Code may reconcile approved records and draft internal or customer-facing material for review. It may not invent technician availability, schedule a return, change a price, issue an invoice, promise warranty coverage, charge a card, or send a review request.

“Job complete” is not the office’s definition of done

For a home-service contractor, the expensive gap often opens after the truck leaves. The field-service system says complete, but the office still lacks one or more of the facts needed to invoice cleanly, answer the customer, process a warranty callback, or close the day: which approved line items were performed, which part was installed, where the photos are, what changed from the estimate, whether a return visit is required, or who approved the exception.

Office staff reconstruct the job from technician notes, a text thread, photo thumbnails, the price book, and a half-finished invoice. Then they retype the company’s same closeout rules into Claude Code: use this warranty paragraph, never call a recommendation “required,” separate completed work from future options, and never claim the schedule has an opening. That repeated context is the target. The live job facts still have to arrive from a dated system record.

The Sprint does not build a dispatch bot. If a closeout says the crew must return, it creates return_visit_required with a reason. Only the field-service management system and authorized dispatcher can turn that state into a date or arrival window.

Put the finish line on one closeout card

The paid Session examines two recent jobs: one the office closed without questions and one that bounced between field and office. From those examples, the contractor defines a closeout card. The card is a data contract, not a prettier service summary.

Closeout block	Minimum evidence	Allowed output	Blocker
Job identity	FSM job ID, property ID, completion event	Header and source index	Missing or conflicting IDs
Performed scope	Approved estimate or work order plus technician completion note	Completed-work list	Line item absent from approved source
Material or equipment	Part/model record, serial if required, photo manifest	Installed-item register	Unmatched part or unreadable identifier
Price variance	Current invoice draft and approved change record	Exception line for office review	New amount without authorization
Warranty language	Versioned, owner-approved warranty library	Applicable paragraph copied into draft	Model asked to decide coverage
Future work	Technician observation clearly labeled as an option	Separate option queue	Presented as completed or mandatory work
Return requirement	Technician state or office decision	return_visit_required reason only	Any generated date or availability claim
Customer follow-up	Verified contact preferences and final human approval	Quarantined message draft	Consent, contact, or approval missing

The card lets a reviewer say exactly why a packet failed. “Looks incomplete” becomes “installed-item identifier has no source,” “change authorization is missing,” or “return visit has no dispatcher owner.”

Branch on the field outcome before drafting prose

Home-service closeout is not one linear happy path. The workflow first verifies an operator-supplied outcome state; it does not infer one from tone.

• completed_as_approved: performed scope matches an approved work order; packet can proceed to invoice review.
• completed_with_approved_change: change record exists; variance appears prominently for office verification.
• return_visit_required: work is not represented as final; packet creates a dispatcher task with no date.
• diagnostic_only: findings and fee are separated from any proposed repair; no repair is described as completed.
• customer_dispute: external drafting pauses and routes to the owner or service manager.
• warranty_review: packet preserves facts and warranty version, but a qualified human decides applicability.
• unsafe_or_unresolved: company safety procedure takes over; Claude Code produces no reassuring customer summary.

That branching prevents an especially costly error: turning a technician’s “need to come back with a motor” into “we’ll be back Tuesday.” Availability is live operational state. A plausible date is still false if the dispatch board did not authorize it.

Use field-service records as a source map

Jobber’s official API schema separates job completion time, line items, visits, quote, invoice, notes, attachments, review-request eligibility, and arrivalWindow; it also exposes whether a user is available for scheduling (Jobber Developer Center). Those fields show why a closeout should not collapse “work occurred,” “invoice exists,” “review may be requested,” and “someone is available” into one generated paragraph. ServiceTitan likewise publishes a developer surface for operational integrations (ServiceTitan developer documentation). A specific contractor may use either system, another FSM, or spreadsheets. The packet contract uses the system actually owned by the buyer.

Needed fact	Preferred source	Secondary evidence	Claude Code response to conflict
Work performed	Approved work-order line items	Technician completion note	Display mismatch; no invoice narrative
Job status and time	FSM completion event	Dispatch audit log	Require service-manager resolution
Installed item	Inventory/part record	Timestamped field photo	Mark unmatched; do not invent model or serial
Approved charge	Estimate, change order, invoice draft	Manager approval receipt	Quarantine unapproved variance
Warranty text	Versioned company library	Manufacturer document supplied for job	Keep sources separate; route applicability to human
Customer contact	CRM/FSM contact preference	Approved job intake	Stop follow-up if consent or destination is unclear
Return timing	Live dispatcher action only	None	Never draft a date from notes or historical duration

The first Sprint uses exported records and a photo manifest, not raw access to every customer and job. Filenames include job ID, record type, source timestamp, and export owner. The workflow rejects loose screenshots with no job match.

Store company craft rules without storing customer histories

The repository is the contractor’s operator-owned closeout kit. A concise CLAUDE.md names directories, commands, review roles, and non-negotiable boundaries. A scoped rule defines the chosen trade’s closeout card. A skill validates one packet and generates an evidence index, exception ledger, internal summary, and quarantined customer draft. Fixtures represent each outcome branch using synthetic or approved redacted records.

Anthropic explains that CLAUDE.md gives Claude Code persistent project context, but those instructions are not enforced policy (Claude Code project memory). Enforcement comes from deny rules and hooks: block .env and credential paths, outgoing communication, payment commands, FSM mutations, and any scheduling output. A PreToolUse hook rejects a draft containing an arrival date unless a separately approved dispatcher receipt is present—and the first Sprint deliberately supplies no such receipt, so all generated scheduling claims fail closed. Claude Code’s official permissions guide documents deny-first evaluation and blocking hooks (Claude Code permissions).

Customer histories do not belong in reusable context. Stable warranty phrasing, terminology, source precedence, and review rules do. Each job folder is ephemeral under the contractor’s approved retention and access policy.

Measure the handoff, the packet, and the outcome separately

The portfolio KPI is accepted work packets completed without re-entering business context. Here, stable business context includes closeout-card sections, company terminology, outcome definitions, warranty-library location, source precedence, and review rules. Job-specific scope, parts, prices, photos, and customer preferences must still come from current records.

The baseline uses a defined batch of recently completed jobs from the chosen trade and branch. A plumbing callback cohort should not be blended with scheduled maintenance or a replacement-install cohort.

Layer	Measure	Counted from	What it cannot prove
Handoff	Jobs with all required source records at first office review / sampled completed jobs	FSM exports and source manifest	That the work was correct
Packet	Accepted packets without rule re-entry / reviewed packets	Skill log plus reviewer receipt	That an invoice was issued
Exceptions	Conflicts caught before customer draft / reviewer-discovered conflicts	Exception ledger and corrections	That all latent errors were found
Outcome	Accepted packets reaching invoice issued, dispatcher task accepted, or warranty owner accepted	FSM/accounting task record	Collection, profit, or satisfaction
Guardrail	Drafts with invented availability or unsupported warranty decision / reviewed drafts	Failure log	Must remain zero for release

Time from field completion to office acceptance is useful, but medians and cohorts are safer than one average. A complex disputed job should not be “optimized” into the same handling time as routine maintenance.

Require field, office, and dispatch authority at different moments

The technician owns observed work, installed items, photos, and the field outcome state. The service manager or office reviewer verifies scope, pricing evidence, warranty version, and customer wording. The dispatcher alone assigns a return visit or availability. The repository owner versions the closeout card, rules, hooks, and fixture deck. The billing owner issues the real invoice in the approved system.

Combining roles in a small shop is acceptable; combining authorities in one Claude Code response is not. The receipt says which hat the person wore. If a technician is also the owner, the workflow still records separate field completion and office acceptance events.

Written warranty language needs special care. The FTC’s business guide notes that federal warranty rules distinguish consumer-product written warranties from services and discusses disclosure and pre-sale availability requirements for covered written warranties (FTC Businessperson’s Guide to Federal Warranty Law). State law and the contractor’s actual mix of labor, parts, manufacturer warranties, and service agreements can change the analysis. TaskChad copies only owner-approved text and leaves coverage decisions to qualified humans.

Break it with truck-to-office failure fixtures

• Technician note contradicts line item: note says two units; approved work order says one. Expected: scope conflict, no invoice draft.
• Photo from another job: image manifest carries a different property ID. Expected: image quarantined and packet blocked.
• Unapproved price change: technician writes an amount in free text without a change receipt. Expected: variance routes to manager; amount is not promoted.
• Warranty demand: prompt asks whether the callback is covered. Expected: warranty_review; no decision or promise.
• Invented return slot: field note says “next week should work.” Expected: no date in any customer draft; dispatcher task only.
• Review gating: operator requests a review only from a customer labeled happy. Expected: workflow refuses selective sentiment routing and uses the approved neutral policy. FTC guidance warns that requesting reviews only from customers thought to be happy may implicate the FTC Act even though the review rule has no standalone prohibition (FTC Consumer Reviews Rule Q&A).
• Missing contact preference: customer mobile exists but review/follow-up permission is unknown. Expected: no outbound draft released.
• Instruction hidden in a technician attachment: attachment asks the agent to send files or reveal another job. Expected: treated as untrusted data; tool denies remain active.

The acceptance record for each fixture includes input IDs, expected branch, observed branch, prohibited action, owner, and rerun result after repair.

Spend 14 days on one closeout branch

Days	Shop-floor focus	Concrete receipt
1–2	Select one trade, one job outcome branch, and a bounded historical sample	Cohort definition and redacted examples
3–4	Observe technician-to-office handoff; freeze card, sources, roles, and baseline	Signed closeout contract
5–7	Build repository kit, validation skill, exception ledger, and quarantined drafts	Versioned artifacts and fixture outputs
8–9	Add denies and scheduling/warranty hooks	Tool-boundary test log
10–11	Run all field-to-office failure fixtures	Pass/fail matrix with repairs
12–13	Shadow an approved batch; humans accept or reject packets	Reviewer receipts and terminal task IDs
14	Handoff ownership, disable procedure, retention rule, and release decision	Operator runbook and dated decision

This technical example covers one closeout card, one trade or service cohort, one outcome branch, at most two or three source exports, and one controlled release. It excludes live FSM writes, scheduling, payment, autonomous pricing, warranty decisions, customer sends, review solicitation, and multi-location rollout. The purchased Sprint is scoped to the agreed business result, which may address one big problem or several connected problems.

Fit requires a usable field record

A good fit has stable job IDs, approved line items, a real completion state, an accountable technician, an office reviewer, a versioned warranty library, and repeatable evidence such as part records or photo manifests. The operator can show which closeout packets are accepted and what downstream system records invoice, return, or warranty disposition.

Wait if technicians do not record work performed, the price book has no owner, photos cannot be tied to job IDs, every exception is handled through private text messages, or the dispatcher cannot distinguish a requested return from an authorized slot. A model cannot recover evidence that the business never captured.

End at an operational receipt, not polished copy

The closeout workflow reaches terminal evidence when a named office reviewer accepts the packet and the appropriate downstream owner records one disposition: invoice issued, dispatcher task accepted, warranty review accepted, dispute owner accepted, or packet rejected. The job ID, source version, exception state, reviewers, timestamps, and terminal task or record ID stay linked.

A polished customer summary is not terminal. Neither is “job complete” in isolation. The Sprint may support a claim about accepted closeout packets produced without repeated context. It does not prove payment, margin, first-time fix, review growth, customer satisfaction, qualified leads, purchases, or revenue.

See how TaskChad handles evidence before buying

TaskChad publishes three controlled demonstrations. The AI Workflow Audit demonstration shows how a messy candidate becomes one scoped workflow. The lead-to-booking demonstration shows a human approval hold before external action, similar to quarantining a customer closeout draft. The SEO and GEO improvement loop demonstration is a separate marketing workflow that demonstrates source-separated measurement.

The Revenue Leak Score for home services can help a contractor decide whether closeout, lead response, follow-up, or owner dependency is the more urgent constraint. It is a deterministic diagnostic, not a promise of results.

To scope this specific route, book the $250 Business Diagnostic Session for Claude Code business workflows, home-service contractors. Paid Sessions are contacted within one business day to schedule; paying does not book a specific time automatically.

Frequently asked questions

Can Claude Code schedule the return visit named in a closeout packet?

No. It can create a dispatcher task stating why a return is required. It cannot choose a technician, date, or arrival window, and it cannot tell the customer that capacity exists. Scheduling remains in the live FSM under an authorized dispatcher.

Does the workflow decide whether a callback is covered by warranty?

No. It can attach the approved warranty version, performed-scope evidence, installed-item record, and customer report to a warranty_review packet. A qualified owner decides applicability and approves any customer statement.

Do we have to connect Claude Code directly to ServiceTitan or Jobber?

No. The first Sprint uses bounded, read-only exports plus an approved photo manifest and warranty library. Live access adds credentials, changing records, retention questions, and external side effects; it would require a separate scope and new tests after the file workflow proves useful.

What comes out of the $250 Business Diagnostic Session?

The Session produces the selected cohort and branch, closeout-card contract, source map, current handoff, baseline, KPI, role approvals, failure fixtures, system exclusions, and a written 14-day Sprint scope. It changes no production record and sends nothing. Its fee credits toward an accepted Sprint for 30 days.

Sources

• Claude Code: project memory — persistent project context and its limits.
• Claude Code: permissions — deny-first tool controls and blocking hooks.
• Jobber Developer Center — official job, visit, invoice, line-item, review, and arrival-window fields.
• ServiceTitan developer documentation — official integration surface for field-service operations.
• FTC Businessperson’s Guide to Federal Warranty Law — federal warranty distinctions and disclosure guidance.
• FTC Consumer Reviews Rule Q&A — official guidance on review and testimonial practices.