Skip to content
Guarantee Restoration Services EstimateIQ Docs

Deal detail page

The deal detail page (/estimates/:id) is where an estimator does the work of moving one file through the loop. It renders server-side from live Durable Object data and re-hydrates in place after every action — no full-page reloads. Any :id resolves on demand, so an estimate created a minute ago is viewable immediately.

Header & primary actions

The header shows the estimate / claim / job numbers, the insured, loss type, phase, location, and estimator, plus status, ball, and aging pills and the round count. Three action buttons appear, each enabled only when it’s valid for the current ball:

ButtonWhen enabledEffect
Submit to carrierball = us (draft / revision_requested / responded)POST /api/estimates/:id/submit — records an outbound leg, ball → carrier, starts the desk-audit clock.
Log auditor revisionball = carrierOpens a modal for the auditor’s note → POST /api/estimates/:id/revision.
Mark settlednot already donePOST /api/estimates/:id/approve — ball → done.

Log auditor revision (modal)

When a carrier returns the estimate, click Log auditor revision and paste the desk-audit note. On submit, EstimateIQ:

  1. Parses the note with AI into reason codes + disputed items + a summary.
  2. Records an inbound revision leg on the swimlane and marks the prior outbound leg answered.
  3. Flags any disputed line items as challenged by code.
  4. Runs the per-carrier rules engine against the parsed result.
  5. Sets the estimate to revision_requested (ball → us), computes the response due date, and creates a respond follow-up (plus any rule-generated follow-ups).

Stats row

Cards show current RCV / ACV, approved RCV (settled or pending), rounds (count of revision legs), submitted / opened dates, and challenged / total line items (highlighted when any are challenged).

Revision thread — ball-in-court swimlane

The centerpiece. A two-lane timeline — GRS (estimator) on one side, {carrier} (auditor) on the other — plots every leg in order: outbound submissions on our side, inbound returns on theirs. Each bubble shows the round number, direction, timestamp, the note, the delta (green up / red down), reason-code chips, any disputed items (code · description · issue), and the turnaround hours held before that leg. Before the first submission it reads: “No submissions yet — draft is still in our court.”

Line items

A table of the Xactimate scope — code, description, round introduced, state chip (accepted / challenged / added), and RCV. + Add line item opens a modal (code required, description, RCV, round, status) that POSTs to /api/estimates/:id/line-items.

Follow-up & follow-through

The follow-ups pinned to this estimate — title, kind chip, owner, due date, and status pill (overdue / pending / done). Each open row has a Done button (POST /api/followups/:id/complete). + Add follow-up opens a modal (title, kind, owner, due date, note) → POST /api/estimates/:id/followups.

Next-best-action (AI brief)

A short, plain-language recommendation of what to do next to move the ball. The page shows the persisted brief (stored in R2), so it doesn’t change on every view. Refresh from model recomputes it — POST /api/ai-brief/:id runs the model and saves the result. A source hint shows the inputs (ball, SLA days, audit days). If no model is available, a deterministic brief is generated from the ball and aging. See AI.

Correspondence

The email thread attached to this estimate (GET /api/estimates/:id/emails), newest first — subject, from/to with a direction arrow, received time, a body preview, and a source badge (e.g. XactAnalysis for portal automation).

Identity & activity log

A read-only identity card (claim #, job #, carrier, O&P cap, loss / phase, location) and the per-estimate activity log — every event (opened, submitted, revision, rule fired, follow-up completed, approved) with actor and timestamp.