A job's process and timeline

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 timi…

6 min read·Updated July 11, 2026
On this page

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 directly under The Journey on the job profile. 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 five lifecycle milestones, Assigned → Started → Completed → Billed → Paid, from the dates on the job.
  • Each supplement's sub-cycle, submitted to responded, folded in where it belongs in time.
  • 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.

Note

The timeline only draws a duration when the dates are in order. If an imported claim carries a billed date earlier than its started date, Verinode shows the stages but leaves that gap blank rather than printing a negative or misleading number. Correcting the dates in Claim Details on the profile fixes it.

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) · 12 operators like you in CA

That is the peer median with the middle range (the 25th to 75th percentile) beside it, and how many operators stand behind the number. 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.

Tip

The header of the profile also carries a phase-appropriate SLA tile, the Onsite SLA before work starts and the Cycle SLA once it is underway, reading "Day 6 / 14d," "Met," or "Missed." The SLA tile is the one-glance verdict; the timeline is where you see which stage drove it.

When peers are still forming. Peer timing rests on a floor of five or more operators contributing the same lifecycle data, so no single operator can be identified behind a number. Until a cohort reaches that floor, a line reads "Peer comparison appears as the network grows. Peer timing shows beside each stage once five or more operators contribute the same lifecycle 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: did the job follow the right procedure? 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 S770 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 SOP scores well below the standard, sits below the peer median, or runs materially longer than the reference. Then the SOP steps list the procedure itself, the first twelve steps flat and numbered, each with its required flag, estimated minutes, and role where set, and a "+N more steps in the full SOP" note when there are more.

If you have no SOP for the category yet, the view reads "No documented SOP 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.

Did this job follow the SOP?

The last part of the process view is a capture form: "Did this job follow the SOP?" If anything on this job was different, steps skipped, added, or done in a new order, you record it here in a sentence or two. The button reads Didn't follow the SOP when you have a documented procedure, or Capture what we did when you do not.

When you submit, Verinode writes the variance against the job and the Processes agent assesses whether it was a one-off or a real signal that the SOP is out of date. If it is worth acting on, you will see "Captured. Decision card now in Findings," and the call flows into your decisions to plan and act on. This is how a job that went off-script quietly teaches your process to get better, rather than the lesson being lost the moment the job closes.

Note

Nothing here rewrites your SOP on its own. Capturing a variance opens a question for the Processes agent to weigh; you decide whether it becomes a change to how the work is run.

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 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

Data sources

  1. 1.Your job lifecycle dates, supplements, payments, and documents. Your business.
  2. 2.Your documented SOPs and process scores. Your business.
  3. 3.Anonymized peer stage timing. Verinode network.
  4. 4.IICRC and LEAN reference standards. Verinode Research.

Before you start

Related articles

Was this helpful?