A job's process and timeline

What the job's process view is

Every job runs a process, from the day it is assigned to the day it is paid. The process view on a job answers three questions about that one claim: how long each stage actually took, how that timing compares to operators like you, and whether the work followed the standard for its category. It is process mining pointed at a single job, and it renders at the bottom of the Job File tab on the job profile, after the stitched timeline, The Story So Far, and (where one exists) the drying reconciliation. If you have not read the job profile yet, start there, the process view assumes you know how the profile is laid out.

Verinode assembles all of this from data you already have, the lifecycle dates on the job, its supplements, its payments, and its documents. There is no separate process to set up per job. As the claim moves and the paperwork flows in, the timeline maps itself. Verinode reads it and, where it can, sets it against the network. It never runs the job for you.

How the timeline is mapped

The job's timeline is pure assembly, not guesswork. Verinode takes the facts on the claim and stitches them into one chronological rail, oldest first:

• The lifecycle milestones, from the dates on the job. The five-stage spine Assigned → Started → Completed → Billed → Paid is still the common backbone, and the lifecycle now runs up to twelve stages: Loss, Received, Contacted, On site, Authorized, Assigned, Estimate submitted, Carrier approved, Started, Completed, Billed, Paid. The intake and estimating stages are optional, they draw when their dates are on file and are bridged when absent, so a job carrying only the five core dates still reads as a clean spine rather than a rail of gaps.
• Each supplement's sub-cycle, submitted to responded, folded in where it belongs in time. Where the carrier pushed back, the response carries the fuller record: the denial reason, the dollars cut of what was submitted, the adjuster, the documentation demanded, and the contested lines.
• Payment events stamped to the job.
• The document trail, estimates, invoices, and reports, as they were dated.

Between each consecutive stage, Verinode shows the elapsed time, for example "12d from Assigned" or "Same day as Assigned." That elapsed number is the raw material of everything below: it is how long that step of the process actually took on this claim.

Cycle time versus peers

A duration on its own does not tell you much. Fourteen days from billed to paid is fast for one carrier and slow for another. So beside each canonical stage transition, where your cohort has the data, Verinode shows the peers' timing:

Peers 6d (3–9d) · operators like you in CA · Observed

That is the peer median with the middle range (the 25th to 75th percentile) beside it, and a confidence label, Indicative, Observed, or Verified, telling you how deep the peer set behind the number is. It is the same ladder used on every benchmark surface, and it stands in for a raw operator count on purpose: the count is one of the things Verinode holds back so that no one can work out what any single operator contributed. Under it sits your delta, for example "+4d vs Peers" in red when you ran slower, or a green figure when you beat them. Read down the rail and the slow step is obvious: it is the transition where your delta is red and large. That is where the job lost time.

The peer comparison only attaches to a consecutive stage pair. If a job skips a stage, say it jumps from Assigned straight to Billed with no Started date, Verinode does not compare that span to peers, because your elapsed time would cover two peer stages and the comparison would be apples to oranges.

When peers are still forming. Peer timing only publishes once enough operators contribute the same lifecycle data that no single operator can be identified behind a number. Until then, a line reads "Peer comparison appears as the network grows. Peer timing shows beside each stage as more operators contribute the same lifecycle data, and it is not about anything missing from your data." Your own timeline is fully drawn either way, the comparison is what fills in.

The standard for the job's category

Timing is one half of process. The other is method. The process view shows the reference standard for the job's category and, if you have documented your own procedure, how it stacks up.

Verinode maps each category to its restoration standard, for example IICRC S500 for water, IICRC S700 for fire, IICRC S520 for mold, and the LEAN reference for reconstruction, contents, storm, and general work. The section header names the framework in play.

If you have a documented SOP for the category, the view leads with its title and a three-number lockup:

• LEAN score, your SOP's process score out of 100.
• Step count, your SOP's steps, shown against the reference step count where one exists ("14 vs 11").
• Est. minutes, your SOP's estimated active-work minutes, against the reference.

Below that, plain-language recommendations call out real gaps, for example when your process scores well below the standard, sits below the peer median, or runs materially longer than the reference.

If you have no documented process for the category yet, the view reads "No documented process for {category}. The {framework} reference standard is available in /processes By Standard." A View {framework} in /processes link takes you to the standard so you can build from it.

This job against your process

Above the standard, the Job File shows the process linked to this job step by step, with what this job's own records say about each one. Nothing here asks you to remember anything: every line is read off a record you already have.

Each step lands in one of three places.

• In the records. A record on this job accounts for the step, and the line names the record and the date it carries, for example "Backed by your drying log for this job (3 readings), Mar 13, 2026."
• Open question. Verinode can see this kind of record on your other jobs and finds none on this one. The line asks rather than concludes: "Nothing in the post-repair verification on this job accounts for this step. Was it done and filed somewhere else, or not done?" A missing record is not the same as work that was not done, and the section never says it is.
• Unknown. Nothing in your book can answer the step either way, usually because the record it would read has not started flowing in yet. The line names the artifact that makes it answerable, for example a daily drying log from your field documentation app. An unknown step is never counted against you.

The summary line above the list says how many of the steps this job's records account for, out of how many the process holds. It is a statement about your paperwork, not a grade on your crew.

If the wrong process is linked, use This isn't the right process to point the job at the right one. That is the only thing this section asks you for, and it is a correction, not a report: which process governs a job is a fact only you hold, while whether the job followed it is something your own records answer.

If you have no process for this kind of work, the section says so with your own numbers: how many jobs of that kind you have completed, what it would buy you, and how to close it, either by writing a process in Processes or uploading the SOP document you already have. Once enough of those jobs are complete, IQ offers to propose a starting sequence drawn from what those jobs already record, for you to confirm.

If your team wrote notes on a job back when this section asked them to describe what was different, those notes are still there, under Reported by your team. They are kept and read-only; nothing new lands there.

How this relates to Process insights

The process view is one job. Process insights is every job. The same milestone mapping and stage-timing that Verinode draws for a single claim rolls up across all your work into your process picture: which stages consistently run long, where your cycle time drifts from the standard, and how your SOPs score against peers. A slow billed-to-paid transition you notice on one job is a data point; when it repeats across the book, it becomes a pattern worth fixing. See Process insights for the network and portfolio view.

Empty states

• Before lifecycle dates and documents flow in, the timeline reads "As lifecycle dates, supplements, payments, and paperwork flow in from your inbox and tools, this job's full story maps itself here."
• Before you have documented a procedure for the category, the process section names the gap in your own numbers and points you at writing one, and the standard section points you to the reference in /processes rather than showing a blank.
• When peers are unlocked but the cohort has not yet reached the anonymity floor, the peer line explains that the comparison appears as the network grows.

Data sources