How Does Scaftra Handle Service and Warranty Work?

How do you handle a callback after the job closes and recover the cost when it was a sub's fault?

Scaftra opens a service request against a closed-out project, snapshots the warranty window at intake, tracks repeat visits, and can fan out a backcharge when the defect was someone else's fault.

The problem it solves

When a finish-trade job closes out, the contractor's obligation shifts into the warranty period. The homeowner calls back: a cabinet door has dropped, a countertop seam is lifting. The GC needs a first-class place to log the issue, decide whether it is actually covered under warranty versus owner damage versus a goodwill fix, dispatch someone, track repeat visits, and recover the cost via a backcharge when a sub's defect caused it.

Why it matters

A callback handled by text and memory loses the warranty decision, the visit history, and the chance to recover the cost. Whether an issue is covered is a human judgment about cause, not a date calculation, and it has to be recorded. Repeat visits to the same problem are a dispute signal worth tracking. A deliberate post-completion loop is what turns a callback into a tracked, recoverable record.

Common mistakes

How it works

1. Open the service request

   A staff member or the client opens a request against a post-completion project; the warranty window is snapshotted at intake.
2. Decide coverage

   Staff set an explicit warranty decision, warranty, non-warranty, or goodwill, separate from the date window.
3. Dispatch and track visits

   Service visits accumulate against the request, so one issue carries its full visit trail.
4. Recover the cost

   When a sub caused a covered defect, a backcharge fans out inheriting the request's context.

How Scaftra does it

Scaftra runs a reactive service and warranty loop end to end. A Service Request can only be opened against a post-completion project with a real warranty window configured, and it snapshots that window at intake so the historical truth of what was seen that day is frozen. Coverage is an explicit, staff-controlled warranty decision (warranty, non-warranty, or goodwill) that can intentionally diverge from the derived in-window flag, because coverage is a judgment about cause. Service visits accumulate as a visit trail. When a covered defect was a sub's or supplier's fault, a backcharge fans out inheriting the request's project, room, and trade context. A retrieval-only board surfaces history and detects repeat callbacks. There is no preventive-maintenance scheduling; service is triggered by reported issues. This is built and live.

Key capabilities

• Warranty snapshot at intake: The warranty window is frozen the day the issue is reported, so coverage rests on what was true then.
• Explicit coverage decision: Staff set warranty, non-warranty, or goodwill as a judgment about cause, separate from the date window.
• Visit trail: Multiple service visits accumulate against one request, so the full history of an issue is recorded.
• Backcharge fan-out: A covered defect caused by a sub can fan out a backcharge that inherits the request's context.

Benefits

• Callbacks become tracked records with a recorded coverage decision and visit history.
• A sub's defect can be recovered via a backcharge instead of absorbed.
• Repeat callbacks to the same problem surface as a dispute signal.

Who it's for

• GC owners in the warranty period.Contractors fielding callbacks after closeout who need coverage decisions and cost recovery recorded.
• Service coordinators.Staff dispatching visits and tracking repeat issues per request.

Related on Scaftra

Go deeper